Comment by lmm | Hacker News Reader

Comment by lmm | Hacker News Reader

Parent Full thread

> I wish all software would auto-update silently in the background -- when's the last time you even thought about upgrading Chrome?

Updating everything has always been one click in Ubuntu (and I'm sure there's an option to have it go automatically).

> The author of this article claims it's too difficult to find Flatpak apps and that the Ubuntu software center prioritizes Snaps over .deb. Are platforms never allowed to migrate to a new standard? Why is it Canonical's fault that authors of individual applications have yet to migrate Snaps?

Churn is bad, and having to migrate your application is burdensome. Maybe the benefits justify it, but what are those benefits supposed to be?

> Maybe I'm just naive and not doing advanced super user stuff these Snap haters are doing but from a distance to me this resembles the systemd vs init controversy. One which, IMHO, Linux super users seemed unusually attached to an older standard for not always clear reasons. Snaps offer real benefits: maybe instead of complaining that 'this sucks' users could offer constructive criticism about how to improve the new standard.

I hate systemd because it breaks a bunch of stuff but I'm still forced to use it. So far that's been my experiences of snap as well (specifically it breaks Japanese input for some applications).

What are those "real benefits"? You've only talked about auto-update, which was already working fine thank you very much. Snap, like systemd, seems to be more a case of https://www.jwz.org/doc/cadt.html than something that actually makes my system better.

This is getting OT, but could you elaborate on your issues with systemd? I’m genuinely curious. I often see people complain but haven’t seen or experienced specifics apart from it being complex and having higher learning curve than initd.

(I don’t know if you’ve tried MX Linux BTW; Debian derivative without systemd by default)

I will never defend pulseaudio though, that’s a horrible mess.

Systemd gives you less control. I used to pipe stderr to email, cant do that with sustemd. The journaling system is very slow compared to plain text files. Systemd overwrite mounts made by ip netns. Network settings is complicated with systemd. Not all bad though, setting up services is easy, and it has never failed to start a service for me so far, and it do start services in the correct order, which is all it should do imho.

Can't you just wrap your service? Something along the lines of

> ExecStart=/bin/sh -c "/usr/bin/foo > /var/foo/bar 2>&1"

As for networking, it's not like you have to buy in to systemd-networkd, systemd-resolved et al - or am I missing something?

What I've definitely had issues with is the way networking services are configured in recent releases of Debian, but that's mostly from several of the network subsystems being in different degrees of weird limbo with "the new way" and "the old" interfering with each other. For example how resolv.conf is managed. And the whole back-and-forth with network names. Come to think of it, it's a bit reminiscent of snap/deb in Ubuntu 20.04 ;)

My first experience with systemd was when they implemented a default that would kill processes when a user logs off. This may be acceptable in some single-user desktop environments, but it is absolutely unacceptable in any server environment. If I am using tmux, emacs --daemon, nohup, or any other custom program that catches SIGHUP, then it is inexcusable for systemd to escalate to sending SIGKILL.

I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon.

I know that this default setting can be overridden at the distribution level, or at the system level. This doesn't matter, because it shows that systemd developers do not know how to choose appropriate defaults, and that any changes that are made in systemd need to be continually monitored for stupidity.

Maybe this is just me being soured by a very poor first impression of systemd, but I haven't seen anything since to dissuade me from this impression.

> ... they implemented a default that would kill processes when a user logs off

Is that still the default? That’s horrific.

It doesn’t seem to do that on my Ubuntu 18.04 / 20.04 servers; I haven’t tried on desktop though as I don’t use Ubuntu there, would indeed be a huge violation of my expectations of how a system should work if so.

Most distributions have taken the sane route and changed this option at the distribution level. The point is more that any decisions systemd makes may be absolutely nuts, and need to be audited in detail by anybody choosing to use systemd. It is extra work that should never have been necessary, because systemd is untrustworthy.

As of this thread [1] in January 2019, yes. The user poettering is Lennart Poettering, the original Creator and lead developer of systemd, and doesn't show any signs of coming to the light.

At this point, my standard .bashrc includes a check of whether systemd is running, and whether this absurd setting is set, so at least I will get some warning, and can either fix it or complain to the sysadmin.

[1] https://news.ycombinator.com/item?id=19023232

I've had systems become unbootable, services not start, that sort of thing. All perfectly understandable bugs that have been fixed, I'm sure, but fundamentally my experience is that it's this intrusive thing that I never asked for that's broken a bunch of stuff that was working fine before.

I like the init system (admittedly, I have not been using Linux long enough to remember a time before systemd), but components like networkd and resolved are a pain to work with in general. I've had the networkd DHCP client fail in situations that dhcpcd and dhclient handled with grace. It is not clear to me what benefit said systemd components provide over the more traditional solutions.

The promise is that providers can build one package for all Linux distros, Afaik. Less work for packagers. More packages for obscure distros.

"Less work" undersells it, in my opinion. What snap (and things like it) do is promise to remove the support headache upstream providers get from users still using a version that was current 5 years ago which happened to make it into an LTS distro release because that happened to be the most recent build a packager had working at the time.

Love it when vendors shift their responsibilities onto users. Silently updating some piece of software on that 5-year-old LTS release might break the workflows of hundreds of people. But it's all good! It saves the vendor some "support headaches".

> Updating everything has always been one click in Ubuntu (and I'm sure there's an option to have it go automatically).

And what percentage of users do that? From your experience in software in general how much of the general population manually updates their software? It's almost always a low number and that creates problems. A different set of problems than new updates that cause bugs, but IMHO worse ones.

> Maybe the benefits justify it, but what are those benefits supposed to be?

Security, compatibility, uniformity. Not having to support 18 different versions.

> I hate systemd because it breaks a bunch of stuff but I'm still forced to use it.

Exactly what stuff does it break? And are those things more important than the benefits of systemd?

The auto update because users can't make the decision themselves is just copying windows 10 model.

Do applications break after auto-updates? of course they do and that is something that is important to ubuntu users because they have to manually fix. Given the choice I would rather choose when to upgrade so I could set aside time for fixes.

Ubuntu users are not windows 10 users. Why treat them in the same way?

Auto updates have existed long before Windows 10.

It's great that you are diligent about updating your software regularly. But how many people do? If you agree that it's a low percentage, then why is not better for the ecosystem as a whole to improve security and compatibility?

If you're making up percentages of people who update when they see an icon and a message telling them updates are available, asking other people to make up their own numbers, then deciding that we should make decisions based on these made-up numbers, I think you're on the wrong track.

How often Ubuntu users who turn auto-update off manually update themselves is an actual thing that can be researched. It's disappointing how many developers just think you should assume the worst based on your imagination and ego, then justify taking away control from users whenever one can get away with it as a safety measure.

I'm "making up" numbers? What would you call this? https://theconversation.com/the-petya-ransomware-attack-show...

This percentage seems to be the crux of your argument so I'm curious to know what it is. Are you relying on any data?

Pretty simple Google search: https://theconversation.com/the-petya-ransomware-attack-show...

Many more examples.

Reply on news.ycombinator.com