redjard

Efi spec states it must be safe to delete all variables. It’s only motherboards not adhering to the spec that are affected, effectively faulty hardware.
If you do this on a mb from that era chances are nothing will happen, and if something does happen chances are it is recoverable. You’d have to have some truly bad luck on your choice of mb to have it be permanently bricked by that.

genkernel is basically deprecated. You can use distkernel and supply your own config or config mods.

Yeah, on some fundamental level.
Most linux distros would be very moddable repairable off-the-shelf cars. LFS would be your diy project with various guides. And gentoo would be a parts garage with their own guides and precompiled kits of components, so you can either follow those sets and build a more off-the-shelf car or diverge at any point for any section and run wild. But also you can still use the machine shop of the store and they offer to custom build some consumables for you and keep shipping them.

If it’s something outside packages, like say the filesystem, it should be similar to fix to what you did in the initial setup. You already have to know how to partition your system, so at worst you’d have to relearn that if you installed a very long time ago.

If you mean break some regular file, you can reinstall the package it belongs to or everything if you have the time.

Gentoo has a proper package manager (portage), so most things you can rebuild. If you fuck some config, you can probably rebuild and get the default files back.

If you break portage config somehow, you’ll probably have to start from scratch in essence. Though there too once you start to redo your setup you’ll likely run into the same issue and have to figure it out.

Because all distro-problems will be caused by you, the only escape is to understand the issue.

Any “rebuild” would just be you copying in all your old stuff and repeating all the settings, you could just as easily revert your settings till it works again and pinpoint what is causing it.

I have no specific automation for setting up a system from scratch (did it 2 more times on different systems but manual copy was good enough), but automating it wouldn’t be hard. Just dump all the commands I run during setup into a script, and add a few scp to pull in my own stuff (or I could even put it in an official gentoo repo and pull it in with one portage config file).
But why would I? I don’t regularly set up copies of my system, and this is the same as just looking at my system. It can’t break itself past what those config files and setup commands do. The system won’t diverge from your commands so there is no need to force reset it to your commands.

I suppose the fact I comment my package set (the config file that contains all the packages I have installed) with install reasons is the same as starting from scratch. I simply reevaluated all my installed packages when I wrote it.

In a way I did once “fuck my system”. I switched to wayland (end of '22, before it was cool) and wanted to remove all X flags from all packages (a global flag unset). So I endlessly figured out what packages really needed that flag, added exceptions, and after months still ran into occasional issues, instability, or the weirdest dependencies. Whenever I had any problem I started considering if it was somehow caused by that.
I knew it was stupid, I knew plenty issues it had caused, everyone was telling me it was in fact stupid. Basically I was test-running 200 packages at once under settings noone had ever intended. So my “rebuild” was just to remove that -x from my make.conf and rebuild all affected packages. (I may have even rebuilt the entire system just in case).

The only way I see you actually starting from scratch is if you

• Did something stupid from lack of knowledge or out of fun
• forgot about it
• couldn’t trace it back nor anyone else could figure it out
• it’s in something not logged (which I’m fairly certain doesn’t exist unless you explicitly turn it off)

The most “I’m fucked, rebuild everything” moment in my memory was me doing an update after half a year when kde6 was released. What happened was I had manually specified a bunch of kde system components (instead of stripping down the kde meta package via flags) and some were removed in kde6, so portage tried building a kde6 system with kde5 and failed in enough ways to generate like 5k lines of error.
I was unable to read that error, and while someone in the gentoo irc was able to, I would have had to “rebuild” my package selection otherwise.
Meaning leave the system running as is, remove stuff from the installed packages config until the update finds a valid config, add back stuff while it keeps working, and be left with in this case the packages that were removed, where I would have then checked them and seen they were removed in kde6.
This would have essentially been me “rebuilding my installed packages”, so “rebuilding the system”, but while still using that same system and with the final “apply” being a regular update using my fixed config. No need to throw everything away in the mean time, it may destroy my valid package state but the system doesn’t mind (it just stays outdated). I could have even updated only specific important packages and delayed the package rebuild for more months.

The main flaws here are me (adding stupid dependencies) and portage producing unreadable errors (to be fair there are so many ways to fuck up package configs it’s gotta be really hard to make every case readable and traceable to some sane cause).

Without fixing it I ofc could not have gone to a different system and copied over my stuff (automated or not) since that would also have refused to build all my selected packages.

It’s very controllable.
You start out with control over everything, but that also means you have to do everything and know everything. Then you can hand back that control by automating on your terms, and gentoo provides a lot of tools for that.
But you always have that confidence that when something is weird, you can go back, take the control, see what happens, redo the automation. Or keep it manual.
Gentoo won’t ever touch your config files (It proposes changes you approve), and if something happens you didn’t want you can always trace it back to your own mistakes.

I’ve never gotten the same feeling of being in control with any other distro. There is always that time it fucks up my ssh config, or breaks due to some oddity I chase back down to a decision by some maintainers.

It’s stable only based on your decisions and skill. It will make you a lot better at using linux. But also if you don’t have the time, or the will to keep automating and scripting and learning new things, then you won’t be able to use it and you’ll have a really bad time.

It does bring automation but only up to a still very manual level. You can’t go “fuck this shit mode” and turn it into opensuse with a config option. For example you can do your own kernel, or add a few changes to a default kernel and use it without init system, or follow a tutorial to pull default binaries and just have what most other distros have, but you won’t find an installer to check that as an option, you are forced to still understand what components you are putting in where, connecting how, automating with what commands and tools.

Also protip if you do your own kernel start with the binkernel config not the default the fresh kernel repo starts out on. You’ll never find all the footguns autoconfigured to make your system weirdly choppy. And recompiling stuff you forgot in a module then loading that into the old kernel usually works but can crash your system.
Change all the options, be my guest, but at least start from a working state so you have a chance of knowing what you fucked up and which flag you didn’t understand.

I type kill -4 $$ all the time so I don’t pollute bash history. It’s probably up there as most typed command in 3rd place after l and cd ...

I swear I can type the entire thing in 1s flat on a good day.

The archive repo has the old versions, the main repo omly goes back a few weeks.

I could export and import with minimal issues around half a year ago after it was discontinued.
Based on what @eager_eagle@lemmy.world said maybe try installing an older version, importing, then updating.

forces me to commit to one issue at a time

Skill issue

Paperclips in your comments are a bit more annoying in comparison, also you’ll just forget them.

The newest rossmann video explains the idea more, but in short the goal is to get a feel for how large the movement is, not creating some slogan.

What about ye olde “googles on ddg”?

You probably mean daemon-reexec, which also does not restart services (it better not, would be really problematic if it did).

I do mean reload, which has uses, otherwise it wouldn’t even exist and services would simply always reload: You may not want to reload yet, but keep a working state of service definitions in systemd while editing things, similar to typing away in a code file in production without saving yet.
I don’t see why I would need to “save” all my service definitions to get a usable (non-spammy) mount back, especially when my mount isn’t even part of systemd. How does the message even get sent by mount when mount is not aware of systemd?

PS: systemd can replace my text editor over my cold dead body

shutdown, reboot, … are symlinks on multiple different systemd repos, I have no reason to believe that is not the systemd standard.

systemd is not moving all it does into a single binary, obviously. Others already mentioned that and a bit further up I mentioned some systemd components that can be isolated too.

GNU posix is one extreme, and busybox the other, and the accusation is that the core of systemd sits too close to busybox, and the other projects might too group together things into fewer binaries that used to be multiple independent commands.

As for the core, I think that constitutes: services, logging (journald), cron+anacron (timers), blocking (systemd-inhibit), and mount.
I am probably missing some there. Timers does not interfere with other cron, but it is there whether you like it or not. Those components also come bundled with otherwise optional linux features like cgroup which do complicate using other posix tools with systemd, as you get unexpected results (like nohup not working).

My problem is 1) how do I revert to dedicated mount, and 2) mainly that I want to edit fstab, and mount without having to reload systemd. Dedicated mount doesn’t need a reload, it simply pulls config from fstab at time of call.

