> though at this point they could probably edit the ELF binaries and patch the fixed path to ld.so when nix is installing the program.
That's exactly what they're doing right now - though instead of being "when installing the program", it's "when compiling the program". The problem with hardcoding the path is that it pins the "nix store" (where nix installs all of its programs) to a hardcoded location. If you want to move it, you have to rebuild all your packages - which is suboptimal.
In theory, nix could have a system in place to just patch all binaries when moving the nix store, but that would be incompatible with content-addressed derivation and otherwise break some other nice properties of the nix store.
In theory, ld.so could provide a stable interface to its dynamic loading capabilities independently of glibc. Then glibc would not have to be updated in concert with ld.so. There's no inherent reason that glibc should be the library shipping a dynamic linker - we could easily be in a world where libld was developed independently from libc.
On Windows, things are less modular, so it's less of an issue. That said, there's also weird shenanigans when it comes to the CRT (which can be statically linked) vs ntdll (which provides the actual linker implementation), that can make certain niche features of the linker misbehave (delay loading in particular is weird).
> There is an arrogance in the way of thinking that when you see everyone breaking your arbitrary rules you think to yourself "there is no way my rules are at fault, it's everyone else's fault for breaking them."
It's not really arrogance - it's just a different way to design a system. NixOS wants a few things:
1. An input-addressed dependency system
2. Easy and robust rollback/upgrades
3. Different versions of software/libraries/services coexisting on a single machine.
A lot of this is just impossible to have together with the way software were written, so NixOS made the changes necessary for them. When it became obvious it might be useful to other people, they upstreamed it.
I do agree with you that the whole `#!/usr/bin/env bash` shebang shenanigan is kinda ass (my personal nixos machine has a `/bin/bash` alias because there's not enough time in my life to care about this issue). But I also think that NixOS is right here, shebangs requiring a full path is just a terrible design in a multi-user world. If different users want to have a different bash implementation, they should be able to!
---
Fundamentally, I think the NixOS OS design is actually beautiful. It's taking most of what makes modern phone OS so reliable (read-only system, A/B partitions, etc...), and bringing their ideas in a shape that is coherent with desktop/server OS design.
How is that more valuable? It comes with two big pitfalls:
- It would still not allow downgrades to work properly
- It would cause glibc/ld.so to have a harder time adding new features, as they now need to worry about incompatible versions being used together
Meanwhile, having different ld.so has many good use-cases, like simplifying development of ld.so itself, allowing them to swapped during updates in ways that are safer, etc...
And the eBPF binfmt support is a rather simple, generic mechanism that is likely to have many other use-cases beyond ld.so. So it's overall a pretty good resolution to the issue?
Not with NixOS. ld.so is tied to a version of glibc, in ways that can be subtly incompatible. And nixos can have multiple glibc version installed on a single machine.
Besides, it allows for upgrades/downgrades to be done in a way that's much less error-prone.
There’s a lot of ways you can hold an engine wrong. Some 3rd party browser (often by security vendors…) have been vulnerable to exploits due to not compiling it with all the hardening options, or injecting vulnerable extensions that expose an attack surface to the webpage, for instance.
Monaspace has a feature called "texture healing" that does something similar: it allows bigger letters to "steal" space from adjascent smaller letters, to make it easier to read. The result is that the letters are still in a grid, while still allowing for bigger letters to "breathe".
You say this as if ad revenue is the only possible way we could have done AI research - which is an _extremely_ weird take given the history of academia and R&D. Today adtech companies just make up the richest companies in the world, so it's not very surprising that they're the ones behind LLMs - they have more money to throw at the problem than most. I'm pretty confident that - if adtech companies didn't exist, we'd find other means of funding AI research (private investment, public funding, R&D spend from non-adtech companies, etc...).
When the internet was researched and developed, it wasn't funded by adtech, and yet it managed to develop it just fine.
---
Also, the point of GDPR wasn't to reduce the number of ads. It was to prevent massive, indiscriminate information gathering. Now, whether that was successful or not is debatable - I have my own gripes on GDPR enforcement (I really hope the banners will get nuked out of existence).
The tech sector represents 15% of EU's GDP. I currently work in the tech sector in europe, there's no shortage of companies hiring (both startups and enterprise), and anecdotally, from my personal network, enough startups are surviving the 5 and 10 years mark that I'm pretty confident there's enough new ideas/companies (as opposed to only having old/legacy enterprises) to ensure the good health of the sector.
Now, I will acknowledge that funding is more complicated in the EU compared to the US - but that's something that has been acknowledged by EU leadership and is being actively worked on. The Draghi report lays out a vision for how this can be achieved, with recommendation on what steps to take to achieve that vision. https://commission.europa.eu/topics/competitiveness/draghi-r...
So yeah, the tech sector is still well and alive in the EU, and there is reason to believe that it's going to get in an even better position.
[citation needed] here. The tech sector is still well and alive in EU, and outside adtech (which was hit hard by GDPR - that was the point) doesn't seem to have been visibly impacted.
SKG cares about games staying playable. If a game with both MP and SP modes has MP disabled, SKG’s proposals do not fall under it, because the game is still playable offline. They have repeatedly hammered this point in their official communications (such as their youtube and press releases).
PEAK uses P2P networking as far as I can tell. AmongUs has multiple mods that allows P2P gaming[0].
Most indie games don't rely on servers for the gameplay loop because those are expensive and an indie studios can't afford it. They instead rely on P2P networking for the gameplay loop, and at most have a matchmaking server to both give a nice experience to find other players to play with, and to allow NAT traversal.
You can easily design a game like PEAK/AmongUs in such a way that, even if the matchmaking server is disabled, the game still works because it has a direct connection or LAN option.
> Most match-based FPS don't do that anymore, as it's susceptible to DDOS.
We're talking about EOL plans here. You don't have to care about DDOS.
> This is only feasible if the multiplayer backend is a simple server binary, which in many cases it's not anymore, but a full cloud architecture you would find for any SaaS app. There additionally is the issue of licensed libraries, which may prohibit redistribution of the server binaries (and may e.g. be bound to a per-host pricing).
I have multiple issues with this framing:
1. We're talking about regulation about _future games_ that haven't been made yet. SKG doesn't want to regulate existing games. So we're not talking about retrofitting an EOL plan on games that already rely on complex backend. If you're planning for it from the get-go, getting an architecture that isn't so cloud-reliant isn't that complicated.
2. Even if we accept the premise that a game _absolutely needed_ a cloud only architecture to function for one reason or another, that doesn't prevent releasing the architecture binaries.
3. Licensed libraries may have redistribution prohibitions _today_, but should EOL regulations come in place, you'd find that those libraries would quickly move to allow redistribution for EOL purposes, as otherwise studios would just _not use them_.
> Take your pick from[0] or a competitors website: PEAK, Content Warning, Gorilla Tag; All games from indie developers that heavily rely on good networking that wouldn't be feasible to be replaced.
AFAICT, Photon Fusion is fully compliant with SKG already - it supports games where one player is the "host" and all comms are P2P. Players can direct connect to one another. While it does work better with a STUN server or with Photon's cloud, they are not *necessary* for the game to function.
Photon's Voice offering might be different, but turning that off for an EOL plan is totally acceptable according to the SKG's wanted regulation - they would fall within the same category of "extra services" that aren't part of the core game.
And _furthermore_, of the three games you cited, I know for sure that PEAK and CW are playable fully offline. They're already SKG-compliant even if photon fusion was somehow not. I haven't played Gorilla Tag or looked into it, but I think I've already made my point clear.
> Ah, yes the simple option of "completely tank your playerbase".
WoW still has active players in the millions. FF14 has a 25k peak concurrent players in the past 24h. There are other success stories. But sure, it "tanks your playerbase".
[ my public key: https://keybase.io/roblabla; my proof: https://keybase.io/roblabla/sigs/dHVC2Jm2HgxiZRm0LlHdZ4B8lfYIXT8qY3A-hoHs89M ]
hnchat:UWnZd20LafKJcpuGyLTI