Wait you thought that meme was factual? 🫨 Even OP themselves said in that thread it was a joke he made to troll Canonical haters. !linuxmemes@lemmy.world is rarely factual.
Wait you thought that meme was factual? 🫨 Even OP themselves said in that thread it was a joke he made to troll Canonical haters. !linuxmemes@lemmy.world is rarely factual.
This sounds plausible. I have seen a few guides for headless use suggesting disabling the built-in remote desktop feature and setting up xrdp, xvnc or related and then trying to fixup that session.
My guess is that something related to the headless setup you had changed during upgrade - likely some package got obsoleted and removed. Then you got some default behaviour from the replacement package along with the rest of the setup.
If you don’t get the help needed to resolve this here, you should also post in askubuntu.com.
Get out with this noise. This is the same nonsense as “just install Linux” to a person with a Windows problem.
Ignore the noise and go with Ubuntu LTS. When you get comfortable with that, you could try Debian.
You could play it backwards too. Try Debian, if you can’t get it to do what you want, wipe and do Ubuntu LTS. But I do not recommend this path if you have no idea what you’re doing. People underestimate how difficult it is to do simple things when you don’t know how to, no matter how trivial.
Well I don’t know what OP is planning to use it as, but desktop VLC can cast to Chromecast on the LAN for example.
I don’t think you can. On the other hand, if you register a Google account, use a secondary user on your phone to login, install the app and activate the Chromecast, I think you can subsequently use it without the Google account. Delete the secondary user once you’re done with the setup. You wouldn’t have given Google any useful data and you’d have cost them some.
Not necessarily. For all of these cases, Debian, Ubuntu, Pro, the community and Canonical are package maintainers. Implementing patches means means one of: grabbing a patch from upstream and applying it to a package (least work, no upstream contribution); deriving a patch for the package from the latest upstream source (more work, no upstream contribution); creating a fix that doesn’t exist upstream and applying it to the package (most work, possible upstream contribution). I don’t know what their internal process is for this last case but I imagine they publish fixes. I’ve definitely seen Canonical upstreaming bug fixes in GNOME, because that’s where I have been paying attention to at some point in time. If you consider submitting such patches upstream as actively involved in project development, then they are actively involved. I probably wouldn’t consider that active involvement just like I don’t consider myself actively involved when I submit a bug fix to some project.
Exactly. In Debian, the community implements security patches. In Ubuntu, Canonical implements security patches for a part of the repo (main), the community implements them for the remainder (universe). This has been the standard since Ubuntu’s inception. With Ubuntu Pro, Canonical implements security patches for the whole repo (main and universe).
10 years security updates, plus security patches for community packages (instead of waiting on community patches). It’s basically the corporate support plan provided for free for up to 5 machines per account.
💥 Free for up to 5 machines 💣
I activate Ubuntu Pro
Fine. I’m gonna go give them more money.
I mean I give my money to Valve as is tradition, but is there some new reason to give from today?
You could try finding changed config files by running:
Note that this won’t catch all. There are files that packages install and don’t touch afterwards. I my case for example it does catch that
/etc/gdm3/custom.conf
was modified to enable autologin among other things.