Atemu

Atemu , 6 months ago to games in Nintendo is suing the creators of Switch emulator Yuzu

“copied the game ROMs into Yuzu” Yuzu is not a VM or other container and the ROMs are simply stored on disk in their original dumped form… Yuzu doesn’t “store” or “contain” any games.

ROMs are indeed copied “into Yuzu”. They must be loaded into Yuzu’s memory in order for Yuzu to execute their code or render their assets. In copyright law, even loading something to memory constitutes a “copy”.

Also, almost every emulator is a VM; do you think those ARM instructions are running on your x86 processor and its desktop OS kernel natively?

Atemu , 6 months ago to selfhosted in Good mini PC for around 100€

USB is not really a reliable connector for storage purposes. I’d highly recommend against USB.

Atemu , 6 months ago to linux in Why aren't more people using NixPKGs?

I tried signing my own keys. I replaced them in the bootloader, but when I do the final step to lock them down, the TPM chip flushes the new keys and reissues fresh keys again

It may just be that the firmware of your particular board is buggy to the point of being broken.

You could try updating it but sometimes it’s futile and the firmware is just the biggest pile of crap.

Indeed there are many times I “need my hand held” in order to take my first steps into a subject. I need an intellectually-intuitive foundation that is stable and I can build upon.

Absolutely reasonable expectation. I wish we had that.

why a user owned directory in root is needed

I initially glossed over the fact that you said “user-owned” here. It still shouldn’t affect anything because nothing uses /nix for anything security-critical at any point but it’d certainly be smelly.

User-owned /nix is only the case in single-user installs which I believe have been deprecated for a while and certainly aren’t the way to go anymore.

These days the preferred and default method is a multi-user install where /nix is owned by root there and exclusively managed by the privileged nix-daemon.

What it means for NIX in reference to configuration files, dot files, and my mental model of mess that belongs in /home/$user. While unfounded, I immediately worry root will somehow get cluttered with junk too. It is probably wrong, but I think of $user being largely sandboxed in /home/$user/

Nix (the package manager) itself does have some limited local state (cache, current profile link) that is put into the appropriate XDG user dirs. It will never touch anything outside of those specific state dirs, the TMPDIR and /nix.

Nix is designed to be fully contained in /nix. This property enables you to even wipe their entire root on every boot under NixOS.

Apps installed via Nix behave as they always do w.r.t. cluttering directories. openssh will still create and manage its ~/.ssh directory for instance, just like on other distros. If you ran some daemon that you installed via Nix with sufficient privileges, it may try to create its state directory in /var or whatever; just like the same daemon from any other distro’s package would.

That is all to say: Nix does not do anything special here. Its packages largely behave the same as they do on any other distro and that behaviour includes state directory cluttering behaviour at runtime.

I don’t know what the SELinux context is for NIX, but I only have a limited grasp of SELinux from hacking around on Android to add things like busybox, and I know it is permissive but enabled in Fedora.

No SELinux support whatsoever.
There is somewhat explicit non-support even as Nix’ model of files and directories does not include xattrs; you cannot produce a Nix store path that has special xattrs for SELinux purposes.
Metadata like permissions, dates and owner information are all normalised in the Nix store. The only permitted metadata apart from the file name is whether regular files can be executed.

If your system uses SELinux, you must add an explicit exception for the Nix store. (Installers may do that automatically these days, I haven’t kept up with that.)

question how anything placed directly in the root directory of another distro will impact future updates from the packagers of the distro.

Other distros simply do not touch /nix; it’s not their domain.

FHS distros control FHS directories such as /usr or /bin depending on what individual packages contain but no sane package of an FHS distro will try to control /nix/store/hugehash-whatever/.

Isn’t this against the Unix framework to place something directly in root?

Nix does many things that go against original design principles of Unix and that’s a good thing. It’s not the 70s anymore and some aspects of Unix have not aged well.

economicsfromthetopdown.com/…/nixing-technologica…

trouble with Nvidia with a mainline kernel and kobold.

Using Nix for applications that have userspace driver dependencies on non-NixOS requires a hack unfortunately: github.com/nix-community/nixGL

Atemu , 6 months ago to linux_gaming in Nintendo goes after Switch emulator yuzu in new lawsuit

I’d absolutely buy switch ROMs, even for 60€. Just gimme a damn download link.

Atemu , 6 months ago to linux_gaming in Nintendo goes after Switch emulator yuzu in new lawsuit

Seeing Tears of the Kingdom actually run in 60 fps on the steamdeck

Uhh, you did not see that. It doesn’t even get to 30 in most cases sadly.

Atemu , 6 months ago to linux in Why aren't more people using NixPKGs?

IIRC it puts a user owned directory inside the root. I have no clue what the total implications are in respect to privacy and security.

None.

The last time I looked the NIX solution to secure boot keys was to disable secure boot

Are we talking about Nix or NixOS here now? These are entirely different things.

Nix on non-NixOS does not care whether that OS can do secure boot or not.

As for NixOS: github.com/nix-community/lanzaboote

(Not sure what you’d actually want to achieve with “secure” boot as it doesn’t protect you against anything on its own.)

