she/they
I’m sorry but what are you talking about? How is this random GNOME extension related to DHH (who does not even use GNOME if that isn’t obvious)? How does that relationship poison the concept of scrolling window management? Is Drew DeVault a fascist because he made Sway which works vaguely similar to Hyprland, which was made by a fascist?
In my world that kind of transpilation should be instant.
Well, as you’ve guessed, it’s not really just a transpilation. A NixOS rebuild evaluates significant parts of Nixpkgs, <nixpkgs/nixos> as well as your configuration from scratch (technically flakes have evaluation caching, but it’s not fit for purpose).
Nix isn’t a fast language to begin with, but the evalModules call that actually takes your configuration and turns it into a package that can be built is very expensive. Because NixOS imports (almost) all modules by default, it has to do deep merges of most of <nixpkgs/nixos>, which amounts to almost 32 MB of Nix code. Everything else is a rounding error compared to that.
Oh, and it has to do this for Home Manager too, because Home Manager is also built on evalModules and also imports all the modules. As is flake-parts if you use that (though in that case the set of modules is small so you it’s much less noticeable).
How much of speedup would it yield to rewrite Nix and/or home-manager in a faster language like Zig or Rust?
It would probably make the performance worse before making it better. Nix is slow but it’s not because of the implementation language (which is C++), you would have to do actual interpreter engineering (e.g. writing a JIT) to make an interpreter much faster than the current one.
A builtin (C++ instead of Nix) implementation of evalModules would probably help, but nobody wants the versioning headaches that would come from that. I’m also not sure it would do that much, the amount of data is just massive.
A more promising optimization is to make NixOS not import all the modules by default, but efforts to do this haven’t really gained traction. Probably because you pretty much have to check all modules for cross dependencies.
As a user the best thing you can do right now is using Home Manager standalone and not as a NixOS module. That way, while switching generations will still be slower than it really should be, at least it won’t evaluate and merge all NixOS modules every time you change your mind about a background color.
You can also use a non-Nix-based dotfile manager and forego Nix evaluation (and building) entirely. The only thing you really lose is being able to remote deploy dotfiles with things like nixos-rebuild build-vm.
That is basically what the EUPL is.
Shift-Tab just does the correct thing for me on Emacs 30.2. That might be a newer default though.
I think on an older version something like this should do it:
(keymap-set completion-list-mode-map "<backtab>" #'previous-completion)
This only works when the completion buffer is selected though (e.g. via completion-auto-select). I’m not really sure how to get useful backtab behavior in the minibuffer itself.
Edit – These bindings might be worth trying as well if you don’t like the auto selection:
(keymap-set minibuffer-local-completion-map "<tab>" #'minibuffer-next-completion)
(keymap-set minibuffer-local-completion-map "<backtab>" #'minibuffer-previous-completion)
Every blog post like this contains a bunch of new variables I’ve never heard of but always wanted. Like help-window-keep-selected or window-combination-resize.
Putting that aside though, am I the only one who likes the built-in completions buffer?
(use-package minibuffer
:custom
(completions-format 'one-column)
(completions-sort 'historical) ; Emacs 30
(completions-max-height 20)
(completion-styles '(basic partial-completion substring))
(completion-auto-select t)
(completion-ignore-case t))
I like that it doesn’t move the modeline up for completion and that it feels like shell completion. It also works for completion at-point.
The variable completion-auto-select is load bearing for my workflow though, before I knew about it I very much thought I needed icomplete or vertico.
In the sense that allowing a malicious application to steal your SSH keys is “fixing”, yes.
This is interesting, but I wouldn’t consider this to be at all comparable to Flatpak. From what I can see the only purpose of using bubblewrap here is the dependency isolation (without having to recompile the world ala Nix), which does have some value but it feels misleading to even call it a sandbox.
It mounts /home and /run into the sandbox chroot, which means that “sandboxed” applications can do things like reading your SSH keys, dumping your keyring or escaping the sandbox via write to .bashrc (so most of the attacks you’d want to prevent). This is presumably done because without /home access you wouldn’t be able to write to the filesystem and without /run access you can’t even display a graphical window, which would make the packages quite useless.
XDG Desktop Portal solves this by allowing filtered dbus access controlled by package metadata (/.flatpak-info), and then having sandboxed applications use portals to access files, secrets and other resources. The metadata is a major flaw in Flatpaks design (note that a lot of the most popular Flatpaks want full $HOME access), but it’s also what allows Flatpak to be useful. In this project, there’s no metadata since the packages just come from Alpine repositories.
I haven’t heard of Coldbrew before, it looks very interesting.
The unfortunate thing about snap is that of all options, it is the most capable. You get GUI, CLI, server, full filesystem access if needed (aka classic snaps). But Canonical really drags the project down and handicaps it with poor decisions.
That’s also how I feel about it. I’ve heard many good things about it technically, but Canonical really killed its adoption outside of Ubuntu.
Then you look into it a bit more and the story changes to “oh actually you need to enable this experimental feature to get better reproducibility”.
This unfortunately gets misunderstood a lot, mostly because of the stupid flake hype. You do not need flakes for reproducibility, Nix comes with a fetchTarball builtin function which allows you to pin a specific Nixpkgs commit and output hash.
You’re right though, I agree on basically every point (including the part about flakes).
I’ve used NixOS, wasn’t that big of a fan. I certainly love the idea, but not the execution.
Would you mind elaborating on that? I do have some suspicions but I would love to hear what bothered you about it.
There’s probably a combination of magic command line flags that allows podman/distrobox to work, but we honestly shouldn’t need containers for this at all.
It’s frustrating how we have all the pieces to make this work, but they just don’t come together properly:
Maybe this is a hint that I should write my own package manager, with blackjack and hookers that works like Nix, but doesn’t hardcode /nix/store, runs everything in bubblewrap and works with SELinux?
This was already posted three hours ago.
The only strong holdout is glibc (musl is no match, and doesn’t pretend to be anyway).
Chimera Linux patches musl to use mimalloc and that allegedly mostly closes the performance gap. With notable glibc stronghold systemd supporting musl in recent versions I wouldn’t be too surprised if it catches on eventually, like clang arguably already has.
I appreciate the work ahead of time, and the law is the law. @svartkanin raised this PR internally within staff channels, and the feedback is that we’ll wait until there’s an overall stance from Arch Linux on this before merging this, and preferably involve legal representatives on this matter on what the best way forward is for us.
But from a personal reflection it’s clear that there’s a disconnect between law makers intent and how things like this will be implemented in reality, and once a law is in place - we might have to implement inconvenient things…
So I’ll leave this open for now, but I’ll also lock the conversation because experience from the mailing lists on this topic has told us this thread will get out of hand quickly.
@dylanmtaylor: this stance does not mean that we won’t merge this. And despite locking this thread, I think you, me and other contributors and maintainers can still comment (which is fine, and good).
Sounds reasonable to me
Discover itself doesn’t guarantee anything. Flathub (the Flatpak repository you are presumably using) requires a human review for new applications but not updates (and the human review doesn’t include a full audit of the app). I’m not aware of malware being distributed via Flathub in the past, but that doesn’t mean it can’t happen.
I wouldn’t call using Limo straightforward, and the project hasn’t had a commit in eleven months (it’s still on Qt5…).
Honestly I would rather manage my mods with a bunch of shell scripts that are just repeated lines of ln -sfn. Those can’t do bulk downloads from Nexusmods, but I couldn’t get Limo to do that either…
Auf der einen Seite stehe das staatliche Interesse an effektiver Strafverfolgung, auf der anderen das Eigentumsrecht des Betroffenen – einschließlich des fortschreitenden Wertverlusts der Geräte. Entscheidend war, dass es über 2,5 Jahre keine ernsthafte Auswertung gegeben hatte. Und das, obwohl es sich überschaubare 56 GB handelte, es keine Verschlüsselung gab, die PINs bekannt waren und die Daten bereits gesichert.
Was für ein Saftladen. Erinnert mich an XKCD 538, nur umgekehrt.
In the xdg-desktop-portal PR there is a very interesting discussion about how OS level parental controls probably should work:
The other way to approach this would be to turn it on its head, and instead of having a portal which tells apps what age the user is, instead have a portal which apps can query to tell them whether content which has a certain rating should be shown to the user.
gnome-software, AppStream and malcontent use the OARS ratings system for tagging content with what might be age-restricted about it. This has a mapping to a CSM age (which is international), and that has mappings to most countries’ national ratings systems, and is designed for web content as well as games and films.
Presumably an app would send a list of specific OARS tags (which exist for precisely this purpose) to the OS via xdg-desktop-portal, and the OS would respond by classifying each tag as acceptable or unacceptable. The app then is only responsible for not displaying the unacceptable content, and tweaks to the filters based on jurisdiction and new laws/amendments happens in a clearly defined place which is the portal implementation (which could be in an optional package, e.g. xdg-desktop-portal-content-controls).
Of course that system wouldn’t comply with any of these new laws because they’re just bad. Even ignoring all technical considerations, most of them have a ridiculously broad scope (or large uncertainties). They’re very poor legislative work.
Technically yes but tabs are modal: You have to leave the tabbed mode to look at more than one window at once, and then the third window that opens will cause one of them or both to resize. Then you need to fix that by moving it to a new workspace or the tab container.
The idea is that with scrolling, resizing is always manual. New windows will never resize any existing ones, independent of any “mode” or which element you have focused.
It’s not for everyone (personally I realized after a few months that I did not actually like scrolling, I just put up with it), but I do think it’s a comparable paradigm shift as going from a stacking WM to a tiling one. Sure you can create tiling layouts on almost all stacking WMs fairly easily with simple mnemonic keyboard shortcuts, but using it feels different, if that makes sense?