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

71–80 of 284 posts

Re: Shall we fork Debian?

#71

Post by yaantc »

csirac2 wrote: post #57
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…

I'm not even "anti-systemd". I'm actually in the process of implementing systemd for the firmware of an embedded target in $dayjob because socket activation is actually a good idea and happened to work well when I played with it. But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypt…

You can still use a keyscript (I do), it just need to be done in a different way. Instead of putting the configuration in /etc/crypttab, which confuses systemd indeed, you can still use the kernel cryptopts variable. For example, in the grub configuration add something like:

cryptopts=source=/dev/,target=sdc5_crypt,keyscript=/lib/cryptsetup/scripts/passdev,key=/dev/:/somdir/root.key

Anf then in /etc/fstab use the /dev/mapper/ (sdc5_crypt in the example above) as the root device, as before.

Then you need to make sure the initramfs contains all the tools needed to support this (that was done automatically with /etc/crypttab, it's "manual" with the kernel option). To do this, add under /etc/initramfs-tools/hooks a script file to load what's needed in the initramfs: cryptsetup, passdev, the needed kernel module. You can roughly copy the existing /usr/share/initramfs-tools/hooks/cryptroot and simplify it.

I've seen other distro documenting the kernel approach instead of /etc/crypttab for the root filesystem. It may become the standard way in the future, and there's no reason it couldn't be fully automated. There's some coordination between several components so it may take a bit of time to converge to an accepted and supported way thought.

Re: Shall we fork Debian?

#72

Post by pmontra »

I'm a devop, not a system administrator. I setup and administered a number of single machine web services for my customers along the years, almost all of them with Debian plus some Ubuntus recently. Database, application server, web server. Nothing fancy. I also use Ubuntu as my primary desktop (some sort of gnome fallback DE) after I removed a lot of cruft if comes with by default.

From my experience what I need on a desktop is very different from what I need on a server. On a server I don't care about displays, keyboards, backlighting, sound, USB disks, mics, scanners etc. On my desktop they are very important. There are a number of companies offering Linux VPSes with 512 MB RAM and they can be good to host a low traffic web service. Good luck running a modern Linux DE on a 512 MB machine. Not impossibile but not very productive.

So I can imagine having very different init systems for desktops and servers if this means that the server won't be encumbered by a number subsystems which are of no use to it. Furthermore binaries instead of scripts and opaque log files leave a bad taste in my mouth. They make me figure a future with a Windows like event viewer to browse the log files, over a terminal based ssh connection. I'm quite concerned about it. It will waive one of the biggest advantages of a Linux server over a Windows one.

A fork, or an alternative init system, could be a good solution. We should run this experiment, pick what we like and don't harass the people on the other side. We will see the results after some years. The satisfaction of the admins will decree the winner.

Re: Shall we fork Debian?

#73

Post by andor »

TheSwordsman wrote: post #37
buster wrote: post #28

Or just shut up and put your efforts into maintaining https://packages.debian.org/jessie/systemd-shim Also, critique starts with "We like controlling the startup of the system with shell scripts that are readable".. How on earth is a systemd service file less readable then a hundreds of lines bash script? Also relevant: http://www.itwire.com/business-it-news/open-source/65684-deb...

And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script. And don't get me started on binary log files. As was said before, buster, your attitude is the problem. It's the same as the systemd developers and those within the community. SysVInit has served me thus far with no issues.

And if that service file screws up how do you troubleshoot it? You end up diving in to the source code of systemd, versus fixing a bug in your script.

That's a good thing, because if you find a bug, it will be fixed for everybody, not just for your one-off init script.

your attitude is the problem

The attitude here is to fix problems at their source. Instead of using the hammer for everything, sometimes coming up with a new tool is a better idea.

Re: Shall we fork Debian?

#75

Post by therealidiot »

rdc12 wrote: post #67
TheSwordsman wrote: post #45

Earlier quoted context omitted.

As someone who manages a large Debuntu fleet, please don't speak on my behalf. If I had the opportunity to vote for systemd it would have been 'no'.

And you don't speak on behalf of every other sysadmin on the planet either

Isn't this a pointless statement? Nobody does.

Re: Shall we fork Debian?

#76

Post by csirac2 »

cbsmith wrote: post #64
csirac2 wrote: post #57

Earlier quoted context omitted.

I'm not even "anti-systemd". I'm actually in the process of implementing systemd for the firmware of an embedded target in $dayjob because socket activation is actually a good idea and happened to work well when I played with it. But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypt…

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

It's dicey to obtain key material from external hardware because...?

Re: Shall we fork Debian?

#77

Post by srean »

pmontra wrote: post #72

I'm a devop, not a system administrator. I setup and administered a number of single machine web services for my customers along the years, almost all of them with Debian plus some Ubuntus recently. Database, application server, web server. Nothing fancy. I also use Ubuntu as my primary desktop (some sort of gnome fallback DE) after I removed a lot of cruft if comes with by default. From my experience what I need on…

Wish I could upvote this a thousand times.

Re: Shall we fork Debian?

#78

Post by grifferz »

pmontra wrote: post #72

I'm a devop, not a system administrator. I setup and administered a number of single machine web services for my customers along the years, almost all of them with Debian plus some Ubuntus recently. Database, application server, web server. Nothing fancy. I also use Ubuntu as my primary desktop (some sort of gnome fallback DE) after I removed a lot of cruft if comes with by default. From my experience what I need on…

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 to try it before deciding it's something you won't find useful.

Avoiding it looks like it's going to be significant effort and you'd want to know for sure that you're justified in that before embarking on that course of action.

Re: Shall we fork Debian?

#79

Post by csirac2 »

yaantc wrote: post #71
csirac2 wrote: post #57

Earlier quoted context omitted.

I'm not even "anti-systemd". I'm actually in the process of implementing systemd for the firmware of an embedded target in $dayjob because socket activation is actually a good idea and happened to work well when I played with it. But a switch to a different init system shouldn't break your system so badly that it no longer boots. And yet that's what happens if you rely on keyscript to unlock your drives in /etc/crypt…

You can still use a keyscript (I do), it just need to be done in a different way. Instead of putting the configuration in /etc/crypttab, which confuses systemd indeed, you can still use the kernel cryptopts variable. For example, in the grub configuration add something like: cryptopts=source=/dev/ ,target=sdc5_crypt,keyscript=/lib/cryptsetup/scripts/passdev,key=/dev/ :/somdir/root.key Anf then in /etc/fstab use the /…

Thanks, I appreciate the hint, I should have noticed that a kernel parameter would be one way to do it (I'm familiar with writing initramfs-tools/hooks to make the existing keyscripts work).

The fact remains though that a wheezy dist-upgrade is going to ruin your day badly enough to spend some time digging up your iDRAC/whatever creds (admittedly, nobody is going to dist-upgrade their prod servers without testing first... or are they? :P)

Re: Shall we fork Debian?

#80

Post by mseepgood »

atmosx wrote: post #26

If Ritchie and Thompson knew the damage fork-ing would cause to the open source community, they would have never implemented the idea, as a system call in UNIX[1] in 1971. [1] http://cm.bell-labs.com/cm/cs/who/dmr/man21.pdf

I don't think that they care(d) much about "the open source community". And why do you think forking causes damage to the open source community? It helps resolve conflicts of interest.
Post reply on HN