I’ve heard it as a word, “Rustles”. Not sure how canonical that is though.
Person interested in programming, languages, culture, and human flourishing.
I’ve heard it as a word, “Rustles”. Not sure how canonical that is though.
I mean, the simple proof is that Rust has been growing by leaps and bounds in the embedded world, which is the closest to bare metal you get. It’s also being used in the Linux kernel and Windows, and there are several projects building new kernels in pure Rust. So yeah, it’s safe to say that it’s as close to the metal as C.
Also, the comparison to Java is understandable if you’ve only been exposed to Rust by the memes, but it doesn’t hold up in practice. Rust has a lot more syntax than C (although that’s not saying much), but it’s one of the most expressive languages on the market today.
It’s satire, pointing the cognitive dissonance that allows people to recognize that fumes are deadly but never question the fact that our entire “modern” concept of city planning is built around constantly being in and around the machines that produce these fumes 24/7.
My preferred variation of this is to make it an open question that leaves them in the position of authority, and assumes that they made a deliberate decision.
For example, instead of “Why aren’t you using StandardLib that does 90% of this?”, I would try “Could this be achieved with StandardLib? Seems like it would cover 90% of this”.
As with all things, there’s a trade off: how much do you value the [convenience/ecosystem/insert other thing that proprietary system offers you] compared to the ongoing cost - monetarily but also in terms of privacy, market manipulation, environmental impact, etc. of supporting and relying on the proprietary system.
You can’t do your work without connecting to Exchange because Microsoft has leveraged decades of monopolistic gains to make Outlook the default option for any “serious” business, and has invested even further in making inconvenient (or soon impossible) to connect to Exchange from outside their sanctioned walled gardens. Demanding that Linux solve that for you is akin to demanding that the person commuting on bike undo a century of automotive-centric urban expansion in the US so that they don’t interrupt your commute. It’s not their fault they can’t solve the problem and it doesn’t help anyone to get mad at them for doing their best to behave rationally in a system stacked to only serve the 1%’s corporate interests.
The most obvious cost of detached homes is the completely unsustainable amounts of infrastructure required to maintain them. Roads, sewage, electric, etc.
It’s a well documented fact that suburbs of sprawling suburban homes are bankrupting towns/cities all across America and only the densely built downtown cores are keeping these cities afloat because the tax revenue of dense mixed-use areas is substantially higher than the cost of maintaining the infrastructure for these places. Check out Strong Towns if you’d like to know more and see the studies showing all this.
Proton Pass already supports passkeys: https://proton.me/support/pass-use-passkeys
I think the point is that they don’t want to have to use a full JS framework (which is what HTMX is) for this behavior.
And this is where HTMX fits in. It’s an elegant and powerful solution to the front-end/back-end split, allowing more of the control logic to operate on the back-end while dynamically loading HTML into their respective places on the front-end.
But for a tech-luddite like me, this was still a bit too much. All I really want to do is swap page fragments using something like AJAX while sticking to semantically correct HTML.
EDIT: Put another way, if you look at HTMX’s "motivation"s:
motivation
- Why should only
<a>
&<form>
be able to make HTTP requests?- Why should only
click
&submit
events trigger them?- Why should only
GET
&POST
methods be available?- Why should you only be able to replace the entire screen?
By removing these constraints, htmx completes HTML as a hypertext
It seems the author only cares about the final bullet, and thinks the first three are reasonable/acceptable limitations.
I can’t claim full understanding, but what I took away from it was that NVIDIA somehow ended up using GPL-licensed code in their proprietary drivers, possibly in a way that could incriminate the Linux kernel if not handled properly. My best guess (as someone with no kernel programming experience) is that NVIDIA sometimes contributes code directly to the Linux kernel that exists solely to support their proprietary drivers (the shims mentioned in the article). Apparently, these shims were exporting GPL-licensed code for use inside the proprietary drivers, which would be a violation of the GPL (unless NVIDIA made the source code for their proprietary drivers freely available in compliance with the GPL).
TLDR: (I think?) NVIDIA essentially infected the linux kernel with license violations to support their proprietary drivers, and the linux kernel devs are working to excise the violations and prevent anything like that going forward.
I have stopped giving Apple my money, for this among other reasons. I have to say, though, that Asahi Linux makes a compelling case for repurposing their hardware for better use.