I wouldn't expect an LLM to be good at spell checking, actually. The way they tokenize text before manipulating it makes them fairly bad at working with small sequences of letters.
I have had good luck using an LLM as a "sanity checking" layer for transcription output, though. A simple prompt like "is this paragraph coherent" has proven to be a pretty decent way to check the accuracy of whisper transcriptions.
For anyone curious about the new growth of Bluesky and the decline of Twitter (x), the youtuber D'Angelo Wallace did a video exploring what the new user experience on Twitter (x) is like as of a few months ago: https://www.youtube.com/watch?v=gzwVqKtLBGc
I suspect these programs are mostly an attempt to claw back some people lost to the brain-drain that the region has been experiencing for decades. $10k over 5 years is not enough to seriously convince most people with no ties to the area to relocate there.
I have family roots in Cumberland and the nearby areas of West Virginia and MD and I still wouldn't consider moving back. But, if you still have a good relationship with family in the city and were already considering the move, this offer might look more compelling.
I believe Vermont also had a similar program for several years - offering a similar amount of money for people to move and work there in VT.
Cryptography lets you certify attestation. So an organization can certify that an image is legitimate, and you can cryptographically verify that this organization has indeed certified that this is a legit image.
That's it. It doesn't verify that the image itself is real, only that some organization has put their stamp of approval on the image. You can verify that the image wasn't tampered with between when they approved of it and it got to you, but you can't verify that the image was real to begin with.
On principle, you could build a chain of certification into the camera itself but this strikes me as a losing battle because you could just stage whatever you want in front of the camera.
The impetus then is on organizations to build that trust.
My question is how would those stamps exist in the first place? Is the idea that Canon or w/e will ship their physical cameras with keys, and sign those images with the keys. Now when you go to look at an image it'll be verified Canon, or w/e.
In that world wouldn't keys leak pretty easily? The key exists on the device. Is there a way this sort of stuff is actually viable? Or do i have the model entirely wrong?
You're right, hardware keys will leak. The idea is not to put trust into hardware, but to put trust into organizations.
Some photographer gives images to a news organization, and they take the photographer's word for it that these images are real before they sign and redistribute them. They trust the reporter, and you trust the organization. Or if the reporter has built enough credibility, they can vouch for the images themselves and you can trust them directly.
Cryptography allows you to verify that this reporter or organization attests that the images are what they claim. It doesn't allow you to verify whether the organization is worthy of your trust.
Either way, the system relies on being able to trust people, not things.
From another angle, I think it's understandable that people like to have premium "signifiers" of their skill. A carpenter with a full set of well maintained chisels seems on first glance more likely to be a good carpenter than one who carves uses with a box cutter.
So there may be a natural drive to collect and display things that indicate skill in our chosen areas of interest.
Now, to twist this around a bit: is this "gear acquisition syndrome" a contributor to the constant churn of tools and frameworks in our field? Especially in programming, collecting and using new "gear" (libraries, frameworks, administrative tools) is essentially free - often the only cost is time.
I know a tradesman who works out of a bucket with a ripped up tool organizer inside that's held together with duct tape and zip ties. His tools are all falling apart and often doesn't have the correct tool and is one of the types you'll see using a wrench as a hammer non-recreationally.
But still he's one of the cleverest there is, has seen every issue in the field 10,000 times and knows exactly how to handle it... but the immediate lack of respect he gets when he walks into a building is stunning. It adds so much friction to encounter.
I'm not really sure what this proves, since there aren't really good reasons for spawning 1 million processes that do nothing except sleeping. A more convincing demonstration would be spawning 1 million state machines that each maintain their own state and process messages or otherwise do useful work. But examples of that on the BEAM have been around for years.
So, in interest of matching this code I wrote an example of spawning 1_000_000 processes that each wait for 3 seconds and then exit.
This is Elixir, but this is trivial to do on the BEAM and could easily be done in Erlang as well:
The default process limit is 262,000-ish for historical reasons but it is easy to override when running the script:
» time elixir --erl "+P 1000001" process_demo.exs 1000000
spawning 1000000 processes
________________________________________________________
Executed in 6.85 secs fish external
usr time 11.79 secs 60.00 micros 11.79 secs
sys time 15.81 secs 714.00 micros 15.81 secs
I tried to get dotnet set up on my mac to run the code in your example to provide a timing comparison, but it has been a few years since I wrote C# professionally and I wasn't able to quickly finish the required boilerplate set up to run it.
Ultimately, although imo the BEAM performs quite well here, I think these kind of showy-but-simple tests miss the advantages of what OTP provides: unparalleled introspection abilities in production on a running system. Unfortunately, it is more difficult to demonstrate the runtime tools in a small code example.
The argument regarding representativeness is fair. But I think it is just as important for the basics to be fast, as they represent a constant overhead most other code makes use of. There are edge cases where unconsumed results get optimized away and other issues that make the results impossible to interpret, and these must be accounted for, but there is also a risk of just reducing the discussion to "No true Scotsman" which is not helpful in pursuit of "how do we write fast concurrent code without unnecessary complexity".
I have adjusted the example to match yours and be more expensive on .NET - previous one was spawning 1 million tasks waiting for the same asynchronous timer captured by a closure, each with own state machine, but nonetheless as cheap as it gets - spawning an asynchronously yielding C# task still costs 96B[0] even if we count state machine box allocation (closer to 112B in this case iirc).
To match your snippet, this now spawns 1M tasks that wait the respective 1M asynchronous timers, approximately tripling the allocation traffic.
var count = int.Parse(args[0]);
Console.WriteLine($"spawning {count} tasks");
var tasks = Enumerable
.Range(0, count)
.Select(async _ => await Task.Delay(3_000));
await Task.WhenAll(tasks);
In order to run this, you only need an SDK from https://dot.net/download. You can also get it from homebrew with `brew install dotnet-sdk` but I do not recommend daily driving this type of installation as Homebrew using separate path sometimes conflicts with other tooling and breaks SDK packs discovery of .NET's build system should you install another SDK in a different location.
After that, the setup process is just
mkdir CSTasks && cd CSTasks
dotnet new console --aot
echo '{snippet above}' > Program.cs
dotnet publish -o .
time ./CSTasks
Note: The use of AOT here is to avoid it spamming files as the default publish mode is "separate file per assembly + host-provided runtime" which is not as nice to use (historical default). Otherwise, the impact on the code execution time is minimal. Keep in mind that upon doing the first AOT compilation, it will have to pull IL AOT compiler from nuget feed.
Once done, you can just nuke the `/usr/local/share/dotnet` folder if you don't wish to keep the SDK.
Either way, thank you for putting together your comment - Elixir does seem like a REPL-friendly language[1] in many ways similar to F#. It would be impolite for me to not give it a try as you are willing to do the same for .NET.
[1]: there exist dotnet fsi as well as dotnet-script which allow using F# and C# for shell files in a similar way, but I found the startup latency of the latter underwhelming even with the cached compilation it does. It's okay, but not sub-100ms an sub-20ms you get with properly compiled JIT and AOT executables.
But that CO2 is then theoretically recaptured to make more fuel, right? At least if the carbon in the methane is sourced from the atmosphere in the first place.
Personally I would prefer the tool that allows me to choose when updates will be applied, regardless of the level of isolation. It does look like snapd now finally allows automatic updates to be disabled, as of version 2.58 (so Jan 2023), but it always left a really bad taste in my mouth that the ability to control what gets updated and when was kept out of user control for so long.
Yeah that’s an issue for some users. But the vast majority of packages are available on apt as well, so you don’t have to use it for packages where this is critical.
Another problem is that many packages have been sitting waiting for critical bug fixes for months. I'm not sure what their focus is, but they really aren't particularly suitable for use as a desktop or server OS.
A third problem is that the quality of the .deb's they package is low and decreasing rapidly. For instance, they don't seem to understand how to properly configure update-alternatives anymore.
I'm guessing all the above can be explained by establishing hiring bars that aren't good predictors of job performance, and then letting it play out for a decade or so.
> Another problem is that many packages have been sitting waiting for critical bug fixes for months. I'm not sure what their focus is, but they really aren't particularly suitable for use as a desktop or server OS.
This is something that bothers me with all the containerisation yes.
If there is a big vulnerability in libssl found now, you just update your distro once and boom, everything that uses openssl is fixed.
Now with all these snaps you have to wait for every maintainer to incorporate the update in their package when they feel like it. It's a mess.
I have had good luck using an LLM as a "sanity checking" layer for transcription output, though. A simple prompt like "is this paragraph coherent" has proven to be a pretty decent way to check the accuracy of whisper transcriptions.
reply