/tech/ - Technology

>>1 (OP) 
Instead of removing just get a distro without it in the first place.
<Gentoo
<Alpine
<Void
<KISS
<GUIX/NixOS
<Sabotage
<Artix
<Devuan

>>4
This. But NixOS uses systemd by default and it probably wouldn't work well with alternate inits. GuixSD does use their own init and service manager.

gentoo-chan.png
[Hide] (1.2MB, 1000x944)

Literally impossible. Especially with the upcoming wave of rainbow employees in Red Hat.
There's currently no known way of convincing people that converting GNU/Linux into Windows/macOS ecosystems isn't good.

>>6
You forgot to put the Rust logo on that image.

Is BSD free of systemd?

>>10
BSD has BSD init. It's closer to something like Open RC than systemd.

>>10
systemd is only made for Linux. It won't work on BSD or other *nix OSes.

f630b344c8f3d34ecb4c57be3048076eccede8df58bb5af22ed448c27e818c2e.jpg
[Hide] (32.1KB, 640x481)

>>11
>>12
Might've sounded like a stupid question - I'm really just curious what the dangers of systemd and things like it are. 

t. Never used any unix or linux OS but am looking into it now that I've got my hands on a spare laptop from work

>>13
It's GNU/Linux, not Linux.

the_very_hungry_systemd.gif
[Hide] (4MB, 426x284)

>>13
Init is the first process started a Unix-like operating system when your machine boots up, and to some extent (exactly how much depends on your init system), it's responsible for all other processes which start up afterwards. Ideally you want something simple, both for your sake as a user and because simple software usually has fewer bugs and fewer security holes. And for context, until a few years ago most Linux distributions used SysV-style init which was widely regarded as a mess.
Now systemdicks is anything but simple. At absolute best its config files are supposedly less of a pain than SysV init scripts, which is the main reason distro maintainers adopt it, but otherwise? It's this horrendous clusterfuck which is not-so-subtly trying to take over the Linux ecosystem by shoving a bunch of unrelated shit into itself and absorbing unrelated projects. Not only is it an init system, now it has its greasy fingers in everything from logging and device management to DNS, printing, your computer's clock, boot management, and managing your home folder. All of these are interdependent in complex, very retarded ways, and they're also written by some legendarily shit programmers who are convinced they're hot shit. This also means systemd breaks in complex, very retarded ways, and more often than not its dumbass devs are too proud to admit any bugs you find exist until the entire internet and occasionally the fucking government screams at them.

So why does anyone use this piece of shit? That's...complicated. And it involves distro politics and lefty faggotry way, way more than it should, including the devs calling people who don't use systemd sexists and racists. The devs and systemd's fanboys also love to pretend that there are only two alternatives to SysV init: systemd and upstart, so they flog  upstart over and over even though no one's used that trash for years and hope no one notices that there's other init systems these days and that they're objectively better and way simpler than systemd.

moon_tux.png
[Hide] (49.9KB, 265x373)

>>105
>calling people who don't use systemd sexists and racists
I was already considering switching to Devuan, but now I definitely will.

>>108
I was just looking at that as well, thinking about switching to it from Kubuntu instead of updating to 20 next year. How much of my shit will break without systemdicks though?

>>105
Note: most of the time systemd does "just work." But if it does fuck up for you there's a significant change your only recourse will be patching it yourself.

>>105
Thanks, anon. So can systemd even be removed? Something at a kernel level like that seems like it would be impossible to detach without rebuilding things from the ground up.

>>115
The whole point of init is that it's in userspace. PID 1 has special rights but you should be able to replace it with whatever and have no problems. Not that you should have to, because all init should be doing is reaping child processes.

>>115
As >>116 says, it's in userspace, the problem is that systemd likes shoving its tentacles in everything and its fanboys do everything they can to help this along. Distros which go full-throttle into systemd cancer can be hard to uncuck thoroughly, hard enough that just switching to a systemd-free distro is often the better option. It took Devuan several years to make sure everything worked without systemd, for example.

>>4
>Slackware's not listed in there despite being the great old one of distros, AND not using SystemD

Come on man.

>>105
>including the devs calling people who don't use systemd sexists and racists
[citation needed]

>>109
Differen't inits didn't break stuff for me when I used Gentoo + OpenRC and Void + runit. Not sure about Devuan as I haven't used it yet.

>>164
>Differen't
*Different

>>163
I know for certain that Lennart Poettering called anti-systemd people sexists in a Google+, can't remember if he called them racists in that post too but it wouldn't surprise me.

>>118
I'm not an authority on non-systemd distros. I though NixOS didn't have systemd but apparently it does. I just gave a couple of distros off the top of my head.

Could someone tell me why a regular use would need systemd? I've never really used it but OpenRC does absolutely fine. I start, stop, and restart services. What else does a regular use want? I can understand maybe sysadmins want something more standardised.

>>175
>I can understand maybe sysadmins want something more standardised
That's the point. Instead of maintaining several different options, the board that maintains direction of essential Linux software development chose to just give Poetteringware reign over the ecosystem to streamline everything. Sysadmin or not, systemdick will get shoved down your throat and you will like it. This top-down direction of events is also why other Linux software devs started making systemd components a mandatory dependency, resulting in shims and hacks from distros like Debian, Artix etc. I understand the sysadmin reasons for the change: things like special snowflake boot and service management in enterprise setups coded by retarded pajeets. But this will result in never being able to switch off the One True Init System, even if it becomes completely ridden by exploits and bugs. OpenRC turns into a viable alternative for absolutely everyone? Too bad, it breaks policykitd, logond, whateverthefuckd and the entire kitchensinkd. And come on you guys, do you really want to reinvent the wheel again? Just let Lennart take care of things :^)

The future of Linux is a shittier Windows, because of zero security in window management systems still, which fucks desktop users (X or Wayland, doesn't matter) and no incredibly long backwards compatibility support despite fucking over the flexibility Linux offers over Windows, which fucks server operators.

Hoenstly, I don't hate systemd, the biggest issue is that it has become "standard" and retards have started to add systemd as a dependency for packages even when there's no reason it would be required. Live and let live.

>>183
if you want the unix way you should be using *bsd

>>175
Doesn't OpenRC have a utility to convert systemd units to whatever mutant shell syntax it uses? It's not even about standardization, it's about freezing out small contributors so when something goes wrong you have to pay Red Hat to fix it.

>>105
this.

Why would anyone want to use init system that includes stuff like (shitty) logging daemon, cron, sudo, bootloader, NTP client, etc. stuff that you don't need or even care about? The systemd developers downplay bugs (muh not a bug, muh wontfix) Also, remember when systemd developers tried to add their shitty and bioluminescent IPC (kdbus) into the Linux kernel? To make things even worse, IIRC, the only reason why systemdicks developers tried to push kdbus was that they were simply too lazy/incompetent to add some feature to systemd ("it should be called SystemD/Linux")

21fe079450d0d1f6d6d60aab97e29e52c891250f0f3cfd2d385e2c5129e7ea25.png
[Hide] (152.1KB, 1375x772)

>>186

dc7068f9e8a1346d05fd1e8a0880cc76288e941de4fc78936fcad85ab336dfa2.png
[Hide] (905.3KB, 676x626)

HOW DO I GET ANKI 2.35 RUNNING ON SOMETHING THAT ISN'T SYSTEMD
WHY DOES THIS REQUIRE SYSTEMD
PRETTY FUCKING SURE IT'S QT5-WEBENGINE OR SOME SHIT WHY THE FUCK DOES THAT REQUIRE SYSTEMD
I HAVE EVERYTHING ABOUT MY OS PERFECTLY TUNED EXCEPT I CAN'T USE THIS SHITTY FLASHCARD APPLICATION TO LEARN MOONRUNES BECAUSE IT REQUIRES THAT MY SYSTEM'S INIT BE SYSTEMD

>>257
2.1.35* my bad

>>258
Why 2.1.35? 2.1.15 can be emerged without systemd and rust.

>>259
2.1.15 has an issue with audio playing that isn't rectified until I think 2.1.16. And systemd and rust is required after 2.1.16. And also a ton of gay ass extensions require more recent versions. But anything above 2.1.16 would be good for me because that audio bug is atrocious. I use void, for a while I've been running Arch in a VM just to use Anki, occasionally seeing if I can figure out how to compile a recent version without much knowledge.

>>257
What's your distro? I made a dependency tree for Anki and the offenders are, as you've guessed, QT5 packages. Namely, qt5-base and qt5-webengine. But that's because they've been compiled to work with your distro's init, i.e. they depend on systemdicked dbus, util-linux and p11-kit. Unless they snuck something in their Rust code as well, any non-systemD distro that ships their own qt5 meta package with necessary flags (or you compile your own if you're on Gentoo) should support Anki. If compiling is not your thing, there is, for example, Artix.

You could prepare a separate installation of whatever distribution of GNU/Linux you prefer in a virtual machine dedicated to this purpose specifically which will have systemd so you can run anki in that machine, if you do not want systemd to touch your actual machine.

install gentoo

>>13
>systemd comes from redhat
>redhat not a free distro for ages
>suddenly things like debian forced into systemd
>even rapsberry pi zero has it when underpowered?

It's conspiracy tier bullshit and proprietary. Even if you don't know what it does intuition should make you question it's use. That and it came out late in the game, why suddenly did linux need this? 

>>186
Is bsd stuff even going to be  very usable at this point or do you have to be a super genius?

>>1748
Depending on use case, OpenBSD is quite usable, it takes about the same level l33tness to use it well as in Linux. But all of them are pozzed, OpenBSD wasn't, freebsd is the original SJW-pozzland and OBSD was forked from netbsd for its dramas.

If there's one thing I hate about bsd os,it would be their documentation. Everything about it is a fucking mess and not helping especially when you're a new user.

>>208
systemd is eating up Windows these days. RedHat managed the EEE the inventors of EEE.
https://devblogs.microsoft.com/dotnet/net-core-and-systemd/

>>257
You think that's bad,now read this
>Deployed one of the most comfiest DE out there known as the CDE (Common Desktop Environment)
>Post It in AUR, and it is the only package available for Arch fag. 
>Slap it with hard dependent systemd.
>Tried to install it anyway but removed the make dependency with systemd
>Shit installed with completely broken package
I wish there's a program that can remove all these hard dependent systemd on software package.

Can one of you tell me the exact reason to hate system-d? I seriously know little about it, and never had issues with it. Except for the bootloader, holy crap that thing is garbage.

>>1808
https://nosystemd.org/
http://galexander.org/systemd_sucks.html
For me, systemd is over-engineered and requires lots of reading to understand it well when I already know enough bash. Also fuck Pottering and (((Redhat))).

>>1808

What >>1832 said is a start for me.

The others are:
1. The people that are really singing the praises of this software seem to be very cultist-like people.
2. it creates a common point of weakness, when linux's biggest strength is that every single distro has elements that do different things.
3. It has the software-company issue of "fixing what was not broken just to give employees something to do".
4. the software is being engineered as a necessity that needs to be constantly run instead of something that can be run once, or run whenever/wherever/forever on the user's own time.
5. like >>1761 said, it's being arbitrarily applied to packages that have no need or reason to have it.
6. 95% of the linux-using population doesn't directly interact with systemD, and the people pushing for it are either stupid or (this is kinda tinfoily but logically-sound) paid by microsoft to deliberately sabotage Linux culture by creating a common attack point.

