Hacker News Reader

Comment by travisgriggs | Hacker News Reader

Seems like a cool project and kudos to the authors attentions to detail.

These lines tickled my Bone of Irony:

> No installing apt packages. No dealing with missing header errors. It should just work out-of-the-box, and for every platform

I think it’s interesting/ironic because at some point the layers of header files were pitched as a way of making things more modular and better. A means of simplifying. Aptitude was meant to do the same thing. Simplify a process that was formerly seen as icky and complicated.

The author could have just as well mentioned just about any other software install/deploy/configure technology. In the end it always seems that yesteryears “it makes things easier” is eventually derided and replaced with a some new simple straightforward mechanism. As whatever the new approach is, scales in time and application, it takes the place of what it derided and becomes the new derided. One big merry go round.

View on HN

There is a key difference here- if your build instructions include "install this package using apt" then you are limiting your developers to using Ubuntu or Debian, and even then limiting it to a particular version range within those distros.

If your build instructions are "zig build" then that works for everyone, on every platform: Windows, macOS, Linux (all distros!), FreeBSD, etc., and it works for all versions of them.

One thing that has been bugging me for quite a while is that how a Zig library would be packaged downstream. AFAICT all Zig programs have to vendor their Zig dependencies which is a huge turn-off for Debian or Fedora developers. There is not an existing way to install Zig source files and IMHO this hurts reusibility (in a different way).

This is an issue with any modern systems language like Go and Rust, and it doesn't seem like this trend is going to stop. NPM will happily download precompiled binaries for certain packages, and NuGet only works with prebuilt packages (like the java ecosystem).

In current day, everyone wants their own package manager, and compiled builds to have no dependencies. While this makes distribution and building easier, it makes it impossible for distro maintainers to integrate it properly into their ecosystem, apply fixes and upgrade libraries across swathes of programs. I don't get why people can't accomodate for distro packaging in their tooling as well - many languages like python handle this just fine.

I believe we'll end up at a point where the system package manager will mean nothing - it'll manage end-user programs, which will all bundle their own versions of libraries - even ones considered "system" like libc and libX11. No sharing of (security) fixes and feature upgrades, and you'll have to learn a new package manager each time you switch languages or sometimes even projects...

Welcome in appstore land, where the system is merely a collection of independent applications with no relationship with each other.

Makes it indeed easier to build, deploy and sell software, compared to the former world of one big distribution where thousands of software packages were designed to work together.

I do believe the driving force in this trend is not coming from the users but from the producers desire to assert property of the software. Think the enclosure trend, for software.

> Welcome in appstore land, where the system is merely a collection of independent applications with no relationship with each other.

"App store" is having a centralized distro repository where you get all applications from (e.g. Windows Store), and "merely a collection of independent applications with no relationship with each other" is exactly the opposite (e.g. that's how the Windows apps were distributed before the advent of Windows Store).

I mean, the build instructions could also say "install this package" and then you install it however your distribution does it.

Installing a package to build some code is just fundamentally wrong, though. Why am I making unspecified, permanent changes to my underlying operating system in order to build a random piece of code?

That just make no sense, and it is insane that this is the standard way of doing things.

Install in context of library package manager doesn't necessarily mean install to operating system. It can be just caching it somewhere in your home directory.

Part of the problem is, packages have different names on different systems, and many are missing altogether (is it libxml-dev or libxml-devel or does your OS simply not have that package, because the package repository owners are in a state of gang warfare with the libxml devs?)

Reply on news.ycombinator.com