Laser @ Laser @feddit.de

Posts

0

Comments

309

Joined

2 yr. ago

This kills the joke

It was about as easy as configuring my own NixOS system.

Probably true but also potentially misleading

Not to belittle their work, but the majority of stuff that made up proton wasn't theirs back then (basically wine+dxvk did the heavy lifting). They owned up to it in the end, paying driver developers and hiring dxvk authors and if I'm not mistaken also fund some wine work. A rather successful open source story but they aren't the initial driving force.

Of course because there's absolutely no issue with tracks that were under water. The foundation is just fine.

Depends on what you're looking for.

I cannot recommend NixOS enough, it's such a good distribution but on the other hand it's quite tough to learn as it deviates a lot on how distributions do things. It still uses a standard stack (glibc, systemd, GNU tools and all) but the nix tools which include the package manager are totally different from what other distributions offer. It's very solid, yet flexible. It offers a lot of packages by default. I've switched my machines to it because of the advantages.

Arch is great as a rolling release distribution with solid repositories (lots of packages and quite up to date) and it's very close to upstream with a more traditional approach to the distribution tools. In fact there aren't really any apart from the package manager by default. I feel this is one of the most comfortable distributions if you want to learn how a classic Linux system is structured. I ran Arch for about 15 years and didn't really have anything to complain about and I learned more about Linux there than with Ubuntu and Debian.

Please note that neither of these are what one would consider beginner-friendly distributions.

It's the same here in Germany except for the cheap house in the country part.

systems always implies Linux, but Linux doesn't necessarily imply systemd.

I always try to cover most of my stack with systemd components because they actually tend to be quite sane with a very transparent configuration. It's no surprise a lot of distributions picked it up. As you said, it does exactly that, make an OS based on Linux easily available. Sure you can do the same with a variety of other tools, but just letting systemd do the heavy lifting for you sure is tempting.