>>1808
It's a new approach that has no desire to accommodate anything that's not SystemD, written in an era of move fast and break stuff faggotry. And it's going to be controlling your system. I'm sure it's better than maintaining SysVinit scripts made by some Dunning-Kruger victim though, which is why it's being adopted even without pressure from RedHat. Aside from the points already mentioned, it just feels annoying to be constantly gaslit by monkey brain nerds. It's a vicious cycle of: you don't need X component of SystemD, just turn it off; so what if library Y now requires component X, the alternatives were unsafe and poorly maintained; asking library devs to maintain backwards compatibility is toxic, they do it for free you know; SystemD isn't eating into userspace, stop spouting conspiracy theories; you don't need Z component of SystemD, just turn it off; etc.

The best part of SystemD are going to be the minimalistic rewrites taking the rare good parts of it and making sure libraries compiled against it work anyway, like how some distros do it with shims but hopefully less painful.

I see a bunch of faggots not discussing any valuable thing in this thread, lets chance this.

Lets talk about most based init of all, sinit. Not only is it minimal and follows the unix philosophy better than any other init, it is also written by based suckless devs. After several unsuccessful boots with sinit solely caused by my incompetence in linux i decided to cuck out and install openrc again. This is the last time i am cucking on my init. Post your /bin/rc.init, post your daemontools setup ( or don't https://github.com/nshp/sinit ) 

https://core.suckless.org/sinit/

>>1865
>call others stupid
>huh duh based based based

>>1840
>>1832
>>1838
Thanks. May give me a reason to move from EndeavourOS to Artix.

>>1875
To demonstrate what the good parts of the systems bloating up Poettering's shitty init are, here's a talk by an unironic furry tranny using a Vtuber avatar to give the presentation: https://christine.website/talks/systemd-the-good-parts-2021-05-16 I wish people stopped inserting their mental illnesses into technical discussions, worst shit ever.

>>270
Months later here, but it's Void. The Flatpak for Anki works so I'm just using that.

>>1897
i watched it while masturbating
zes voice is very sexy
that low rumble gives me a tingle in my balls mmmmmm

>>1909
same, I think the right conjugation for xe is xir though
fucking cumming to xir right noe tbh

Creepy_Joe_Biden_Mega-Mix.mp4
[Hide] (5.1MB, 640x368, 01:26)

>>1897
>a tranny furry killer-whale roleplaying autistic man with an anime webcam is going to tell you us anything
Dude lmao

I went to this guys youtube channel and he was a smart fedora 9 years ago before he got bought into societal cultural and social decay by getting POZ suicide cult'd, It's actually a tragedy. I feel bad for this idiot now fuck you nigger.

>>1897
Yup, I can confirm I am cumming  to this right now

>>1922
Update: just cummed

>>1 (OP) 
There is completely nothing wrong with SystemD.

>>2053
Everything is wrong with SystemD.

tty.png
[Hide] (3.9KB, 640x480)

For me the simplest solution was to install a statically-linked busybox and set that up as the init.  It's pretty easy because it uses the traditional /etc/inittab for configuration.  It's small, simple, and transparent, without all kinds of layers of abstraction and useless bullshit.
Then I disabled all the systemd crap, but left the packages installed that were dependencies for other packages.  This is Ubuntu 16.04 btw, so if I can do that here easily, then it must be possible with basically any distro.
There's a few bugs though.  Not in the init though, I never had trouble with that (unlike systemd that crapped out on me several times).  But there's a bug in the ash job control somewhere, I think.  If I use "less" to view a file, then suspend the process with ^Z, it locks up that terminal (have to kill the shell from another tty, or use Alt-SysRq).  But this is the busybox that shipped with Ubuntu 16.04, so it's and old version, and maybe this got fixed already.  I keep forgetting to try the newer ones, because I've been busy working on other stuff.

>>1 (OP) 
But systemd is good though I like it alot.

>>1897
tech troons are the best
https://www.bitchute.com/video/pKUhYFC79Z1b/
I waant to suck the faeces out of this bitchdick so bad, and then fist his anus while giving electroshocks to his balls

>>2277
Hot
Does this work ?

gaycaptcha.png
[Hide] (8KB, 155x65)

>>2277
back2/b/

>>2287
>g-gay

gentoo-chan_suffering.png
[Hide] (1MB, 1000x944)

>>7

New systemd poz landed in Gentoo a while ago. Behold: https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
On first glance you may think that this is useful, but look at the z/Z option. It is completely useless (since the files are to be created in the first place) but has the nice side effect of resulting in a root privilege escalation if implemented the naive way because of symlinks and hardlinks, the latter of which can't be easily worked around. Systemd of course gets around that by reimplementing chown from scratch and using Linux-specific hacks, which sys-apps/opentmpfiles can't do.

So the official party line is that opentmpfiles is now Deprecated™ and you're to use sys-apps/systemd-tmpfiles. Don't worry goy, it's merely a standalone program, so what if you need the fuckhuge systemd source tree for it? :^) Expect some pilpul along the lines of
>what's one more systemd "standalone" thing goy, you already have the source tree after all :^)
in the coming months. I personally just patched out this retarded feature and kept opentmpfiles. As far as I can tell, nothing uses it anyway, at least nothing on my box.

Patch for v0.2:
possible language: perl, relevance: 13
--- a/tmpfiles
+++ b/tmpfiles
@@ -551,5 +551,5 @@
 		# whine about invalid entries
 		case $cmd in
-			f|F|w|d|D|v|p|L|c|C|b|x|X|r|R|z|Z|q|Q|h|H) ;;
+			f|F|w|d|D|v|p|L|c|C|b|x|X|r|R|q|Q|h|H) ;;
 			*) warninvalid ; continue ;;
 		esac

>>2425
It's a waste of time to even care about this crap.  Nobody needs systemd, freedesktop.org, gnome, redhat shit.  You pick a window manager like fvwm or whatever, you configure it and the standard X config files like .xinitrc, and you're done (assuming you even need X at all).

>>2426
What do you think of the XDG Base Directory standard?

>>2425
enews >>2395

>>2426
The only reason I even bothered patching it is because the faggots immediately added it as a dependency to ten gorillion things.

>>2428
This wasn't even in my enews. The last entry is 2021-06-30  migrating from glibc[crypt] to libxcrypt in ~arch and I updated today. The only reason I even noticed this shit was because an update tried to pull in systemd-tmpfiles, what the fuck. But thanks for the link, I wasn't following that thread.

>>2430
It isn't on enews yet because of dev drama: https://marc.info/?l=gentoo-dev&m=162585045017891&w=2

>>2431
God, Gentoo really has been going to shit in the last five years. What the fuck happened to this distro? Was there a big exodus of competent people?

mc.png
[Hide] (8.1KB, 640x480)

