Classic latency vs throughput problem. 10s of GB/s of disk bandwidth doesn't help when my problem is serialized durable writes.
9,138 karma · joined April 28, 2021
This is literally our job as software developers. If this expectation is unreasonable to you then you do not belong anywhere near software development.
Because I've lived in a few of the largest urban areas and the answer is "nowhere near the jobs."
It absolutely does not but people keep repeating this on social media
(1) scare quotes because I think it's dumb for us software people to call code we picked up on the side of the road part of a 'supply chain' like that means anything.
What I'm getting at is that you really need to avoid anthropomorphizing these models. A model can't have an opinion, for example. It's a part of the psychosis I'm talking about.
The reason they're tightly coupled is because there needs to be a bridge between Sys-V ELF ABI and the C runtime, and it makes sense for the implementation of that bridge to use libc itself which means special-casing the bootstrapping of libc during program loading.
glibc isn't unique here btw - musl libc ships its own loader that does the exact same thing as rtld (parse auxv/envp off the stack, relocate itself and load libc, initialize the CRT, then load the rest of the program's SOs in order).
Even if they were fully decoupled it is not unreasonable for software targeting newer versions of an operating system to only run on that version or later. Linux is actually the outlier here where the syscall interface is stable enough to make this a non-obvious problem.
There's a universe where you can load multiple versions of the same libc into the same address space but that isn't ELF, and it's not common. aiui the only reason PE can support e.g. multiple versions of malloc/free in the same executable is due to two level namespaces in symbol relocation tables.
---
edit: another observation is that for a functioning ELF loader you basically need a three stage bootstrap. Stage one parses the stack passed by the kernel and performs self-relocation. You need that to make non-static function calls and read/write global variables. Stage two loads libc and initializes the CRT with stuff like environment variables, aux vector, any dso for syscalls passed by the kernel, etc. That has to coupled because POSIX specifies stupid stuff like "getenv" and "argv" requires the loader to know how to move from the stack passed by the kernel to the memory reserved by the CRT that gets used by the final executable. Finally in stage 3 it can relocate and load shared objects and run any constructor functions pre-main, before jumping to start where the precompiled CRT start (then jump to main goes).
So if you want an ELF loader on Sys-V you probably need to couple the loader to the libc, just for libc to work at all. Unless you want to specify a bunch of behavior and binary layout in the C standard.
None of this is designed by glibc, it's the simplest way to go from exec to main.
I'm not arguing that there aren't problems here, just that I think people have different expectations that are a little extreme. The libc implementation is a core part of the operating system, if you want to target that OS you should target that libc. Some distros (alpine) prefer musl libc, most prefer glibc. And distros really are different operating systems.
Not really, though. glibc uses symbol versions that are forward but not backward compatible. If you got an error that said "this program was built for a newer version of <distro>" would you say the same thing?
Note this is the same (if not worse) on MacOS, and on windows you used to distribute the CRT with your application just to deal with the same problem.
Even when it comes to manufacturing the tooling/testing infrastructure, it's just a question of money aiui.
That article is two years out of date, and looking at nationwide electricity usage doesn't account for the local impacts of these data centers.
(* nb4 "it's summer": talking about price per kWhr)
But that discards my point, which is that you should probably have been prevented from pushing all those to github unless you were paying them for it, but you weren't because the executives running github can't admit that AI is bad for their platform.
People should really use the individual optimization flags they want (no signed zeros, no trapping math, associative math, reciprocal math) and not -ffast-math because the other optimizations it enables leads to surprising code (for example, isinf and isnan may become noops, which will break production code).
Basically never use an optimization flag that changes the semantics of your code without understanding exactly what that means. I have had to fix this in a number of codebases because someone thought that flag was as innocuous as -O3.
And if you have to enable flush to zero/denormals are zero it should be explicit in your code and scoped.
The relevant text doesn't call it an "algorithmic feed" for what it's worth. They define an "addictive" feed and it's essentially any kind of personalized recommendation.
> "Addictive feed" means a website, online service, online application, or mobile application, or a portion thereof, in which multiple pieces of media generated or shared by users of a website, online service, online application, or mobile application, either concurrently or sequentially, are recommended, selected, or prioritized for display to a user based, in whole or in part, on information associated with the user or the user's device, unless any of the following conditions are met.