So I guess systemd had an issue where it would fucking delete your /home/ folder? lmao
https://www.theregister.com/2024/06/20/systemd_2561_data_wipe_fix/
#libresoftware #init #gnu #linux #systemd
#systemd
GhostBSD - Almost Ready for Prime Time
Little “nickel-and-dime” issues have given me pause about making #GhostBSD my daily driver, but 3 out of 4 of them were resolved after a bit of searching and applying things. I even managed to get ungoogled-chromium to accept uBlock-Origin with one complicated workaround. I would have been better off to just install Brave using a linux-compatibility layer from the #FreeBSD repo. I probably still will do that, since YouTube has decided to block ungoogled-chromium.
Cairo-dock locked up and froze everything up once, and once was enough. I replaced it with Plank just because I wanted a dock rather than just another Xfce panel for nothing but launchers. Just enough eye candy to make the difference I like. I had to turn off "shadows" in Xfce's window manager tweaks to erase a stupid horizontal line that appeared above the dock (which it also did with Cairo-dock), no big deal.
Settings don’t stick after a reboot, though, and I have to use Pulseaudio mixer to restore my USB headset to usefulness every time I log out and back in. There must be some way to make my settings “stick” between sessions!
Other than those little minor annoyances, I think this could become my daily driver. It would ease my concerns about:
- The literal takeover of Linux by IBM, Microshit, and Google, plus
- the whole stupid #systemd cancer that effects even most distros that claim to be “systemd-free.”
GhostBSD lacks some of the wicked-cool GUI stuff that spoiled me in Linux distros, like “minstick” and Systemback (later “Timeshift”), but those tasks are actually easily handled from the command line. There’s even some GUI stuff for keeping bootable snapshots of the existingOS (with /home, /etc, and other stuff backed up separately). This is an almost-ready-for-prime-time OS for BSD beginners with a little bit of Linux experience.
#BSD Runs Faster than #Linux - even in a Live Session
Pow, zoom, zip! Snappy, nimble, and quick! No #systemd pollution and monitoring of every little process. 30,000+ software titles available including most all my favorites (except BSD thinks that Seamonkey is "abandonware").
Everything works. Including wifi. It's not very much different from running Slackware-based #SalixOS, and it has lots of nice GUI tools for users like me who are scared of pushing the wrong button and accidentally igniting the Earth's atmosphere and destroying all life on the planet or something.
Got a sweet Xfce desktop on at the moment, but I think I'll try Openbox + Plank and a few little bits of eye candy here and there. Lots of room to play.
Rolling-release, too! No having to re-install and reconfigure every so often, or trying to preserve /home and finding that configuration files won't work after an update. All that trouble goes away as well.
If you're a GUI boy like me, and want to explore a UNIX-like system that hasn't been bought, gone woke, or been politicized down to the very kernel itself, I heartily recommend #GhostBSD as an introduction to the still-unsullied FOSS world of #FreeBSD!
Well, dammit, now even #Linux has gotten "political." All developers and maintainers with ties to #Russia are being kicked out.
Linux - until now - has been a global, free and #open-source ( #FOSS) project. But Microsoft, IBM, and others who are big money "contributors" to the Linux Foundation have been using their Embrace --> Extend --> Extinguish strategy to mess it up.
It appears to be working.
So today I'm experimenting with a different UNIX-based desktop operating system called #BSD (also free and open-source, with less of the politics and none of the influence imposed by Big Tech (Micro$oft, IBM, etc) their #systemd pollution and influence-buying bullcrap.
Wie benutzt man run0 anstelle von sudo?
https://linuxnews.de/wie-benutzt-man-run0-anstelle-von-sudo/ #systemd #sudo
Years ago I was wondering what this init freedom thing was all about. Today in the wakes of regreSSHion and xzUtils it dawns on me.
This article has been written in 2022 but could not be more up to date today.
#gnu #linux #foss #init #freedom #devuan #debian #backdoor #systemd
The fight for Init Freedom
Distro Walk – Devuan
Devuan, with its promise of Init Freedom, provides users an alternative to systemd as an init process.
Long-time Linux users may remember a time when Debian was viewed as a collection of anarchists, with radical ideas about voting and decision-making. At times, Debian was even the lone dissenter among distributions about decisions made by the Free Software Foundation. However, over the years, Debian has developed its own hierarchy along the way to becoming the source for some two-thirds of active distributions. Today, the Debian derivative most reminiscent of early Debian is Devuan [1], which forked from Debian in 2014 over how decisions were made and the technical connotations of using systemd. Recently, two Devuan developers – fsmithred, who builds the live images and helps with support, and golinux, the community manager – took the time to recall Devuan's past and why their issues are still relevant today. Because Devuan lacks a formal hierarchy, they emphasize that their remarks are "unofficially official."
In 2014, major Linux distributions were transitioning from SysVinit to systemd as an init process – init being the first process to start on a system and the one that manages other processes. Ubuntu had started using Upstart a decade earlier with little controversy. By contrast, systemd was controversial from its earliest days. To start with, systemd is much more than an init system. Rather, as contributor dasein described on the Debian User Forums, "calling systemd an init system is like calling an automobile a cup holder" [2]. That is, while systemd includes the functions of an init system, dasein said systemd is also "an effort to recreate large portions of existing userspace (including login, job scheduling, and networking, just to name a few) inside a single process traditionally reserved for the sole purpose of starting *nix userspace. (Just in case it isn't clear, there is a huge difference between starting userspace (init) and being userspace (systemd).)"
From this perspective, not only is systemd overkill, but it is a violation of the basic tenet of Unix development that an application does only one thing and does it very well. As Christopher Barry stated in the Linux Kernel Archive, this philosophy is what makes Linux "a collection of simple modular components that could be plugged together at will to do real work" [3] – an operating system that is both flexible and accessible. Just as importantly, a modular structure allows the pieces to be assembled in different ways, so that each distribution can be unique. By contrast, systemd imposes a structure on all Linux systems that reduces variety – which is convenient in some ways, but needlessly limiting in time-honored ways.
As expected, the Debian mail forums debated these perspectives extensively. Unsurprisingly, the discussion culminated in a General Resolution among Debian users, with many Debian officials favoring systemd. The winning option was to use systemd, but at the same time, a more general resolution to favor systemd placed last – a decided ambiguity. Although rarely stated in so many words, much of the dissatisfaction implied that the decision to use systemd was imposed by the Debian hierarchy upon the general membership.
Whether this implication was valid is besides the point. Many believed it was. On November 24, 2014, the Devuan fork was announced. The intention was "to produce a reliable and minimalist base distribution that stays away from the homogenization and lock-in promoted by systemd" [4].
Introducing Init Freedom
Rather than being seen as simply an anti-systemd project, Devuan calls its position Init Freedom (Figure 1). The name invokes Richard Stallman's four essential freedoms, although the idea itself might seem less basic. Devuan's Init Freedom page [5] simply defines the idea as being "about restoring a sane approach to PID1 [init] that respects portability, diversity, and freedom of choice," assuming that the value of these goals is self-evident.
Figure 1: Devuan supports a choice of init alternatives.
In practice, Init Freedom means supporting a choice of init freedoms. Although systemd advocates often maintain that supporting multiple init systems would make packaging more difficult, from its first release, Devuan has continually added init alternatives without any apparent difficulties. Today, in addition to the default SysVinit, Devuan lists six alternatives: OpenRC, runit, sinit, s6, 66-devuan, and Shepherd, and it is open to considering others. Fsmithred suggests that most people simply use sysVinit, although OpenRC and runit, which use SysVinit scripts, are also available. Scripts are also being developed for runit and to extend usability of other shipped alternatives. For those interested in learning more, discussion can be found on the Dev1 Galaxy Forum [6] and on Devuan's IRC channel [7].
In addition, the Init Freedom page lists other Linux distributions that offer systemd-free alternatives, as well as other Unices such as the BSD Family. DistroWatch also offers a search filter for distros without systemd – currently, 97, a total far higher than many might suspect, although it includes only a handful of major distributions, such as MX Linux, Alpine Linux, and KNOPPIX [8]. Devuan keeps in close touch with these distributions, especially on the Dev1 Galaxy Forum.
Fsmithred adds that, "We rely heavily on Debian. Most of the packages in Devuan are unchanged from Debian. We only fork packages that require systemd. There is collaboration between Devuan and Debian on a few packages, and we occasionally send bug fixes or patches upstream to Debian for packages we do not fork."
Beyond Init Freedom
Devuan is usually referred to in terms of Init Freedom – often with the obviously mistaken assumption that it is a lost cause. However, Devuan also features Docker images and community-developed ARM packages. Chimaera, the latest Devuan release, also includes an option to not install PulseAudio to enable simultaneous speech synthesis in both a graphical and console session. In addition, at least one Devuan-derivative exists, Maemo Leste, whose goal is "to provide a free and open source Maemo experience on mobile phones and tablets like the Nokia N900, Motorola Droid 4, Motorola Bionic, PinePhone, PineTab, Allwinner tablets, and more" [9]. Although Devuan might be a niche distribution, clearly it is a thriving one.
But can Devuan's cause become mainstream? It's not impossible. Linux is in an era in which large parts of it are being written. If PulseAudio can be replaced with PipeWire – which is currently happening – then systemd's obsolescence is not impossible, either. Meanwhile, for those who disagree with the majority, Devuan provides a workable alternative, while keeping the early spirit of Debian alive.
Source: https://www.linux-magazine.com/Issues/2022/260/Devuan
I had mentioned the new #systemd version 256 recently, because its announcement came with the proud comment that it got rid of much Unix philosophy. There is a new minor version, because a number of people suddenly had their home directories deleted - which was entirely as desired, according to one of the main developers.
Systemd 256.1 Fixes "systemd-tmpfiles" Unexpectedly Deleting Your /home Directory - Phoronix https://www.phoronix.com/news/systemd-tmpfiles-purge-drama
Over on Mastodon and a systemd bug report, users were surprised that running "systemd-tmpfiles --purge" will delete all files/folders created by a tmpfiles.d configuration file even with the default behavior of /home being created by one. Thus those trying to do system maintenance without reading the man page could find their /home data deleted.
Initially the bug report was shot down by systemd developer Luca Boccassi of Microsoft with:
So an option that is literally documented as saying "all files and directories created by a tmpfiles.d/ entry will be deleted", that you knew nothing about, sounded like a "good idea"? Did you even go and look what tmpfiles.d entries you had beforehand?Maybe don't just run random commands that you know nothing about, while ignoring what the documentation tells you? Just a thought eh
Wow, just wow. "On your knees and worship the new Windows registry we brought to Linux, even though you worms don't deserve it!" When I get a new computer, I will definitely switch to a distro without systemd, perhaps even earlier...
Mit systemd 256 kann versehentlich das Home-Verzeichnis gelöscht werden
https://linuxnews.de/mit-systemd-256-kann-versehentlich-das-home-verzeichnis-geloescht-werden/ #systemd
Version 256 of systemd boasts '42% less Unix philosophy' • The Register https://www.theregister.com/2024/06/13/version_256_systemd/
Now with 42% less Unix philosophy!
I wonder why someone would need to emphasize this. And what are those 42% then? Windows philosophy? Why would someone who chose Linux over Windows would want that?
#Linux #Unix #systemd #Windows
Debian diskutiert ĂĽber systemd-boot
https://linuxnews.de/debian-diskutiert-ueber-systemd-boot/ #debian #systemd
Systemd haters have a point
from https://serverfault.com/questions/1159599/how-to-change-the-ssh-server-port-on-ubuntu
Ubuntu has been using systemd-sockets for some time now, which makes the port configuration in the SSH server configuration obsolete.
To change the port of the SSH server, the systemd configuration for ssh.socket must be changed or supplemented. The configuration adjustment is made by creating a *.conf file in the directory /etc/systemd/system/ssh.socket.d/.
Create conf file to extend the default config:
systemctl edit ssh.socket
or
vim /etc/systemd/system/ssh.socket.d/override.conf
[Socket]
ListenStream=
ListenStream=2222
The line ListenStream= is required that port 22 is no longer used. Without this line, the SSH server would then be accessible via port 22 (default) and 2222.
WHAT THE ACTUAL FUCK? systemd silently overrides SSH configuration with obscure parameters, and silently keeps default parameters active? WHO THE FUCK IS THE DANGEROUS MORON who imagined this ? What other services are similarly hobbled silently ?
How do I set a property in #systemd?
I have:
root@mx1:~# systemctl show postfwd | grep ^CanReload
CanReload=yes
I want to change that to no.
The fine manual says:
```
set-property UNIT PROPERTY=VALUE...
Set the specified unit properties at runtime where this is
supported. This allows changing configuration parameter properties
such as resource control settings at runtime. Not all properties
may be changed at runtime, but many resource control settings
(primarily those in systemd.resource-control(5)) may. The changes
are applied immediately, and stored on disk for future boots,
unless --runtime is passed, in which case the settings only apply
until the next reboot. The syntax of the property assignment
follows closely the syntax of assignments in unit files.
Example: systemctl set-property foobar.service CPUWeight=200
But when I follow the example I get:
root@mx1:~# systemctl set-property postfwd.service CanReload=no
Unknown assignment: CanReload=no
```
