Welcome to Friendica.Eskimo.Com

Home of Censorship Free Hosting

 Eskimo North Linux Shells, E-mail, Virtual Machines, Web Hosting.

E-mail, Web Hosting, Linux Shell Accounts terminal or full remote desktops.

Sign Up For A Free Trial Here

Please tell your friends about federated social media site that speaks several fediverse protocols thus serving as a hub uniting them, hubzilla.eskimo.com, also check out friendica.eskimo.com, federated macroblogging social media site, mastodon.eskimo.com a federated microblogging site, and yacy.eskimo.com an uncensored federated search engine. All Free!

friendica - Link to source

The tragedy of systemd


A very nice talk. If you still harbour resentment or dislike towards systemd, maybe take the time to watch this and consider the arguments.

inb4: "againts the UNIX philosophy" - you do know GNU literally means "GNU's Not UNIX", right? That's not just a cute name, and it actually guided design decisions and meant incompatible changes, e.g. --long format command parameters. See also: POSIX_ME_HARDER.

youtu.be/o_AIw9bGogo

#gnu #linux #software #freesoftware #systemd #change #evolution #video #flamewars

Roland Häder🇩🇪 doesn't like this.

reshared this

in reply to jec&

friendica - Link to source

jec&

@randygalbraith we are not in 1970 anymore. Computers today are completely differents beasts than once upon a time. Not only that but computer science has evolved and changed pretty dramatically. It's been FIFTY YEARS. When people think that a few dozen shell scripts are enough to manage a modern OS is an illusion, and a reactionary attitude.

I should btw clarify I'm not some capricious zoomer that simply wants glossy GUIs. I've been working as a sysadmin for 20 years and I wouldn't ever want to go back to pre-systemd times. systemd is about so much more than just "quicker boot times". The service management is so solid and powerful that the idea of using classic init would feel like having to write on stone tables or something

in reply to jec&

friendica (DFRN) - Link to source

Roland Häder🇩🇪

@jec @randygalbraith I get your point that Earth has continued rotating and that computers are WAY more complex, still they follow a simple principle. In German language it is #EVA (Eingabe-Verarbeitung-Ausgabe) which is Input-Processing-Output. The more important question here is, why do we have to over-complicate things e.g. in bootstrapping? Why these over-complicating dependencies? Why not make it simple? Do these folks at #systemd never heard about #KISS ? #sysvinit is hands-down simple: You have a few shell scripts with symbolic links (and priority in their names, like S10-mount) for each run-level and then configuration files in /etc/ and finish you are. Stripped-down simple and robust. Always known where to look when something got broken.
Unknown parent

friendica (DFRN) - Link to source

Nanook

@randygalbraith @David Craig There are aspects of systemd I like, the way you can specify dependencies in start-up order and parallelizing those dependencies as much as possible, but beyond that it has been a tremendous buggy pain in the ass. I don't like it's taking over DNS resolution, time keeping, among other things. It started out a good idea poorly implemented and turned into an octopus poorly implemented.
Unknown parent

friendica (DFRN) - Link to source

jec&

@David Craig I don't understad what you think I don't understand, or how it negates my comment. GNU was a Unix lookalike/behavealike copyleft replacement, yes, but superseeded it since the GNU project chose not to be limited by what Unix did at the time. It did Unix and then some. Therefore saying something in GNU is "not the Unix way" is a gross misinterpretation of its inception and history, imo.

Linux (the kernel) did the same. It started because Torvalds was annoyed and disatisfied with Minix's limitations, and when you get stuff like cgroups or whatever, you don't see people saying it's "not the Minix way".

in reply to jec&

friendica - Link to source

jec&

Current hardware is wildly different. A PC is not a static set of components, it's a dynamic entity, with USB and wireless devices coming in and out of it all the time. Some of those are network or have network-like features. Some have filesystems. Some do sound. Modern OSs have to be able to deal with that and more. How do HDMI, 3D-accelerated GUIs, MTP, ExFAT, Bluetooth, DisplayPort-over-USB external monitors, or cellular network modems, factor exactly into the "Unix way"?

btw talking about virtualization being around for a long time is disingenous, when you consider it was actually available on IBM Enterprise-grade mainframes and OSs which weren't even Unix! Containers and VMs on personal computers and commodity hardware are definitely a modern phenomenon.

Unknown parent

friendica (DFRN) - Link to source

Nanook

@randygalbraith @David Craig I prefer nvi to vim, I have both on my systems as users have different preferences. As an old timer that first started using Unix in 1977 and in that day 'ed' was the only editor on the system, I got use to command line editing and when vi came out I appreciated the enhancements, but still relied heavily on the command line interface ex. Vim does not properly implement the ex interface of vi, nvi does. The original BSD vi didn't handle two-byte character sets, vim and nvi do. So for my purposes, nvi has the best of both.
in reply to jec&

diaspora - Link to source

Michele Leonardo

What is a modern OS? What is a OS? I think the kernel is the os. All other are tools and ways to manage the OS packages. In the 1990 to 2000 are not so many Hardware available. I was happy about systemd. Bevor systemd have all distributions made his own configuration philosophie. That is horrible from view as administration. In this days can you switch from Ubuntu to Archlinux. All uses systemd.
Unknown parent

friendica (DFRN) - Link to source

Roland Häder🇩🇪

@randygalbraith You can make scripts (e.g. Bash) more flexible by "sourcing" libraries and "hooks" in it.

"Hooks" are functions that are empty by default and can be called wherever they are needed. So here are some "phases" of an init script:

1) Load "global" (valid for all init scripts) configuration file for variables (distro-specific)
2) Load script-specific configuration file (for variables)
3) Start/stop daemon/mount file system/whatever
4) Check status

Example postLoadConfigurationFile() which is - the name suggest it - only being executed after the configuration file is loaded. So if a script (e.g. MariaDB) needs to run something after the configuration is loaded, it simply can overwrite that function call by its own steps. MariaDB here could then check if the database is initialized (first startup) and if not, do so by whatever they have to do.

An other daemon could overwrite preStartDaemon() (obviously the mount init script would never overwrite it as it is not a daemon) maybe because it needs to initialize other things first.

You can easily expand that flexible "hook" system by simply adding more "hooks" (empty functions but calling them). So each time an init script wants to do something "special" at one point of the script phase, let it overwrite that hook. Others won't overwrite it so, the empty "hook" function is called instead.

Maybe my proposal isn't perfect, but it is a start to renew #sysvinit.

Unknown parent

friendica (DFRN) - Link to source

jec&

@randygalbraith Sure, but the issue that I think makes the systemd debacle irrational is that a lot of people never deal with the init system directly (or even other non-init components systemd replaced) and it doesn't affect their workflow at all. They just know systemd = bad and they simply repeat what they heard.

This website uses cookies. If you continue browsing this website, you agree to the usage of cookies.

⇧