>>2427
ebin, just like everything else they did.  I like having the dotfiles and dotdirs directly in my $HOME, rather than scattered into subdirectories.  If I can do "ls -a" and see everything, that's perfect.  If I don't want to see the dotfiles, then I hide them by only typing "ls" or toggle the file listing mode with . key in Midnight Commander (maybe that's not the default binding, I configured my mc to behave more like vifm).

>>2440
.config is nice tho.

.local, .local/share, .var and so on aren't, because they mirror the retarded directory structure of an unix system.

>>2463
Like I said, dotfiles go in $HOME, so .config is unnecessary.  I basically don't want any of their nu-Linux desktop environment related shit.

>>2463
He is absolutely right, on average i have about 5 files in $HOME but some progs just decide they need a file in $HOME.
.cache is also nice btw

>>2480
You're absolutely wrong.  It's all complete garbage.

>>2485
no u

benis.gif
[Hide] (85.8KB, 1500x500)

>>2486
FGU XD

>>1897
Why is that the only good female programmers are men pretending to be women?

5429e7a905bfc5fdae98e60134936588d41215c287faf0fadddbb7727419ddbf.png
[Hide] (445.6KB, 640x480)

I've been using Artix for a few months now, and it's awesome.  You get all the utility of Arch/AUR with OpenRC from Gentoo.  They have a bunch of ISOs with various DEs so it's super easy to get up and running: https://artixlinux.org/download.php
I'm using the Xfce build, and it's great with a good, minimal set of packages.

Has anyone tried to run Proxmox without Systemd? 
Maybe installing it through devuan would work?

>>2523
>what is searching "proxmox devuan"
First result.

>>2525
You mean the first and only result where the dev doesn't know and the guy who tried it never reported back?

>>2526
My first result is a forum thread.
>proxmox uses several systemd features
>Dec 6, 2019
Imagine how much deeper they shoved the sysD up in 2 years.
https://forum.proxmox.com/threads/building-proxmox-on-devuan.61289/

>>2527
But isn't Devuan made with Systemd alternatives built in with the intent of running programs that require systemd?

>>2528
No. Devuan have some systemd components replaced with alternatives. Programs that uses specific systemd parts may not have api-compatible replacements. For example, some program can use openssl and libressl, because only the api-compatible part is used. But if the program uses part of openssl with a different api than libressl or if that part doesn't exist in libressl, there is no replacement. Proxmox is probably using systemd parts with specific api. Unless the part it uses has common api for different implementation, patching would be needed to make it work.

Has anyone tried MX Linux? 
According to Distrowatch, the distro contains systemd but apparently the default init is SysV.
Assuming that you install the distro with SysV, would the installed distro still contain software that are dependent on systemd?

https://distrowatch.com/table.php?distribution=mx

One thing I've come to realize is that there isn't a single normalfag distro without the poz.
And here's the thing, if you get normalfags off of Windows so they stop making computing so horrible, they'll make Linux as horrible as Windows in the process and we're already in the late stages of that.

The core issue of this is that no matter what normalfag friendly distro they use, they're all cancer. They're all evil predatory software with Apple or Microsoft-tier quality that will force everything to be as horrible as themselves. If you get rid of systemd, there's still Python, Pulseaudio, GNOME, GTK, QT, KDE, DBUS, glibc, consolekit, Wayland, VLC, Firefox, Chrome, those are all true visages of hell in software form and they purposefully drag everything they touch down to their level.


There needs to be a normalfag catcher distro that won't kill the few good distros left. Something like Alpine but entirely managed off the clickyclacky UI that normalniggers love so much.

>>2617
What's wrong with python? People using it as anything more than a scripting language is retarded, but that's more of a user issue.

>>2842
Not him, but almost every Python update has caused major breakage on my system. It's not as bad as Perl yet, but having to fix setuptools by hand gets tiring really fucking quickly.

possible language: csharp, relevance: 36
2021-08-24-eudev-retirement
  Title                     eudev retirement on 2022-01-01
  Author                    Anthony G. Basile <[email protected]>
  Posted                    2021-08-24
  Revision                  1

sys-fs/udev is becoming the standard provider of udev on non-systemd (e.g.
OpenRC) systems. Users of systemd will continue to use the udev services
provided by the sys-apps/systemd package itself.

The transition should be uneventful in most cases, but please
read this item in full to understand some possible corner cases.

eudev will be retired and removed from Gentoo on 2022-01-01. We will
start masking eudev on 2021-10-01 and give people 3 months to prepare
their transition. You should ensure that sys-fs/eudev is not in your
world file by running

  emerge --deselect sys-fs/eudev

in order for Portage to replace eudev with sys-fs/udev once the
package.mask is in place. We fully support udev on musl, whereas uclibc
will still have to rely on eudev before also being removed on 2022-01-01.

  **WARNING**

If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob,
you will inevitably break your system. sys-fs/udev contains "systemd" in
some of its filenames, hence a blanket filter rule will likely lead to
a non-functional udev installation.

  Rationale

The integration of udev into the systemd git repo introduced numerous
problems for non-glibc systems, such as musl and uclibc.  Several
options were considered, and the one chosen was to fork and maintain udev
independent of the rest of systemd.  This was meant as a stop-gap solution
until such time as the problems with systemd on musl had been resolved.
This is now the case with patches provided by openembedded, and my original
reason for maintaining eudev is no longer relevant.

I am willing to transfer eudev to another umbrella organization or Linux
distribution that is willing to continue its maintenance, but maintaining
eudev cannot be done purely through proxy-maintaining and requires an
understanding of its internals.  This is a steep learning curve and must
be an earnest effort.  For this reason, the Base System project has decided
not to support eudev as an option going forward.
Haha sure is weird how these all happen within a few months of each other.

>>2876
I'm glad I fucked up when installing gentoo and decided not to use it as my main OS.

>>2876
Fuck. Not this shit again. Looking at https://wiki.gentoo.org/wiki/Mdev

The libinput and evdev drivers for Xorg have a hard dependency on it. I'm pretty sure libinput is required now too because they deprecated and killed the old mouse/keyboard drivers.

Not looking good for me, I need lvm for dm-crypt.

>>2878
>>2879
Found this: https://github.com/illiliti/libudev-zero from https://github.com/swaywm/wlroots/issues/2257. This may be it.

>>2876
Get the fuck out of Gentoo

https://kisslinux.org/
https://venomlinux.org/
https://sabotage-linux.github.io/

cbcf4d8f8ef5a6d142884d1034e9683bcd6dfbe88cbc93f10f3fdd38dbe8c29c.jpg
[Hide] (507.9KB, 2000x2489)

>>2883
>no SMGL
Install Source Mage Gnu/Linux  https://sourcemage.org

Is Funtoo affected?

>>2891
Yes, unless they pick up maintenance of eudev.

>>2895
One can hope, though I fully expect the udev upstream to go ham on pointless compatibility breaking changes now that eudev is in a bad spot.

>>2883

Don't forget Carbs Linux:
https://carbslinux.org/

>>2890
Fuck this is still a thing? I remember this from at least 15 years ago. I was a teenager dabbling with Linux and tried sourcemage after getting frustrated with Gentoo. Never used it that much but how has it evolved?

>>2896
(((Red hat))) never gives a fuck about compatibility, the guy who maintained eudev had to manually follow development on upstream. Not an easy job for anyone.
>I am willing to transfer the eudev repo to another organization, but I
>will not maintain it anymore and Base System doesn't want to either.
>Let me warn people, to maintain it correctly you MUST become familiar
>with its internals and watch what systemd is doing upstream to keep up.
>This is not trivial. I learned a lot from eudev, and it did save musl
>on gentoo, but there was a period there when it was taking up almost all
>of my time. If you don't know what you're getting into, you don't want
>to take on its maintenance.
https://archives.gentoo.org/gentoo-dev/message/dff4bf35636efef95f6d7926823b4e8d

This mess is due to having to support shit software that depends on bigger and smellier shit. (((Upstream))) got lots of money and manpower to make everything complex and bloated at fuck. Shit is so bad that installing any gnome program, even their version of mspaint pulls in the whole gnome, systemd and other shit. Forks and development is not sustainable because of the complexity. kiss and other minimal choices solved the problem by simply not support those software at all. The best solution is killing Redhat and pottering in hell fire and go back to simplicity.

>>2899
>but how has it evolved?
sadly the project doesn't have enough manpower so it's pretty ded.

>>2900
I didn't say they cared, but I expect there to be a mysteriously timed increase in changes that are really difficult to port so that eudev's revival never gets off the ground.

>>2903
Right. At their current speed https://github.com/systemd/systemd/pulse, they don't need to do anything and the bits will rot.

>>2883
>>2898
Are any of those actually usable? I have heard of all of them. Don't know anything about Venom, but it's based on LFS, right? And I consider using that eventually. Sabotage seems promising, Carbs uses busybox, which is nice, and I considered KISS before but didn't try it because it only supports Wayland and last time I checked you couldn't even record your screen on that unless maybe using fucking Pipewire. And I don't like the complexity being moved to the actual window managers. Not having multilib would be kind of a pain, though, and a downside of using musl to eliminate the GNU/bloat. No more Wine Touhou on Linux unless I use another machine. 

I have really been struggling to get a clean system without udev, elogind and others. Even the BSDs are full of garbage dependencies like dbus (holy shit, dbus is fucking difficult to avoid) and other crap, so there aren't many easy ways to do that, so my new old main computer is not being used, because I don't know what to install on it, so I'm using a computer with an older install full of this garbage. This one can't be librebooted, so it's hopeless anyway. I would go straight to LFS, but I have no idea how long it will take to learn that, so I would rather use something else for now and do it in a VM in order to prepare myself for the avalanche of cancer to come.

>>2890
It's a shame that it's dead. Never got to use it, but I heard that the package manager was good. I like the theme too. Perfect for a wizard.

>>2903
Expect more totally accidental vulnerabilities in all of this garbage in the future. And expect Rust.

>>2905
>(holy shit, dbus is fucking difficult to avoid)
It really isn't. The big offender is GTK3 and you can trivially patch the Dbus support out of that one. Yes, it doesn't actually require Dbus, the faggot developers just removed the option because disabling the accessibility garbage is ableist and hurts The GNOME Brand™. Here's how to remove it, the patch is easily adapted to other versions.
possible language: c++, relevance: 26
diff -ruNd gtk+-3.24.1/configure.ac gtk+-3.24.1_patched/configure.ac
--- gtk+-3.24.1/configure.ac    2018-09-19 03:42:49.000000000 +0200
+++ gtk+-3.24.1_patched/configure.ac    2019-04-13 10:36:23.281715341 +0200
@@ -1400,11 +1400,7 @@
 # Check for Accessibility Toolkit flags
 ########################################

-if test x$enable_x11_backend = xyes; then
-   ATK_PACKAGES="atk atk-bridge-2.0"
-else
-   ATK_PACKAGES="atk"
-fi
+ATK_PACKAGES="atk"

 PKG_CHECK_MODULES(ATK, $ATK_PACKAGES)

diff -ruNd gtk+-3.24.1/gtk/a11y/gtkaccessibility.c gtk+-3.24.1_patched/gtk/a11y/gtkaccessibility.c
--- gtk+-3.24.1/gtk/a11y/gtkaccessibility.c     2017-11-16 14:21:24.000000000 +0100
+++ gtk+-3.24.1_patched/gtk/a11y/gtkaccessibility.c     2019-04-13 10:38:12.529715578 +0200
@@ -37,10 +37,6 @@
 #include <gtk/gtktogglebutton.h>
 #include <gtk/gtkaccessible.h>

-#ifdef GDK_WINDOWING_X11
-#include <atk-bridge.h>
-#endif
-
 static gboolean gail_focus_watcher      (GSignalInvocationHint *ihint,
                                          guint                  n_param_values,
                                          const GValue          *param_values,
@@ -988,9 +984,5 @@
   _gtk_accessibility_override_atk_util ();
   do_window_event_initialization ();

-#ifdef GDK_WINDOWING_X11
-  atk_bridge_adaptor_init (NULL, NULL);
-#endif
-
   atk_misc_instance = g_object_new (GTK_TYPE_MISC_IMPL, NULL);
 }I've been DBus-free for years now. One downside is that you have to compile FF from source though, which has painful compilation times that became even more painful when they added Rust to the mix.

>>2906
Having to do that at all is fucking bullshit, and it definitely won't be possible when they shove GTK4 down our throats. Firefox is trash and I don't want to use it anyway, so that's not a problem, but other browsers use GTK too (except qutebrowser). I wish I could just not use GTK and Qt. Almost possible, but not quite.

>>2909
Palemoon can be compiled with gtk2, where dbus is not required.

>>2909
>Having to do that at all is fucking bullshit
You either take control or you remain the play ball of the niggers currently in charge.

>>2905
>Are any of those actually usable?
Yes, venom and sabotage are the best options imho.

A big plus that they have over kiss is the ability to have dependency checking+resolution. They both serve very different purposes. Sabotage is musl only with a unique filesystem layout, where all packages are installed to /opt. It is actually very old, being the first musl distro. Plus the devs are based, look on the leader's blog https://sabotage-linux.github.io/blog/about/ . Venom is very young, but it has been advancing fast. It has a musl version, but focus is on the glibc build. The system shell is dash for speed, and it took inspiration from lfs, crux and kiss. Porting software to it is very easy and the scratchpkg (the pkg manager) is handy too.

> And I don't like the complexity being moved to the actual window managers.
Wayland is utter crap, you can get xorg for kiss here
https://github.com/ehawkvu/kiss-xorg

>>2912
True, but polishing a turd is still not something that should be necessary. I would rather not use crap made by the fucking GNOME project at all, instead of just trying to make their garbage less bad until they eventually make that impossible too.

>>2910
Really not a fan of Palemoon. It's still basically Firefox (maybe an older version), and Firefox is a terrible browser, and it's basically Google cancer too. I was thinking about Qutebrowser (sure, Python, but it works well enough and I already need it for youtube-dl), but then I notice that it downloaded dbus as a dependency. Piece of shit. I guess I either have to clean up GTK3 or I have to go with Palemoon.

>>2913
I know about the filesystem thing. It's like Gobo, right? Pretty neat idea that can solve the multiple versions issue without adding a lot of complexity to the package manager for no reason (like Nix and Guix did). Anyway, I will give both Sabotage and Venom a shot. Switching to musl is something that I kinda wanted to do, so maybe I should sacrifice multilib and use a different machine for that. BusyBox would be very nice to have. I don't need GNU's bloat, and there is no need to install another shell when the BusyBox version of ash is already there.

>>2883
>>2890
>>2898
Also, CRUX linux https://crux.nu
or LFS https://www.linuxfromscratch.org (with pkgsrc and/or Guix package manager)

>>2914
>It's like Gobo, right?
Gobo was one of the inspirations, but I've never used it to know how close they are.

Their sites don't mention it but there are liberachat channels for the distros, see #sabotage and #venomlinux .

>>2905
>Don't know anything about Venom
Crux, which Venom is based on, is basically LFS with a rudimentary SysV type init and a source package manager. No USE flags or anything, just Pkgfiles.
It's very stable, extremely fun and easy to use, very fast and customizable, and above all it makes you a better programmer/user.
Try it on a vm https://crux.nu/

t. have been using Crux as daily driver for a year and wouldn't trade it for anything.

>>2913
>Venom
Why do you think Venom is better than Crux? From what I understand the main difference is that it has a different package manager. But crux is older and arguably more stable just because of that.

>>3025
Hey
I am just not installing it (systemd)
I know... Ugh, I know...
I am sorry!
It is just I am not installing it is all
HAHAHAHAHAHAHAHA

They said it is a drop in replacement, it's not.
https://forums.gentoo.org/viewtopic-t-1142068-highlight-cryptsetup+static+udev.html
>Hello, an update this morning asks me to disable udev for lvm2 & cryptsetup since I have static enabled for both, lvm2 (static static-libs) cryptsetup (static); why this change ? How to solve that ?
Systemd bug: https://github.com/systemd/systemd/issues/20600
Of course that soy piece of shit stamps WONTFIX.

>>3023
I dont, it's not on the list because i forgot to include it :p

what_in_tarnations.png
[Hide] (448.5KB, 759x543)

>>3036
>we are simply not going to rename all our internal symbols
<literally has to rename version to systemd_version (or something like that)
What is wrong with these people?

>>3036
Lol, of course it's Poettering himself WONTFIXing it. The Freedesktop shitters have been on the warpath with static linking for a while now so it's unfortunately no surprise they'll happily break it. Seriously, read some of the dynamic linking propaganda. It's exactly the same kind of dishonest shit you see with systemd, Wayland, dbus, etc.

If you forgot why you are trying to remove SystemD.
Here is a refresher:
https://yewtu.be/watch?v=RkFNMEk0xn8&nojs=1

[ebuild  N     ] sys-fs/udev-249-r3::gentoo
[uninstall     ] sys-fs/eudev-3.2.10-r1::gentoo
I have been putting it off for a few weeks. It finally came. What do bros? Should I make the switch to kiss or get mdev working?

>>3804
Definitely try setting up mdev. Actually, mdevd is much better and it uses the same config syntax as mdev. For configuration, there's https://github.com/slashbeast/mdev-like-a-boss and https://github.com/alpinelinux/aports/blob/master/main/busybox-initscripts/mdev.conf but I'd recommend going through, seeing which user/groups you actually need, and building up a minimal config based on that. I didn't bother being comprehensive, since most groups are superfluous, and some pose security risks if you actually use them (like putting you're regular user in the disk group). Here's my mdev.conf:
possible language: typescript, relevance: 7
$MODALIAS=.* root:root 660 @modprobe -b "$MODALIAS"

