What do you mean by personal package manager?

What do people use for command line utilities? The selection on flatpak is a bit sparse

It depends on whether those dependencies are shared with other programs.

Waiting for a 8x1B MoE

Ironically thanks in no small part to Facebook releasing Llama and kind of salting the earth for similar companies trying to create proprietary equivalents.

Nowadays you either have gigantic LLMs with hundreds of billions of parameters like Claude and ChatGPT or you have open Models that are sub-200B.

Good luck! Feel free to DM me I’d you have any questions!

You can start a different TTY than the install automatically starts. Guix has a ‘guix system init‘ command you can point to a system config and mounted filesystem, much like arch’s system init.

If you use the curses-based installer it auto-generates a system config file for you.

Note that the base configuration is entirely libre kernel so some drivers may not work (like wifi)

In order to get these working out of the box you have to make a boot iso with guix with a non-libre kernel.

The system crafters channel has a guide that details using nonguix (a non-libre kernel channel) in the installation out of the box: https://systemcrafters.net/craft-your-system-with-guix/full-system-install/

Doing a reconfigure right after a pull and half the packages don’t have substitutes yet 😭

Active GuixSD user.

Our application catalog is much smaller than many other distros simply because we don’t have the userbase large enough to surface the volunteers necessary to support it. So you will have to learn to write your own packages eventually

That said, if you know your way around functional languages (in this case, scheme), it’s probably the easiest time I’ve ever had writing a package. Everything that goes into the script is known at the time the script is written, so weird extrinsic problems don’t really occur after you’ve written the package.

Some stuff that you and the guix maintainers may not have the time to support will also get updated more slowly.

Luckily flatpak exists, and is a godsend for the new wave of read-only (functional/ostree-based) OSs.

Biggest appeal for me was having all my configuration in one place (and documented) so if I forget I did something in 6 months, it’s always staring at me in my home or system config file. You can accomplish the same thing by being diligent with say, script files, but it’s drop-dead easy to just maintain a system and home descriptor file and keep editing that.

The problem is that the Linux kernel is monolithic so introducing rust into it does have certain repercussions about downstream compatibility between modules.

Right now the rust code in the kernel uses c bindings for some things and there’s a not-insignificant portion of C developers who both refuse to use rust and refuse to take responsibility if the code they write breaks something in the rust bindings.

If it was pure C there would be no excuse as the standard for Linux development is that you don’t break downstream, but the current zeitgeist is that Rust being a different language means that the current C developers have no responsibility if their code refactoring now breaks the rust code.

It’s a frankly ridiculous stance to take, considering the long history of Linux being very strict on not breaking downstream code.

Well part of what it does is grab your actual desktop background to use, and there’s a couple different ways to do that on Linux afaik

Also I guess the file dialogs would open only to the wine prefix? My experience with wine applications and dialogs is mostly through bottles, so I’m not sure of the sandboxing…

I think it does that for some parts, but it does close the game out and open up folders for some spooks

It’s a game that messed with the windows on your desktop and opens file dialogs and stuff (as part of the spooks)

It makes me wonder how it works on the Linux side

> Kinito Pet now playable

How the fuck is that gonna work

You can use nix alongside guix, it’ll just double-up the dependencies on disk:

services (append (list (service nix-service-type))
                    %base-services)))

Services are, in guix terms, any configuration change to a computer, so creating your own service 99% of the time is just extending etc-service-type and creating a variable interface to fill in the config file text yourself

Creating a service as in a daemon of some kind uses shepherd and involves extending shepherd-service-type or home-shepherd-service-type with your service description, depending on whether the service runs in root or user space.

Shepherd service configurations aren’t actually part of the guix spec(https://www.gnu.org/software/shepherd/manual/shepherd.html#Defining-Services), but still use Guile, so you can interoperate them super easily.

It’s important in guix to understand lisp pretty thoroughly, and knowing how to program lisp is still a very useful skill to have so I’d recommend learning it even if you never touch guix.

I use guix because, while it has a small community, the packaging language is one of the easiest I’ve ever used.

Every distro I’ve tried I’ve always run into having to wait on packages or support from someone else. The package transformation scheme like what nixos has is great but Nixlang sucks ass. Being able to do all that in lisp is much preferred.

Plus I like shepherd much more than any of the other process 0’s

You could try Guix! It’s ostensibly source based but you can use precompiled binaries as well (using the substitute system)

It’s a source-first Functional package distro like Nix but uses Scheme to define everything from the packages to the way the init system (Shepherd) works.

It’s very different from other distros but between being functional, source-first, and having shepherd, I personally love it

It’s cause Epic/McKesson has complete control over the EMR world so everything has to work with them to some degree.

GNU health is great but I haven’t seen where it could support the massive amount of legal and monetary hoops that Epic and co have to jump through as well.

For some reason there just isn’t a lot of volunteer efforts/space for open source development in the healthcare world.

This feels like the same kind of issue mesa just had around the zlib update breaking downstream user programs (viewperf). If there are significant downstream issues for users you shouldn’t upgrade, even if that is the end goal.

Projects that are big and important get old and bloated because they need to try and span legacy issues alongside their attempts at newer paradigms. It’s just kind of the natural lifecycle of these projects.

I’m in the Alacrity+Zellij cargo cult