Or even better, participate in improving it. The reference encoder is, I believe, in the libjxl repository[1].
Much of the recent effort seems to be focused on the performance of the Rust version of the decoding library[2], which is quite understandable because of the fresh browser adoption.
Ruuvi Air[1] seems to be close to the middle in both price and CO2 measurement accuracy between aranet4 and the IKEA device. I don't have personal experience with Ruuvi Air specifically, but have been using their cheaper Ruuvi Tags (that don't measure CO2) for temperature, humidity and air pressure measurement at home and office.
Yes, and the corn-based ethanol here is used for "feeding cars" that have combustion engines, i.e. it's already used exactly for energy production. The most recent Technology Connections video[1] quoted some numbers on this. All this land dedicated to disposable energy production could be dedicated to renewable energy production instead.
Such an unfathomable waste when you put it in the context of “feeding cars”. I really appreciated the way this channel broke down this viewpoint. Made me want to finally get some panels for my balcony.
It means that it doesn't generate any mechanical work, it's wasted as heat not captured for any other productive purpose (since waste heat can be useful in some contexts).
Your main point still stands, but aren't both of them renewable? Corn is a renewable resource, thus ethanol derived from it is too. It's just seemingly a much less efficient renewable fuel for powering a car compared to solar.
You're right. Perhaps clean would better capture the distinction in favor of solar in this context? Both corn and solar convert insolation to usable power with a short time between capture and use. Solar, on the other hand, is net negative when it comes to emissions, while the corn harvest is just burnt with the CO2 escaping back to the atmosphere. (And potentially, the solar panels can just be recycled back to new solar panels when they reach the end of their lifetimes. They're mostly aluminum and glass after all.)
Corn ethanol isn't a renewable resource. The land use of corn is a problem, but it's rounding error compared to the petroleum consumption of that industry, or the topsoil degradation.
To get one Joule out of corn ethanol, the US is burning more than one Joule of oil. This is probably the main reason corn subsidies are so popular politically. They serve the oil barons, mega farms, and big agriculture firms like Monsanto.
On top of that, modern farming practices degrade topsoil over time. It's gotten a bit better than the Dust Bowl days, but we're still burning through topsoil at crazy rates, and it is beyond current technology to manufacture new topsoil.
So, ethanol corn is like heating your house by dumping gas on a field and burning it to boil water. Then you carry the water inside. There only difference is the number of levels of indirection.
The last I checked, it took less energy to make a solar panel than the expected lifetime output of the panel. So, at least you can power solar factories (in theory) with solar. There's still the problem of the environmental impact of rare earth refining, but at least it's a second order issue, and not like the first order issues corn ethanol has.
(Note that not all ethanol farming is as dumb as what the US does: For example, Brazil has had a net positive energy industry from sugar ethanol for a while. They "just" have to clear cut the rain forest to replace the farmland that house of cards is destroying.)
Even ignoring all non renewable consumption in growing the corn to be turned into ethanol it is still going towards an incredibly polluting infrastructure.
While each solar panel is a small step towards more and better electrification
Just today, a citizens' initiative started collecting signatures in Finland to stop recent projects that aim to transfer hosting of election, taxation, and social security data on services provided by US-run companies.[1]
Is it, though? It's genuinely hard for me to tell.
There's both serialization and deserialization of data sets with, e.g., JSON including floating point numbers, implying formatting and parsing, respectively.
Source code (including unit tests etc.) with hard-coded floating point values is compiled, linted, automatically formatted again and again, implying lots of parsing.
Code I usually work with ingests a lot of floating point numbers, but whatever is calculated is seldom displayed as formatted strings and more often gets plotted on graphs.
For serialization and deserialization, when the goal is to produce strings that will be read again by a computer, I consider the use of decimal numbers as a serious mistake.
The conversion to string should produce a hexadecimal floating-point number (e.g. with the "a" or "A" printf conversion specifier of recent C library implementations), not a decimal number, so that both serialization and deserialization are trivial and they cannot introduce any errors.
Even if a human inspects the strings produced in this way, comparing numbers to see which is greater or less and examining the order of magnitude can be done as easy as with decimal numbers. Nobody will want to do exact arithmetic computations mentally with such numbers.
Think about things like logging and all the uses of printf which are not parsed back. But I agree that parsing is extremely common, just not the same level.
I'm a long-time Xmonad user. Currently, I'm using Ubuntu 25.04, having upgraded to new non-LTS releases every six months, on two computers running Xmonad. I haven't run into any problems.
There's something about real optimization stories that I find fascinating – particularly the detailed ones including step-by-step improvements and profiling to show how numbers got better. In some way, they are satisfying to read.
Nicholas Nethercote's "How to speed up the Rust compiler" writings[1] fall into this same category for me.
Since you seem to enjoy this kind of writing I'd love to get your feedback on something I've written a while back about branchless partitioning [1]. Despite it being content wise the most work to create of the things I've written about the topic, it found much less attention than other things I've written. So far I've wondered if it was maybe too technical? Would love to get an honest opinion.
Just finished reading your linked article. I found it interesting and I experienced similar excitement from the results as mentioned up-thread. There were some new things I learned, too.
I wouldn't say your article is too technical; it does go a bit deeper into details, but new concepts are explained well and at a level I found suitable for myself. Having said that, several times I felt that the text was a bit verbose. Using more succinct phrasing needs, of course, a lot of additional effort, but… I guess it's a kind of an optimization as well. :)
Thx for taking the time and glad to hear you enjoyed it. I keep being impressed by people like Cory Doctorow that can express nearly every sentence they write extremely succinctly and on the point. That's something I aspire to, so hopefully next time I'm a little better at it :)
I read an article a while ago where the goal is to process a file as fast as possible and the article talks about compressing the data chunks so they fit in L1 cache. The cache misses were slower than compressing and decompressing the data from L1 cache.
I've been trying to find that article ever since but I'm not able to. Anyone knows the article I'm talking about?
Generally, I agree the situation with errors is much better in Rust in the ways you describe. But, there are also panics which you can catch_unwind[1], set_hook[2] for, define a #[panic_handler][3] for, etc.
Yeah, in anything but heavily multi-threaded servers, it's usually best to immediately crash on a panic. Panics don't mean "a normal error occurred", they mean, "This program is cursed and our fundamental assumptions are wrong." So it's normal for a unit test harness to catch panics. And you may occasionally catch them and kill an entire client connection, sort of the way Erlang handles major failures. But most programs should just exit immediately.
A prime example: JIRA's backlog view. In the self-hosted version, you could easily find the issue you were looking for in the backlog view by just using the browser's search, press Ctrl+F, write some words, you have the issue you were looking for. The cloud version Atlassian forced their users into, OTOH, features their own implementation hijacking Ctrl+F combined with dynamically removing the issues not currently visible from the DOM, to ensure that no-one can have the convenience of the browser's built-in search.
Or even better, participate in improving it. The reference encoder is, I believe, in the libjxl repository[1].
Much of the recent effort seems to be focused on the performance of the Rust version of the decoding library[2], which is quite understandable because of the fresh browser adoption.
[1] https://github.com/libjxl/libjxl
[2] https://jxl-rs-perf.lucaversari.it/?config=desktop%7Csingle&...