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

Shall we fork Debian?

debianfork.org

Post reply on HN
Print view View original

251–260 of 284 posts

Re: Shall we fork Debian?

#251

Post by Twirrim »

dijit wrote: post #110
0x006A wrote: post #39

Earlier quoted context omitted.

Just curious, have you ever used systemd and ran into a problem where your service file screwed up and you had yo read systemd's source code or are you making this up?

xl2tpd, still doesn't work. I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out. took me some time to figure out it was systemd. the firewall wrapper for iptables gives you an insecure default config and is hard to fix via config management "add a service that means port 3…

> I actually had to try to figure out why, turns out systemd supercedes lsmod/modprobe etc; causing those programs to return 1 when invoked, there's no debug or anything so I was seriously weirded out.

Why on earth does it need to do that?

Re: Shall we fork Debian?

#252

Post by bza »

icebraining wrote: post #186
monochr wrote: post #123

Earlier quoted context omitted.

Different people have different definitions of complexity. For me having a single point of failure is complexity, for most people a centralized single process handling as much as possible is simplicity. Neither is right or wrong.

systemd is not implemented as a single process.

Whether a system is tightly coupled is independent of whether it's implemented as a single process. Objections to systemd as monolithic, as constituting a single point of failure, etc. are based on its being a tightly coupled set of components.

Re: Shall we fork Debian?

#253

Post by LaSombra »

vezzy-fnord wrote: post #196
zanny wrote: post #178

Earlier quoted context omitted.

There needs to be a distinction between Linux distros for us, and Linux distros for everyone else. For us, we care about all that stuff, because we are engrossed in it daily. For everyone else, they will never touch or understand and / or should never need to understand what a kernel, filesystem, sound system, or desktop environment is. To them, the computer is a tool, not an environment, and to use it is to press bu…

To them, the computer is a tool, not an environment, and to use it is to press buttons to get some tangible result you want from it, and the buttons you have are not buttons you are going to know how to change. Your general point is correct, but the analogy you're using is incorrect. It's not tool/environment, but rather, it's tool/appliance. The fundamental cultural shift going on between many anti-systemd and pro-s…

What's the big picture on this case?

Re: Shall we fork Debian?

#254

Post by csirac2 »

XorNot wrote: post #166
csirac2 wrote: post #95

Earlier quoted context omitted.

During boot - before the rootfs is even mounted, what kinds of exposure are you thinking of that's worse than the shell scripts which already make up cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm querying? If I can control the smartcard response, wouldn't I also be able to crash a similarly badly-coded custom C program which does the same?

Conversely a well-coded C program isn't pulling in a huge amount of additional, irrelevant functionality to the task.

Yet it seems installing systemd drags dbus and bunch of other dependencies in with it... tomato, potato.

Re: Shall we fork Debian?

#255

Post by csirac2 »

kolme wrote: post #225
IshKebab wrote: post #135

Earlier quoted context omitted.

I don't think you're wrong. I imagine all these people saying systemd is so awful are just worried that their hard-earned sysvinit knowledge will become obsolete and that new users won't have to go through silly bash scripts (that are totally secure of course - no chance of security vulnerabilities in something as ancient and wtf-free as bash). Instead they'll have something sane like this: [Unit] Description=Apache…

One of the things that boggles my mind is the "single responsibility principle violation" that they're calling. What? Systemd will only handle the starting and stopping of services. How's that doing more than one thing? This seems to me a technically better solution.

Doesn't it do logging? And cron? And login/console? And configure network interfaces? And a bunch of other stuff...

... systemv sucks enough that I'm in the middle of re-working our firmware at work to use systemd instead (I do like socket activation and supervisor stuff), but of all the systemd features one could like, "do one thing and do it well" isn't one of them.

Re: Shall we fork Debian?

#256

Post by asdfaoeu »

thaumaturgy wrote: post #246
IshKebab wrote: post #135

Earlier quoted context omitted.

I don't think you're wrong. I imagine all these people saying systemd is so awful are just worried that their hard-earned sysvinit knowledge will become obsolete and that new users won't have to go through silly bash scripts (that are totally secure of course - no chance of security vulnerabilities in something as ancient and wtf-free as bash). Instead they'll have something sane like this: [Unit] Description=Apache…

At this point I don't really want to touch the systemd argument with a barge pole anymore, but I think it's worth saying that I'm a lot more comfortable with the sysvinit script. After a lot of years of maintaining and editing and writing configuration files for more Linux daemons and applications than I can remember, my least favorite are the ones like the top example, that have a pile of predicates and values. They…

