@sjw @Moon @graf I'm kind of sick of the "oh these old init scripts were so complicated" systemd bullshit argument. It is not real:
Here, you can make an init script.
I made the init script 4kB.
Don't, that's stupid. Make it start a daemon. It should be like ten lines.
But what if it should do something else?
It's a shell script. It's in /etc because it's configuration, not code.
People can't configure their own systems so the package manager installs them.
Stop.
Instead of that, it now sources 12 other files and it's like 100kB of code.
Stop, that'll be slow. You should just write a program if you need that much code...and then have the ten-line init script call it. Or, you know, it's a program, nothing says that you've got to write it in bash. If you need shit the shell doesn't do very well, maybe don't write it in bash.
No, I wrote "dash" and "ash" as non-interactive shells specifically designed for running all of my 100kB init scripts because they were slow.
That's stupid. Stop making 100kB init scripts.
Pfffft, you're just addicted to bashisms. Proper POSIX shells don't need bashisms!
Stop. You are creating problems.
Now that the shell is twice as fast, I bloated the init scripts to 200kB.
Stop.
These init scripts are slow and unreliable.
Stop.
IBM gave us the Systems D because our shell scripts were too big.
You goddamn idiot.
YOU ARE LITERALLY DEMANDING WE GO BACK TO RUNNING 200kB SHELL SCRIPTS THAT SOURCE 12 FILES!
It's fucking retarded. "I created this problem to solve this other problem that I also created. If you think I shouldn't have created either problem, then you hate *progress*!" There are zero init scripts on my system that use "grep". Know why? This distro was written by adults, not RedHat glowies or Debian retards. If you spend all your time kicking yourself in the dick and then you figure out it hurts less if you wear a cup, my first suggestion is "Stop kicking yourself in the dick so you can stop wearing a cup" and then the response is, invariably, "HA! You're walking around with a bruised dick!" because dipshits only listen to the second half and I just don't care. I don't. It's a pointless exercise to argue with someone that can't even hear you and doesn't care what you have to say to begin with and then about what, an init system? It's a fucking init system, it's there to bring up userspace, it doesn't matter.
You talk about something and if you call it "bloat" people will chant "Bloat bad!" and if you call it "lots of features" people will chant "Features good!" even if you're talking about the same thing. Trimming bloat is something people pay lipservice to while adding bloat to their own code and running that code on systems that are so bloated that they inspire envy in beached whale carcasses. I'm not going to stop anyone from washing down a Big Mac and a half dozen donuts with a Coke, it's their business, not mine, but I'm not going to pretend it's great. You wanna run shit software? Your business, not mine. We don't need to run the same init system the same way I don't need to adopt someone else's shit diet.
(I'm not exaggerating about 200kB of scripts, by the way. That is not an arbitrary number, although I did round up from 189,277 bytes.)
Here, you can make an init script. I made the init script 4kB. Don't, that's stupid. Make it start a daemon. It should be like ten lines. But what if it should do something else? It's a shell script. It's in /etc because it's configuration, not code. People can't configure their own systems so the package manager installs them. Stop. Instead of that, it now sources 12 other files and it's like 100kB of code. Stop, that'll be slow. You should just write a program if you need that much code...and then have the ten-line init script call it. Or, you know, it's a program, nothing says that you've got to write it in bash. If you need shit the shell doesn't do very well, maybe don't write it in bash. No, I wrote "dash" and "ash" as non-interactive shells specifically designed for running all of my 100kB init scripts because they were slow. That's stupid. Stop making 100kB init scripts. Pfffft, you're just addicted to bashisms. Proper POSIX shells don't need bashisms! Stop. You are creating problems. Now that the shell is twice as fast, I bloated the init scripts to 200kB. Stop. These init scripts are slow and unreliable. Stop. IBM gave us the Systems D because our shell scripts were too big. You goddamn idiot. YOU ARE LITERALLY DEMANDING WE GO BACK TO RUNNING 200kB SHELL SCRIPTS THAT SOURCE 12 FILES!It's fucking retarded. "I created this problem to solve this other problem that I also created. If you think I shouldn't have created either problem, then you hate *progress*!" There are zero init scripts on my system that use "grep". Know why? This distro was written by adults, not RedHat glowies or Debian retards. If you spend all your time kicking yourself in the dick and then you figure out it hurts less if you wear a cup, my first suggestion is "Stop kicking yourself in the dick so you can stop wearing a cup" and then the response is, invariably, "HA! You're walking around with a bruised dick!" because dipshits only listen to the second half and I just don't care. I don't. It's a pointless exercise to argue with someone that can't even hear you and doesn't care what you have to say to begin with and then about what, an init system? It's a fucking init system, it's there to bring up userspace, it doesn't matter.
You talk about something and if you call it "bloat" people will chant "Bloat bad!" and if you call it "lots of features" people will chant "Features good!" even if you're talking about the same thing. Trimming bloat is something people pay lipservice to while adding bloat to their own code and running that code on systems that are so bloated that they inspire envy in beached whale carcasses. I'm not going to stop anyone from washing down a Big Mac and a half dozen donuts with a Coke, it's their business, not mine, but I'm not going to pretend it's great. You wanna run shit software? Your business, not mine. We don't need to run the same init system the same way I don't need to adopt someone else's shit diet.
(I'm not exaggerating about 200kB of scripts, by the way. That is not an arbitrary number, although I did round up from 189,277 bytes.)
@p @sjw @Moon @graf Damn, it really hit a nerve. I also dislike systemd for doing too much things other software does better, but from my perspective as end-user, its ini-like service configs are quick and easy to make and modify. Still, OpenRC scripts (at least in my system) aren't that much bloated either.
@mintplague @Moon @graf @sjw The thing that hit a nerve is I'm really sick of hearing the same dumb arguments. This specific argument about "YOU JUST LOVE BLOATED SHELL SCRIPTS" is DOA and people never stop with it.
I don't like Poettering's
-ware, but my solution to that is just not using it.
ken-yshl.jpg
I don't like Poettering's
-ware, but my solution to that is just not using it.ken-yshl.jpg
@p @mintplague @sjw @Moon my opinion on poettering, systemd, pulseaudio? poa.st/@graf/posts/ADFYheLde2ECTHu8PY
+bonifartius 𒂼𒄄
@p @sjw @mintplague @graf @Moon
https://libslack.org/daemon/ init scripts are really just ~20 loc using that. it's the bees knees imho.
@bonifartius @sjw @mintplague @graf @Moon That looks like good stuff, but I thought start-stop-daemon had basically the same functionality. If this is smaller/simpler, that's great, ssd is a pain. (A small pain, but a pain.)
My rc script for venti is about 30 lines, I think it's usually not hard to do things that way.
My rc script for venti is about 30 lines, I think it's usually not hard to do things that way.
@p
idk much about ssd, i never really had to do init scripts for debian based systems.
daemon never gave me problems so far. it's really just
daemon -n fancyname -u user -- /usr/bin/theprogram
and
daemon -n fancyname -u user --stop
for starting/stopping. redirection of stdout/stderr to syslog (or a file if you want) also works using some flags. that is essentially everything i use :)
@bonifartius @sjw @mintplague @graf @Moon Delete and redraft considered harmful.
That does sound way better than start-stop-daemon, though.
That does sound way better than start-stop-daemon, though.
@p
> Delete and redraft considered harmful.
i didn't delete and redraft :) i guess something bugged out here with the tagged users or something like that because i deleted a space too much (or something like that).
> That does sound way better than start-stop-daemon, though.
daemon definitively made my life 100% easier in this aspect :)
@bonifartius @sjw @mintplague @graf @Moon
> i didn't delete and redraft :)
Oh, right, sorry. I had to mute the hellthread because FSE gets accidentally DDoS'd if I participate too much, sometimes this can make a notification get double-delivered.
> daemon definitively made my life 100% easier in this aspect :)
Yes! I'm surprised there's not a CRUX package for it, someone always puts stuff like this into at least one of the ports repos.
> i didn't delete and redraft :)
Oh, right, sorry. I had to mute the hellthread because FSE gets accidentally DDoS'd if I participate too much, sometimes this can make a notification get double-delivered.
> daemon definitively made my life 100% easier in this aspect :)
Yes! I'm surprised there's not a CRUX package for it, someone always puts stuff like this into at least one of the ports repos.
> Oh, right, sorry.
no offense taken!
> sometimes this can make a notification get double-delivered.
i always wondered how the double notifications happen :)
> Yes! I'm surprised there's not a CRUX package for it, someone always puts stuff like this into at least one of the ports repos.
it doesn't seem to require many hoops to jump through for compilation:
http://ftp.slackware.com/pub/slackware/slackware64-15.0/source/n/daemon/daemon.SlackBuild
maybe i should try CRUX at some point, looks nice :)
@bonifartius @sjw @mintplague @graf @Moon
> i always wondered how the double notifications happen :)
> it doesn't seem to require many hoops to jump through for compilation
Yeah, it's just nice when someone else increments a version number. It's ridiculously easy to make your own ports repo¹, but "Okay, let's figure out where the download page is, let's figure out the new version, let's see if it builds" etc., just nice when someone else does it unless it's critical infrastructure.
> maybe i should try CRUX at some point, looks nice :)
It makes Slackware look bloated; other than that, if you run Slackware, everything will make sense, just there's less of it. The ports system is nicer than Slackbuilds. It is somewhat more minimal, so I run Slackware on servers most of the time. (I was using Devuan a lot, which I regret; I should have just stuck with Slackware.)
> it doesn't seem to require many hoops to jump through for compilation
Indeed. I had a look at libslack, that is really cool stuff. Aside from the
quote at the top, it's all just really good stuff. "There are no gratuitous data structures that wrap around perfectly acceptable data structures that are provided by the system. For instance, the networking functions do not return some home grown Socket object. They return file descriptors just like underlying system calls." Like, everything, the page starts with what it is, the description makes sense, description of the facilities provided, documentation, and downloads. You know what a rare gem that is nowadays, it's all 4-color glossies that don't tell you what the thing is or does or where the code is or where the repo is, I mean...I might cry looking at this guy's page: https://libslack.org/ .
¹ You can basically figure it out by looking at /etc/ports/core.rsync. Ends with rsync, all right, rsync server. Contents of the file:
host=crux.nu
collection=ports/crux-3.6/core/
destination=/usr/ports/core
It's in the manual but you can probably just guess how to make a ports repo. So I've been running a personal ports repo for about as long as I've been running CRUX.
> i always wondered how the double notifications happen :)
> it doesn't seem to require many hoops to jump through for compilation
Yeah, it's just nice when someone else increments a version number. It's ridiculously easy to make your own ports repo¹, but "Okay, let's figure out where the download page is, let's figure out the new version, let's see if it builds" etc., just nice when someone else does it unless it's critical infrastructure.
> maybe i should try CRUX at some point, looks nice :)
It makes Slackware look bloated; other than that, if you run Slackware, everything will make sense, just there's less of it. The ports system is nicer than Slackbuilds. It is somewhat more minimal, so I run Slackware on servers most of the time. (I was using Devuan a lot, which I regret; I should have just stuck with Slackware.)
> it doesn't seem to require many hoops to jump through for compilation
Indeed. I had a look at libslack, that is really cool stuff. Aside from the
quote at the top, it's all just really good stuff. "There are no gratuitous data structures that wrap around perfectly acceptable data structures that are provided by the system. For instance, the networking functions do not return some home grown Socket object. They return file descriptors just like underlying system calls." Like, everything, the page starts with what it is, the description makes sense, description of the facilities provided, documentation, and downloads. You know what a rare gem that is nowadays, it's all 4-color glossies that don't tell you what the thing is or does or where the code is or where the repo is, I mean...I might cry looking at this guy's page: https://libslack.org/ .¹ You can basically figure it out by looking at /etc/ports/core.rsync. Ends with rsync, all right, rsync server. Contents of the file:
host=crux.nu
collection=ports/crux-3.6/core/
destination=/usr/ports/core
It's in the manual but you can probably just guess how to make a ports repo. So I've been running a personal ports repo for about as long as I've been running CRUX.
guess i might as well try out crux. seems nice and i have enough spare thinkpads :P
the glossiness of a projects page (or the projects ui, for that matter) seems to be inversely proportional to how useful the project is.
better revel in the nice things that exist: the "supported platforms" part of libslack is really the cherry on top. not many things can claim to support GNU hurd :)
@bonifartius @sjw @mintplague @graf @Moon Yeah, you might like CRUX.
Plan 9's fun, I'm a big fan. You probably know that already, though, because I never shut up about it.
Plan 9's fun, I'm a big fan. You probably know that already, though, because I never shut up about it.
@bonifartius @Moon @graf @mintplague @sjw Anyway, I gotta get the hell out of this thread, systemd is one of the third rails and now we've talked about Linux distros and it's only a matter of time before the M67's start rolling in.
@p @sjw @mintplague @graf @bonifartius @Moon I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.
Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.
There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.
@p
yeah, probably a good idea :D
@sjw @mintplague @graf @Moon
@p @bonifartius @Moon @graf @mintplague @sjw the attached scene is from right after lain is told that systemd "might not be all that bad, you know?"
pathetic.gif
pathetic.gif
yes.gif