The idea of leaving it up to the user to figure out keys and self signing was a giant red flag for me.

The current support for secure boot in NixOS is rather experimental still. It’s the same as any other distro that hasn’t applied to RedHat to get their shim signed with a M$-trusted key, so I don’t really see your point here.

That aspect is also being worked on as we speak.

I didn’t care to figure out Keytool on my own to boot into UEFI and try to change them by force. That knocked NIX off my list of complete distros to run.

That’s your ignorance’s fault, not any distro’s. If you can’t be bothered to plug in your own keys, you limit yourself to the set of distros that are indirectly officially approved by M$.

I also ran arch for a few weeks once and am now extremely skeptical of any distro that presents anything that hints at “you figure it out yourself” complications for basic function. After Arch I went to Gentoo back when the Sakaki guide still worked and that was much more my style. I had something that just works, and made extra complications much more approachable. Specifically, I found documented entry points on things I didn’t understand, approached in ways I found useful.

If you need your hand held, the Nix ecosystem won’t be for you. It’s not really approachable by people who can’t research things in its current state.

Nothing wrong with that but Nix just isn’t at the point where mere mortals can reasonably be expected to be able to use it.

Atemu , 6 months ago to linux in Nix/Silverblue users: How big is the advantage if you already have 100% automated your deployments via Ansible?

If I can stow all of my dotfiles, why would I use home-manager to handle them instead? In most cases it’s just going to be harder to configure anything, and you also need to rebuild your home every time you want to update a config.

Yes, yes indeed. That’s why my dotfiles are still in a git repo (don’t get the point of stow), not in home-manager.

If you do in fact need home-manager’s features for some of your dotfiles though, it can effectively act as a stow superset for the rest.

What benefits does it have over just using a shell script?

Declarative stateless configuration rather than imperative stateful configuration.

With a bash script, you’d have to meticulously craft together the i3config file using shell script syntax and remember to run that every time you change something. home-manager just does all of that for you with high-level data types and frameworks specifically made for that purpose.

that ties into another problem I’ve had when messing around with home-manager: the only source of options I found was mynixos. So to configure anything I had to first guess potential keywords to search for the option I’m interested in.

Yeah, it’s not great. search.nixos.org/options? is really useful for NixOS.

You have to either use your browser’s dumb search on nix-community.github.io/…/options.xhtml or your pager’s dumb search in man home-configuration.nix.

Can you give me some examples, what issues will I face running MX + nix that I wouldn’t if I ran nixos?

All the issues which declarative immutable stateless system configuration solves such as atomic updates, configuration rollback in case you messed something up and trivial recovery. I’m sure I’m forgetting some since I’m so used to having them.

The main problem was getting started from 0, so I’m considering writing a post about it when I get a bit more comfortable. Trying to learn nix declarative package management from the nix manual is a bad idea, and almost all of the resources are on nixos. A quickstart guide with a few commands and examples would’ve had me up and running in 10 minutes instead of days.

Yeah, docs are a pain point. If you think that section is bad (I think so too), everyone will thank you for rewriting it. Feel free to shoot a PR to Nixpkgs and ping a few people from the docs team if you’re motivated.

Yet I never see it mentioned, while even beginner threads are being spammed with nixos recommendations.

I don’t get it either. NixOS is the best thing since sliced bread for a certain kind of person (experienced hacker who has felt the pain points which NixOS relieves) but I’d never recommend it to an inexperienced user in its current state.

Atemu , 6 months ago to linux in Why aren't more people using NixPKGs?

It tends to get your software out there and used faster if you bootstrap the packaging

It’s fine to provide some sort of “official” binary package in some common format such as a Flatpak, Appimage or even just a plain old tarball but trying to package something for many different distros is insanity IMHO.

My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix.

it’s easy on most distros

It all depends on what you’re used to and how cursed the project’s build process is.
For sane build systems, I find it much easier to package for Nix now that I know its intricacies. I wouldn’t want to go back to weirdly sourced bash scripts without proper structured data types or any sort of abstractions or mechanism for extremely common patterns.

On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.

It’s the same for NixOS. When I encounter something that somehow isn’t packaged in Nixpkgs yet, I usually start out by simply packaging it in my local nixpkgs checkout.
There are handy tools to generate the little boilerplate there is and, if the package uses a reasonably standard build system, it usually only takes adding the dependencies and one or two tweaks to have a working package that is then also ready for submission to upstream Nixpkgs.

Atemu , 6 months ago to linux in Hardening Arch Linux

Currently it takes ~50 minutes to recompile the kernel. Are there any tutorials what drivers to disable to speed up this process?

Step 1: Buy a faster CPU.

The only thing you could do is ccache but that’s just a cache and can get invalidated whenever.

After doing that I will try to compile it with -O3 and LTO.

Don’t use -O3, especially when your goal is to harden. It has no measurable benefit beyond measurement bias due to memory layout changes and some of its optimisations may produce wrong code which is a big no-no if your goal is to harden.

install ClaimAV

Are you planning to host a file share for Windows system or what are you trying to achieve using ClamAV?

install flatpak versions for every non open-source app

