

If a messaging service requires a phone number then it’s not “secure” lol.
If a messaging service requires a phone number then it’s not “secure” lol.
Are you saying that not all bourgeois are the same?
Haven’t used GNOME for a while, but I guess that’s a problem of open source projects in general. Though GNOME at least has Red Hat behind it.
I don’t think Fedora has a “stable” channel. It has “testing” repo from which updates are pushed to “updates” repo after approval, and that’s it. My understanding is that ublue’s “latest” channel follows Fedora’s “updates”, while “stable” seems to update weekly (though it’s unclear what happens if a package update arrives in Fedora just before “stable” image is about to be built)
Does it use the same flawed approach as Manjaro by indiscriminately delaying all updates (including critical security fixes)?
Fedora is a bit too eager to deliver new updates IMO, especially KDE. As much as I love KDE, their .0 releases have had serious bugs several times in a row now. It’s always better to wait for .1 patch with Plasma. It may be hard for the user to break Kinoite, but it won’t save them from bugs.
Fedora’s mission have always been to push new stuff when it’s “mostly ready” at the cost of inconveniencing of some users, so I wouldn’t recommend it for non-tech-savvy people.
I know people say that it’s 100% stable for them (as they do for Arch, Tumbleweed, Debian Sid, etc) but that’s survirorship bias. As any bleeding edge distro, Fedora has its periods of stability that are broken by tumultuous transitions to the new and shiny tech (like it was with Pipewire, Wayland default, major DE upgrades, etc). During these times some people’s setup will break and you don’t know ahead of time if it will be yours.
You can still install RPMs through dnf. There is also dnfdragora AFAIK. Packagekit (cross-distro API and daemon that abstracts package managers like dnf and apt) is a pile of crap anyway, and is a source of many GNOME Software’s issues.
It does. This discussion is about Fedora where packagekit works with dnf and RPMs.
Not just synonymous, it the official name of DE itself.
That’s not a good argument. Most of these additional languages are used for separate things, like build scripts and stuff. They don’t affect actual kernel code which is C and assembler language.
It is hard when you mix them in one codebase and need bindings and wrappers for interoperability. This always introduces additional work and maintenance burden. It’s always a tradeoff and for most projects not worth the effort. Tech corporations that do this regularly have dedicated teams to deal with boilerplate bullshit and tooling issues, so that regular devs can just code with minimal friction. Rust-in-Linux community decided to take it upon themselves, but I’m not sure if they can keep it up for years and decades in the future.
Though gradually getting of C is still a good idea. Millions of lines of C code is a nightmare codebase.
Some differences I see: Shepherd does some firewall management with ports, and I don’t see the services it depends on.
That looks like it sets up sshd to start when someone connect to its port, not on boot. You can do the same with systemd, but you need additional .socket unit that will configure how .service unit is activated.
Why this kind of files should be written in a programming language at all? I guess it’s a remnant from the old times, but I like when tools abstract away the programming parts, and users shouldn’t have to deal with that
Systemd invents its own configuration language (it looks like ini but there no standard for that and systemd’s flavor is its own) so you still need to learn it.
All POSIX compatible shells have their quirks and differences because the common POSIX part is rather small, so you will need to learn them anyway when switching from one to another. Fish is not that different from them (to much less extent than something like nushell) and it benefits from having less ancient baggage.