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

171–180 of 317 posts

Re: Systemd 252

#171

Post by atonse »

TacticalCoder wrote: post #142
lakomen wrote: post #86

Earlier quoted context omitted.

The arrogance of Lennart has something to do with it. The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right. Numerous cases of that. Then the security aspect of a jack of all trades process running as one that controls every other process. Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, readi…

> There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft. I only learned about that a few days ago, here on HN (some thread or some old comment). It is completely insane and gives lots of fuel to the systemd haters. I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff…

> It is completely insane and gives lots of fuel to the systemd haters.

Sorry, what exactly is the issue with a bunch of Linux maintainers working for Microsoft? Is there still some sort of collective adjustment issue with Microsoft being a major backer of Linux now? If the maintainers themselves (people who have dedicated their lives to progressing Linux) are ok with it, why does anyone else have an issue?

And what kind of fuel would it add? That systemd has corporate backers?

Re: Systemd 252

#172

Post by [deleted] »

captainmuon wrote: post #97

About removing support for what they call split-usr and unmerged-usr: Why does a init system and daemon manager even need suppport for a certain directory layout, shouldn't it be agnostic? Having a separate usr-space saved my bacon in the past a couple of times. The thing I dislike most about Systemd is that it leads to homogenisation, where to me, running Linux is about choice.

[deleted]

Re: Systemd 252

#173

Post by jcranmer »

rfmoz wrote: post #148
lakomen wrote: post #86

Earlier quoted context omitted.

The arrogance of Lennart has something to do with it. The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right. Numerous cases of that. Then the security aspect of a jack of all trades process running as one that controls every other process. Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, readi…

About the bugs, the Github have 1.8k issues open. That makes me think, is there a way to know what are the projects with more open issues on Github?

Just some large projects whose bug trackers are on github:

* LLVM: 19,219 open issues

* Rust compiler: 8,580 open issues

* Python: 6,693 open issues

The number of open issues isn't a particularly good indicator of program quality.

Re: Systemd 252

#174

Post by WastingMyTime89 »

teddyh wrote: post #52
erik_seaberg wrote: post #48

Earlier quoted context omitted.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/n... blocks SIGHUP and captures output in a file. That lets me type nohup ./long_batch_job.sh & and walk away, knowing that it will keep running after my shell exits and the controlling terminal is lost. systemd broke that at some point, for no obvious reason. I think there is some nonstandard route to make systemd run something in the background, but end use…

Unix traditionally has never had proper seat and/or session management, with all the chaos this entails. With systemd, they added it. You’re effectively proposing that systemd (or anything else) should never implement session management. The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup comm…

> The most reasonable solution seems to me to be that nohup is instead adapted to do the semantically correct thing and tell systemd in the modern way that it should run the nohup command in a detached session.

That was proposed to nohup when systemd introduced the modification. It’s what nohup does on macOS.

A very productive discussion was happening but then the anti-systemd mob showed up with pitchforks, brigaded the discussion on the bug tracker and made sure nothing good would come out of it.

That’s when I personally decided Linux was a lost cause and definitely switched to macOS.

Re: Systemd 252

#175

Post by tenebrisalietum »

Timja wrote: post #45

I despise systemd. Having shell scripts that you can read and edit makes so much more sense. Putting a script in a directory to have it run at startup makes sense. Systemd's approach of "registering a service" is hell. Having logs in plain text is beautiful. Having to use special software to read logs is hell.

So I think systemd is becoming a tentacle demon upon Linux but "registering a service" is not hell.

- You create a new whatever.service text file with some data=value pairs and put it in /etc/systemd/system. Doing this is at least only 25% as hard as learning bash.

- systemctl daemon-reload

- systemctl start whatever.service

Not hard.

Re: Systemd 252

#176

Post by lotharcable »

