KVM is indeed a much better hypervisor, but it does require some setup with the terminal.
Since he is a beginner I decided to recommend virtualbox since it just works after installing. But if he doesn't mind setting up things via terminal then KVM is definitely the way.
If you decide later to test other distros I would highly recommend using a virtual machine in virtualbox. Saves the hassle when it comes to testing distros 👍
I was saying that you do spend less time cause it is already there. Also you can have logs on other init systems, what I said on the post is that if later I wanted logs I could just setup instead of being already there (and the other utilities, not just the logs of course).
I am not saying this proves single-handedly that systemd has vulnerabilities but it is one of probably many out there. I am not saying enterprise is stupid but I could definitely see some sacrifice being possibly made to spend less time setting up utilities on every systemd machine for enterprise work.
I didn't know about bashrc poisoning, thx for the intel.
You are probably right, systemd attack vector might not be that big as it seems. But its a bit unfortunate that it has that small extra negative layer of security.
For daemons, its simply symlinking the services in the 'sv' folder to the var/services, it should be running after that.
Not sure how compatibility with systemd apps work on other inits but for what I know the packages that are shipped focus on specifically the init system that you are running (from whatever repo you use to install on the distro, for example artix has other inits besides runit).
Edit: Also you have the 'sv' command on runit that acts exactly like systemctl. You can stop, start and all that stuff
"Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface. All the systemd "cloud of daemons" is tightly coupled by dbus interfaces that enable an attacker to move from one exploited system service to the next. Even if the attacker doesn't manage to find an exploit in another system service, DoS is easily possible because the DBUS interfaces are quite fragile. Even as a benevolent admin it is easily possible to get the system into a state where e.g. clean shutdown is no longer possible because systemctl doesn't want to talk to systemd any longer and you cannot fix that. systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors. At the very least I would, for hardening, recommend not using any network-facing systemd functionality.
And lines of code are not ridiculous, they are the best first-order estimate available. Of course an actual inspection of the code is better for a comparison, but that is a huge task. sloccount is quick and easy."
Are there any plans on adding features that enable easier interaction with other federated platforms like mastodon and peertube (for example being able to comment/interact with peertube videos and mastodon posts)?
I would recommend trying out first sway just because the configuration is very straightforward and you easily find on the internet configuration files of other people, most of the setup is already done for you out of the box as well.
After getting used to sway I would then recommend moving into WMs that require more tinkering, like hyperland you mention on the post.
Also if you ended up removing animations and don't really care that much, you might want to try other projects that have different focuses such as the minimalism of dwl or the different approach of tilling with tags with river (it all ends up on preference after getting used to this kinda of graphical servers)
Edit: FYI, most of the ricing (aesthetics) tends to come from the status bar you choose, the colors you choose to configure on files and the background image (I would say background img being the most important cause everything is built around it (colors, themeing, etc) )
Like some have mentioned, if you want to try different distros setup a VM (I would recommend KVM for better performance, but virtualbox is easier for beginners in VMing) with the iso of the distro you want to test out.
Like this you can keep a functional system without the hassle of having to setup on baremetal just for testing and having to go back again if doesn't pay-out.
Also would suggest messing around with more tech-savy setups like debian and fedora (specially minimal ones) if you want to delve deeper into the Linux nerdiness.
Congrats bro!!! Welcome to the club 😎😎😎