null    root:root 666
zero    root:root 666
full    root:root 666
random  root:root 666
urandom root:root 666
hwrng   root:root 600

console root:root 600
ptmx    root:root 666
tty     root:root 666

kvm         root:kvm 660
vhost-net   root:kvm 660
vhost-vsock root:kvm 660

fuse root:root 666

sd.* root:root 660 */etc/mdev.d/block

SUBSYSTEM=sound;.*    root:audio 660
SUBSYSTEM=graphics;.* root:video 660
SUBSYSTEM=drm;.*      root:video 660
SUBSYSTEM=kfd;.*      root:video 660
SUBSYSTEM=input;.*    root:input 660

SUBSYSTEM=net;INTERFACE=eth0;.* root:root 660 @ethtool -s eth0 wol g

To determine the uevents that my machine generates I created a script:
possible language: bash, relevance: 15
#!/bin/sh
exec >>/tmp/mdev.log
echo '<<<'
env
echo '>>>'
and ran it like so in mdev.conf: .* root:root 660 */path/to/script

>>3807
Appreciate it, will try to rig it up this weekend or the next.

>>3808
Did anyone tried stali 
https://sta.li/
It is suckless's distro with musl, no systemd and a /sucks dir for everything that sucks. Did anyone tried it?

>>3816
First time hearing about it. May try that if mdev doesn't work out.
>tfw distros without systemd becoming the unvaxed

ripstali.png
[Hide] (33KB, 403x547)

>>3816
>>3821
RIP sta.li. I don't think it was very actively maintained anymore anyway IIRC. I can highly recommend KISS Linux, as has been recommended a few times in here already. Everything is just POSIX shell scripts. It is the greatest shit ever. Been running GKISS for a while now, which is a fork that uses glibc instead of musl. I know glibc is trash, but I don't want to deal with patching stuff that isn't in the official repos because I'm a pleb. I've been kindof itching to switch anyway though

>>1748
I have been running openbsd for about a week and the main difference is even with my beefy computer bloatware like qutebrowser(has pulseaudio as dependency, btw) take 4+ seconds to load, twice the time it took in linux. Default tablet driver is make do mouse drivers soo it doesn't detect touch sensitivity by default, usbtablet driver seems good but i weren't able to make it work. Also no openbsd software respects the xdg directory standarts soo your ./ will be filled with dotfiles. For comparison I had only .config .cache .local and .pki(qutebrowsers garbage) dotfiles in linux but i have 12 dotfiles right now and some .core(obsd creates them when programs die unexpectedly, which is always) files that refuse to go away. The stability is over the top thought, i had a defect GPU that sometimes randomly locked the system and i had to reboot but in openbsd it just locks xorg and i can kill/restart xorg from another tty.

>>3804
Eudev is maintained again, you don't have to switch.

>>4075
That's normal. XDG is some Linux bullshit. But even in modern OpenBSD some things like Firefox or Chromium probably use it anyway, unless they patched it out.

>>4107
But it tickles my autism, this singlehandedly might be the reason to change OS for me. The worst part is if i change to linux root file structure is fucked soo linux won't be enough after i saw how well openbsd handles file structure by default.

lad.png
[Hide] (1.3KB, 640x480)

>>4113
Fun fact to make autists squirm uncomfortably: CP/M has no directories, and so all files are visible at all times.  There is a USER command though, that gives you like 16 different "views" of a floppy or hard disk, but it's basically just a hack.

>>4118
There were probably 10 files total in the system anyways

Sanco_8001.jpg
[Hide] (1.1MB, 2560x1920)

>>4123
A bit more than that (see pic), and especially once you start actually using the system and creating data files, program files, and so on.
Then there's all the 3rd party tools you could get from mail order user groups (or maybe from a BBS, if you were so lucky to own a modem back then).

>>1 (OP) 
Don't use a systemd distro in the first place. If your package manager keeps wanting to reinstall systemd dependencies for your fucking everything, then running your distro without systemd means you basically can't use your package manager (or will keep butting heads with it) which pretty much kills the appeal of your distro and means you are stuck manually compiling shit, at which point you would be better off running Gentoo which is actually good at manually compiling your software and having a systemd-free experience.

If you want to be systemd-free, find a distro that's closest to your needs (or otherwise has a strong enough community supporting it that you can tweak it towards your needs without too much difficulty) and use that in the first place. Life is simply better that way, and if you have a problem doing something in a systemd-free way, you can get help that actually fits your circumstances rather than sifting through an ocean of systemd shit.

Make the switch instead of sticking with a distro that treats non-systemd users like second-class citizens. You'll be happier for it.

>>12
There has been interest by systemd fanatics in bringing it to BSD, but it hasn't taken because it's too much work and because the BSD communities are more technically competent than most Linux distros and generally bigger on the "unix philosophy" (software tools should be small and specific to the task they fulfill, as well as replaceable) so they weren't interested in being handcuffed to doing things the systemd way and dealing with all the insane bugs and issues systemd spits out.

>>4289
>i don't know anything about the subject and i didn't read the thread. Here is a textwall of what you should do.

s.png
[Hide] (13.9KB, 640x480)

>>4289
There's no perfect solution for everyone.  A lot of people have some constraint or another to work around.  In my case, I only use old processors that don't do speculative execution and don't have x86 bugs and insanity.  Well gentoo isn't going to work out very well on such small/old hardware, and the other options I tried (devuan, slackware) just didn't work to the level I needed.  Those either didn't have some drivers I needed (would have required me to build an old 3.4 kernel) or they came with DRM video, which I don't want, because I want to keep using the old simple framebuffer that's been around since Linux 2.x which does exactly everything I need.
Maybe alpine would work, but it's not really worth the trouble to fiddle with it now that Ubuntu 16.04 LTS is on here and working fine for years without systemd.  The most I did was build a newer version of BusyBox, which fixed the ^Z bug I was talking about earlier >>2077

>>4291
What about distcc/crossdev? Couldn't you use another more powerful system to cross-compile Gentoo for that old hardware?

>>4291
>gentoo isn't going to work very well on such small/old hardware
>old processors that don't do speculative execution and don't have x86 bugs and insanity
Me too with gentoo. 1GB ARM. GCC takes 2 days, but you can always compile when you don't use it.

>>4292
I just don't have anything faster than old ARM boards.  They pretty much do everything I need.

>>4293
I don't think it would be necessary to build gcc very often, but stuff like Firefox or Chromium always have security updates, and those seem like they'd take forever, especially with all their crazy dependencies.

>>4294
>Firefox 
I hope you're talking about forks only.

>>4294
>don't have anything faster than old ARM boards
local second hand market, dell optiplex or some other used desktop. Air gap it and transfer files through usb drives. Or get more old ARM boards.
>getting rusted
>on my ARM machine
Install Palemoon

IMG_8206-txt.jpg
[Hide] (961.6KB, 2048x2048)

>>4295
>>4296
I don't use these browsers enough to really care about which one, it's more of a case of being forced to use a modern browser to login to some accounts once or twice a month.  Firefox seems rather slow lately though, and often pops up the "some scripts are taking too long to complete" error, whereas Chromium normally just works.  But I keep it around just in case.
In fact, I'd get rid of Xorg altogether if I didn't need to use a modern browser ever.  That would be cool because it would open up other options than Linux or BSD, and maybe I could even use even older hardware from the 80's and 90's.

>>4297
Firefox went pozzed and also got a lot of "donations" from google. 
Not only has their code become increasingly shitty these past few years, they also stopped caring about privacy completely, going as far as to forcefully link users to google because "we think analytics is important". 
Chromium is objectively better, and forks might be destined to die if they're too reliant on the upstream. 
Decent browser fucking when?

>>4298
>going as far as to forcefully link users to google because
Actually I'm wrong, they eventually added an opt-out option. It only took two years after the initial complaint.

>>4294
>I just don't have anything faster than old ARM boards.  They pretty much do everything I need.
Well, you could get some used hardware that is much more powerful, that you can outsource all the compiling to. Makes sense to think that it's not worth the effort, though. Could also try a BSD.

https://www.zdnet.com/article/major-linux-policykit-security-vulnerability-uncovered-pwnkit/
12 year old local root exploit in policykit. Of course, everyone who purged this shit from their computers is unaffected.

To this day I don't even know what policykit is supposed to do, ever since I deleted it I noticed no difference.

>>4395
>To this day I don't even know what policykit is supposed to do, ever since I deleted it I noticed no difference.
This so much by every piece of RedHat/Freedesktop/GNOME/whatever malware.

I wrote a script that kills dbus every 5 seconds. Nothing happened.

>>4396
>dbus
One of the stupidest thing I patched out of a package is using dbus only for instance detection. i.e. open file in the same instance without running another instance of software. They could've just write the pid to /run/ or accept unix socket.

I'm on Alpine now.
It's pure bliss.

Just another mention why SystemD is bad.
https://mgtowmirror.is/watch/?v=RkFNMEk0xn8

>Alpine
Alpine is pretty good. Alpine uses busybox and musl (you can install GNU tools if you want to). It has taken some ideas from Arch and Gentoo. It has an installer but you can install Alpine à la Arch/Artix (you can install the base system and then chroot and finish the installation). Alpine offers both stable releases and a rolling release (edge). Writing package scripts is as easy as Arch's PKGBUILDs.

After 10 years in development, ((( (((SystemD))) ))) had " 1,349,969, or nearly 1.4 million. With our happy-go-lucky metric, systemd comes out at about 5 percent the size of the kernel, which is crazy!
As another comparison, the line count for a modern implementation of System V init for the Arch Linux distribution came out to 1,721 lines."
<https://www.howtogeek.com/675569/why-linuxs-systemd-is-still-divisive-after-all-these-years/ 

If you are looking for a modern, fast and simple init system, just use RunIT: http://smarden.org/runit/

>>183
Retarded question, but what is that steaming thing?

>>4569
Systemd

Daikon_oden_and_Beer_by_shrkflickr_in_kyoto.jpg
[Hide] (3.1MB, 3264x2448)

>>4569
Looks like Daikon oden.

