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…
Shall we fork Debian?
161–170 of 284 posts
Re: Shall we fork Debian?
#162I'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…
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?
#163Earlier 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?
Re: Shall we fork Debian?
#164Earlier 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.
Re: Shall we fork Debian?
#165Earlier 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?
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?
#166Earlier 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?
Re: Shall we fork Debian?
#167Earlier 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.
P.S. What happens for packages in Debian for FreeBSD and Hurd where systemd isn't available?
Re: Shall we fork Debian?
#168Earlier 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.
Re: Shall we fork Debian?
#169Re: Shall we fork Debian?
#170I'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…