The iso has an encryption key problem. I tried the distro one year after, the same problem 😆 . Its the only distro that has that kind of problem. Once the problem is solved thanks to the forum, the shell didn’t switch the language properly, the “-” prints a wierd character, most keys on the that row was wrong. Maybe all the praise for that distro comes from non-french speaking people, so they didn’t saw the problem.
I know, the DE versions of the iso should works nice, but Void is advertised as minimalist, I want my WM. If this is that hard to switch the installation to french language, why Alpine is able to provide a correct installation experience (not easy, but correct) ?
Explained by someone that doesn’t know the technical side super well.
1: It’s a new protocol for displaying. The main difference from X11, as I understand it, is a simplification of the stack. Eliminating the need for a display server, or merging the display server and compositor.
2: Some things impossible (or difficult) with X11 are much better supported in Wayland. Their not necessarily available, as the Wayland protocol is quite generic and needs additional protocols for further negotiation. Examples are fractional scaling & multiple displays with differing refresh rates.
Security is also improved. X11 did not make some security considerations (as it is quite old, maybe justifiably so). In X11 it’s possible for any application to “look” at the entire display. In Wayland they receive a specific section that they can draw into and use. (This has the side-effect of complicating stuff like redshifting the screen at night, but in my experience that has fully caught up).
3: If you’re interested, are in desktop application development (but I have no experience in that regard) or have a specific need for Wayland.
4: I think X won’t die for a long long time if “ever”. I’m not super familiar with desktop app development, but I don’t think it requires more work to keep supporting X.
On the other hand, most of the complaints about Wayland I’ve heard were ultimately about support. At some point, when you’re a normal user, the distro maintainer should be able to decide to move to Wayland without you noticing, apart from the blurriness being gone with fractional scaling.
I’m not super familiar with desktop app development, but I don’t think it requires more work to keep supporting X.
It doesn’t depend that much on desktop application developers, but on GUI toolkit developers. It does need more work for GTK and Qt devs to support both. But the outcome will likely depend not that much on ammount of work as on “political” decisions. RedHat are now somewhat actively forcing Wayland in their distros. They also have their impact on GNOME, so it’s not impossible that due RedHat’s decision GNOME and then GTK (that is now developed mostly by GNOME developers, despite being GIMP Toolkit initially) will ditch X “just because”.
End user Application developers usually don’t deal much with Wayland or X — they just use toolkits (GTK or Qt for the majority), and toolkits do all the under the hoof work for them.
LeftWM. I’ve been using it for about a year now and I have no complaints vIt doesn’t hold your hand as much as other WMs, but it is extremely powerful if you’re willing to do some manual setup.
Long time since I used Ubuntu, remember updates breaking network twice… Peppermint OS, Debian(and devuan if you don’t like systemd) based. all the important bits (not arch level) but nothing more. Rolling, Runs on 1 GB ram. Haven’t distro hopped anymore since I found it.
strictly speaking, NixOS doesn’t have repositories.
NixOS has “derivations” (rules are written in the Nix language to generate a script that builds a package, which is called a derivation - yes, everything is built from source to the extent possible/reasonable) and “platforms” (the system that builds the derivation OR the system the derivation is built for). A “platform” is e.g. the CPU architecture, the libc used, the target kernel (there’s most support for Linux and Darwin, which is the macOS kernel, but e.g. FreeBSD is supported to some extent too). The derivation code may well be shared across platforms, though often platform-specific workarounds are required.
Of course, different platforms have different support. Some platforms have derivations from nixpkgs (the NixOS git repo) regularly built for them and put into the official binary cache (which stores the derivation outputs, i.e. ready-built packages for a certain set of inputs, which generally match what you would’ve built from source because Nix strives for reproducibility, you’re still free to override a package’s inputs and build it from source). linux-aarch64 is one of such platforms. Other platforms may only have a small set of core packages like gcc built for them, or simply require building absolutely everything from source.
The reason nixpkgs is not a repository (though I guess you could call it one) is because it only provides rules to build a package, but not the package itself. Some derivations (e.g. for Gog games) even require you to add some non-redistributable files to the Nix store manually. The derivations may or may not build correctly for each platform they’re supposed to work on.
The reason the binary cache is not a repository is because it’s just a cache for nixpkgs - it stores every derivation’s output (if the build doesn’t fail), even if that derivation is one that downloads a package’s source code (yes, that’s a derivation too), even if the derivation is from many years ago (which has historical value, as you can revert nixpkgs to an old version and still be able to download prebuilt versions of packages).
Together, they form something like a repository, but it’s still way too different. For example, unlike on Arch, I can stay on the same nixpkgs version for a long time without updating, which I really prefer because I have to build 3 kernels on each update, since I’m syncing the nixpkgs version of my 4 NixOS devices, only 1 of which doesn’t require a custom kernel config. Or I can always revert back to an older version of nixpkgs if a new one breaks something and it will still work. Or I can fork nixpkgs and change some stuff, and the stuff with changed inputs will have to be rebuilt locally, with stuff that didn’t change still available from the binary cache.
yes, if that AUR was in a centralized git repository, and kept track of inter-package compatibility, and centrally cached prebuilt versions of the packages for every single update, and you could also easily modify any of the packages, and there was a way to autogenerate build scripts, and and and…
I also used it and dropped it years ago because it tended to break a lot in updates.
That, their poor kde support, their constant reinventing the wheel (poorly) drove me away.
Now I run opensuse as a rolling distro that’s always up to date and just never breaks even when there are 6000 packages to update. It’s boring and safe.
linux
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.