>>4595
Hmmm interesting. I wonder what's the meaning of the original unedited picture. Like, it seems so random: a dude forcing Madoka to eat a Daikon Oden. Maybe it's not random, and it has something to do with something that I don't know? Maybe something about Japanese culture?

>>4595
haha yeah that's totally it

>>4600
That's not a dude that homora

1618066022039.jpg
[Hide] (217.2KB, 1920x1080)

I'm kind of a newfag to Linux in general, but I have a question: Why would they want the init system to be more complex anyways? Why not just make systemd a simple init system that just does what it's supposed to do? What was their reasoning for all this?

>>4611
>What was their reasoning for all this?
The people behind systemd wanted a software suite similar to the one on Windows.

>>4612
Why would they wish to emulate something that is most likely very convulted and filled with bugs galore?

>>4614
redhat is malicious to make it more user friendly, anon.

>>4610
Ah. I'm retarded.

>>4
Thank you. I needed this.

>>4617
That list is a bit dated. I know that NixOS uses systemd for sure for one.

Scroll to the bottom of the page to look at some distros without systemd: https://nosystemd.org/

>>4116
s..sauce?

>>5199
Savaged by Systemd: an Erotic Unix Encounter, searx.

Systemd_scopecreep_chart.png
[Hide] (184.6KB, 717x648)

