Not true. Archinstall automates much of that, and it’s easier to navigate than the Calamares installer. The process takes less than five minutes of interaction, the rest is just waiting for the packages to sync. Installing Arch manually using arch_pacstrap is an option, but it’s the worse option.

deleted by creator

Now go back and actually read what I linked. The comments too. And don’t dismiss those points just because the old ways work for you.

Such as initscripts being a nightmare to maintain, and insufficient for the complexity of a modern system. Read about it here: https://redlib.privacyredirect.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/

You didn’t realize there was a problem to solve because others, the distro maintainers and developers, worked their asses off to solve that problem for you.

You really shouldn’t do that. SysRq reboot is like SIGKILL on steroids. If the OS hasn’t flushed and closed every file handle, you can corrupt the shit out of the system. Ask me how I know.

You can skip waiting for services to stop by pressing Ctrl+C eight times within two seconds. If you really need to reboot using SysRq, then at least do a sync (Alt+SysRq+S) before that.

– snip –

Not worth the effort. Go on hating.

(for the record, that is not my downvote)

I don’t know what kind of program it is, but if it works on X11, you could try forcing it to run inside Xwayland by unsetting the WAYLAND_DISPLAY variable. I’ve had to do this with Qt Creator because dockable windows didn’t work at the time on Wayland.

env --unset=WAYLAND_DISPLAY DISPLAY=:0 /path/to/prog

Please share those options, don’t keep them secret.

I’m not reading all that. Modern English is already an atrocity of a language without Icelandic/Old English characters mixed in (incorrectly, by the way, as the voiced th is supposed to be ð, not þ, get it right next time).

(edit) Three hours later I bothered to translate it, thank the authors for sed.

It’s… it’s called a dependency. What you’re describing is a dependency. Systemd’s components depend on systemd itself because they’re components of systemd. Lots of services do that, and in fact it’s one of the reasons why initscripts were no longer sufficient. Lots of things don’t work if you don’t have glibc for example. I don’t see the controversy.

As for using systemd without its components… I use systemd-boot, but I could just as easily install GRUB into my boot partition. I don’t use homed, I don’t use run0. For that matter, I don’t use systemd-resolved either. I thought I did, but I’ve just checked and it is dead and disabled (probably been since I installed the system), and the system log shows NetworkManager failing to send resolution requests to it through dbus because it just defaults to having it running… but it’s never caused any issues, hence why I didn’t know it was disabled.

The answer is more complex than a simple yes/no. Fortunately, an actual Arch Linux maintainer shared their experience with init scripts and why it was necessary to switch to systemd: https://redlib.privacyredirect.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/?

This line is particularly great:

What most systemd critics consider “bloat”, I consider necessary complexity to solve a complex problem generically.

Other than that, and especially in the case of Arch Linux, nobody is forcing anybody to use any other component of systemd, or as proven by the likes of Artix and Devuan, systemd itself.

GNOME: “…and that’s why I think client-side decorations are the greatest. What do you guys think?”

The camera zooms out to reveal all other desktop environments staring, stone-faced, at GNOME. After a moment, KDE speaks up:

“You really can’t help putting your foot in your mouth.”

Laugh track plays at 300% volume, followed by the Seinfeld outro.

change very fundamental things in the project

That’s not what’s happening. Right now, modules written in Rust are completely independent from modules written in C. If a Rust module wants to interact with a C module, it has to use that module’s API, as it is intended. If that API changes, the Rust module has to adapt to it. Nobody is forcing C developers to change anything they don’t want to. In the latest tantrum, a kernel developer called Christoph Hellwig was exposed sabotaging Rust projects: he was NACKing Rust PRs that interacted with the DRM API even though they touched none of the code he was maintaining, nor required any changes be made by a C developer. In the fallout, two Asahi/ARM developers left the mainline kernel, and one of them retired completely because of burnout.

Wrong opinions can exist if they are formed using incorrect assumptions. Hellwig had no right to sabotage the Rust projects, and certainly no right to call Rust-for-Linux developers a cancer on the LKML.

“I love a good sitcom!”
“Oh, what’s your favourite? Friends? Seinfeld? Fesh Pince?”
“None, it’s wayland-protocols”

Narrator voice: “Six years later, they still haven’t tried it again.”

Even UEFI has its haters, and they’re calling for a return to BIOS in the aftermath of the Gigabyte UEFI vulnerability: https://www.youtube.com/watch?v=BTjj1ILCwRs (scroll through the comments)

It’s not just about memory safety, honestly. Rust is a modern programming language. C is a fucking fossil buried in a tar pit of unmaintained libraries and workarounds. A newly minted programmer won’t likely choose C as their primary language when things like C#, Python, and Rust are available (I work in a university, I see what our students do), and the current generation of C-only maintainers will eventually retire, with nobody to replace them. Being openly hostile and abusive against Rust will hurt the kernel in the long term.

This is the Dreadnought effect once again. A new thing appears that thoroughly changes the landscape, and the people who can’t adapt push back with fear and violence. Crossbows and arbalests have been effective for centuries, who needs this ridiculous new “gun” thing?

You bet. Not many, but they are extremely passionate emotional about it. They mostly grace the anti-intellectual cesspools with their presence (twitter and such).

I used to be like that, about two years ago, mainly because of some bad experiences with compiling Rust programs from source. Then I realized that I’m literally never going to be affected by it since I never compile the kernel myself. Now I’m learning Rust myself.

It’s both.

Christoph Hellwig, a kernel contributor, and a bunch of anti-Rust fossils, were sabotaging Rust-for-Linux projects for using their C APIs for months until Torvalds intervened, and have been actively hostile and abusive against R4L contributors until they left the project. Summary by Aussie Linux Man.

XLibre, headed by a… shall we say, interesting figure, has attracted a rabid fanbase who are frothing at the mouth and calling Wayland woke DEI garbage that will destroy Linux. The first day of the git repo saw threats of gun violence, the antisemitic (((triple parenthesis))) dog whistle, openly transphobic statements by non-developers, and the owner’s commitment to allow all of that under the banner of being “non-political”. More context here, in the comments.

It’s NixOS and CachyOS these days.

Linux users are peaceful* and level-headed*.

* barring discussions about Wayland, X11’s obsolescence, Systemd, Pipewire, Rust in the kernel, or even UEFI at times