Had to add:
sys-kernel/gentoo-kernel-bin ~amd64
virtual/dist-kernel ~amd64
sys-fs/zfs ~amd64
sys-fs/zfs-kmod ~amd64
to /etc/portage/package.accept_keywords just to be able install the really latest kernel in Gentoo.
I think I'm 90% done setting up this thingamajig. Just have to add some packages to make gaming work.
Gonna take a break for now.
I think it's about time I ditched Arch Linux for Gentoo. Arch has gotten easier and I've gotten bored with it. Once I've settled to Gentoo, I'd have Void Linux scratch my "Arch Linux" itch
I mean, I've already explored Linux distros with different inits. I don't think anything can stop me when I have Arch, Gentoo, and Artix wiki handy
tangentically related: I like doing this with #OpenRC initfiles:
extra_commands="pull"
pull() {
service "$name" stop
cd "$service_dir"
su "$command_user" -c 'git pull --recurse-submodules'
service "$name" start
}
removes a significant chunk of effort when I already have tested the update elsewhere and know that it’s fine. comfy.
In 2021, I built the 3D printed #OpenRC F1 car. It opened the gates to #3dPrinting RC vehicles, which is both fun and frustrating when you break parts that you have to print again.
When my fan boat recently failed to go in the snow, I remembered seeing snow conversions for the F1 car. Earlier this week, I printed these skis and paddle wheels. I tested it out today, and it works good in the shallow snow of my driveway but the skis need to be longer. They flip over too easily.
I'm now gonna try Arch Linux with inits I haven't tried/not yet familiar. I'm curious how it'll all go, lol.
I'm open for any suggestions on what inits to try other than OpenRC, runit, dinit, s6, and sysvinit cos I've already done those, but I'm also open to hear your thoughts and if I should also try them on Arch as well.
#arch #archlinux #linux #opensource #freesoftware #foss #busybox #openrc #runit #dinit #s6 #s6-rc #sysvinit
Out of all Artix Linux init "siblings", OpenRC is the slowest to boot, at 6 seconds. Subsequent reboots doesn't help either.
Not much has changed in RAM & disk usage though.
It's alright. I'm also the slowest and the laziest out all my siblings. It usually takes me 1 - 2 hours to finish my meals while they're done in like 5 - 10 minutes lol
I just like to savor the flavors, y'know? Plus I eat a lot more than them.
I got it! So for Artix Linux OpenRC:
rc-update add/delete <service> to enable/disable a service.
rc-service <service> start/stop to start/stop a service.
Gotcha. This will really come in handy for when I actually migrate to Gentoo and become a Gentoo citizen (just kidding lol)
After I finish the game on stream, I'll probably go back to Linux stuffs if I'm not in the mood to sleep the whole day off. This time, some Artix and the 4 inits, Arch with the unsupported inits, and making Alpine usable for everyday use.
i know its a divisive topic, but i actually really like #AlpineLinux approach of running #OpenRC instead of #systemd
i dont Hate systemd, but its so neat to quickly set up a service with a simple service file rather than a fuck ton of syntax that i cant be bothered to remember
How To List All Running Daemons In Linux #Linux #Daemon #Process #Initsystem #Systemd #SysVinit #OpenRC #Linuxcommands #Linuxbasics #Linuxhowto #Linuxadministration
https://ostechnix.com/list-all-running-daemons-in-linux/
Episodio 41: Devuan
#devuan #FreeSoftware #gnu #GNULinux #linux #openrc #opensource #runit #sysvinitI was so happy to see a modern OS use just 270 MBs of RAM with XFce. And it's FAAAAAST. But very soon afterwards, it let me down.
Alpine Linux is ridden with dependency issues and other random bugs that made it impossible for me to use it as a desktop. Maybe it's great as a server, but it has not seen much love on the desktop side. Maybe it's a human resources problem. More info in the conversation here: https://www.reddit.com/r/AlpineLinux/comments/1haq57c/complete_lockup_with_xfce_as_a_user/
I just updated my tutorial on how to enable Secure Boot on #Gentoo using GRUB. I hadn't been paying attention and the script I provided to automatically update the bootloader would only work under #OpenRC. I've now added a second script that automatically updates the bootloader when you install a new kernel that works under #SystemD too. Enjoy!
https://www.setphaserstostun.org/posts/secure-boot-on-gentoo-with-shim-grub/
My #Devuan #OpenRC experiment is going really well. So far everything I need daily is working fine. One annoying thing though, when using OpenRC you have to use `openrc-shutdown` to shutdown and reboot. Desktops however seem to use the regular `shutdown` which basically just logs you out. Does anyone know how to teach desktops to use OpenRC's shutdown? I've thought about replacing /sbin/shutdown and /sbin/reboot by bash scripts which call `openrc-shutdown`, but I'm a bit scared of doing that 
.
Okay, I finally understand #OpenBSD's syslogd. I still prefer #OpenRC's `output_log` and `error_log` parametes though.
I've never been a fan of having one monolithic (Or in syslog's case, a few monolithic) log files. Atleast it's not as bad as #systemd's binary log file with journalctl imo
I like just managing plaintext files, and it's a bit annoying having to configure syslog.conf to put each daemon's output into it's own log file.
So I got telnet working in debug shell (postmarketOS now uses NCM rather than RNDIS and seems like there’s an upstream USB regression as well) but still struggling to get telnet/ssh after debug-shell
I think I’m supposed to wait till #OpenRC boots up all the way for ssh access? Got through some problems (enabled UNIX config and increased ramdisk offset)
The current problem I’m facing is OpenRC hanging on “SVCNAME=dmesg”. /etc/init.d/dmesg is a simple script. Maybe missing kernel configs? Dunno
"""
#OpenRC […] has been in a state of bureaucratic decay for a decade now, having all been hoarded by a random corporate contractor about as responsive to the outside universe as OpenOffice (while taking up as much space; they're the entire reason for the farcical metadata/AUTHORS file in the main package repo).
"""
https://lwn.net/Articles/964589/ (cited only as the context that provoked the recollection)
This reminds me of the story. The modern #Gentoo copyright policy (AKA #GLEP76) has been a long time in the making. More specifically, as you can guess from the author list, it has been a long time in fruitless debate, followed by a short period of creative activity. In its original form, it has been unanimously approved both by the Council and the Trustees in September 2018.
https://bugs.gentoo.org/653118
Not a month later, once we've actually started requiring signoffs per the new policy, one of the Council members requested a "transitional period", to give their company's legal team more time to approve it. Like, they've actively influenced the policy, they've actually voted for approving it, but they didn't mean for it to actually apply at the time — and they've never bothered telling anyone about the problem earlier. Fortunately, they've managed to get a quick approval and started using it.
https://bugs.gentoo.org/667602
As a side effect of using it, attribution lines to said company started popping up in random ebuilds that their employees touched (malicious compliance or just corporate bullshit?). This heralded a maintenance nightmare. Two months later, metadata/AUTHORS was proposed as a compromise to stop that.
https://bugs.gentoo.org/672962
All these years later, I'm thinking that we had a simpler solution to all these, and many later problems, at our disposal back then…
"""
#OpenRC […] jest w stanie biurokratycznego rozkładu już od dekady, po całkowitym zawłaszczeniu przez przypadkowego pracownika korporacji, która ma podobny kontakt z resztą wszechświata, jak OpenOffice (i równie mocno się rozpycha; są jedyną przyczyną tej farsy w postaci pliku metadata/AUTHORS w głównym repozytorium z paczkami).
"""
https://lwn.net/Articles/964589/ (tłum. własne, cytowane wyłącznie jako kontekst, który przywołał wspomnienie)
Przypomniała mi się cała historia. Nad aktualną polityką praw autorskich w #Gentoo (znaną również jako #GLEP76), pracowano kilka lat. Jak można domyślić się na podstawie listy autorów, w praktyce przez długi czas bezowocnie nad nią debatowano, a potem w krótkim czasie ją ukończono. W oryginalnej postaci, jednogłośnie przyjęto ją we wrześniu 2018, za głosami wszystkich członków Gentoo Council i "powierników" Fundacji.
https://bugs.gentoo.org/653118
Nie minął miesiąc, zaczęliśmy wymagać linii Signed-off-by zgodnie z nowymi zasadami, a jeden z członków Council wnioskuje o "okres przejściowy", by korpoprawnicy mogli zapoznać się z nowymi regułami. Aktywnie uczestniczył w formułowaniu tych zasad, głosował za tym, żeby obowiązywały, ale nie miał na myśli, że mają obowiązywać już teraz — i słowem wcześniej nie wspomniał, że będzie z tym problem. Szczęśliwie, szybko udało się uzyskać zgodę prawników, i problem został rozwiązany.
https://bugs.gentoo.org/667602
Niestety, skutkiem ubocznym tego rozwiązania było to, że przypisania praw owej korporacji zaczęły lądować w każdym pliku, którego się dotknęli ich pracownicy (złośliwość czy tylko korporacjonizm?). Zwiastowało to koszmar utrzymania właściwego autorstwa w przyszłości. Dwa miesiące później, zaproponowano utworzenie pliku metadata/AUTHORS, by to powstrzymać.
https://bugs.gentoo.org/672962
Po tych kilku latach, myślę sobie, że mogliśmy te, i wiele późniejszych problemów, rozwiązać znacznie prościej…
