Linux Desktops are having a moment this year, but there are still all sorts of sharp edges that a user has to navigate.
Getting a laptop to properly hibernate such that the battery life is usable on the road is a whole roll-your-own-adventure.
WirePlumber apparently mis-classifies some headphones resulting in only input or output working in web meetings.
I've worked with Linux on the server side for over 20 years and these were just two Fedora issues that LLMs helped me sort out recently. If I had to spend a whole day debugging these items, I would likely be drifting back towards macOS or WSL2.
Getting Linux installed has always been the "easy" part. It's everything after that in daily operations that has been hard.
Even with copy-on-write, fork() still has to pay the setup cost for COW. If the parent process has a lot of busy threads (e.g. Java), you can end up doing a lot of unnecessary COW before exec() fires.
vfork() does NOT stop the world in many / most implementations. The ones that do stop the world do it because someone misunderstood the whole "vfork() stops the parent process" -- yes, it stops the parent process in a pre-threads world, but it doesn't have to stop any other threads but the one that called vfork(). Indeed, many implementations don't do that.
(Someone once tried to make NetBSD's vfork() stop the world because that's what the pre-threading man page said it does. I did my utter best to keep that from happening at the time, and it didn't then. Hopefully no one tried again later.)
If I understand the article correctly, that second proof was published as a rider on a first proof that was entirely Dedekind's. So, there was definitely a credit owed at time of publishing.
I came away with the impression that the biggest villain in this story was Kronecker. Without the need to tiptoe around his ego and gatekeeping, these results may have been published as a paper with joint authorship.
I read it the other way. Here's the quote from the article:
On December 7, 1873, he wrote to Dedekind that he thought he’d finally succeeded: “But if I should be deceiving myself, I should certainly find no more indulgent judge than you.” He laid out his proof. But it was unwieldy, convoluted. Dedekind replied with a way to simplify Cantor’s proof, building a clearer argument without losing any rigor or accuracy. Meanwhile Cantor, before he’d received Dedekind’s letter, sent him a similar idea for how to streamline the proof, though he hadn’t worked out the details the way Dedekind had.
"Dedekind quickly replied that...he’d worked out a proof that the algebraic numbers (the numbers you get as solutions to algebra problems) could be counted.
[...]
Weierstrass had been most excited about the proof that algebraic numbers are countable. (He would later use that result to prove a theorem of his own.) So Cantor chose a misleading title [for his paper] that only mentioned algebraic numbers.
[...]
Writing his paper, Cantor put the proof about algebraic numbers first. Below it, he added his own proof that the real numbers cannot be counted — Dedekind’s simplified version of it, that is."
So the first proof -- the one the article was titled after -- was completely created by Dedekind.
> he’d worked out a proof that the algebraic numbers (the numbers you get as solutions to algebra problems) could be counted
I can't say I'm fully comfortable with that characterization of the algebraic numbers. The definition itself does suggest a proof that they are countable:
1. The number of symbols that can appear in a well-defined algebra problem is finite. (For example, if we define algebra problems as being posed in written English, we can use an inventory of no more than 50 symbols to define them all. If we define "algebra problems" in some other way, the definition will specify how many symbols are available.)
2. The number of possible strings describing algebra problems, created from this finite symbolic alphabet, is necessarily countable, because the strings have finite length.
3. Each algebraic number is the solution to one of those strings, and therefore the algebraic numbers are countable.
But I don't really feel like it's possible to learn anything about the numbers from that proof.
Yeah, that was a weird way to describe the algebraic numbers. The formal definition (those numbers for which a finite polynomial p exists with p(x)=0) is not that complicated, is it?
You can also get to computable numbers through a similar argument, substituting something Turing-complete for algebra. You definitely do get to learn some interesting things about numbers from computable numbers. The differences between the computables and the full reals are much more subtle than the differences between the rationals and the reals.
> The differences between the computables and the full reals are much more subtle than the differences between the rationals and the reals.
How so?
Using the definition of computable numbers where you provide input of n and the output is every digit of the number up to n places past the decimal point, we can rephrase that definition like so:
A computable number c is one with the following property:
A Turing machine exists which, provided with a tolerance δ, will exhibit a rational number q < c such that c - q < δ
Clearly, a suitable rational will always exist, since rationals can be found within any distance of any real.
But for some particular real, we might not be able to find that rational through the use of a fixed Turing machine, in which case the real would be noncomputable. This suggests to me that there is a wider gap between the computables and the reals, where the approximation of a real number is limited by the need to describe it with a Turing machine, than there is between the rationals and the reals, where we can use the same approximation, but without that limitation.
(Obviously the rationals are a subset of the computables, but if we're considering a relationship to the real numbers, the rationals seem to have one that is closer and more direct...? The relationship of a computable number to a real number is defined through intermediary rational numbers.)
"This suggests to me that there is a wider gap between the computables and the reals"
I didn't say "wider". I said more subtle. It doesn't take much mathematical intuition and training to understand the rationals versus the reals. Understanding the computables versus the reals is a lot more tricky and takes a lot more thought. The simple arguments that show the difference between the rationals and the reals require a lot of very careful adjustment if you want to translate them to the computables versus the reals.
From a quick skim of hardware support on Wikipedia, it looks like encoding support for H.265 showed up in NVIDIA, AMD, et. al around 2015 whereas AV1 support didn't arrive until 2022.
So, the apparent preference could simply be 5+ years more time to do hardware-assisted transcoding.
Agreed. I think the buried lede here is actually the clawback clause. With that in the contract, this isn't a $1.5 million dollar grant, it's a $1.5 million dollar liability.
If you take the money and spend it on research and development and then get hit by a clawback, whether due to "DEI" or some other reason, that is a financially ruinous event to somehow come up with $1.5 million dollars that was already spent.
A shame and a waste as it sounds like the project would have been beneficial outside of the Python ecosystem, had it been funded.
As treasurer of a similar FOSS org, this is the correct take.
An important responsibility of the people running a FOSS community's backing non-profit is to keep the org safe and stable, as the community relies on it for vital services and legal representation. A risk like that is unacceptable, even more than in commercial business.
Typically in grant work you submit a complete proposal with milestones and roles defined, and receive payout over time to cover the costs in the plan, or some part of them. It's earmarked money.
In more established non-profit areas there's usually also quite some compliance overhead and audits to be passed, so this can be someone's fulltime job on the org side. FOSS backing orgs are typically smaller and less experienced, so donors have so far found ways to make things easier for them and give more leeway.
> If you take the money and spend it on research and development and then get hit by a clawback, whether due to "DEI" or some other reason, that is a financially ruinous event to somehow come up with $1.5 million dollars that was already spent.
This is it. The conditions / circumstances of the clawback are irrelevant. If there's any possibility of a clawback, then the grant is a rope to hang your organization with.
I don't think an NSF grant should be a trade, wherein your org sells its mission / independence, and the NSF buys influence.
> I don't think an NSF grant should be a trade, wherein your org sells its mission / independence, and the NSF buys influence.
This is the whole reason the administration is implementing these policies. It's not just about political opposition to diversity programs, it's about getting hooks into science funding as a whole. With a clawback clause, the administration gets the ability to defund any study that produces results they don't like.
They'll use this to selectively block science across entire fields - mRNA vaccines, climate studies, psychology - I fully expect to see this administration cutting funding from anything that contradicts their official narratives.
Also, "git reflog" lists out all commit SHAs in chronological order. Trying to figure out how to rebase, but got lost and everything seems broken? You're just one "git reset" away from the better place you were in and "reflog" has the list.
For anyone looking for a convenient way to set restic up: Backrest[1] provides a docker container and a web interface to configure, monitor and restore your restic backups.
Getting a laptop to properly hibernate such that the battery life is usable on the road is a whole roll-your-own-adventure.
WirePlumber apparently mis-classifies some headphones resulting in only input or output working in web meetings.
I've worked with Linux on the server side for over 20 years and these were just two Fedora issues that LLMs helped me sort out recently. If I had to spend a whole day debugging these items, I would likely be drifting back towards macOS or WSL2.
Getting Linux installed has always been the "easy" part. It's everything after that in daily operations that has been hard.