gorgoiler wrote: post #65

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend. How long until “Systemd: The Good Parts”? *The most trivial new name would be système which would at least be in keeping with the French naming. **In Debian stable if you create a new user, ssh in as that user, logout, then delete th…

> It feels like the time is ripe for something simpler and more modern to replace* systemd.

Well then do what Poettering did and write it.

It's threads like this why I am eternally grateful that Linux kernel uses a merit driven approach and not concessus driven one.

Re: Systemd 252

#177

Post by fullstop »

lakomen wrote: post #91
Octabrain wrote: post #50

Earlier quoted context omitted.

You can still have your wonderful script but in the case of systemd, you delegate the execution lifecycle of that script to a unit, which, IMHO, is a great abstraction compared to the mess of having to deal with the status of the service from the script itself. You simply throw the unit file into directory, then enable it. Your script does its thing, systemd deals with when to run it, in which runlevel etc About the…

> journalctl is really great too until you're forced to run a rescue system without systemd and try to read logs. And don't say that it doesn't happen, because that situation is 99%.

Surely the answer here is to add tools to the rescue system. You could make the same complaint with systems that use file systems not yet supported in rescue systems, such as zfs, btrfs, etc.

Why would you limit what can be done based on the current abilities of a rescue system?

Re: Systemd 252

#178

Post by WastingMyTime89 »

HNDV wrote: post #74
stevefan1999 wrote: post #73

Earlier quoted context omitted.

But I almost never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora. Without systemd, bootstrapping a complicated desktop environment would be a hot mess. Well, maybe you would say Alpine is not intented to run heavyweight stuff like that and is mostly focused on security and containers. That's exactly what Alpine is, the OpenBSD of Linux distros…

>never saw anyone using Alpine as the infrastructural distro for their, say like desktop environment akin to Manjaro and Fedora Alpine runs musl libc. This makes it buggy with all sorts of software that rely on glibc-isms, that makes it incompatible with proprietary drivers like NVIDIA and make it harder to run proprietary/binary software on the userland. musl is developed by people with that sort of break-everything…

Musl is mostly a good libc.

There are some very unfortunate ideological choice made by its author but they are not the one you quote. The reluctance to give developers a way to detect Musl from C code would be a better exemple. It’s both annoying and counterproductive.

Re: Systemd 252

#179

Post by seszett »

dark-star wrote: post #165
gorgoiler wrote: post #65

It feels like the time is ripe for something simpler and more modern to replace* systemd. The timing of this release coincides with me being bitten with yet another bug** on the weekend. How long until “Systemd: The Good Parts”? *The most trivial new name would be système which would at least be in keeping with the French naming. **In Debian stable if you create a new user, ssh in as that user, logout, then delete th…

Wait, what French naming?

I don't know if it was intended, but "système D" in French means hacking together something with whatever you have available. D meaning "démerde" (literally getting out of shit or a shitty situation) or "débrouille" depending on the language registry you want.

It's a rather common expression.

Re: Systemd 252

#180

Post by lotharcable »

lakomen wrote: post #86
stevefan1999 wrote: post #71

I just never get why people always flame on systemd. Sure, it's kinda bloated in the sense that it is "battery included" just like Python, but the intention to have a stable init with great system and service management is very good from both a DevOps and Sysadmin perspective. It is at least much better than writing your adhoc init.d script that may not guarantee to run on other Linux distros.

The arrogance of Lennart has something to do with it. The way he tends to disregard real bugs as not a bug, since he and his production are perfect and always right. Numerous cases of that. Then the security aspect of a jack of all trades process running as one that controls every other process. Reading logs after a panic and rebooting to check them is a pain in the ass without journald on the chrooting system, readi…

> There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.

Yeah, well... Microsoft is probably soon to be one of the bigger Linux developers out there. As the profit slowly drains out of the desktop their core business model is going to be increasingly dependent on open source and Linux.

Just in case anybody reading this is a big fanboy of Linux... This is what winning feels like.

Post reply on HN