Live data from Hacker News

Shall we fork Debian?

debianfork.org

181–190 of 284 posts

Re: Shall we fork Debian?

#181
post #175
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?

Forever, till this very day and presumably forever more.

If there’s anything this debate shows me, it’s that people have VERY different experiences with SysV init.

Re: Shall we fork Debian?

#182
post #178
post #137

Earlier quoted context omitted.

Nobody said you had to futz with it. Ideally packages would ship with the correct init scripts and things would work exactly as you expect them to, or as they did. Unlike with systemd. Why the hell would you have a choice in kernels? Why the hell would you have a choice in filesystems? Why the hell would you have a choice in sound systems? Why the hell would you have a choice in desktop environments?

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…

There might or might not have to be a division between distros - personally, I think you can serve both demographics by having choice and good defaults - but I don't think Debian has ever been the distro for the "inner workings don't matter" crowd. That's why Ubuntu was made.

Re: Shall we fork Debian?

#183
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.

I'm in a similar position with regard to those (or any) desktop features not being relevant for most of the systems I administer. I'm kind of irritated about having to learn a whole set of new things. I do recognise that there are some benefits for my use case in systemd. The desktop stuff aren't the only things that systemd brings. More than that though, is the fact that it's going to be the new default everywhere.…

I am almost the same as you except:

1) No desktop features are of any interest to me.

2) My position is between "that sucks" and "ambivalent"

But I do think that going with the flow is a much easier way. This isn’t a fight worth fighting if your concern is maintaining running systems. Of course it might be worth while to stay on an LTS release till the very last moment, to let all the bugs shake out.

Re: Shall we fork Debian?

#184

From the source: ..... > Why don't you do that [i.e. vote against systemd] yourselves? > > We are excluded from voting on the issue: only few of us > have the time and patience to interact with Debian on a > voluntary basis. ..... In that case, you don't have the time and patience to operate and maintain a worthwhile and ongoing Debian fork. In that case, there is no substance to the "question" you're raising, becaus…

Only a Debian Developer can vote on a General Resolution. The process for becoming a DD can take, and I am not joking, years. See the actual stats here: https://nm.debian.org/public/stats/

The process is oriented towards supporting the development and maintenance of packages in Debian, which is probably as it should be, but it means that the viewpoints of people who actually use Debian -- and the vast majority of these are systems administrators with hundreds to tens of thousands of machines in their datacenters -- are not part of the organization.

Many decisions are based on the results of people installing the popcon package -- it's a popularity contest that sends the list of installed packages back to debian.org, and for that reason it systematically overcounts individual desktops and systematically undercounts servers in places which have even the vaguest notion of a security policy.

Re: Shall we fork Debian?

#186
post #114

Earlier quoted context omitted.

For people like this "do one thing and do it well" is the only way that you can beat the impossible complexity of a modern machine back into a running computer even some of the time. When you have a single point of failure which is a black box you're just back to windows land: restart the service, reboot the computer, reinstall the system. For the developers, on the other hand, it might mean that some use case that i…

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.

Re: Shall we fork Debian?

#187
post #167

Earlier quoted context omitted.

To clarify: why would you want a choice in init systems in a single distro? To me, a distro is a package manager+packages and an init system. You add a different init system, you have a different distro. Everything else is modular, but the init system is something that is at the very core of the OS. This is why most distros support multiple kernels, file systems, etc. but only one init system.

Debian lets choose between the Linux, FreeBSD, and Hurd kernels, but choosing an init system is too much? P.S. What happens for packages in Debian for FreeBSD and Hurd where systemd isn't available?

> Debian lets choose between the Linux, FreeBSD, and Hurd kernels, but choosing an init system is too much?

Unless you actually want to use one of these kernels that are not Linux. Hurd has nerver made it into a stable release and kFreeBSD is on the verge of being dropped as well.

There is only so much manpower and supporting every possible init system on every possible architecture on every possible kernel is getting out of hand.

Re: Shall we fork Debian?

#188

From the source: ..... > Why don't you do that [i.e. vote against systemd] yourselves? > > We are excluded from voting on the issue: only few of us > have the time and patience to interact with Debian on a > voluntary basis. ..... In that case, you don't have the time and patience to operate and maintain a worthwhile and ongoing Debian fork. In that case, there is no substance to the "question" you're raising, becaus…

I came here to say exactly that. "We don't have time to work with the Debian folks on a solution, but have time to create our own distro." Right. Then again, they should go for it. If nobody but them uses it, that's that. If it gains traction, cool. On another point: why the hell would you have a choice in init systems? As a user of the OS, I care that the proceses start, stop, and keep running. I don't care how. A p…

Because when you're a sysadmin, you often have to write init scripts for the software you have to run.

Typically, you run servers for a company, the developers wrote a web application and the whole point of the server is to serve that app. You need init scripts to start, stop monitor this app. The choice of init system makes a big difference in your daily life.

Re: Shall we fork Debian?

#189
post #138

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…

Actually, systemd is pretty awesome for servers. I wrote a simple program that outputs to stdout and ran it under systemd.

  * it automatically cares about starting it
  * it automatically puts the programs stdout into the journal (from which I can filter the output of my specific program without having to syslog() everything)
  * it allows me to run the program as user with one line in the INI unit file
  * it allows to make the users home directory read-only (or even inaccessible), so in case someone takes over, there is only so much they can break
  * it can create a private /tmp for my program
Actually, for desktops I don't care but for servers systemd is pretty awesome.

Re: Shall we fork Debian?

#190
post #162
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…

Your log files are binary already. What do you think 'cat' is, other then a binary log reader? Binary log files are as easy to read as ASCII with the right translator. Tagged binary formats are easily and trivially self-describing, and as resistant to corruption as ASCII. The problem is, people think they'll be able to understand corrupt ASCII logs, but in reality basically never deal with them. They deal with trunca…

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" is a sensible distinction ... I'd say taking a hex-editor to a mangled but mostly ascii text file is easier than some (any) binary format, but perhaps you know of some easy-to-use tool that will take a file-description and give you back data? Things like figuring out integer encoding and offset for timestamps across different files etc... is much easier with a rather redundant ascii timestamp than some binary number?

If your filesytem eats your files... well then that's a different problem.

Post reply on HN