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

271–280 of 284 posts

Re: Shall we fork Debian?

#271

Post by spb »

csirac2 wrote: post #51
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...

I dare you to tell my why lxc-docker silently fails to start at boot in jessie. Without a single shred of clue in any log, no matter what logging options are turned up - at least with a shell script I can add some echo/exit/touch etc. statements to convince myself it's at least being noticed at startup: https://groups.google.com/forum/#!topic/docker-user/bg5-hlmR...

Without doing any further investigation: does the type of service you're setting in your user file match the way you're starting up the daemon? For a "normal" service, you need to start the service as "normal" and have it run without forking / exiting (as systemd handles daemonization).

If you start a "normal" service using a command that double-forks and immediately exits (like a `--daemon` flag), systemd will see that the process has exited to mean that the service has finished, and will terminate any of its child processes (as you want runaway dependencies culled when a service crashes). This sounds like the behavior you describe.

Re: Shall we fork Debian?

#272

Post by spb »

chias wrote: post #219

Please fork Debian. I find it very difficult to get behind a movement whose primary complains are that the status quo is "a slap in the face to the _____ philosophy" and "betrays the _____ philosophy" and so on. If you want to sway me, you have to tell me why your way is better. The alternative is "offensive" to you? I cannot begin to describe how much I don't care. You can tell a lot about a movement by those they s…

> It read like it was asking people to pressure Debian to follow the authors' agendas, with a threat (?) of making a fork if it didn't.

This. The point of this site seems to be the author begging Debian not to make him fork, because that would be such an imposition on him. It's the same threat as a child threatening to run away from home (except that parents have a reason to care about their child's life).

Re: Shall we fork Debian?

#273

Post by spb »

mcosta wrote: post #234
rodgerd wrote: post #217

Earlier quoted context omitted.

> C is very insecure for daemon coding with all other options why no use go for example? What's sysvinit written in? What are bash and dash written in? What are coreutils written in?

What the kernels are written in?

What is everything that isn't C written in?

(inb4 someone says "assembly/ELF")

Re: Shall we fork Debian?

#274

Post by cbsmith »

csirac2 wrote: post #262
cbsmith wrote: post #258

Earlier quoted context omitted.

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?

The trigger is the appearance of the volume. If the mounter actions crypttab properly it'll run the keyscript which challenges the smartcard or TPM or USB crypt token or some combination thereof, which in turn provides the response to cryptsetup. By default nothing happens when you insert a smartcard; if the keyscript tries to run without the smartcard it will retry, timeout, and eventually fall back to askpass. If t…

> The trigger is the appearance of the volume.

I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc.

Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens).

Now handle the case where you have a bad connection so it is constantly flapping as inserted & not.

Now handle the case where it gets ripped out with no warning.

Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...

Re: Shall we fork Debian?

#275

Post by cbsmith »

csirac2 wrote: post #254
XorNot wrote: post #166

Earlier quoted context omitted.

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.

dbus was already there. How do you think udev works?

Re: Shall we fork Debian?

#276

Post by digi_owl »

Twirrim wrote: post #250
pas wrote: post #216

Earlier quoted context omitted.

You can strace pid1 too. If start-via-systemd doesn't work, hack around it with a script and report it as a bug or write to the mailing list.

you're seriously suggesting strace as an acceptable form of troubleshooting? Don't get me wrong, I love to bring out strace and will use it to solve all sorts of problems, but it really shouldn't be necessary use it near the start of troubleshooting.

I guess that is what is meant by Systemd being for developers...

Re: Shall we fork Debian?

#277

Post by digi_owl »

mateuszf wrote: post #240
progman wrote: post #226

Earlier quoted context omitted.

> "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…

> If other people prefer SystemV why don't they simply let them go? You are free to fork Debian and modify it as you wish.

Compare that mentality to trying to get a big new subsystem into the kernel.

Torvalds is likely to require you to hammer out all the details and debugging in a separate tree. This even more so if it is replacing a tested, stable and maintained subsystem.

As such, it is the Systemd proponents that should be doing a fork. And run it alongside stable for a time to demonstrate that it works. Then people can move over at their own pace.

Re: Shall we fork Debian?

#278

Post by digi_owl »

XorNot wrote: post #164
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.

This. SystemD means you can boot the system without needing a shell installed at all which is what Debian has been proposing moving towards for a very minimal server image.

Ok, somebody has clearly jumped the shark!

Re: Shall we fork Debian?

#279

Post by digi_owl »

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…

Looks to me like all Systemd does it move the logic from the init file itself and into a binary blob inside init.

And that blob is going to be harder to debug, never mind fix, on a production system. While your manager is breathing down your neck about getting it back up ASAP.

Re: Shall we fork Debian?

#280

Post by EmanueleAina »

cbsmith wrote: post #275
csirac2 wrote: post #254

Earlier quoted context omitted.

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

dbus was already there. How do you think udev works?

To be fair, udev communicates over netlink. :)

Only in the future it may use kdbus for some purposes (eg. uploading firmware blobs), but this will only affect internal interfaces.

On the other hand, systemd does not require the D-Bus daemon when you're launching systemctl it as root, the D-Bus daemon is only needed to route the call when used by unprivileged users. When used as root, systemctl connects to the PID1 socket directly and D-Bus is basically just a serialization protocol (and systemd does not depend on libdbus either).

Post reply on HN