Git is incredibly mediocre. But it's all most people know. It's a version control tool that can't handle binary files; and no GitLFS does not count. The end result is a version control tool that is unable to actually version control all the things you need for a project.
This results in a Meta VCS layer where a ton of critical assets are stored in Docker files and other misery. If you want to re-compile a project for 2015 then good luck and god speed.
Personally I think full toolchains belong in source control. And that you should be able to clone / materialize a repro, yank your network cable, and build. This is how big tech monorepos work. It is TheWay imho.
IMO screw that. It's maybe a good way to build software in exactly one environment for exactly one environment, deployment to a corporate server fleet.
Consider a Linux desktop distro: if every little binary (out of order of magnitude 1000) acted like the center of the universe with gigabytes of build environment and "opinions" galore instead of portability, builds would take much more resources than they already do and parts wouldn't necessarily work together.
The .git directory does not contain plain files, so the same files may look different in different .git directories. But yeah, you could make it work if you designed for it.
Visual Studio and Xcode take up tens of gigabytes, are updated often, and include system components. Storing them in VCS is impossible, and would be a waste of disk space.
Disagree. They’re stored _somewhwre_ anyway, and they may as well be versioned.
Putting toolchains in perforce is how it works for lots of C++ shops, the setup instructions are “sync and hit build”, whether there’s a toolchain upgrade required or not
Threw $10 at this to help me prepare for my league’s fantasy auction this weekend. It spend $3.50 and then said “this action would cause you to go above your spending limit”.
Then I threw $100 for a Codex Max sub and it included Astra and it did it for me.
It does when you have a team of 100's of engineers every change has to pass through, 3 layers of management, SRE teams, DevOps YAML engineers, product management and a partridge and a VP.
My gut feeling is that Nix is just not quite the right abstraction level. I can’t quite articulate this. And hell maybe I’m wrong.
I don’t want to configure a global environment. I just want a build system that works reliably in any environment and can cross-compile from any platform to any platform.
Nix does too damn much. All I want is a build system that doesn’t suck. And I want to run it on windows + Mac + Linux as a first class citizen. And I want to arbitrarily target any platform.
What this really comes down to is that Linux C/C++ toolchains are badly designed. Nix is a huge massive convoluted architecture to try and twist itself around that unfortunate reality.
At least that’s my spicy unpopular opinion that is probably wrong but is at least has elements of truth.
Shared Dynamic Libraries. Not to say they aren't useful. Keeping applications small, keeping security updates simple, sub linear ram scaling, yada-yada-yada, big wins cross the board, not debating that.
The pervasive link detection structure of effectively everything on GNU/Linux assumes is (more-or-less) objectively incorrect behavior in any sane security minded context. Binaries should be able to declare the interface/contract they expect (args/types/abi/exceptions/cryptographic signatures/digests). Then the runtime linker "match" against the local system. The current system is basically 2 levels of string equality checking.
Nix goes into the right direction by getting your runtime linker/elf-runtime & package manager "integrated". But this sort of just feels like putting 'lipstick on a pig' and dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer. Nix just manages the environment/symlinks such that `foo.exe` doesn't realize this fact.
> dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer
I’m curious if you have an opinion on how you think this should be handled?
At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
I also blame C/C++ toolchains for being very very bad on Linux.
> I’m curious if you have an opinion on how you think this should be handled?
To "totally overcomplicate things" but do it correctly
- Binary states a list of constraints (namespace:name [<|>|>=|<=|!=] semver).
- ldconf/ld.so either integrate into your package manager and/or are easier to update (I'm not writing conf files by hand and/or flakes). I should simply be able to recursively scan.
- Give the runtime linker an SMT constraint solver (when <1000 this is nearly instant)
- Cache known states to avoid solving NP hard problems every time you launch `cat`.
> At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
Honestly same.
Having the package manager <-> elf runtime <-> shared libraries more-or-less be a blackbox is probably for the best (which is sort of what windows does with the install-shield/install-wizard stuff). But nobody in Linux Land really wants to "improve" userland, other then change to flavor-of-the-month display managers.
> I also blame C/C++ toolchains for being very very bad on Linux.
They honestly aren't, it is more your pacakge manager *is* your library manager. Because of the absolute bullshit of shared libraries.
If you pretend it is the 1970/80s everyone at your company has the architecture, unix version, etc. It is pretty nice. No cross compiling, multiple OSs, everything just sort of works pretty well. But like I said, "pretend".
> They honestly aren't, it is more your pacakge manager is your library manager. Because of the absolute bullshit of shared libraries.
Hrm. It’s trivial for Linux to cross-compile for Windows because Windows is sane. It requires moving mountains for Windows to cross-compile to Linux. Hell, the only way Linux can reasonably compile to target an older version of glibc is to create a full container image containing and using the old glibc. It’s absurd. I suppose this isn’t the root evil. But it feels related to me. Maybe not.
I mean... a big part of that with conventional Linux distros is the idea that you can security-update a low level library and all the stuff linking to it gets the fixes "for free", a dream abandoned both by Nix and also the movement toward distribution via containers/flatpaks/VMs/whatever.
> The truth is like the sun. The light from the sun touches everything, it's bright and it's obvious... yet no one can stare directly at it.
bad analogy. It can be very painful to accept the truth, but doing so is always a good thing. Staring directly into the sun can cause permanent damage to your eyes -- not a good thing.
No this is not true. There is an evolutionary reason why people lie to themselves. Look at the world.
Almost everyone believes in religions. The world lies to themselves on an unprecedented scale. If accepting the truth had an evolutionary benefit then most of the world would not be so delusional. Delusion dominates the population because lying to oneself conveys a survival benefit such that natural selection selects for this trait.
This short infographic illustrates and proves it. But you know what else proves it? Me getting voted down as I throw the truth down in front of everyone’s faces. I’m a target for selection.
Maybe nix will one day be a tool that’s actually good. It has elements of it but complexity and usability hinder adoption. So overall nix is just shit imo. It’s shit wrapped in a dream, a dream of an ideal way to do things. How do we make that dream a reality?
By lying to ourselves. By claiming nix is already there and that other people can’t see the light such that over the years after enough improvements nix becomes an actual good tool because enough delusional people pushed the dream far enough that it actually happened. But in order to do that… people like me must be culled from the herd.
Whoa. So is Jeff effectively leaving Google to work on this new venture full time? Or is the venture a side project? It sounds like the former. I’m sure he’ll still have internal access as an advisor of sorts. But this feels like a seismic change. Much larger than I initially realized?
reply