I also don’t see why you would ever want to reload service files due to editing fstab, it seems dumb in both directions. Those two systems should just be decoupled.

I need systemd-run to start a process in my startup scripts (that are a systemd oneshot service) so that the process won’t get killed when the startup scripts have run (subshells, nohup, … still keep the same systemd cgroup so get killed with the tree).
I need journalctl to get output from services, so basically every system and user process I didn’t explicitly start in a console. I don’t even know how to get info from systemd stuff in any other way, as they don’t have alternate logging facilities to my knowledge.
Systemd also ate my fstab at some point and translates mounts into services, but I haven’t really looked into that.

I think there were a few more components packed into this systemd core. Without the init system/servixe manager, logging, … you can’t really use systemd stuff including parts of that core.

Past that, things like networkd, resolved, … are very modular in my experience.
I can imagine running resolved under a different init system, and I have migrated both to and from resolved on systemd systems. They do still change old paradigms, resolved replaces a file not a service for example, but they do provide adequate translation layers and backwards compatibility in most cases (Though the mounts for example has lead to me getting 5 “run daemon-reload” info messages on every execution of mount before). An issue here might be when something only supports the new systemd interface not the old stuff, say a program directly calling resolved instead of looking at resolv.conf. But I haven’t seen that, and most of those interfaces seem decent enough to implement into systemd-alternatives.

Maybe someome who actually tried cherrypicking some systemd stuff into their system can provide some more experience?

Unix is where the model of linux commands originates, and those commands absolutely embody the unix philosophy.

Systemd is a bit like busybox in that many formerly standalone comands turn into symlinks to systemctl.
Take a look at shutdown for example.

comapss, dyslexia edition

*gets downvoted to oblivion*
The lemmy experience

Please tell me you do at least proofread the unit tests though.

Ps: No your garbage

Was about to say this.

I saw a small-time project using hashed phone numbers and emails a while ago, where assume stupidity instead of malice was a viable explanation.

In this case however, Plex is large enough and has to care about securiry enough that they either
did this on purpose to make it sound better, as a marketing move,
did not show this to their security experts,
or chose to ignore concerns by those experts and likely others (turning it into the first option basically)

There is no option where someone did not either knowingly do or provoke this.

But you could feasibly have conversion that crashes a system.
Say a log is generated and prefixes the entries by a padded unix timestamp. The field is padded to length 9, so after y2k1 the unsigned integer math specifies to prepend -1 = 2³² - 1 spaces

Anything but root and hidden elements directly below root.