I would like to contribute to the documentation and have a few questions.

• There are a number of open issues in the Github repo for the documentation. If there are no objections, I would suggest beginning with these: evaluating them to see if they are still relevant, closing the ones that are not immediately, and making updates / creating new content for the ones that still are. Who would be the right person to coordinate with, i.e. who is in charge of the documentation?
• The move from UT 16.04 to 20.04 may have rendered some sections of the existing documentation outdated. Will UT 16.04 continue to exist alongside UT 20.04? If so, might it be a good idea to preserve the existing documentation as it is, create a copy, and update the copy / create new content to reflect the current functionality of UT 20.04?

I have solved the problem and will post a detailed guide on how to set up automated Syncevolution sychronization of contacts with Nextcloud (CardDav) using a systemd service and timer in the next few days.

@mrt10001 said in Does Ubuntu Touch actually replace Android or does it somehow run on top of it?:

unless its' Apple or Google, most users are not interested

To be perfectly honest, if the choice were between Apple and Google, I would choose not to have a smartphone at all. I'm absolutely serious about that.

@kristatos said in Few thoughts regarding coming back after several years:

I don't understand why people want to change from iOS/Android to UT but on the other hand still want to use all their services. In my opinion one effort of UT is, that you don't have to use accounts and services from these big companies and still have a functional and free phone in your hand.

I agree. Big Tech surveils you 24/7, exploits your most private data, and tries to control what information you have access to. I am so not down for that. If the only choice was Apple or Android, I would not have a smart phone.

I'm afraid I can't spend any more time on this right now, so I'm going to have to wrap it up: Here are the key points:

• cron is gone in UT 20 and is not coming back
• Anything that relied on cron previously does not work anymore.
• The recommendation I received from a member of UT's core development team is to use systemd timers instead.
• I have tried countless variations and combinations of bash script files and systemd services over the past two days, but I am unable to get a systemd service to sucessfully execute a Syncevolution synchronization.
• I suspect that this has something to do with the requirement to export the DISPLAY and DBUS_SESSION_BUS_ADDRESS variables as well as the user account used to execute the syncevolution command, but I do not have the expertise to solve the problem at this time.

@moem Yay! It works! Thanks!

@arubislander said in Cron not installed?:

That implies the promise or possibility of future work.

As does "outside of the (current) goals of the project and design of the software", I would say. In that case, I would simply state "outside of the goals of the project and design of the software". This leaves no ambiguity regarding possible future work on whatever it is that the user is trying to achieve.

Now we can use that to nail down what the red line is that makes an action "unsupported". If I derive it from the above definition, then I arrive at a red line that is much more stringent than just making your system image writeable. Maybe some procedures/tutorials show you how to do advanced things that don't require making the system image writable. It's irrelevant. If what you're trying to achieve is not within the scope of the goals of the project and design of the software, then it's "unsupported".

@arubislander said in Cron not installed?:

I feel that if you are going to do 'unsupported stuff', it is best to know what you are doing and be willing to do the research if and when it breaks stuff.

And I agree with you.

The vibe that I'm getting is that if something is "supported", or more precisely "within the scope of the goals of the project and design of the software", then if a user tries it and gets in trouble, the likelihood that someone can help is high. On the other hand, if something is "unsupported", or "outside of the goals of the project and design of the software", and a user attempts it and messes things up, then there may not be anyone with the knowledge to help, and, as a consequence, a complete reinstall may be the only solution.

If we can agree on this, I think it is a very good basis for a clear message to users, and it also enables us to unambiguously label tutorials as "supported" or "unsupported".

Thinking further ahead, one thing that we might communicate to users is that if they want to attempt something "unsupported", then they should be aware that they may brick the system and a full re-install may be the only solution, so they should be comfortable with re-installing UT from scratch before they attempt it. What do you think?

@Moem said in How to sign up to telegram on ut?:

Wow, that's suboptimal. It used to be, you only needed a phone that could receive an SMS to verify your phone number. I guess those days are over.

I tried that several times at first, but it never worked. I also contacted support, but they never responded. On the bright side, the process isn't too bad:

1. Insert your SIM card into any Android or iOS phone that has the Telegram app installed
2. If someone else is already logged in on the phone, log them out
3. Create and verify your account on the phone
4. While still logged in on the phone, initiate login process on any Telegram desktop app
5. Use logged in account on phone to verify login attempt from desktop app (QR code, verification code via Telegram message)
6. Log out on the phone, remove your SIM card, put other person's SIM card back in, etc.
7. Done. As long as you always have at least one active, valid session on any device, you can use it to verify other devices and never need the phone again.

I was just browsing the documentation and I found some info on repo2.ubports.com, so I decided to check it out. If you just copy/paste the name of the server (without "https://") you get an unencrypted connection. SSL is enabled, and navigating to https://repo2.ubports.com/ gives you an encrypted connection. I think a permanent redirect http > https might be good.