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.
I remember, as a child, attempting to reproduce the BASIC program in one of the MAD magazine issues. Somewhere, I had made a typo, which completely screwed the output. I guessed that the tediousness of the whole exercise was part of the joke, shrugged, and moved on.
It was pretty common to distribute code as "listing" like this. Typically it came with a checksum for every line and a small program to compute and print that for your own program that you had typed over, which you could then use to fairly quickly(-ish) spot any typos.
All of this is how I learned to program by the way. Kids these days don't know how easy they have it.
Huh, we used to type in BASIC programs from magazines back in the 1980s and I don’t ever recall seeing any kinds of checksum. We would often resort to printing out the code and visually comparing line by line against the magazine.
We mostly had Family Computing magazine. I looked up an issue from 1985 with one of my favorite type-by-hand games, Hit or Miss [0], and no sight of a helpful checksum.
To be honest, the idea of it would have blown my mind back then; the idea that your BASIC code is just a text file that can be processed by other programs is something that would never have occurred to me.
Checksums became popular at some point in the 80s. I remember when COMPUTE! first added them they were a godsend. Especially for the machine language programs that were just pages of data statements.
> Kids these days don't know how easy they have it.
Maybe it’s rose-colored glasses, but I have much fonder memories of programming basic on a Ti-84 calculator than debugging an import incompatibility between. Es5 and CommonJS modules
In case there are any other Sergio Aragones superfan weirdos like me here, who only click MAD-related stories in order to command-f for "Sergio Aragones" and then move on when inevitably there are no results: today's your lucky day, click that link above!
The Commodore version of the source in the magazine never worked. I probably typed it in at least five times in whole thinking I'd screwed something up. It wasn't until a few years ago (from an HN post, no less) that I found the link above and finally, finally got to see what the code did.
There's also a middle ground: Painstakingly describe the solution first, along with its downside of not being general in the same way as some of the existing features (I guess for example seeking back 10 seconds) are not, and ask whether a patch implementing this solution would be welcome before implementing it.
I wanted to report a big about VLC's extraordinarily badly designed "Magnification/Zoom" user interface, so first I searched the forum to see if there was any other discussion about it, which there naturally was.
So I painstakingly wrote up an extremely detailed description of a bunch of interrelated bugs related to zooming and how it terribly interacted with other features like rotation, in response to the VLC development team brushing off another user complaining about its terrible "Magnification/Zoom" user interface, and they brushed me off too because they were too lazy to read it.
They told me to just submit a bug report, but I pointed out that I was describing a several interrelated bugs, which would require submitting many bug reports, which they would have known if they had actually bothered to read what I painstakingly wrote in great detail with step by step instructions about how to reproduce the bugs and suggestions for improvements, so I obviously wanted to discuss them all first to see if they were even worth my time submitting multiple bug reports about, or if all my efforts reporting bugs and trying to fix them and submit patches would be a waste of time, brushed off and ignored like they did to the other users who described the bugs and usability problems they were experiencing.
Jean-Baptiste Kempf himself replied "If you did shorter posts, maybe people will read them..."
To which I replied "if you did less arrogant responses to long posts, maybe people wouldn't give up on trying to help you."
And of course most of the pathologically terrible bugs I described are still there, a dozen years later. And Jean-Baptiste Kempf still continues to act that way.
HN user KingMob's post perfectly summarized my discouraging experience from a dozen years ago, about a set of bugs and usability problems relating to the horrible "Magnification/Zoom" interface:
>KingMob 5 hours ago | unvote | parent | context | flag | favorite | on: Mpv – A free, open-source, and cross-platform medi...
>It's because the developer is misconstruing a non-technical decision they made as a technical limitation.
The commenters are trying to point this out, which misses the reality that the developer probably isn't going to budge from their requirement of universal support.
>That dev's rationalization also sends a signal to any commenter with the technical chops to submit a PR, that it will probably be rejected for not supporting 100% of the codecs. I have no doubt people who could do it, over the years looked at that thread and concluded it would be a waste of their time.
Jean-Baptiste Kempf still continues to act that way, and still hasn't even admitted to those bugs and usability problems, let alone fixed them or accepted patches from anyone else who did. He just discourages qualified developers from collaborating, and brushes off legitimate requests from users who can't code but fucking well know other video players don't suffer from those problems.
To be fair, as a maintainer I also dread walls of text from super motivated people about details to which I assign very low priority. I’m never an asshole about it, though.
To also be fair, to "Painstakingly describe the solution first" absolutely requires a wall of text to enumerate all the multiple layers of interacting bugs, and give step-by-step instructions for reproducing them.
At least I put in the effort to search the discussion group for an existing thread about the problems I had, and contributed to that thread by supporting other users and validating their complaints, instead of opening yet another redundant thread.
The reason I went into so much detail was that the VLC developers were ALREADY acting like assholes by brushing off other people's shorter less detailed descriptions of the same problems, with glib quips like "The holy grail already exists... built in to OS X."
The zooming built into OS X definitely doesn't solve the problems that they refuse to admit exist with their astoundingly terrible "Magnification/Zoom" interface, so I described the problems for their benefit in the same detail I would appreciate in bug reports on my own open source software, in response to their rudely and curtly brushing off other users with the same problems, who don't all have a background in user interface design and software development and writing bug reports.
If the holy grail already exists and solves the problem, then they should REMOVE the horrible unusable "Magnification/Zoom" feature that breaks even worse when you dare to rotate or flip the video, or better yet they should have never allowed that broken "feature" to be merged into VLC in the first place, because of its ridiculously poor design and implementation quality (like drawing and tracking the gui with gigantic fat pixels in un-scaled, un-rotated video pixel coordinates, instead of full resolution screen overlay coordinates, and ignoring the flip/rotation for mouse tracking so you can't see what you're pointing at, which is negligent and insane).
Ironically, VLC accepting and distributing features like the "Magnification/Zoom" interface certainly undermines their arguments that they don't want to accept other patches because of quality and reliability and usability issues. If they refuse to fix it, they should remove it instead, it's just so bad.
And if I didn't bother going to the effort of describing the problems in detail with step-by-step instructions to reproduce them, I'm afraid that Jean-Baptiste Kempf is so thin skinned and arrogant that he would have brushed off my bug report for that reason too. Just like he CONTINUES to rudely and passive-aggressively brush off and ignore other people's perfectly valid bug reports to this day, 12 years later. He's not going to suddenly change.
Optimally, next to a source of water that can be split into hydrogen, ready to be used for the chemical process producing the pure iron. (Not the process in TFA.)
An array of SMRs (small modular reactors) located at the steel factory could be used – and would be sufficient – both for heating and producing the electricity without interruptions caused by fluctuating prices or blackouts.
Currently, birding. Got really into it in 2021 since it pretty much runs in the family. I feel that observing the lives of our fellow creatures helps me really destress and put my mind off work. Interestingly, I find that birding while walking in the nature works better in this regard than just walking in the nature.
Get a good pair of binoculars, a bird sound recognition app for your mobile[1], and a bird field guide (as a European, I prefer [2]), and you're good to go.
Nice, i'm an amateur birder, meaning i'm just standing in front of the office building and ..watch the birds. But lately i have been thinking more and more about professionalizing it.
It's so calm and fascinating.
I love to spot any raptor - I'm even a little superstitious about them and tend to take sighting a hawk as a good omen. I also always love to watch a heron/crane - they just seem so dinosaur-ish. Very interesting birds.
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.
reply