Shall we fork Debian? • Hacker News Board

Re: Shall we fork Debian?

#221

Post by neurobro » Sun, Oct 19, 2014, 5:54 PM UTC

philsnow wrote: post #207

snogglethorpe wrote: post #13

Earlier quoted context omitted.

The anti-systemd-brigade only seems to be a small minority of Debian devs (though they're very loud, and very persistent), so I'm not sure it would have much effect on the project as a whole. If a fork would reduce the time spent arguing about the init system (which 99% of users don't care about), it could even prove beneficial for Debian. [It seems unlikely the fork would attract the critical mass of devs/users to s…

> The anti-systemd-brigade only seems to be a small minority of Debian devs (though they're very loud, and very persistent) The pro-systemd brigade only seems to be a small minority of Debian devs (though they're extremely loud, and trollishly persistent). I've thought for a long time that they must have a place where they all hang out in secret and share links to discussions where they need a pro-systemd response /…

> The pro-systemd brigade only seems to be a small minority of Debian devs (though they're extremely loud, and trollishly persistent).

And generally more convincing, probably due to actually understanding both sides under debate.

Re: Shall we fork Debian?

#222

Post by takeda » Sun, Oct 19, 2014, 5:57 PM UTC

ancarda wrote: post #117

Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking. I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.

I personally like rcNG from FreeBSD (it possibly was borrowed from NetBSD, but I don't know the details).

It is a great compromise between a shell script and a configuration file.

Here is example of a simple use:

http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/bsnmpd?r...

But when you need more control, you still got it:

http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/motd?rev...

Re: Shall we fork Debian?

#223

Post by takeda » Sun, Oct 19, 2014, 6:02 PM UTC

IshKebab wrote: post #135

ancarda wrote: post #117

Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking. I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.

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…

And this is FreeBSD's rcNG which combines the best from both worlds:

http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/inetd?re...

Re: Shall we fork Debian?

#224

Post by gdamjan1 » Sun, Oct 19, 2014, 6:02 PM UTC

progman wrote: post #172

asdfaoeu wrote: post #150

Earlier quoted context omitted.

A lot of the components mentioned are actually optional and you can build systemd without them or disable them at runtime. I'm guessing this idea that this idea that systemd is targeted for the desktop is from the logind kerfuffle with GNOME and friends but it's actually an optional component. If anything though systemd is more targeted towards server market.

Fine. There speaks nothing against Debian Desktop for servers by admins who prefer systemd. I am current happy Debian user myself, and I would use such a system for my desktop. However regarding servers I agree with the Unix veterans that Unix(-like) systems should be faithful to the KISS philosophy which made Unix so great. The IT world has become very complex, and we should not make it more complex than necessary.…

In the total sum, systemd and it's declarative unit files, is more KISS than all the services coming with their own shell scripts, their own log handling, their own daemonization etc.

http://www.freedesktop.org/software/systemd/man/daemon.html

Re: Shall we fork Debian?

#225

Post by kolme » Sun, Oct 19, 2014, 6:25 PM UTC

IshKebab wrote: post #135

ancarda wrote: post #117

Am I the only person who prefers systemd? Maybe because it's the only init system I've managed to get my head around. Other init systems seem so complicated. A config file vs a bash script is far easier and they all seem to require forking. I only use Linux for servers so I may be unaware of a sane init system that works like systemd but isn't systemd. Until something like that appears, I'll stick to systemd.

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.

Re: Shall we fork Debian?

#226

Post by progman » Sun, Oct 19, 2014, 6:32 PM UTC

m45t3r wrote: post #138

grifferz wrote: post #78

Earlier quoted context omitted.

systemd has a number of features which are of interest to server operators, especially those who use containers, which may well be many of us before long. Running systemd as pid 1 does not imply running a desktop environment. I have plenty of VPS customers running systemd as pid 1 in 512MiB RAM. Running systemd as pid 1 doesn't imply having every single binary and subsystem of systemd running. I would encourage you t…

Yep, this is true. The only thing I concluded from this page is "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork". Actually, I find it's funny how anti-systemd people nowadays claim that "systemd is a init for desktop systems" since Gnome adopt something unrelated to the _init_ part…

> "I am an old time Debian admin, I don't want to learn another way to configure my system that is not a bunch of shell scripts, so I am gonna bitch about this decision and create a fork".

Even if this claim were actually true -- what's wrong about that? Why should someone move to a new immature system if his current one works perfectly for him? If an Apache server works perfectly for me why should I invest time and effort to switch to nginx just to get the same thing?

I consider a fork a good idea because it would split Debian development into a safe area of old-fashioned reliable technology, and a testing area of new technologies like systemd. If those new technologies have proven their reliability _then_ the moment has come to think about exchanging old stuff. It is too risky to throw a reliable system overboard and to force all people into an immature new technology.

I wonder what's the problem with the systemd proponents. If other people prefer SystemV why don't they simply let them go?

Re: Shall we fork Debian?

#227

Post by mcosta » Sun, Oct 19, 2014, 6:34 PM UTC

takeda wrote: post #223

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…

And this is FreeBSD's rcNG which combines the best from both worlds: http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/inetd?re...

Nad this is for the power profile:

http://svnweb.freebsd.org/base/releng/10.1/etc/rc.d/power_pr...

so what?

Also: Usage: $0 [0x00|0x01]. That is the real unix way these people is proposing.

Re: Shall we fork Debian?

#228

Post by CrLf » Sun, Oct 19, 2014, 7:17 PM UTC

XorNot wrote: post #175

CrLf wrote: post #81

As much as I dislike the idea of systemd, I'm starting to think it's pointless to fight it. There's still a large chunk of people that think the desktop is important for Linux's future and will keep pushing for turning it into a brittle mess of opaque components, unaware of what's really important to maintain and troubleshoot servers on a daily basis, and unaware of what has made Linux so successful in this area. It…

Since when have init.d scripts been anything but brittle?

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 aren't the solution.

It worries me to see people justifying increased complexity pretenfing it matters for servers. Two examples:

1. I don't care how long my servers take to boot, that doesn't happen very often and when it does, who cares about cutting 30 seconds on the operating system side when the POST itself takes twice as long?

2. I don't care about too much hardware detection magic. Once a server is installed, at most it will get a memory upgrade sometime along the way, and replacement disks coming in and out of it will be transparently handled by the RAID controller. Most often it will just get scrapped in the exact same configuration it had on day one.

The systemd approach is not unlike the Windows approach. I've managed Windows servers for may years and I've also had to deal with at least an order of magnitude more boot issues that with SysV-like init systems.

Re: Shall we fork Debian?

#229

Post by icebraining » Sun, Oct 19, 2014, 7:22 PM UTC

perlpimp wrote: post #209

icebraining wrote: post #191

Earlier quoted context omitted.

I am not sure why debian needs to force replace sysvinit, can't they have systemd-debian distro that will have all the shiny stuff in it? and maybe have it grow and if it won't go down with their userbase then they can discontinue it? Go read the arguments, there are many reasons why they decided to switch. A big part of it is that Gnome/KDE and other upstream software is already dependent on systemd, so keeping SysV…

what does linus say about systemd?

That he doesn't have any strong opinions about it.

Re: Shall we fork Debian?

#230

Post by e12e » Sun, Oct 19, 2014, 7:27 PM UTC

XorNot wrote: post #204

e12e wrote: post #190

Earlier quoted context omitted.

Good points. As for compression: I think most people compress logs post-rotation. So you'll be unlikely to have a corrupted compressed log. Either the file will be compressed, then then original removed, or compression will fail, and the original will remain untouched. It's more of an issue with whatever is written to disk by running processes. As you point out, it's debatable whether or not unicode/ascii vs "binary"…

Exactly my point: this isn't a complex database format. It's a tagged binary format, written in an append only fashion. So you're only going to lose data if the tool decides to write bad data, but that's just as true of a text log format - your logs are useless if all those numbers don't actually relate to the values they claim to. So any tool which can read a journald journal can happily do so until it hits hard cor…

Fair enough. But you still then need to fit an additional tool into your recovery image. As long as it is possible to do with a small static binary that can be expected to be available (say built into a version of busybox) I don't have a great problem with it.