I started writing this because I wanted to know if there is even 1 thing that SystemD is good at, and I didn't find anything worthwhile.
tl;dr
Switch SystemDick to a sane alternative, like OpenRC (https://wiki.gentoo.org/wiki/Project:OpenRC), Runit (http://smarden.org/runit/) or GNU Shepherd (https://www.gnu.org/software/shepherd/).
Other options include S6 (https://skarnet.org/software/s6/), SysVinit (https://savannah.nongnu.org/projects/sysvinit), BSD init (install a *BSD and look at /etc/rc.d) and Busybox's init (https://git.busybox.net/busybox/tree/init/init.c)
If you are looking for a distro that doesn't have systemd, install Gentoo/Artix/Void/Slackware/Alpine/CRUX/Guix System and/or visit GNU/Linux distro thread: >>530
There is also a thread for "alternative" operating systems: >>4968

>inb4 but systemd is so fast!
As Lennart Poettering put it "For a fast and efficient boot-up two things are crucial: To start less. And to start more in parallel." You can set up other init systems to start up daemons in parallel, too.

>inb4 but systemctl is so easy to use!
So is OpenRC and Runit:
OpenRC:
# OpenRC runlevels are in /etc/runlevels
systemctl enable apparmor    → rc-update add apparmor [default]
systemctl [re]start apparmor → rc-service apparmor [re]start
systemctl disable apparmor   → rc-update del apparmor [default]

Runit:
possible language: bash, relevance: 10
# Runit runlevels are in /etc/runit/runsvdir/
systemctl enable apparmor  → ln -s /etc/runit/sv/apparmor /run/runit/service
systemctl restart apparmor → sv restart apparmor
systemctl disable apparmor → touch /run/runit/service/apparmor/down (or just delete /run/runit/service/apparmor symlink)
And that covers mosts of thigs you would use systemctl for.



Systemd
I just watched the "The Tragedy of systemd" presentation (https://www.vid.puffyan.us/watch?v=o_AIw9bGogo)
Some of his points were good, others were stupid (like saying that the feature creep in systemd is okay and that all software has bugs, so bugs in systemd aren't a big deal!). He is mainly concerned about the fact that systemd is not as portable as he would like (he is a FreeBSD user and developer). I don't recommend watching that presentation because I didn't learn anything new.

More links
>https://en.wikipedia.org/wiki/Systemd#Fork_of_components
>https://0pointer.net/blog/projects/systemd.html (cont: https://0pointer.de/blog/projects/systemd-update.html https://0pointer.de/blog/projects/systemd-update-2.html https://0pointer.de/blog/projects/systemd-update-3.html)
<summary: https://0pointer.de/blog/projects/why.html

>https://0pointer.de/blog/projects/the-biggest-myths.html (this is Poettering's answer to common criticism)

If you are looking for a distro to test systemd (hopefully inside a VM!): install Arch/Debian/Fedora.
>https://docs.fedoraproject.org/en-US/quick-docs/understanding-and-administering-systemd/index.html
>https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
>https://fedoraproject.org/wiki/How_to_debug_Systemd_problems



What should a PID 1 (init) do?
>https://suckless.org/sucks/systemd/ (check out the links on this page!)
>https://ewontfix.com/14/ (Broken by design: systemd)
>https://ewontfix.com/15/ (Systemd has 6 service startup notification types, and they're all wrong)
>https://wiki.gentoo.org/wiki/Comparison_of_init_systems

Example SysVinit scripts can be found here:
>https://github.com/gapan/sysvinit-scripts
>https://github.com/hut/minirc
>https://bitbucket.org/TZ86/initscripts-fork/src/master/ (pretty dead)
>https://github.com/kisslinux/init


Init daemon (runs as PID 1) is basically just AUTOEXEC.BAT that also reaps zombie processes (simple example: https://core.suckless.org/sinit/). Most inits also have runlevels. Nowadays, all good init daemons also supervise processes and handle dependencies. SystemD does all this, too. But the real question is that is there something that SystemD doesn't/shouldn't do? For example, should SystemD manage home directories (systemd-homed), should it come with an userspace OOM killer daemon (systemd-oomd)? Why does systemd do NTP daemon's and cron daemon's job? Binary logs by default? - Good luck trying to read those after a system crash. Also, how does systemd's journald comply with GDPR if it still can't filter logs on its own? Also, even if you didn't care about the feature creep or the maintainability/bugs, you should also consider the fact that the adaptation of systemd was heavily pushed by Red Hat (which is a corporation that mainly provides support for Red Hat Linux). That's pretty suspicious, if you ask me. Systemd also uses Goolag DNS by default and Goolag's NTP service by default.

>>5250
>I started writing this because I wanted to know if there is even 1 thing that Systemd is good at, and I didn't find anything worthwhile.
Okay, I found 1 thing. Just one thing: systemd-nspawn is quite nice. But everyone uses Docker or a virtual machine instead.

>>5250
people who say systemd is fast have never used another init system
void boots much faster than any systemd distro

32a.jpg
[Hide] (53.6KB, 400x500)

>>5252
My x60 (5400rpm hdd) boots to a WM in ~10 seconds with runit.
Talking about boot times in 2022 is a serious red flag.
Normal niggers are already sold on SSDs, and always use suspend to ram.
Even if booting took an hour it wouldn't be a problem, this isn't 1995, linux only can run for months just fine.
Pushing for fast boot times suggests they want you to depend on rebooting as a solution to problems.

It occurred to me that if init dies, the whole system dies with it (right?) So if you put a ton of code into an init (systemd) then won't that increase chance that something bad happens (and the whole system goes down)?

>>5256
One case for optimizing boot times is in cloud deployment. When you have over 200 servers running and you need to fix something, bring down a number of machines, rreboot or make more of them, it adds up. On a desktop system, none of this matters. Understanding your system and what each module does is better, so is simplicity. Systemd has no place on a regular install of an everyday user.

>>5271
At this point why are they even using Linux for big servers farms, they should be using an OS they can trivially move processes from one machine to another.  I don't mean VMs, that's a lame, inefficient hack.  All the work that's gone into that systemd pile of garbage to make reboots faster would have been better spent on a better server OS.

>>5272
Not exactly process migration, but you just described kubernetes.

>>5276
Yeah I was thinking more of the ability to dynamically relocate processes to other computers as a core feature of the OS.  Then you don't have millions of extra lines of code for all these containers and systemd hacks.

>>5269
try it out:
kill -SIGSEGV 1

kek. I just found out that systemd's *ctl utilities, like hostnamectl and localectl, freak out if systemd is not PID 1. It just displays an error massage saying that "systemd is not PID 1 - Can't operate." This happened on a Gentoo VM. The LiveCD booted using OpenRC but I decided to try systemd PS. Systemd sucks

Is systemd becoming even more monolithic?

Gentoo news: sys-apps/systemd-utils update needed
Title: sys-apps/systemd-utils update needed
Author: Mike Gilbert <[email protected]>
Posted: 2022-04-17
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: =sys-apps/systemd-utils-250.4

The currently installed version of sys-apps/systemd-utils may cause
kernel modules to fail to load on boot.

Please upgrade to >=sys-apps/systemd-utils-250.4-r1 as soon as possible,
and certainly before rebooting your system.

Gentoo news: Migration to sys-apps/systemd-utils
Title: Migration to sys-apps/systemd-utils
Author: Mike Gilbert <[email protected]>
Posted: 2022-04-19
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-apps/systemd-tmpfiles
Display-If-Installed: sys-apps/systemd-utils
Display-If-Installed: sys-boot/systemd-boot
Display-If-Installed: sys-fs/udev

The sys-apps/systemd-utils package was recently added to the gentoo
repository. This replaces sys-apps/systemd-tmpfiles,
sys-boot/systemd-boot, and sys-fs/udev with a single package. USE flags
are provided to allow each component to be enabled or disabled. This
change was made to significantly ease maintenance of tools split out
from systemd.

When upgrading to sys-apps/systemd-tmpfiles-250,
sys-apps/systemd-utils[tmpfiles] will be pulled in as a dependency.

When upgrading to sys-boot/systemd-boot-250,
sys-apps/systemd-utils[boot] will be pulled in as a dependency.

When upgrading to sys-fs/udev-250, sys-apps/systemd-utils[udev] will be
pulled in as a dependency.

At a later date, sys-apps/systemd-tmpfiles, sys-boot/systemd-boot, and
sys-fs/udev will be masked for removal once a suitable version of
sys-apps/systemd-utils has been marked stable and sufficient time has
been provided for users to migrate.

Possible problems when upgrading:

1. If sys-fs/eudev is present in the world file (@selected), emerge will
   abort the upgrade with a unsolvable blocker error. To resolve this,
   either remove sys-fs/eudev from the world file
   (emerge --deselect sys-fs/eudev), or disable the 'udev' USE flag for
   sys-apps/systemd-utils.

2. The 'boot' USE flag on sys-apps/systemd-utils is disabled by default.
   Users migrating from sys-boot/systemd-boot will need to enable the
   'boot' USE flag (in package.use) to continue receiving updates.

>extract """Duplicate""" code from daemons and move it to Systemd or the Kernel
>get rid of /etc
>Systemd is """modular""" t.poettering
<but you can't just take 1 binary/subprogram and use it without using the whole Systemd

+use Dbus for everything.

>>5321
Soon there'll be systemd-X (sorry, systemd-wayland) and systemd-kernel packages and Poettering's pet dragon will have successfully swallowed the entire @world.

>>5562
It isn't even the final form, wait til you get systemd-wine, systemd-windows and finally systemd-os, rebranding any software to systemd.

https://searx.smlnd.xyz/morty/?mortyurl=https%3A%2F%2Fwww.phoronix.com%2Fscan.php%3Fpage%3Dnews_item%26px%3DAkamai-Security-Panchan

So, this is the power of systemd? now we have botnet that infected user that use systemd to mine crypto? It's a fucking clown world all over again in their init system. Lel.

>>5957
>SSH dictionary attacks
literally just retards using "1234" as their password
>now we have botnet that infected user that use systemd to mine crypto
it installs a service, it could do the same with any other init

>>2566
it definitely boots sysv by default and not systemd
nothing installed seems to depend on systemd to run either

Teach me how to convert systemd scripts or whatever that thing is that I see in many RPi tutorials.

>>4
>>4621
https://sysdfree.wordpress.com/

https://web.archive.org/web/20210706060304/https://without-systemd.frama.wiki/linux_distributions_without_systemd

>>5250
http://ebin.city/~werwolf/posts/systemd-sucks/

https://www.unixsheikh.com/articles/the-real-motivation-behind-systemd.html

>>1751
What's pozzed about FreeBSD? Why isn't OpenBSD pozzed? (If you know anything about Theo being a massive drama fag and bitching at people in mailing lists forevar)

>>6219
freebsd is one of the first to adopt a CoCk, filled to the brim with trannies, runs freebsd on macshit vm.
Theo is a massive drama fag but he is autistic about software quality and security, not about bullshit politics.

>>6220
Nowadays, technology in general has been pozzed to the point that FreeBSD may actually be the second best option, though, because Linux is so much worse and so are both NetBSD and Dragonfly. And Linux now has all the trannies and CoCks, and worse than that, corporate control.

>>6222
There is no reason that is true.
FreeBSD is under tons of corporate control, and has all the trannies and CoCks. For software compatibility and performance, nothing beats Linux. If no pozz is the goal, OpenBSD is the answer. In no way is FreeBSD a viable option.

>>6219
>nerd is socially inept and talks shit on the internet
Wow he's like an imageboard user, cancel him! Meh. Call me when Theo does something that undermines OpenBSD development like purging contributors because some woman who doesn't even know programming told him to like FreeBSD did. Look up CodeGirl on Encyclopedia Dramatica archives.

eeb10e2e6843f23ff54370b34245b44e92912942.gif
[Hide] (2.1MB, 240x256)

* More about Systemd: https://ihatesystemd.com/
* World after Systemd: https://the-world-after-systemd.ungleich.ch/
Also, replacing Systemd will be much harder than replacing sysVinit with Systemd.

>>5256
my openrc pc boots about 40 seconds average with 7200 rpm but I had like root and swap encryption and plasma 5.
I'm sure it can be much faster without encryption but I don't rely on suspends so much,
I also had hibernation but it wasn't reliable whenever I upgrade my system/kernel as it would boot with the new kernel while the one in memory/hibernation was still older kernel (uname -a) so it's not safe (unless I logged out but still not very safe/stable). hibernation also messes with my damned gpu drivers.
shutting down is also nice since it commits stuff in drive write cache.

don't know what people are doing to get slow boot times. even had core 2 duo laptop that did boot under 30 seconds. not like that's a long time, just enough time for me to plug in my router.

>>6222
How are NetBSD and DragonflyBSD pozzed?

My body is more compatible with BSD kernel than Linux, and I am interested in those BSDs for future use. The HAMMER filesystem of Dragonfly spec looks good, similar to the silk MacOS filesystem.

Thanks,
Alexander

>>6293
Your body is also never going to be a woman and is more compatible with a rope. DragonflyBSD has a man page for covid, see the alt os thread. NetBSD is famous for Theo's legacy.

low.png
[Hide] (1.7MB, 1600x900)

>>6293
The man pages pushing the shots were what I was thinking of. 


>>6294
NetBSD has it too. To me that's worse than the CoC and the trannies. FreeBSD doesn't have it, and the Linux foundation (infested with trannies anyway) and IBM (also known as Red Hat) and Linus Torvalds himself are way worse than anything I have seen coming from them. 

So that's why these days, FreeBSD looks like the lesser evil to me. Other than OpenBSD, of course. I would say that this can't get any worse, but wait until Theo becomes a tranny next year and the entire OpenBSD project implodes and Google takes over. Of course, it's just a joke, but in this clown world any joke that you can come up with has a considerable chance of being prophecy.

>>6295
FreeBSD and Linux are on par to me. Except Linux is faster and more well supported.
I wouldn't even think about what you said about OpenBSD, touching the biggest piece of wood I can find right now.

>>6295
>Theo becomes a tranny next year and the entire OpenBSD project implodes and Google takes over. Of course, it's just a joke, but in this clown world any joke that you can come up with has a considerable chance of being prophecy.
I mean, he might... He's a nerdy autistic dude and I've seen middle-aged, 6'4" dudes with families turn tranny out of nowhere. He's a prime candidate honesty, especially with how volatile he is. Its why people joke about Joshua Moon (owner of the New Zealand Kiwi bird website) trooning out despite the fact his website is very staunchly anti-troon.

>>6296
Also keep in mind that FreeBSD has the most use out of any of the BSDs (like 3/4ths market share?), which means more support. OpenBSD guys have created some cool stuff, but you don't need to actually use OpenBSD since it all gets ported very quickly to other BSDs and OSes. The documentation also reminds me of Gentoos, which is a great thing. Way easier to learn about than the hideous OpenBSD website (not hideous because its lightweight, mind you, but because its badly designed).

Does anyone have experience with Slackware or its forks like Zenwalk that make the user experience a bit more friendly?  I'm building my first Linux PC and I want something stable that will let me write programs without much fuss.  I've used Win7 for all my adolescent and adult life, but it's kind of a pain to code in, so I want something similar to that which won't be backdoored by the NSA before the end of the decade.

Slackware seems like a good non-systemd OS since it's old, stable, and is a dictatorship which is presumably free of trannies, but it also seems pretty advanced and I'm only familiar with the basics of Linux (though I do know how to use the command line comfortably).  It's hard to find information on, though, due to the long period between stable releases: most places don't seem to have covered the latest stable release from this February, and prior to that they were all lamenting how long it had been since the last stable release.  Any YouTube videos are just "let's install Slackware" videos that have nothing meaningful to say about the OS itself.

>>6386
I don't know about slackware. If you are a beginner and want no fuss non-systemd distro, artix and gentoo are your best bet. Debian-based system are always full of fuss.

>>6387
>artix
I'm skeptical of anything related to Arch, but that is mostly just due to memes and my dislike of anything that encourages frequent updates which break things.
>literally installing gentoo
I would normally have scoffed at this, but apparently Calculate Linux exists for people like me - it's just a fork of Gentoo with a proper installer.

After a bit more looking around, I think I'll experiment with Zenwalk, Calculate Linux, and maybe something distinct like Void.

>>6390
I think you'll like Void. It's simple enough to use by a beginner while giving its user complete control, as well as zero bloat.

>>6390
I'm personally not a fan of Artix. Unfortunately made the mistake of recommending it to people without extensively testing it and regretted it, because all of them had problems with it, because it's a piece of shit. Honestly, there are no good distributions anymore. That's my conclusion from trying pretty much all the ones that matter, and it resulted in me using BSD instead because there was nothing left. Are you a beginner? Because if you are, then definitely don't go with any of those. If that's the case, just use whatever works out of the box. You can learn on anything that has a terminal and that you can install things on, and that's every distribution. You are going to have to learn if you want to have a good system. Especially if you want to use less common distributions, because all of those have issues and you are going to need to know what you're doing to work around them. Also, you are not going to be able to use Gentoo if you don't know how to use the terminal and how to set up X. You have to know all the basics first. Though if you do want to skip that process, then go with Arch. It's completely pozzed, but it works and if you need information, you will probably be able to find it. If you don't have the knowledge, you are not going to be able to avoid the poz.

>>6392
What is your problem with Gentoo?

>>6386
>Does anyone have experience with Slackware or its forks 
A little, see >>6400
In my opinion, Slackware is not as comfy as Gentoo or Artix. See, >>932 and >>4081

> I'm building my first Linux PC and I want something stable that will let me write programs without much fuss. 
I recommend Debian or Devuan, if you want a stable distro. Gentoo is another good option. Slackware is stable in a similar way like OpenBSD is (but installing new software for Slackware is harder). Also, I recommend you avoid Arch/Artix installers and Gentoo installers because they suck. Instead use the official installation guides from wikis. If you are new to GNU/Linux, you might want to read The Linux Command Line book: https://linuxcommand.org/tlcl.php Both Arch and Gentoo have good documentation on their wikis (the Gentoo Handbook contains everything you need to know about installing Gentoo).

>>6391
It certainly seems promising, that's for sure.

>>6401
>A little, see
A giant copypasta is not experience.  What is it like attaching new hardware devices to distro X?  What is it like trying to roll back an update that broke something you were using for a longer term project?  If I wanted to write a program in C that had a couple small dependencies (say, a simple GUI library), what would that process look like?  That's the kind of stuff I want answered, not vague platitudes about being "comfy" or "for beginners."

I consider myself a tech beginner and a Linux novice since I don't do much dedicated programming (which I'm looking to change), but I'm head and shoulders above most normalfag devs who would vomit at the sight of a command line and I do have an education from a college that was taught to me by white men.  I'm sure that I could do any individual thing needed for a power use installation like pure Gentoo or even LFS, but I know that I enjoy it when computers have sane defaults and do work for me.

>>6403
When you are choosing a distros, you need to consider:
1. Can I trust this distro and its maintainers? (they have basically root access to your system!)
2. Does this distro have all packages I need?
3. Does this distro have a future, or will it die soon? (Source Mage GNU/Linux is example of distro that has too small community and Void had some internal drama some time ago...)
I recommend you install either Arch or Artix because they meet the criteria above and they mainly just work. Arch could better choice than Artix because it's easier to find help with Systemd using Goolag.

>What is it like attaching new hardware devices to distro X?
Plug it in and it just works on all GNU/Linux distros (unless you need proprietary drivers). Using non-free drivers is easiest on Arch/Artix and Gentoo.

>What is it like trying to roll back an update that broke something you were using for a longer term project?
I never have experienced major breakage after an upgrade in years while using GNU/Linux (in general). And I gave up using Slackware because installing stuff on Slackware is not very comfy (you need to solve the dependencies yourself and not everything is packaged on Slackbuilds). 
Archwiki has instructions for downgrades but downgrading and doing partial upgrades are not supported on Arch. See, https://wiki.archlinux.org/title/Downgrading_packages and https://wiki.archlinux.org/title/Arch_Linux_Archive  On Gentoo you can downgrade and do partial upgrades. And on Gentoo selecting a particular version of a package is easy and you can mask broken packages if you want to.

>If I wanted to write a program in C that had a couple small dependencies (say, a simple GUI library), what would that process look like?
You need to just run 1 command to install GCC and tk (or whatever GUI lib you want to use). Debian has a package called build-essential that contains some standard C/C++ development stuff (on Arch and Artix there is a similar package called base-devel).

> That's the kind of stuff I want answered, not vague platitudes about being "comfy" or "for beginners."
Write better question then.

>I consider myself a tech beginner and a Linux novice
You might be interested in https://linuxcommand.org/tlcl.php

>or even LFS
Don't, unless you want to maintain and test every package yourself. LFS is not good for actual use. Also, Gentoo is automated but LFS is not. Gentoo has maintainers who are maintaining and testing packages but LFS has only you.

>I enjoy it when computers have sane defaults and do work for me.
I recommend that you install Arch, but Debian (systemd) or Devuan (no systemd) are also good choices. Debian/Devuan come with a default GUI but other recommended power user distros don't come with a default GUI (instead you need to install a WM or a DE and Xorg). Installing Xorg and a WM is trivial on any GNU/Linux distro. On Arch and Artix, you need to run 1 command to install everything you need to have a GUI: pacman -S pulseaudio pulseaudio-alsa pavucontrol xorg-server xorg-xinit xorg-xrdb xorg-xset xorg-setxkbmap lightdm lightdm-gtk-greeter ttf-dejavu xf86-input-libinput xf86-video-vesa feh rofi alacritty xfce4 xfce4-goodies  Then you need to use systemctl or rc-update to enable ligthdm (Lightdm is a GUI login screen a.k.a. DM that can be used to start Xfce4 easily).

I recommend you check out the Arch/Artix copypasta: >>4081 Because it contains everything you need to install and I highly recommend using rua AUR helper because it's the best tool since it allows you to easily review PKGBUILD scripts.


I really recommend you try Arch Linux. After you have everything set up, you just need to run sudo pacman -Syu a few times a week (and check out the RSS feed).

Also, you really should try Arch or Artix using Virtual Box VM (https://www.virtualbox.org/).

Using SystemDick can cost you money:
>Microsoft Azure customers' virtual machines (VMs) running Ubuntu 18.04 have been taken offline by an ongoing outage caused by a faulty systemd update.
>The outage started nine hours earlier, around 06:00 UTC, after the affected customers upgraded to systemd version 237-3ubuntu10.54 and their VMs started experiencing DNS errors, with no DNS resolver addresses available on impacted systems.
<https://www.bleepingcomputer.com/news/microsoft/microsoft-azure-outage-knocks-ubuntu-vms-offline-after-buggy-update/

>>6404 
>downgrading and doing partial upgrades are not supported on Arch
Lol, is this the current state of vanila arch right now? I do partial update all the time in Artix. There's nothing wrong with partial update as long you know what you're doing. Well of course you shouldn't do partial update on sensative packages like icu,sudo,nettle because that would make you unbootable to your display manager. Lets take a scenario where you broke 1 program. You got an error looking for /usr/lib/example.so.34 library is missing. You can always do pacman -Qo /usr/lib/example.so.34 to find which package that is responsible for that breakage. It will name you the package so you could upgrade that single package accordingly. If you lost track on other possible missing packages, use "pactree <package>" to see the whole relatable dependancies of that package in hierarchical result.

kek, poweroff and reboot requires root but you can still use systemctl poweroff and systemctl reboot as a regular user and without sudo...  This means that any normal user can powerofff a server that has systemdick. I tested this on Debian (stable, bookworm and sid/unstable) and Xubuntu LTS. On Arch Linux, any user can use poweroff and reboot as well without root rights/sudo (poweroff is symlink to systemctl). This isn't allowed on any non-systemd distro that I have used (Void, Alpine, Artix, Devuan, Gentoo, Slackware, fucking GoboLinux, ...)

screenshot.png
[Hide] (2.4KB, 348x234)

do_you_hate_handicapped_people?.jpg
[Hide] (70.6KB, 269x389)

>>8429
Are you sure? On a freshly installed arch VM I get pic related.
Also, are you sure this isn't a logind thing? Usually when you login on a physical display (in logind jargon this would be a "seat") logind will give you extra permissions via ACLs on certain files in /dev/ (mainly audio, video and input related). For the poweroff/reboot thing I suspect systemd just detects if the user invoking the command has a seat and goes from there. IMHO it's a good security model. At the very least it's more secure than adding your user to the relevant system groups, but ofc it's still soystemd. seatd is supposed to be an alternative, but I'm not sure if it does the same thing.
That being said, having no revoke syscall breaks the model anyway: files opened when you have a seat retain permissions even when the seat is killed but the user hasn't fully logged out yet (i.e. if the same user logs in both via a physical display and ssh at the same time, opens /dev/snd/controlC0 and logs out of the physical display). See: https://invidious.snopyta.org/watch?v=ZTdUmlGxVo0
I'm curious if you'd still be able to poweroff if you logged in via SSH instead of on the tty/display manager.

screenshot.png
[Hide] (13.8KB, 611x425)

>>8457
Whoops, I fucking accidentally tripfagged
>>8429
Doesn't seem to work on Debian 11 either.

hatred_of_handicapped_people.jpg
[Hide] (46.8KB, 252x326)

This one works a bit better

>>8458
reboot is a syscall, systemctl isnt its just a program doing a priv check for no reason ( postfix: actually its because its expected to be running inside a wm and so it doesnt have tty control hence the need for root  ), the program running in the tty (eg. the window manager) can call reboot without needing root, this is true for all the calls that change hardware settings

>>8458
reboot is a syscall, systemctl isnt its just a program doing a priv check for no reason ( postfix: actually its because its expected to be running inside a wm and so it doesnt have tty control hence the need for root  ), the program running in the tty (eg. the window manager) can call reboot without needing root, this is true for all driver related calls and ones that change hardware settings

>>8462
>expected to be running inside a wm and so it doesnt have tty control
Being logged into a tty just sets the user of /dev/tty1 (or /dev/tty2 or whatever) to your user. Any process running as your user has "tty control" (not sure what you mean by this), once you're logged in.
>the program running in the tty (eg. the window manager) can call reboot without needing root, 
Calling the reboot syscall as anything other than root will never work ( there's literally a privcheck in the kernel source code: https://elixir.bootlin.com/linux/latest/source/kernel/reboot.c#L707 ).
>this is true for all driver related calls and ones that change hardware settings
Not true at all. I'm surprised someone can actually think this.

Screenshot_2023-02-07_17-13-46.png
[Hide] (20.6KB, 711x120)

>>8463
theres only one tty per user idiot and only one program can execute on it what do you think unix means retard, every subsequent program is in a psuedo terminal only the real tty ( /dev/tty0 ) is allowed to make ioctl and driver calls 
and  its checking if the process has the boot flag not if its root, which the programs in the tty always inherit since thats the fucking tty designated as master, idiot  

youre clearly a retard that never wrote driver code, all driver calls are blocked unless you are the tty program or bypass it using root

Too_much_bait.png
[Hide] (91.4KB, 625x626)

screenshot.png
[Hide] (34.2KB, 581x204)

>>8465
>theres only one tty per user idiot
Not true. I can login on tty1, tty2, tty3, etc. as the same user concurrently.
>only one program can execute on it
Not true. Look up what a controlling terminal is ( good resource: https://www.linusakesson.net/programming/tty/ ).
>every subsequent program is in a psuedo terminal
Not true. Multiple programs can have the same controlling term and process group. Multiple processes be controlled by the same actual tty (not pty). Pseudo terminals are created by writing to /dev/pts/ptmx, they're not created automatically once the second process of a controlling terminal is spawned.
>only the real tty ( /dev/tty0 ) is allowed to make ioctl and driver calls
Not true. ttys don't issue ioctls, user space programs do. There is no such thing as a "driver call" (be precise if you wanna call other people names, nigger). tty0 is just a kernel level alias to the currently active virtual console.
>its checking if the process has the boot flag
It's called a capability, and only root normally has that one. You should really scroll up and read the comment before the function.
>which the programs in the tty always inherit since thats the fucking tty designated as master, idiot
Completely wrong. That capability isn't even used in the tty driver ( https://elixir.bootlin.com/linux/latest/C/ident/CAP_SYS_BOOT ). See for yourself. Try writing a simple program that just calls the reboot syscall and see if it works when running it directly from a tty.
It doesn't work, you're wrong.
>youre clearly a retard that never wrote driver code
Post some driver code that you've written (>implying) so that we can all laugh at it.
>all driver calls are blocked unless you are the tty program or bypass it using root
Not true at all.
>idiot, idiot, idiot
That all you got?

>>8473
	mov $169, %rax
	mov $0xfee1dead, %rdi
	mov $672274793, %rsi
	mov  $0x1234567, %rdx
	mov  $0, %rcx
	syscall
this on tty0 does a reboot without root you fucking loser
ONLY tty0 is the actual fucking tty theres only one fucking kernel you clown every other process after the first has a fake tty retard and theres literally tty_ioctl you fucking retard which is specifically for controlling the fucking screen and keyboard loser you literally dont know shit you dont even know that the kernel has fucking driver calls you need to use like kernelmodesetting and drm which is a fucking driver loser only the first program to take master is allowed to make those calls imbecile 
keep showing how clueless you are

>>8476
Holy shit, you sound like an ESL nigger.
>this on tty0 does a reboot without root you fucking loser
It literally doesn't. You clearly haven't actually ran it. You're fucking retarded.
>ONLY tty0 is the actual fucking tty
Addressed in the post you're referring to. All tty's are kernel objects (there all just as "real" as each other lmao), tty0 just points to the tty corresponding to the active virtual console. That's it.
>theres only one fucking kernel you clown
What the fuck? I claimed otherwise where?
>every other process after the first has a fake tty retard
No they don't. Multiple processes can be associated with the same controlling terminal (tty). Just check ps moron.
>theres literally tty_ioctl you fucking retard which is specifically for controlling the fucking screen and keyboard
OK, and? Should I spoonfeed you? ioctl is a syscall. Syscalls are issued by userspace processes. tty's don't issue ioctls lmao. You were wrong when you said:
>only the real tty ( /dev/tty0 ) is allowed to make ioctl and driver calls
You've got it backwards. The tty driver is already running in the kernel's address space. It doesn't need to make a syscall. The whole point of a syscall is to context switch into the kernel. There isn't a single line of kernel code that makes or issues a syscall. You have no clue what you're talking about, you have zero fucking reading comprehension and don't even understand what I said in the post you're referring to.
>you dont even know that the kernel has fucking driver calls
There is nothing in the Linux kernel called a "driver call". You can use system calls to interact with drivers (i.e. using ioctls or reading/writing to device files), which essentially bridge userspace and kernel space. You've just made up your own terminology because you don't know shit. Again, be precise if you wanna call other people names, nigger.
>keep showing how clueless you are
Imagine saying this after being proven wrong again and again. Absolutely embarrassing.

reboot.mp4
[Hide] (208.6KB, 1284x822, 00:29)

>>8476
Video just for you. As expected it returns EPERM with a non-root user. You are the blackest gorilla nigger.

>>8478
it does loser, youre clearly too stupid to know how to assemble as proven by your pathetic attempt at retard semantics after being exposed for an imbecile
an ioctl to a driver is calling something in the driver ie. a fucking driver(SPACE)call  retard
youre so fucking clueless you dont even know obvious shit like the fact ioctl calls require opening the file descriptor in /dev loser only the ONE fucking program running on tty0 can open /dev/tty0 you fucking imbecile and make ioctl calls to it, i said this 3 fucking times now i never said the tty make iotcl calls nice strawman you fucking peabrain all of /dev/tty files above 7 are all fake you imbecile, thats how clueless you are, you cannot use them in driver calls even if you own them loser because they are not real only tty0 is the actual fucking tty with hardware control ie. only ioctl calls on /dev/tty0 fucking do anything for hardware and drivers which i fucking said 3 times now you fucking clown

>>8479
maybe because its vm 
use real hardware or exit properly

>>8480
>i never said the tty make iotcl calls
you literally did in >>8465
>only the real tty ( /dev/tty0 ) is allowed to make ioctl and driver calls
Learn english.
>an ioctl to a driver is calling something in the driver
I know what you meant, but you sounded like an idiot so I called you out.
>only the ONE fucking program running on tty0 can open /dev/tty0
Not even this is true. Try doing anything with /dev/tty0 from the current virtual console. It won't work. It'll just give you a permission error, since it's owned by root with mode 620. And again, multiple programs can run on a given tty. ps aux | grep tty. I bet you don't even know wat a controlling terminal is.
Rest of your post is presumptuous bullshit.

>>8481
Or maybe because you're just wrong. Confirmed for not running his own program. Fucking retard.

>>8484
do this then retard
	str: .string "/dev/tty0"
	mov $2, %rax
	push str
	mov %rsp, %rdi
	mov $2, %rsi
	syscall
	mov %rax, %rdi
	mov $16, %rax
	mov $19258, %rsi
	mov $1, %rdx
	syscall

>>8480
Holy shit, calm the fuck down, sperg.

Wait a minute, I just realized that this thread was the first post in this board.
Perfect way to found a /tech/ board.

>>8644
systemd removal thread won't work if it doesn't get started as thread 1

010e07b3f78c7e6bee56d5fbea528f39630f6951241154be03e673f4460145e0.jpeg
[Hide] (89.3KB, 695x467)

>>8773
heh

>>8773
LMAO!

>>8773
lol

Make a niglist of distros that accepted the systemdicks and when possible the people who shilled for its acceptance.

>>9140
It is easier to make a list for the inverse.

>>6392
>all of them had problems with it, because it's a piece of shit.
What were these problems?

hehehe.jpg
[Hide] (16.5KB, 473x476)

>>6224
Corporate control comes with CoCs and funding. So all the big projects are pozzed in that way. Except OpenBSD, where Theo told the military industrial complex to fuck off and keep their money (with strings attached), and then as a result ended up going through some periods where he had trouble paying his electric bill. Maybe he will have the last laugh in the  end though, as the american empire and its fiat dollar system are quickly falling apart.

NetBSD's The Guide teaches everything you need to operate a NetBSD system daily and a lot more. Even if you have never used some kind of Unix system, you will know how to use NetBSD after reading the guide. For more information on individual programs, the man pages are there.

OpenBSD's FAQ teaches all you need to operate an OpenBSD system daily and a little more (the firewall section is a little more than you need). For more information, you have the man pages.

Neither system is hard to use, in fact they're much easier to use than Linux, Windows, or FreeBSD. Additionally, if you have used a Linux beyond just the Windows imitation GUI of the typical distro, you're already most of the way there in knowing how to use these BSDs, you just need to learn the different syntax of commands that do things you're already familiar with like listing all the disks plugged into the system and mounting the filesystems inside them.

#1 issue with people who think these BSDs are hard to use is that they don't read.

>>13071
netBSD always caught my attention because it supposedly can run on a lot of different hardware. How come nobody else can do the same? Is netBSD just easier to write drivers for?

>>13072
>How come nobody else can do the same? Is netBSD just easier to write drivers for?
Linux has similar or better cross platform support than NetBSD, however for NetBSD making code portable is the main priority.

>>13071
I'm interested in BSDs as an alternative for loonix but I would like somebody to answer these questions for me...
How is hardware support for modern PCs? If I can't live boot on a new machine and get going then I don't want it.
How is backwards compatibility on the software side? If there's another GLIBC situation then I don't want it.
How is software distribution done? If it relies entirely on package maintainers then I don't want it.
Can it run WINE and vidya? Is it slow?

>>13074
>Can it run WINE and vidya? Is it slow?
Probably not. BSD users are glad when they have graphic drivers at all and then it's just a shitty port from Linux.

elephant.jpg
[Hide] (13.6KB, 500x500)

>>13075
I already can't run wine on ARM. And I don't load the GPU drivers in Linux, because gaymes got shitty when they all went 3D. Now the soydevs incessantly suck the GPU cock even when they want to do simple 2D graphics. I'm surprised they don't need it for text yet.

Hello?_Gook_police?.png
[Hide] (70.9KB, 550x678)

>>13072
It's mostly a culture thing. Supporting as many machines as possible is one of NetBSD's goals. It's actually easier to write drivers for Linux, Linux has an absurd amount of drivers and its developers have come up with lots of ways to reduce work when writing them.

NetBSD has also done a lot of work to help get this done, for instance, GCC only supports VAX to this day because NetBSD developers maintain it, and it has an automated testing framework that tests the system and pkgsrc on many architectures (and in the case of pkgsrc other OSes too) to ensure the system stays working. 

NetBSD userlands also maintain backwards compatibility with old kernels. If a device ever gets a NetBSD kernel, it keeps on working forever. This is why there are still new binary packages for the PlayStation 2 NetBSD port that was abandoned in 2009:
http://www.jp.netbsd.org/ports/playstation2/
http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/playstation2

>>13073
The Linux kernel runs on far more platforms than NetBSD. However, most of those platforms aren't supported by a single distro, vendors make their own Linux-based systems for those architectures. A minority of architectures only run something like Buildroot that doesn't work for general purpose computing because Buildroot doesn't have, among other things, a way to update the system or install packages, which are done by reinstalling. For instance, the Linux kernel supports SH-3, but there are no SH-3 Linux distros, while NetBSD runs on several SH-3 machines.

Additionally, when Linux distros run on something other than ARM SBCs or x64 desktops, they're often very limited. NetBSD supports running on systems with no screen and only a serial terminal very well, has first-class support for installation over PXE and root on NFS, etc. With Linux, you have to figure out which distro supports PXE, which distro supports serial, and so on. For instance, I have a Hyperbola Linux install with working serial, but I had to install in a VM and configure serial before I could put it on real hardware.

If NetBSD is available on a machine, it means that the whole NetBSD system and binary packages are available for it. Not the case on Linux. Gentoo runs on PA-RISC, but you'll have to build packages on those 20yo machines yourself. NetBSD has binary packages for all platforms.

>>13074
>How is hardware support for modern PCs?
It's pretty good, but there are some details. The BSDs are going to work and support all hardware on most desktops, but there are some caveats. You need to check if the onboard wi-fi if any is supported. Even when an ethernet card is supported, most likely its hardware acceleration (checksum offloading, etc) isn't. OpenBSD doesn't support nvidia cards other than some very old ones from the 2000s. NetBSD used to be in a similar situation, but it's getting Nouveau support soon, although if you used it you know that driver is slow and buggy. Intel and AMD graphics cards are well supported. OpenBSD doesn't support Bluetooth at all. Also, don't expect the BSDs to support everything on a machine that just released, usually they're 1-2 years behind.
 
It's more complicated on laptops, you need to shop for a laptop that is known to be well supported, otherwise it's very likely that the system will install, but there won't be drivers for most of the hardware.

>How is backwards compatibility on the software side?
OpenBSD doesn't have any software backwards compatibility.
NetBSD has backwards compatibility going back to the 90s.

There's no reason to have software backwards compatibility other than enabling the existence of proprietary software, however. In OpenBSD, a new release comes with repositories completely rebuilt for that release, you're supposed to update your packages when you update OpenBSD, that'll reinstall all the packages you have installed.

>How is software distribution done?
OpenBSD is only supposed to be managed by its package manager. OpenBSD's repositories are small and outdated. Also, the OpenBSD package manager is written in Perl and VERY slow.

NetBSD, following its theme of portability, has a packaging system that runs on many operating systems, not just NetBSD. Thanks to this, it actually has one of the largest software repositories, bigger than most Linux distros, because all the users of proprietary unices and some more obscure systems like MINIX flock to NetBSD's package manager and help maintain it. NetBSD's packaging infrastructure is called pkgsrc, it's source-based and actually very much a pain in the ass to use, but you should just install a program called pkgin (there's an option in the installer to install it easily) that is a binary package manager and works very well. 

>Can it run WINE and vidya?
OpenBSD has no games. I've unironically ported some FLOSS games to it so I had stuff to play. It doesn't even have many emulators, if you happen to be able to live off of emulation.

NetBSD is the same, effectively, "there are no NetBSD games". However, NetBSD has a Linux compatibility layer to run Linux software, and it also has WINE.

>Is it slow?
OpenBSD is one of the slowest systems I have ever used, the only slower ones I know are Solaris and Windows.
NetBSD is significantly slower than Linux and FreeBSD, but one of the faster systems today.

Also, OpenBSD is very bad for realtime response times, this means that games will stutter heavily even if you have a low spec game on very powerful hardware.

>>13082
>This is why there are still new binary packages for the PlayStation 2 NetBSD port that was abandoned in 2009
Damn that's sick.
>The Linux kernel runs on far more platforms than NetBSD. However, most of those platforms aren't supported by a single distro
Ah, that's an interesting distinction, breadth vs depth basically.
>NetBSD has a Linux compatibility layer to run Linux software, and it also has WINE.
Is that comparable/related to FreeBSD's Linuxulator by any chance?

>>13083
>breadth vs depth
The difference here is each BSD is their own distro and kernel. Linux is just the kernel.
Linux the kernel runs on many platforms. The kernel + userland (thus package managing system) forms the distro. You can make a NetLinux today by writing or taking a package manager and start your binhosts with a build for each platform you want to support. The thing is there is no distro whose focus is to support as many arch as possible.

>>13075
>>13082
Thank you both for your answers. So the way I see it the BSDs are not much better than Linux, although NetBSD is a little promising... I've been looking for ways to live boot it but this is turning out to be more challenging than I thought.

>>13085
NetBSD doesn't have a live boot, You can install it in a VM or spare machine.

I installed it to a Nintendo Wii recently.

>>13090
NetBSD doesn't seem to offer live boot images however there are ways to create them by the end user:
https://github.com/IIJ-NetBSD/netbsd-src/blob/master/BUILDING
https://www.netbsd.org/gallery/presentations/jschauma/nblivecds.pdf

68747470733a2f2f747774702e746f6765747465722e636f6d2f73686f772f6c617267652f626778677335-2668458528.jpeg
[Hide] (36.1KB, 640x480)

>>13084
>The thing is there is no distro whose focus is to support as many arch as possible.
In the embedded world you basically make your own distro from source with yocto and you configure it with the correct toolchain and compiler flags and everything else to optimize for your custom hardware. A lot of the time that includes a custom kernel or kernel patches straight from the hardware vendor so there is scope to have an autistic argument about whether that counts as "real linux" running on all these devices.

>>13094
I imagine it's like Android where the vendor abandons the hardware after a few months and you're stuck with a specific kernel version that is eventually not supported by other programs anymore.

>>1 (OP) 
>Discuss methods to remove >systemd.

I'm sure you heard the news already but anyway: https://www.openwall.com/lists/oss-security/2024/03/29/4

>After observing a few odd symptoms around liblzma (part of the xz package) on
Debian sid installations over the last weeks (logins with ssh taking a lot of
CPU, valgrind errors) I figured out the answer:
>
>The upstream xz repository and the xz tarballs have been backdoored.

Long story short:
>Debian and Fedora patch OpenSSH daemon to link libsystemd include sg_notify()
>libsystemd links liblzma
>liblzma is compromised over the course of a year or more
>Every distribution which includes given patch for OpenSSH are vulnerable, other distros (esp. non-systemd) are probably fine.

Poettering claims you don't need systemd to be vulnerable https://news.ycombinator.com/item?id=39867126
Knowing Poettering he's lying through his teeth to cope that his software is responsible for an extremely large amount of vulnerabilities.

>>13190
I still dream of a day when these idiots will come out and say "alright, we fucked up with shoving systemd down everyone's throats, sorry, we will use a saner init system now" but I just know they will double down with systemd shit.

memory.png
[Hide] (9.7KB, 768x544)

>>13190
Heh, I have a modified Ubuntu where I run BusyBox init instead of systemd. But I guess it wouldn't help in this particular case. Fortunately I don't run sshd at all on Linux, and the only way to login is the console tty or serial port.

>>13205
They'll never admit anything, because ultimately it's a CIA nigger backdoor. Just do whatever you can to isolate yourself from their nasty shit.

>>13206
Yeah it's just a dream of mine, I know it's retarded, but still. I already picked a non systemd distro back when I jumped ship to Linux full time, so that is not an issue for me.