Live data from Hacker News

Shall we fork Debian?

debianfork.org

161–170 of 284 posts

Re: Shall we fork Debian?

#161
post #114
post #86

Earlier quoted context omitted.

Being a developer and being an admin are completely different jobs. A admin needs to know a dozen languages and codes in bash most of the time, they have a hand written folder with glued in scraps next to their terminal which explains why they did what, how and why. This folder has entries like "reboot three times, do an rain dance and run godHelpYou.bash as root" because that's the only way that you've found out how…

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…

And what happens when that single file doesn't work? The one time I had to deploy a custom service using systemd, there was no feedback as to why it wasn't working with service start. No error message, no guidance on how to debug online, no indication of where to look. By contrast adding it to a shell script just worked.

Re: Shall we fork Debian?

#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 truncated logs - which, well guess what, can be handled just as easily as for binary logs.

Given that journald can be configured with a log size of 0, and to output everything straight to syslog, this is such a non-complaint it's absurd. Especially when the hot thing in syslog management is usually to stream everything into a database of some kind to make it easy to search!

EDIT: Oh yeah, and this is assuming you're not compressing your logs. Which you probably are. In which case, they're already a very complicated, very corruptible non-binary format for which you have to use a fairly complicated read app (zcat) to access.

Re: Shall we fork Debian?

#163
post #137

Earlier quoted context omitted.

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…

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?

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.

Re: Shall we fork Debian?

#164

Earlier quoted context omitted.

> A fork, or an alternative init system, could be a good solution. I consider this a good idea. Servers and desktops are two different things so why not have two different Debian versions? This way Debian Server could be kept small and simple while the systemd developers could continue without any restrictions. If they go too far then we could use the Debian server and add our own desktops to it.

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.

Re: Shall we fork Debian?

#165
post #98

Earlier quoted context omitted.

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

Someone disagreeing with you doesn't mean they are stupid, evil and part of a grand conspiracy to destroy everything you love. They just have different priorities. Why is this so hard for people to understand?

Because a lot of people are speaking very authoritatively, yet with little content, about systemd. They raise objections based on partial or inaccurate information. Various bans on discussion are happening precisely because it's apparent that a number of people are no longer interested in useful discussion, so much as creating chaos until they get their way.

Manifestly described by the idea that people without time to interact with Debian, are going to instead launch their own Linux distro.

Re: Shall we fork Debian?

#166
post #95
post #64

Earlier quoted context omitted.

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?

Conversely a well-coded C program isn't pulling in a huge amount of additional, irrelevant functionality to the task.

Re: Shall we fork Debian?

#167
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?

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?

Re: Shall we fork Debian?

#168

Earlier quoted context omitted.

Using the same argument, forking would seem like a horrible idea if there isn't active maintainers. Until I saw that line, I was thinking: well quit talking about doing it, and just do it! The idea of a non-systemd distribution in general is something I've been expecting to pop up for a while. And if the vocal people online represent a real desire not to switch, then one really should exist. Beyond that I'm rather un…

The idea of a non-systemd distribution in general is something I've been expecting to pop up for a while. There's already plenty of them.

[deleted]

Re: Shall we fork Debian?

#170
post #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 constrai…

which phones use systemd?
Post reply on HN