Bash
Not because it’s the best or even my favourite. Just because I create so many ephemeral VMs and containers that code switching isn’t worth it for me.
Bash
Not because it’s the best or even my favourite. Just because I create so many ephemeral VMs and containers that code switching isn’t worth it for me.
Yeah that’s solidly it. I use strictly confined CLI snaps all the time. (In fact, I maintain the snaps for a couple of CLI apps.) They work fine as long as the snap has the right plugs.
But I don’t want to have to run flatpak run dev.htop.htop
to get to htop.
Sorry, but I have no tolerance for intolerance /s
I’ve got a desktop that got a dirty install of KDE Neon when the repositories first got put up (before there were isos). Been in-place upgrading it ever since.
Kubuntu works well on mine. A friend has Lubuntu on his.
You could build some additional sidings
Some distro that uses the Ubuntu repos blocked users from even installing snapd manually without jumping through a bunch of manual hoops. It’s one thing to not preinstall it, but that reeked to me of exactly the “we know better than our users” attitude they were accusing Canonical of.
Some distro that uses the Ubuntu repos blocked users from even installing snapd manually without jumping through a bunch of manual hoops. It’s one thing to not preinstall it, but that reeked to me of exactly the “we know better than our users” attitude they were accusing Canonical of.
How about the maintainers blocking a package that’s included in the default repository for ideological reasons?
The problem isn’t that every gnome dev is bad - not by a long shot. The problem is that there are just enough gnome devs in just the right (wrong?) positions who have an “our way or the highway” philosophy that it causes problems not just for people trying to use GNOME, but for people (such as the Kate developers) who are trying to give their users a good experience.
And by being the default in so many distros, GNOME has enough clout that if they choose to abandon a standard, many people will change to whatever GNOME does, making their applications worse for people on other desktops.
In the end it’s not too dissimilar to the problems created by the dominance of Chromium and Windows. The biggest difference IMO is that Google are actually more conciliatory towards others than the GNOME team are in many cases. Which is kinda crazy given how much Google can throw their weight around on the web.
As long as you have polkit setup to work in terminal sessions, yes. This is pretty standard these days, though not particularly widely used.
Kinda feels like writing a script that implements the sudo
CLI but calls pkexec
would be an easier way to do it. Given that so many systems already come with both sudo
and pkexec
, do we really need yet another option?
I’m not on the systemd hate train by any means, but I don’t understand how this is any improvement over pkexec
…is pkexec
not good enough already as a polkit based sudo replacement? Why would one need to systemd-ify that?
If people are frequently crossing between crosswalks, there probably aren’t enough crosswalks. If they’re pressing the buttons but crossing before the light changes, even if the buttons do cause the lights to change eventually they’re probably set up incorrectly and make wait times too long.
It took me 18 months of back and forth with my city to get them to fix a particular light. The beg buttons technically worked, but the light is where a major street intersects with a residential street, and all the beg buttons would do initially was make the pedestrian lights turn green the next time the lights changed. Problem was, if it didn’t detect a car there it would never trigger a change. What finally got it fixed was me sending the city council an 8 minute video of me waiting for the light to change before a car came along.
All words are made up
For all the crap Canonical gets about snaps, these are kinda trivial with snapd. snap download
will download a snap and its related assertion, you can install unsigned snaps with --dangerous
, and you can add trusted certificates to snapd with a single command.
The packages in most distros will also restart the server for you. Any existing SSH sessions will technically be running in vulnerable versions, but if I’m understanding the vulnerability correctly this isn’t a problem, as they won’t be trying to authenticate a user.
If you want to be sure, you can manually restart the ssh server yourself. On most distros
sudo systemctl restart sshd
should do it.