Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd 252

github.com

Post reply on HN
Print view View original

301–310 of 317 posts

Re: Systemd 252

#301

Post by esarbe »

effie wrote: post #299
esarbe wrote: post #288

Earlier quoted context omitted.

systemd ist not an init system and it never was intended to be "just" an init system; from the very start was conceived a system services management layer. https://0pointer.de/blog/projects/systemd.html If there's an expansion of scope in the systemd project, that's because these use-cases were not sufficiently covered in the past. And while I wish you good luck with s6; how do you intend to replace all the functiona…

> these use-cases were not sufficiently covered in the past. Many systems do not have those use cases. Everybody needs an init system, so that's where systemd could have been the fix to the deficiencies of sysvinit (as marketed). Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong. And then instead of fixing and polishing that experience, de…

> Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong.

I have never experienced that kind of errors you describe and I use Linux+GNU on my private workstations, on my professional workstations, on various servers and some NAS devices. Is there a bug report that documents these failures?

> Systemd is becoming a bad OS like Windows is.

Systemd is a system management layer, the operating system is GNU+Linux.

> User sessions and related is really something Desktops should be handling, since it only makes sense on Desktops.

You can disable it, if for some reason you get errors. Never had issues with user sessions on servers either.

Re: Systemd 252

#302

Post by dTal »

squarefoot wrote: post #250
dTal wrote: post #213

Earlier quoted context omitted.

If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux. If you use a computer for actual industrial work , you will hit one of these problems very quickly.

> there's tons of niche hardware that just can't be driven from Linux. Linux developers can often do wonders, but they still do not have a crystal ball. If that hardware is niche+closed+expensive I don't see how they can produce working drivers or software. Manufacturers not releasing documentation are the problem, not Linux, or BSD or any other non supported OS.

>If that hardware is niche+closed+expensive I don't see how they can produce working drivers or software.

Indeed. They can't. Which is why Linux can't drive that stuff.

I fully agree with your assessment of whose fault it is. That wasn't the question.

Re: Systemd 252

#303

Post by dTal »

lrvick wrote: post #232
dTal wrote: post #213

Earlier quoted context omitted.

If only that were true. "Virtually any Windows application" is a fantasy I'm afraid, many important applications run poorly or not at all on Linux. Then there's the "particular attachment to the NT kernel" caused by driver support for $HARDWARE - there's tons of niche hardware that just can't be driven from Linux. If you use a computer for actual industrial work , you will hit one of these problems very quickly.

Can you give an example? Even modern AAA games run as well, and often better, on Linux these days.

Games are the most reliable category of software, the one WINE targets the hardest. Almost every software I try that isn't a game, fails to work in some way.

The worst offenders are "industry standard" software. 3ds Max. Ableton. Photoshop. Altium. MS Office. Visual Studio. Go check WineDB and see how many versions of these are rated "Garbage".

I say again - if you attempt to rely on WINE to do real industrial work on Linux using Windows tools, you are virtually guaranteed to hit a showstopper somewhere almost immediately. It's just not viable.

Re: Systemd 252

#304

Post by lrvick »

traverseda wrote: post #261
lrvick wrote: post #231

Earlier quoted context omitted.

One service per kernel. Hypervisors allow you to run many kernels on the same physical hardware.

Right, so instead of processes you have kernels, and instead of kernels you have hypervisors... So like containers, but heavier weight and you need to pre-allocate ram for every ~~process~~ kernel? It sounds like you've reinvented the multiprocessing operating system.

The Linux kernel is simply not designed to run trusted code and untrusted code at the same time. One service has a bug or a security flaw and everything goes down with it.

The sandboxing is a convoluted mess few even know where to start learning to use. Lets say you successfully configure process namespacing, network namespacing, filesystem namespacing, cgroups, and apparmor or selinux all correctly to restrict every last syscall. You will still get burned by a crash, resource exhaustion, or security breach due to the next of a long series of implementation bugs in each of these arcane features.

Humans cannot create a large codebase of coherent and provably correct C code with memory safety and they really should stop trying.

Hypervisors are the only sandbox that works reasonably well and burning some extra ram is cheaper than most security breaches.

Re: Systemd 252

#305

Post by effie »

esarbe wrote: post #301
effie wrote: post #299

Earlier quoted context omitted.

> these use-cases were not sufficiently covered in the past. Many systems do not have those use cases. Everybody needs an init system, so that's where systemd could have been the fix to the deficiencies of sysvinit (as marketed). Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong. And then instead of fixing and polishing that experience, de…

> Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong. I have never experienced that kind of errors you describe and I use Linux+GNU on my private workstations, on my professional workstations, on various servers and some NAS devices. Is there a bug report that documents these failures? > Systemd is becoming a bad OS like Windows is. Systemd…

> I have never experienced

Good for you.

> Is there a bug report that documents these failures?

I didn't try to document these rare random events. I've learned to expect them, as part of the systemd feature.

But there are such reports, e.g.

https://github.com/systemd/systemd/issues/20920

Re: Systemd 252

#306

Post by tristanbvk »

AnIdiotOnTheNet wrote: post #300
tristanbvk wrote: post #209

Earlier quoted context omitted.

You're not wrong regarding Wine but that may be the ONLY good aspect of Windows on a technical note.

There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc. Don't succumb to fanboyism.

Having a lot of user mode stuff does tickle my fancy, being someone who is very keen on microkernels (despite windows being a hybrid), I can appreciste some of their design choices.

