Live data from Hacker News

Shall we fork Debian?

debianfork.org

91–100 of 284 posts

Re: Shall we fork Debian?

#91
post #9

Earlier quoted context omitted.

You listed two desktop environments, neither of which are of interest to sysadmins. Eg. I run an Openstack cluster and do not care if there are gnome or kde packages available. I don't particularly like systemd and would be happier not having to deal with the compatibility and/or conversion issues for what I perceive as minimal benefit.

The idea of a server based fork of Debian is kind of appealing in some ways, like the Fedora server and cloud projects[1][2] which are quite interesting work, aimed at a (sub)distribution with focus on particular use cases, not the kitchen sink approach. [1] http://fedoraproject.org/wiki/Server/Product_Requirements_Do... [2] https://fedoraproject.org/wiki/Cloud/Cloud_PRD?rd=Cloud_PRD

"The idea of a server based fork of Debian"

I'd be running it on my desktops. All I need is a way to spawn chromium and emacs and consoles (I like konsole, but if it drags in too many dependencies I'll put something else on).

If/When chromium depends on systemd (WTF, a web browser / page renderer logically SHOULD depend on your init system, of course) then I'll use another browser... somehow.

Re: Shall we fork Debian?

#92

Earlier quoted context omitted.

Have you ever used it?

I have. I ran Arch for 3 years, up until 3 months after they implemented systemd. It made a KISS situation incredible complex. I switched back to Debian on my desktop after that. If Debian switches to systemd, I'll switch to Slackware, until SystemD has proven iteself to be stable and simple to administer. Not before.

I other words, you have not used systemd.

Re: Shall we fork Debian?

#93
post #68

Earlier quoted context omitted.

> The issue is that Gnome, KDE, and other software requires systemd. This I can't wrap my head around, why does Gnome for example need systemd? There are standard ways on GNU/Linux to do everything it needs in a unix fashion (by deferring to small specialized tools): shutdown reboot whoami uname mount ... These and similar tools (or libc functions) give you all information you need (username, etc.) and system functio…

Modern DE's also depend on logind. Which could be replaced with non systemd implementation that has same interface on dbus.

To give people some idea of how practical a non-systemd implementation of logind's dbus API is, here's the documentation for it: http://www.freedesktop.org/wiki/Software/systemd/logind/

It's big, gnarly, essentially undocumented, and contains a bunch of features to support tricky cases like multiseat machines (systems with two or more sets of keyboard, mouse and monitor, each with a different user) that are rarely used but still need to be supported because the API's designed around them. Even the systemd developers don't think a reimplementation is feasible.

Re: Shall we fork Debian?

#95
post #64
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...

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?

Re: Shall we fork Debian?

#96
post #61
post #47

Earlier quoted context omitted.

Lennart Poettering is a bully himself, with a well-documented instance where he continuously interruped a talk at the 27th Chaos Communication Congress, even going as far as taking over the stage while insulting the presenter. Lennart Poettering is a toxic person, toxic to the OSS community, and he's the last person that can complain about bullying.

https://www.youtube.com/watch?v=ZTdUmlGxVo0 This is the talk you mean right? Have you actually seen the talk? Yes, Lennart interrupts the talk but everything he says is correct, while the presenter just spreads random FUD. The presenter clearly shows that he doesn’t understand most of the stuff he talks about, talks about 3 year old bugs that already got fixed, etc. Yes, it’s not the nicest way to interrupt a talk, b…

The way Lennart interacted with the speaker during that talk was extremely inappropriate. If he had corrections to make he could have arranged a short talk afterwards or a written blog post. It is very poor form to be so disruptive to a speaker, no matter how much you disagree with them.

Re: Shall we fork Debian?

#97
post #92

Earlier quoted context omitted.

I have. I ran Arch for 3 years, up until 3 months after they implemented systemd. It made a KISS situation incredible complex. I switched back to Debian on my desktop after that. If Debian switches to systemd, I'll switch to Slackware, until SystemD has proven iteself to be stable and simple to administer. Not before.

I other words, you have not used systemd.

In the same words, mverwijs ran systemd for 3 months.

Re: Shall we fork Debian?

#98
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…

You're spreading FUD.

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.

systemd is about choice ;-) Only use the subsystems that you need. For example, if you'd want to save some memory and time, you could use systemd-networkd instead of shell scripts and dhclient.

systemd is used in constrained environments like phones and embedded systems because it's fast and solves problems (e.g. watchdog chaining).

Re: Shall we fork Debian?

#99
post #51
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...

The next step in troubleshooting that one is to run strace and find out what's happening. I agree it's frustrating but if no one debugs these things, problems won't get solved. (and yes, scorching the earth and installing a different distro is a valid solution to the problem at hand)

Re: Shall we fork Debian?

#100

Earlier quoted context omitted.

CoreOS is entirely based on systemd. Fleet is a distributed systemd. It is far more systemd oriented than any other distro, having built it in as a core feature form day one.

Which makes using any useful features of the project impossible.

How? CoreOS has very defined goals of what it does and doesn't do. What have you been prevented from using?
Post reply on HN