Noodlez

joined 1 year ago
[–] [email protected] 1 points 1 year ago

I'm aware, but the appimage I run (Slippi Launcher) will run other appimages, and appimage-run can't handle that, since it extracts the appimage, then runs the contents, but it won't automatically do that for other appimages that are run.

Which is why I used a Distrobox and it was awesome, worked like a charm. I used Arch previously, and I just made an Arch distrobox and it worked perfectly.

[–] [email protected] 28 points 1 year ago (3 children)

Now I want to try this.

[–] [email protected] 8 points 1 year ago (1 children)

Probably omitted as "an exercise for the reader" since it's legally grey. And a difficult exercise. I cannot find it at all

[–] [email protected] 4 points 1 year ago

BetaWiki is gonna go wild with this.

[–] [email protected] 1 points 1 year ago (1 children)

Sorry for the late reply. In the 2 weeks I've still kept using it and I learned a lot! But a lot of my musings still stand, at least in my mind, but after thinking a little longer, a lot of the thoughts I had also apply to other distros as well.

To answer what you asked in final, a good hypothetical that might answer it is something like GNOME. If the nixos channel blew up in a doomsday scenario, I'd be stuck maintaining my packages myself, right? And I use the doomsday scenario, because the problems here apply for self-made packages as well, but it's easier for me and maybe others to wrap their head around the problem I'm getting at. So with GNOME, I'd have to update every single dependency manually in my nix files. With something like Arch/Alpine I could just have those files, and they have these really neat scripts where I can just bump the version, and it'll download, set the hash up, and bump the version all for me. With Nix there are no such tools. I can't just automate the process, nor is it feasible to do this type of thing manually. As new features are added, so are new options needed to activate those features. And yes, although in this scenario, I would probably just opt to not add these options and set it up myself, when making a package for the general public this isn't the case. If GNOME adds a feature (idk why I picked GNOME I haven't used it in like 5 years) to have extensions managed by the package manager, I'd have to add an option for what extensions are needed and all that. And this is a lot of work, at least as far as I know. The extensions would also have to be packaged.

[–] [email protected] 2 points 1 year ago

Gotcha I'll start playing around with derivations. I also just came to the realization that because of the magic of Nix, I can try these things, and if it breaks it, I can just roll back.

[–] [email protected] 1 points 1 year ago (1 children)

So I can use something like systemd.services to make my own services as well? Because I've been wondering how to do this as well.

[–] [email protected] 1 points 1 year ago

Gotcha yeah that makes sense, so I'll start doing this as well.

[–] [email protected] 1 points 1 year ago

I didn't know this before, but a lot of comments said the same! I think I'll start doing this.

[–] [email protected] 23 points 1 year ago (1 children)

Plan 9 has multi-monitor support?

[–] [email protected] 2 points 1 year ago (2 children)

I use Distrobox with my NixOS machine for when I need AppImage support (or some random binary that isn't equipped for Nix's weird ass directory layout) and it's amazing! Pretty much native speed, and when I'm done with it I can just wipe it out. Perfect!

[–] [email protected] 22 points 1 year ago (2 children)

Bash's posix mode still has a lot of bashisms. The only way to test true posix compliance is to test with other shells like dash and ash. I have found this is the case a lot of time. People will say it's POSIX compliant shell, but it'll obviously only be tested in bash Like at that point just make it a bash script, since pretty much every system under the sun has it.

view more: ‹ prev next ›