That doesn't mean it's the only choice. I'd love to try Chimera Linux one day which doesn't include systemd (in fact it doesn't include a lot of stuff most other distributions do) but it ticks a lot of boxes for many.

Thanks for the explanation. I didn't make the connection that buildInputs is an attribute itself as it is an attribute of stdenv instead of the function describing the derivation directly. Or at least I think that's where my confusion comes from.

I tripped over some stuff back then when I found out that which is not part of the sandbox.

That’s what buildInputs are for. Add which to buildInputs and it’s available inside the sandbox. The stdenv takes care of putting its binaries into $PATH and making its libraries discoverable.

In the case of which, you’d probably need it in order to execute its binary during the build process though, so nativeBuildInputs is more appropriate but that only truly matters for cross-compilation.

Small correction, it wasn't which, but rather env, I had those mixed up. The "issue" is described here: https://github.com/NixOS/nixpkgs/issues/6227 What created more problems was that patchShebangs wouldn't work here because it appeared in a configure script that was created and run during the actual build process (I think the build process is horrible, but here it is in case you're inclined: https://github.com/BSI-Bund/TaSK/tree/master/tlstesttool the stuff in the 3rdparty directory gets downloaded, configured and linked against in the main program's build phase so you have no opportunity to actually follow the solution in that issue, similar to what is described here https://github.com/NixOS/nixpkgs/issues/6227#issuecomment-73410536. I got it to work in the end and like to tell myself that it's elegant but the project's build process is just bad in my opinion.

https://pastebin.com/0GwLk1wP if you want to see an example of my level of nix-fu. I have programming basics but the nix language can be confusing sometimes. I'd say I have a basic understanding of things but as said before the more intricate stuff still escapes me.

I don't think NixOS "hates" Docker, in fact Nix has its own tools to build Docker images. There are some examples at https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/docker/examples.nix

I know genAttrs “generate[s] an attribute set by mapping a function over a list of attribute names”, however for this piece of code I’d have trouble locating the list of attribute names.

You mean packageNamesToModify? You have to provide those. I don’t know which packages could be built with my-proprietary-codec and it’s not feasible to figure that out automatically.

Not really. Looking at genAttrs, it says that it's genAttrs :: [ String ] -> (String -> Any) -> AttrSet, and the example code is

    
genAttrs [ "foo" "bar" ] (name: "x_" + name)
=> { foo = "x_foo"; bar = "x_bar"; }

  

So I'd expect a list of strings and the mapping function. However, from my first naive glance at the code you posted, there's no list of strings there, and rather directly a function definition that makes use of overrideAttrs, for which for me the documentation is unclear if it can only set attributes, create attributes or what else; also buildInputs at first naive glance isn't an attribute of the packages, but rather of stdenv (sorry if all of this is wrong), all of which isn't exactly intuitive if you've only worked with imperative languages.

I’ma let you in on a little secret: We’re not actually a binary distribution. We’re source-based.

I do know that, that's why I worded it like I did. In fact I have created a single package myself before and as such, did read a bit about FOB and all that, how the cache works (not that I can fully recall everything or claim that I understood it all) with input-hashes etc. I tripped over some stuff back then when I found out that which is not part of the sandbox. The program however is a bit niche and there's another component it needs that I didn't write a derivation for so I also never wrote a pull request, plus the build process is somewhat ugly. So I wouldn't call myself a beginner exactly but I definitely have trouble with advanced usage of the language and the intricacies of the system.

However, while source-based, I think it's a common understanding that the binary cache is a huge appeal, otherwise the discussion about the cost it wouldn't be had.

You're right that the difference isn't overly obvious. However, for most services, Wants= is enough. I think some of these (like Requisite=) came from actual users' demands where they had to solve corner cases in their setup that systemd did not allow with the existing features. I think especially UpheldBy= is a smart addition; it adds restarting to a service only if that services is used as a dependency for the one it upholds.

I knew systemd could do dns resolving but just learned it could handle the entire network stack and replace NetworkManager.

It depends on your use case. I have three machines and use NetworkManager on one of them and systemd-networkd on the others. The latter is great for static configurations, but for a notebook that roams WiFi networks, it doesn't make the most sense.

Like Matt Gaetz? Maybe, I wouldn't exactly call him left though

Sure buddy

Sure, but what is the point of the thread then? Of course a program will need the libraries it was linked against. The kernel has nothing to do with that really. The point was it is possible to run old binaries. Even a recent program will fail to run if its dependencies aren't provided, that's not an issue with older ones exclusively...

I ran UT2k4 in 2016 or so, it was dynamically linked but brought its libraries, I had to replace some IIRC but afterwards, it ran.

Thanks for the thorough answer.

    
final: prev: lib.genAttrs (n: prev."${n}".overrideAttrs (old: {
  buildInputs = old.buildInputs or [ ] ++ [ my-proprietary-codec ];
})) packageNamesToModify

  

Thanks. I didn't know that worked, however I'd say this is rather advanced nix. I know genAttrs "generate[s] an attribute set by mapping a function over a list of attribute names", however for this piece of code I'd have trouble locating the list of attribute names. But I guess this is because I don't understand overrideAttrs fully / correctly. In my defense, locating the documentation for that one isn't trivial – I think this requires having some more experience with the language and the needed libraries. While I know that genAttrs is defined and explained in nixpkgs/lib/attrsets.nix, I'm not so sure about overrideAttrs– I'd guess it's in nixpkgs/pkgs/stdenv/generic/make-derivation.nix? Even https://ryantm.github.io/nixpkgs/using/overrides/#sec-pkg-overrideAttrs is not very verbose.

Please don't take this as criticism, I know nix is a full language and I'm not trying to bash anyone here, however there's quite the learning curve.

What you’re actually looking for here is a Gentoo USE-flags like system. We have a precursor of that in i.e. config.cudaSupport but it’s not widely used.

In my uneducated opinion, full use of USE-flags are rather complicated with package managers providing binaries, no? It would require a big number of builds for all possible options and their combinations.

You’d do that upstream because that’s something that every instance of ffmpeg should be able to do. And also ping me because I maintain ffmpeg ;)

Thanks for your work, I don't really need jpeg-xl in ffmpeg, I played around with it when I was still using Arch (i.e. take screenshots in the format in mpv) but it wasn't urgent enough for me to file an issue on Github.

I’d expect most packages to make use of such a feature dependently. I don’t know how gwenview or QT stuff works but from a quick Google I gather that KDE stuff has the kimageformats library which then in turn depends on jxl. Gwenview should depend on that but only depends on qtimageformats currently? I’d give adding kimageformats to its buildInputs a spin if you’re curious. If it works, make sure to submit a patch against Nixpkgs.

I had a quick glance at the definitions myself; also since 2021, kimageformats should provide support for jxl. My knowledge here was outdated that it needs a seperate plugin (Arch has one here https://aur.archlinux.org/packages/qt5-jpegxl-image-plugin) but that seems to no longer be the case. Also I don't actually have jxl files to test stuff with, since the major browsers don't support it atm. I tried finding an easy example to OPs problem, though it seems it is kind of moot now, and Gwenview in nixpkgs does support JPEG-XL (just tested it by creating one via cjxl).

No. For a “native” Nix output path, you must have the full build definitions; Nix expressions.

I think I originally misunderstood the question. But I'm still not sure.

This is what overlays are for. They allow you to change the meaning of some package name in the context of an entire package set in which other packages may depend on the meaning of that package name. Those packages will have the change in meaning propagated to them.

The issue with how OP stated it though is that it basically means adding a dependency to a multitude of packages, not changing an existing one. I mean sure I could overlay ffmpeg-proprietary for ffmpeg and all other packages depending on ffmpeg would happily pick it up (as you said probably needing a rebuild) but how would you add my-proprietary-codec to all packages supporting it? Or how would you add JPEG-XL to ffmpeg and other packages that make use of it independently (e.g. so that Gwenview supports JPEG-XL)? I'm not saying it can't be done, but I personally don't know how. The latter might need a separate derivation for the plugin and a change in the derivation for Gwenview itself that can not be achieved through overrideAttrs for buildInputs alone. Or is my understanding incorrect?

Are there any 3rd party repos for NixOS? It seems some people overlay one package, but I cannot find entire packagesets such as the one in Nixpkgs. Are channels used for that? Would I be able to have my own repo with several packages? Can I have more than 1 repo in my Nix system, and set which package install each program from?

Yes, the most common one I think is the NUR, the Nix User Repository, the packages have their own namespace. https://github.com/nix-community/NUR

Would it be possible, for propietary software compiled directly for NixOS, to have a binary-only (as opposed to source, or binary+patched) repository? Everything I see is either source+cache or binary+patched, but nothing like binary especifically for NixOS.

I don't see anything prohibiting that

Let’s say I want to add some extra, propietary codecs unavailable to NixOS. How would I be able to change a dependency so that each package dependent on it automatically picked it? Could I switch a dependency for a certain repo from one of another, different repo?

The issue is that packages (or derivations) only depend on something because it's declared in their definition. That means if you need to add dependencies to existing packages, that can be done via overrideAttrs. However, I'm not certain that you can easily add attributes to functions that don't have a mechanism for it (I don't know derivations that allow for more attributes than specified and I'm not very good at the nix language) and dependencies (buildInputs and nativeBuildInputs) can only use packages that were supplied as attributes. Derivations usually declare their attributes via { x, y ? "bar" }:, what you would need to make use of additional attributes is something like attrs @ { x, y ? "bar", ... }: so that the additionally supplied attributes can be accessed. But again am not an expert in the language so take that with a grain of salt.