The system script posted is actually a fairly bad example because that one just use apache to manage the process. Where systemd shines is where we don't need specific purpose binaries to manage each service.

    [Unit]
    Description=A network traffic probe similar to the UNIX top command
    Requires=network.target
    ConditionPathExists=/var/lib/ntop/ntop_pw.db
    After=syslog.target network.target
    
    [Service]
    Environment=LANG=C
    ExecStart=/usr/bin/ntop -i eth0 -w 3000
    Type=simple
    StandardError=syslog
    
    [Install]
    WantedBy=multi-user.target
Note the lack of pid files of stop commands etc...

> And here's the best part! If the shell script seems to be broken for some reason, I can debug it! I can stuff some stdout or stderr in there; I can call my own binaries or reference other shell scripts; I can do programmer-y things to it!

systemd captures stdout/stderr and the exit code you rarely need to run it outside of systemd. Most of the time the ExecStart command would do the trick.

> I'm really beginning to think this whole systemd thing is actually a culture war between two different generations of sysadmins. The older, bearded generation wants to stay with the thing that has always worked out for them in the end, and the younger, nicer-smelling generation wants to do something new because they haven't made enough mistakes yet.

Or alternatively they've seen the millions of issues you can get with sysvinit scripts that aren't perfect and decided we can do something better.

Re: Shall we fork Debian?

#257

Post by cbsmith »

simoncion wrote: post #244
cbsmith wrote: post #88

Earlier quoted context omitted.

Shell scrips have issues with race conditions (which is why they aren't setuid) and just generally create a lot of points of exposure.

What? Racy code has issues with race conditions. Any error in setuid executables can be very dangerous, so they are strongly discouraged. However, once you've decided that you have to write a setuid program, there's no particular reason to not write it in a scripting language. As a datapoint, the KDE folks think that using scripting languages for setuid executables is okay: /usr/lib/kde4/libexec/fileshareset: setuid…

Perl goes to great lengths to be secure in the face of setuid.

This isn't even remotely controversial. There is a reason that the setuid bit is ignored for unix shell scripts.

Re: Shall we fork Debian?

#258

Post by cbsmith »

csirac2 wrote: post #95
cbsmith wrote: post #64

Earlier quoted context omitted.

Using shell scripts to do decryption seems dicey at best...

During boot - before the rootfs is even mounted, what kinds of exposure are you thinking of that's worse than the shell scripts which already make up cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm querying? If I can control the smartcard response, wouldn't I also be able to crash a similarly badly-coded custom C program which does the same?

You raise a good point. I hadn't considered a shell based init system where the shell scripts only run at startup and aren't available to run at any other time.

You mentioned smart cards... what system would handle when you connect a smart card after boot?

Re: Shall we fork Debian?

#259

Post by icebraining »

bza wrote: post #252
icebraining wrote: post #186

Earlier quoted context omitted.

systemd is not implemented as a single process.

Whether a system is tightly coupled is independent of whether it's implemented as a single process. Objections to systemd as monolithic, as constituting a single point of failure, etc. are based on its being a tightly coupled set of components.

That systemd is tightly coupled is a valid objection, but "single process" has a specific meaning in this context and it implies a much worse design, with every component potentially taking down PID1. As far as I know, this is not the case in systemd.

Re: Shall we fork Debian?

#260

Post by XorNot »

digi_owl wrote: post #233
CrLf wrote: post #228

Earlier quoted context omitted.

SysV init is brittle only for desktop scenarios, where many things can change between reboots. On servers I've always found it to be very predictable. Once you fix an issue, it usually stays fixed. I haven't ran into many startup race conditions in servers. SysV init has many problems and can be improved upon, but solutions that increase complexity exponentially and are impossible to reason about when problems arise…

How many things can really change between reboots on desktop? That i yank one GPU and install another? VGA is still VGA as a fallback, no? Frankly the only bus i can see being much of a issue on desktop is USB. And that is mostly if you are relying on a ethernet dongle or similar that ended up moving from port 1 to port 2 between boots. Yes, this means your desktop may not get connection until you sort out the new na…

At which point why bother with desktop computing or user customizability or ease of use at all! I mean, who really needed Plug and Play?

Or even multi-user desktops. Or removable storage.

In Linux, everything got a lot better when we added udev - which gave us event driven mounts. And then we wrote a bunch of hacks to make sysV init minimally event driven enough to properly wait for it to finish it's work.

systemd simply dispenses with the fiction that SysV init is in anyway actually suitable for bringing up a modern computer, and replaces it with centralization of what we now know are the actual, useful services pretty much all modern computers need to provide. Even embedded systems are likely to be using network mounted and accessible storage.

Post reply on HN