PKGX, the blazingly fast, standalone, cross‐platform binary that runs anything

While it is certainly advertised as cross platform and “runs anywhere”, it is currently mac and linux only.

It says that Windows native is coming soon, so I guess it’s on their roadmap!?

pkgx is an interesting idea, but there are IMO issues.

Aside from one of them, they are somewhat minor and technical (no support for fish shell; packages managed with pkgx must be relocatable, which may mean substantial maintenance or potential divergence from upstream).

The one that’s not minor is that it’s part of Max Howell’s tea token web3 project. (Related to this, they have raised at least US$17M for the web3-ification of open source development. They will have to make this money back somehow.)

It bills itself as:

It’s npx for everything else

I don’t have a very high regard of npx so that’s a turn-off for me right there.

This seems to be homebrew (binary distribution) + a command to execute stuff within the enviroment over linking executables into system directories. I would hardly call interesting tbh. Also I don’t want to see their github actions bill: Workflow runs · pkgxdev/pantry · GitHub

I’ve spotted pkgx a while ago but found it very messy in terms of implementation and wasn’t sure it would treat my machine well (and whether it will leave a lot of traces and leftovers) – granted that was not a 100% informed opinion, it was based on reviewing random pieces of code over the course of 15 minutes max.

One thing is clear though, we need a much better way of finding / installing / running AND updating programs. Especially the updating part is sorely lacking in many ways, f.ex. if you want to track a latest Golang binary executable then you have to install tools like gup in order to be able to mass-update such binaries.

Same goes for the cargo install-update Rust tool. There are others as well.

And don’t get me started on the various zsh plugin managers, we have no less than 8 separate “plugin managers based on GIT” which are more or less just scripts that do git clone and then subsequently git reset --hard && git pull on a list of directories. Tragic.

But all this underlines how sorely lacking this area is. Of course this also shows how much do we need immutable OS-es where you can temporarily install tools and “lose” them on reboot (or manually; or choose to retain them and put them in the immutable image), and how badly do we need sandboxing as well.

…And none of that even touches on “transactions” on the file system that were needed like 40 years ago and are still not implemented in the mainstream kernels. The file system should be a database.

“Modern” OS-es are pretty primitive still.

/rant

NixOS ticks a lot of boxes. I find nix and NixOS, for me, is a much better solution than all the previous language version managers I’ve used before. nix develop shells are awesome once you get the hang of them.

Nix/NixOS does so many things right but is perhaps too hard/different and too steep learning curve to gain wider adoption. In some ways it is similar to erlang which has some great tools and technologies and were way ahead of competition in many places but people picked js on the server. Once you learn the beam you see the light and other technologies become a bit tainted.

When I look at code implemented in other other languages I think: “That would be trivial on the BEAM”. I feel the same thing about Nix and NixOS when I read about all the installation problems and incompatible software and the like. “It is already solved with nix, why go through all that pain when you can live in nix purgatory instead?”

The problem is most people rather do the easy way over the “right” way and hence the mess we are in.

I refuse to learn a dysfunctional Haskell dialect – and that’s not even the most prominent problem… that’s actually the most minor one. They’ll have to try again with something else because their error reporting is abysmal and they require a huge investment of time and energy to get to an operating level.

I am eyeing stuff like immutable Manjaro or Fedora lately.

Not sure if this is addressed to myself or other group but in my case I’ll say that from my 22+ years of experience as a programmer I am 100% sure stuff like Nix can be much easier for the user and yet it is not. I put a hard requirement on the ergonomics of the tools I want to use. Transactional mechanics on software packages or the FS itself are not a difficult thing to express yet Nix made a mess out of it. Shame.

Yes, and one thing Nix creators consistently fail to grasp (evident on their forums, though don’t ask for links, I don’t keep them) is that most of their audience are more senior IT specialists who might be pretty burned out on learning one more super specific DSL.

Allow me to disagree. It might be solved but their ergonomics are abysmal. As said above, I am waiting for something better. Though I also am about 80% along the way of rolling my own thing that simply tracks every filesystem change since reboot and computes a diff between reboots or manual snapshots. So I might end up just open-sourcing that and using it.

…Or at one point we might have ZFS or BCacheFS boot disks that both allow innate snapshotting and just end up making a thin layer on top of it. That would most likely be the ideal solution, if the kernel / grub teams ever get to allowing those FS-es as boot disks without too much ceremony.

A tad bit more aggressive than I anticipated I see nix already scarred you for life (also please, not that I am writing this tongue in cheek, not here to inflame anything (except IT industry overall)

I agree with you (although perhaps not as emphatically). Going down the nix rabbit hole is a blessing and a curse.

Yes, nix the language is awful. I just can’t wrap my head around it.

Indeed.

Hence, the nix purgatory reference.

Even though with all those flaws, it just works better, (again for me) than any other similar technology before, and it means my views on other technology is tainted. I am sure you have the same experience with other technologies in your life.

And as mentioned, I think erlang/elixir might be in the same territory. If we only could get everyone else to see how magical erlang/elixir is! But. “I refuse to learn a dysfunctional prolog/ruby dialect with abysmal error reporting (for erlang)” is generally what I hear.

I’m addressing the IT industry overall which always just puts another layer on top instead of trying to understand the actual problem and make something solid. Like the beam.

Peace

Yes, and I think we are having a tooling renaissance with a big focus on DX after the industry neglected it for so much time. And companies know that people simply don’t have time to waste.

How long can you work on making a routine task more efficient...567×461 44.5 KB

This is why people will choose the “easy” way over the “right” way because time and energy are limited resources (especially if the allegedly “right” doesn’t come with good DX). But also because technology is a Wicked Problem, so this purist sense of the “perfect” tool doesn’t exist in practice.

At this point in my life, I’m taking whatever makes my life easier and I’m glad other people are tackling those problems because I surely don’t have time to invest in fixing this BS myself haha.