Re: Systemd 252

#307

Post by rainbow29822 »

effie wrote: post #262
rainbow29822 wrote: post #258

Earlier quoted context omitted.

>systemd should be an optional package on all distros. Why? Should glibc also be optional? What about the Linux kernel? What about apt-get? You can technically replace those things but it's a ton of extra work, almost like shipping a completely different distro. At the end of the day, a distro decides what packages it wants to support and what it doesn't. The specific choice of supported packages is often what define…

Why? That is a very good question! Libc and linux kernel are good solutions to well defined problems: a standard C library, and a kernel. They pretty much do what is expected, sometimes they do more, but not by much. Systemd? It is not a good replacement for an init system for the users. Instead, it is an OS functionality accretion for the benefit of distributors, a baroque monstrosity that provides mediocre buggy so…

>Libc and linux kernel are good solutions to well defined problems: a standard C library, and a kernel

That's subjective. I've talked to a lot of Windows users who all say Linux is a terrible solution for them. I don't think most Debian developers feel they should suddenly drop everything and start making Linux exactly like a copy of Windows just to please those people. They voted on this several times, they wanted systemd.

>it is an OS functionality accretion for the benefit of distributors

There's no problem with this. Most users don't touch the init system that much. They interact with it primarily through the package manager installing service files.

>solutions to too many problems that have nothing to do with init

Those are all optional add-ons for users who are having thoes problems.

>It boots nondeterministically (socket activation is not such a universally great idea)

This is also only an option. You don't have to use socket activation. It's there if you want it and you don't need to strictly order services.

>sometimes hangs randomly, it disrespects the user when ignoring keyboard input while waiting 90s or indefinitely for some condition

Not sure what this means or what keyboard input you were pressing. In systemd the keyboard shortcut to force reboot is pressing Ctrl+Alt+Del 7 times: https://www.freedesktop.org/software/systemd/man/systemd-sys...

>or launching zillions of bogus hog processes for every user login event

Not sure what this means either. You can disable those.

Re: Systemd 252

#308

Post by rainbow29822 »

forgotmypw17 wrote: post #275
rainbow29822 wrote: post #258

Earlier quoted context omitted.

>systemd should be an optional package on all distros. Why? Should glibc also be optional? What about the Linux kernel? What about apt-get? You can technically replace those things but it's a ton of extra work, almost like shipping a completely different distro. At the end of the day, a distro decides what packages it wants to support and what it doesn't. The specific choice of supported packages is often what define…

> Should glibc also be optional? What about the Linux kernel? What about apt-get? In my opinion, yes, they should absolutely be optional. Whether or not that is feasible today does not change the advantages of each component of the system being optional and replaceable. It is more failure tolerant both from a purely technical perspective, and also from an organizational perspective.

If you're only talking in hypotheticals then they're already optional and replaceable. Someone just needs to do the work to replace them.

You're missing that these parts have to get replaced for a practical reason. Not just because someone vaguely feels it would be more fault tolerant. For example, think of some other libc that's optimized for a certain hardware. Distros that don't support that hardware would have no reason to ever use that libc. If you say all distros should support it, then your opinion is really "all distros should support this random hardware that might be rare, expensive, highly specialized, hard to develop for, etc" and now that's a much more complex and demanding task you're asking someone to do, for very little benefit.

Re: Systemd 252

#309

Post by rainbow29822 »

effie wrote: post #264
b112 wrote: post #183

Earlier quoted context omitted.

And systemd proponents shouldn't go out of their way to try to prevent non systemd Linux from existing. All the changes to gnome, which depended 100% upon systemd at the time, were pushed by redhat, gnome contributers. This one of the biggest reasons given, for getting systemd into debian at the time. When systemd was being pushed origionally, fast boot times, predictable names, and a few other things were big reason…

But debian has chosen to adopt systemd, so at least some substantial part of Debian developers preferred going with it to keeping the status quo with sysvinit. Maybe they were badly influence by Redhat/Poettering, but it was their call.

Of course they were influenced by the author of programs they use. They were also influenced by Linus Torvalds when they decided to use his kernel. I don't see any problems with this. That's what you do when you make something that you're proud of. You go around to other people and try to convince them to use it.

Re: Systemd 252

#310

Post by rainbow29822 »

b112 wrote: post #220
PoignardAzur wrote: post #192

Earlier quoted context omitted.

> The real problem is that Microsoft has historically tried to destroy linux, and beyond that, has a huge history of FUD and embrace and extinguish. And now they're one of the major backers. All the work is being done in the open, so it's not like there's a nefarious hidden agenda there (an agenda that would have needed to somehow stay dormant for 10+ years). The idea that working for Microsoft is something dirty tha…

Pulseaudio was developed in the open. So was systemd, and many take issue with that. And embrace and extend can exist in OSS models. Microsoft is dirty, and it is dirt they cannot wash off in a mere few years. If they behave correctly for 20 years, as long as they behaved in a literally evil fashion, then maybe they have reformed.

Embrace and extend is a fundamental part of the OSS model. That's what you're supposed to do: pick some OSS, make some custom add-ons to it, then upsell it to your customers. The license encourages everyone to do this. Tons and tons of OSS companies are doing this. Microsoft isn't doing anything out of the ordinary here.

Just a reminder holding grudges isn't good for your mental health.

Post reply on HN