You’re going to such lengths and even consider snake oil in order to “harden” your system and then you’re telling me you want to run proprietary (often known malicious) software on it?

What are you trying to achieve here? What do you want to protect against whom? Create a proper threat model before you wildly apply “hardening” that is likely ineffective at protecting against the threats that actually matter to you.

I also want to have SELinux.

Good luck with that. Distros with proper SELinux setups (i.e. Android, Redhat) employ teams of people to write SELinux rules for them.

I won’t discourage you from learning SELinux but know that setting up SELinux for your entire system when the distro does not support it already is not something you can realistically achieve on your own.

Atemu , 6 months ago to linux in Why aren't more people using NixPKGs?

it uses a weird combination of your system libraries, installing its own libraries into your system on its own without informing your primary package manager, and using some specific library versions separate from your system libraries for some apps.

That is not at all true.

There is one explicit case where “system libraries” are used by Nix programs and that is graphics drivers. This is not done outside of NixOS as it does not trivially work there; it’s still an open problem. We can discuss about the reasons for this impurity’s existance and its intricacies but all that is important here that this impurity is the sole exception, not the norm.

Apart from that, Nix will never under any circumstances load (much less modify) libraries of any kind from any global path; system-controlled, user-controlled or otherwise. That’d be contrary to the fundamental principles of Nix.

It will always use “specific library versions separate from your system libraries” aka. the explicitly and exhaustively precisely declared dependencies in the Nix store. That’s the whole point of it.

I’d recommend you read up on Nix again and revise your opinion once you understand what it actually does because it’s clear that whatever source you had for information on Nix was entirely wrong.

Atemu , 6 months ago to linux in (Almost Solved?) Firefox flatpak started taking 3+ minutes to start?

I mean, you could, sure.

As a next sensible step though, I’d start firefox from the CLI with more verbose logs enabled.

Atemu , 6 months ago to selfhosted in Any suggestions for a gigabit modem?

A modem is a sort of “adapter” between physical mediums and protocols and sometimes also a router. It speaks DSL, fibre, cable etc. on one end and Ethernet on the other.

A wireless access point is similar in that is also is an “adapter” between mediums but it’s an adapter between physical and wireless. It effectively connects wireless devices to your physical Ethernet network (allowing communication in both directions) and never does any routing.

What you are typically provided by an ISP is an all-in one box that contains modem, router, switch, firewall, wireless access point, DHCP server, DNS resolver and more things in one device. For a home network, I wouldn’t want most of these to be separate devices either but at least wireless should be separate because the point of connection for the modem is likely not the location where you need the WiFi signal the most.

Atemu , 6 months ago to linux in Why aren't more people using NixPKGs?

Note that Nix is not a full-blown programming language, it’s an expression language. The end result of an expression is always data and side-effects are not possible; you can’t do network requests or write to arbitrary files. There is no such thing as a variable in Nix either, only constants. You can think of it like JSON with (pure) functions and an additional data type (~package).

From a user perspective, it’s really not very different from any of the other 100s of weird configuration syntaxes you’ve surely come across in your Linux journey.

My nixos-config is a bit more complex because I like to reap the benefits that abstraction but here’s a simpler section that is representative of how a typical NixOS desktop config would look like:

github.com/Atemu/nixos-config/blob/…/module.nix#L…

(Though note that even this is slightly more complex than what you’d do when starting out; ignore the LADSPA_PATH and tablet conditional for now.)

Atemu , 6 months ago to linux in Why aren't more people using NixPKGs?

I can reassure you that it does not encroach on anything the “host” distro package manager does and does not cause conflicts with it.

At runtime, it only ever touches things in `/nix; it’s self-contained.

The only time Nix needs to interact with the host distro in any way is during install where it must place a little glue in your system configuration for things like PATH, bash completions or the nix-daemon to work as expected.

Atemu , 6 months ago to linux in Why aren't more people using NixPKGs?

If you maintain upstream software and do not have an interest in learning and using Nix, please don’t put the burden of packaging software in Nix onto yourself. Nobody in their right mind would expect you to package anything for a dozen distros; that’s not how distros are supposed to work.

Leave it to someone who is interested to package your software in Nixpkgs. Your “job” is to make your software better and provide a sane way to build your software that packagers can rely on (i.e. no assumptions where things are or are supposed to go, document your dependencies and build processes).

If you do want to go the extra mile, offer your help in assisting packaging in the appropriate channels. You know the technical details of your software and Nix users how Nix packaging works but the reverse mostly isn’t true, so cross-pollination can be super helpful here.
Even just things like testing that your software works as you expect when the packaging is touched in some way (i.e. an update) is incredibly helpful. (If saw a package update PR with the upstream maintainer’s approval stating that it works as they expect, I’d merge immediately.)

If packaging for Nix is a burden for you, please just open an issue on Nixpkgs with links to your packaging/build documentation and let someone else do it for you.
As a Nixpkgs committer, I’d much rather have someone invested in Nix build and maintain a package than an upstream maintainer who somehow feels obligated to do so but has no experience or actual interest as the former is more likely to produce good code and keep maintaining the package.