He was a rich asshole who personally wronged everyone on the jury in his first season, and carried by luck/ignorance/Parvati Shallow in his second season. Which stats capture that?
9,144 karma · joined April 28, 2021
It doesn't fix the actual problems with C++, which is that it's significantly more difficult to get and use external dependencies because of the compilation and linkage model of C++ libraries.
If C++ were as easy to build and link as modern programming languages you'd see the same kinds of tools as cargo, and the same kinds of ecosystem evolution as rust, like tokio. But you don't, because C++ code sucks to build, package, distribute, update, and reuse.
(I'm aware/have used conan/meson/vcpkg/etc - doesn't change my opinion).
But honestly that's a mischaracterization of the situation in Rust. Tokio is popular for networked service backends. If that's the wheelhouse you're in then yea it might look "dominant."
It's worth pointing out though that just tracing function calls isn't good enough for the kinds of stackless coroutines that run in async Rust tasks. You need a way of mapping between the async tasks and the compiler emitted traces.
afaik, C/C++ have the same problem.
> the idea of a modern dumb TV is non-existent.
They're sold as commercial display panels/digital signage and because they're a business product that isn't subsidized by advertising/spyware they cost a good bit more. But the panels and controls are basically identical to high end TVs.
This is just noise generation. If anyone is meant to actually read the document it should be written by you.
The transition from absolute to relative pitch is like moving from basic arithmetic to algebra, once it clicks. Except that relative pitch is way easier to understand without notation, pick a reference and go from there.
Interestingly this is a strong thing to fight because there are pieces of music that are physically inaccessible to many players, particularly people with hands not wide enough for the intervals. No amount of practice or stretching can overcome it and you can't exactly travel with a piano or keyboard everywhere.
There some cool things like the Janko keyboard that seem strictly superior to the traditional 12 keys but it's kind of an uphill fight to build conversion kits cheap and light and good enough to travel and perform with.
Changing a segfault to a panic with a stack trace is an improvement in developer experience. It does not make better software. The advantage of automatic strategies to mitigate memory safety mistakes either by using GC to make the program sound or static analysis to prevent the mistake by construction is plainly better.
There is a direction in some systems programming circles away from this by eschewing "complexity" (in other words, fixing the damn problems) for programs that have better error messages when the programmer made a mistake. I don't see that as better software.
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.