One of the central purposes of RCU is to decouple the updater/writer(s) from the reader(s). It doesn't matter to the writer if there is still a reader "out there" using the old version. And it likewise doesn't matter to (most) readers that the version they have is now old.
What is delayed is the actual destruction/deallocation of the RCU-managed objects. Nobody cares about that delay unless the objects control limited resources (in which case, RCU is likely a bad fit) or there are so many objects and/or they are so large that the delay in deallocating them could cause memory pressure of some type.
Direct File's initial rollout was only available in a relatively small subset of states. Not sure why (since it handles federal returns) but there were reasons, I am sure.
There are a bunch of us for whom it doesn't have all the info (if any, in fact).
Granted, the ranks of the self-employed are a small fraction of all taxpayers, and there's no reason the latter should be forced to do things as if they were part of the former.
This is sort of what I'm getting at. These are my taxes. I honestly don't want to involve a third party or sketchy links leading to janky websites. I want to go to IRS.gov, download a form, fill it out, submit it, all within a very limited context and with the smallest amount of feedback that the process completed successfully so I can relieve myself of the burden for another year.
The IRS actually already has the forms. It needs the scripting. It needs a digital submission system. That should be it and should be most of what average taxpayers actually need.
The site is actually run in a partnership between the IRS and Intuit and some other company. The GOP prevented it from being branded as an IRS "product".
What problem(s) does Nix solve that macOS's .app format does not? For that matter, that ad-hoc Linux packaging solutions involving LD_LIBRARY_PATH and included dependencies?
Put differently, doesn't the fundamental complexity of Nix come down to the combination of (a) "every app should get its own dependencies" and (b) "don't include dependencies with each app" ?
Building those applications consistently and reliably, e.g. being able to hop on a random Linux box and be able to build and deploy an application without thinking about where to fetch copies of all the dependencies. Nix’s raison d’etre is really to make developer lives easier, IMO.
I don’t use Nix, but I’ve played with other Linux package managers enough to understand the desire for something better, and something that’s actually predictable, especially (emphasis here!) when mixing/matching arbitrary versions of dependencies. I used Gentoo/Gentoo-derivates for several years and it (building random packages with == specific versions) is a sticky problem when using a traditional build system.
Of course, once the packages are built then you can do whatever hacks to bundle the dependencies with it. But the hard part is building them in a consistent, “reproducible” way.
"build and deploy" are two entirely different tasks.
Both the macOS .app design, and various ad-hoc Linux packaging strategies deal with the deployment step in a relatively trivial, extremely non-invasive way.
The build step is something else entirely, and while I can imagine that for some projects what Nix offers has much value, for others the problem is solved by a permanently deployed build stack (or stacks) whose specificity goes beyond anything that a distro-managed system could offer.
I think you're right that it's the build step where nix provides value. It's about replacing:
> a permanently deployed build stack (or stacks)
with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme.
But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package before you distributed it.
The idea behind NixOS is that since we must precisely define our build stack anyway, why not use the same technology to define the rest of our OS. Maybe that's overkill for some, but it sure is handy that there are NixOS users out there so when I want to use something from nixpkgs when defining my dev environment on MacOS it already has the kinks worked out.
As for
> ...whose specificity goes beyond anything that a distro-managed system could offer.
My feeling is that most nix code is not distro managed but rather written by individual project maintainers. We only bother contributing something to nixpkgs if we think it's widely applicable.
> with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme.
> But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package before you distributed it.
This suggests to me that either you don't know how .app packaging works on macOS (or various ad-hoc packaging on Linux, such as Firefox or Ardour), or you're making a point that I'm missing.
The whole point of these non-Nix systems is precisely that you just package up bits of the build stack into the thing you distribute, and you reduce or eliminate system dependencies other than such basics as the system C library or X11.
I had misunderstood what a .app package was, thanks for clarifying. So do people package things like linters and language servers into the .app also? Like, is it everything I'd need to work on the app, or is just everything I'd need to run the app?
And in the USA, at least, glass containers that could be re-used are instead crushed and then either (a) used to create new glass, significantly more energetically costly than re-use OR (b) used for applications like asphalt.
Erewhon is a grocery store in LA and makes its own sauces. You return the bottles back to the store and they reuse them.
Reminds me of my childhood when a milkman delivered milk to your home in bottles and you washed and left the old bottles for him to pick up. (Plus, as a kid, you would tease your friends that the milkman was your real father).
Straus Family Creamery uses glass bottles for many products, and the farmer's market refunds a $3 deposit when they're returned. The bottle caps are plastic, and there's an address where you can send them by mail.
Sending a few bottle caps by mail probably causes more environmental pollution than sending them back (after which still even more energy needs to be spent to recycle them).
Alternatively, what Chomsky was thinking about with his universal grammar idea is something implicitly present in both our minds and an LLM i.e. "it's the wiring, stupid".
I'm not sure there's much evidence for this one way or another at this point.
>is something implicitly present in both our minds and an LLM
The LLM doesn't start with any real structure besides the network of ops though. If there is any induced structure, it's learnable from the data. And given enough data the base network is sufficient to learn the "grammar" of not just human language but more complex CFGs and things you wouldn't traditionally consider "languages" as well (e.g. audio, images). In a sort of chicken/egg scenario, the morasses of data gives rise to the structures needed to parse and generate that data.
Yes, that API is actually great, but the problem with (s)scanf() is that reading an invalid value is undefined behavior. So you can't use it if you don't already know the result fits in &value, which is exactly the situation where you'd use strtol() instead.
Presumably 'undefined behavior' means you'll get an undefined int value back -- which you will (of course) range-check -- not that it will wipe out the next 600KB of memory starting at &value or do something similarly hazardous.
No, that's very much not what undefined behavior means. Undefined Behavior (the man page on my system actually capitalizes both words) means that there are no guarantees at all about the behavior of the whole program. It can very much wipe out whole chunks of memory, or crash (not necessarily in or around the sscanf call), or get stuck in an infinite loop, or whatever.
The bug is in the spec, but as the other pointer also points out:
> However, current implementations are not safe from that bug, so it is not recommended to use them. Instead, programs should use functions such as strtol(3) to parse numeric input. This manual page deprecates use of the numeric conversion specifiers until they are fixed by ISO C.
In other words, sscanf itself is not safe to use for numeric conversions.
Why should you care? Depends. Do you care about writing correct programs? If not, there's no need to care.
> Use of the numeric conversion specifiers produces Undefined Behavior for invalid input. See C11 7.21.6.2/10 ⟨https://port70.net/%7Ensz/c/c11/n1570.html#7.21.6.2p10⟩. This is a bug in the ISO C standard, and not an inherent design issue with the API. However, current implementations are not safe from that bug, so it is not recommended to use them. Instead, programs should use functions such as strtol(3) to parse numeric input. This manual page deprecates use of the numeric conversion specifiers until they are fixed by ISO C.
reply