bgribble

The direction Audacity has been heading now is ok, but it's not for me. I really miss the days when it was just an editor for audio files. I have a DAW already, thanks, but I do still need to just quickly pop open a sample file to trim, normalize, maybe stretch it. I don't want to create a "project" or save really anything other than the edited audio.

I guess I don't really have an opinion about that. Certainly an exact representation of decimal numbers was essential, and was something we needed to implement at the time, but going to a fully rational numeric stack was arguably overkill.

The current value of held assets in another currency isn't really "counting" any more, it's a prediction of the outcome of some future transaction that hasn't happened. So I'm less concerned about exactly computing it than I am in never making a mistake in assets that I am counting, i.e. keeping in one account and only incrementing and decrementing the amount when a transaction occurs.

I seem to remember that we were aware that fractional commodities were going away, but exact rational values would still be important to be able to represent historical holdings and transactions.

I committed to the GnuCash codebase pretty regularly in the 1999-2002 era... I think maybe I actually implemented the fractional representation that the article discusses? Not sure, it was a long time ago! I definitely remember receiving some very heated emails about how this was total nonsense and there was no reason to do anything other than a decimal representation. The phrase "a superhighway of abstraction, leading nowhere" has stuck with me for lo these many years :) good times

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well.

They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engineering team for not delivering to their estimate.

As it turns out, the magic sauce that makes everything taste better is just ketchup.

It's good (maybe even indispensable) for some things. Please don't go "ketchup native" on my ice cream.

How else are you going to liquidity-stalk that company you left with some options or even shares?

I take my first cup of coffee with a little tea-leaf reading based on the activity of the CEO and my former coworkers. If you ever see more than 5 connections reacting/liking the same thing you know that HR or marketing sent out an email about it.

I feel some genuine grief about what GTK has become.

It started out as a toolkit for application development and leaned heavily into the needs of the C developer who was writing an application with a GUI. It was really a breath of fresh air to us crusties who started out with Xaw and Motif. That's the GTK I want to remember.

What it is now is (IMO) mostly a product of the economics of free software development. There's not a lot of bread out there to build a great, free, developer experience for Linux apps. Paid GTK development is just in service of improving the desktop platform that the big vendors ship. This leads to more abstraction breaks between the toolkit, the desktop, and the theme, because nobody cares as long as all the core desktop apps work. "Third party" app developers, who used to be the only audience for GTK, are a distant second place. The third party DX is only good if you follow a cookie-cutter app template.

I switched my long-term personal projects from GTK2 to Dear ImGui, which IMO is the only UI toolkit going that actually prioritizes developer experience. Porting from GTK2 to GTK3 would have been almost as much work since I depended on Clutter (which was at one point a key element of the platform, but got dropped/deprecated -- maybe its corporate sponsor folded? not sure).

I am still skeptical about the value of LLM as coding helper in 2025. I have not dedicated myself to an "AI first" workflow so maybe I am just doing it wrong.

The most positive metaphor I have heard about why LLM coding assistance is so great is that it's like having a hard-working junior dev that does whatever you want and doesn't waste time reading HN. You still have to check the work, there will be some bad decisions in there, the code maybe isn't that great, but you can tell it to generate tests so you know it is functional.

OK, let's say I accept that 100% (I personally haven't seen evidence that LLM assistance is really even up to that level, but for the sake of argument). My experience as a senior dev is that adding juniors to a team slows down progress and makes the outcome worse. You only do it because that's how you train and mentor juniors to be able to work independently. You are investing in the team every time you review a junior's code, give them advice, answer their questions about what is going on.

With an LLM coding assistant, all the instruction and review you give it is just wasted effort. It makes you slower overall and you spend a lot of time explaining code and managing/directing something that not only doesn't care but doesn't even have the ability to remember what you said for the next project. And the code you get out, in my experience at least, is pretty crap.

I get that it's a different and, to some, interesting way of programming-by-specification, but as far as I can tell the hype about how much faster and better you can code with an AI sidekick is just that -- hype. Maybe that will be wrong next year, maybe it's wrong now with state-of-the-art tools, but I still can't help thinking that the fundamental problem, that all the effort you spend on "mentoring" an LLM is just flushed down the toilet, means that your long term team health will suffer.'

I don't know that the hardware is dead yet. They got a cash infusion last year and there are occasional hardware updates in their Discord. It's just a slow process with 1-2 engineers total working on the many different hardware and software and firmware elements of the overall product.

There's no hurt feelings like the hurt feelings of a junior engineer, who has spent the last year kvetching about how much they hate working on legacy junk, hearing someone else refer to one of THEIR projects as "legacy junk".

Any code that's old enough to have its first birthday party is "legacy", which means that "legacy" is a completely useless category. Anyone calling anything "legacy" is generally just showing their own lack of experience.

I ran face-first into this effect at a successful startup where I started as employee number 9.

When everyone can sit around one big table, you don't have to consciously polish your "brand" all the time -- most people have direct experience with you and base their opinions on that. You do good work and you will have a good reputation. If you have a conflict with someone who is a jackass or have a project that fails to launch, people know enough about the context to judge pretty fairly.

When there are hundreds of people on the engineering team, especially in a remote-heavy workforce, most people don't have direct experience with you and can only base their opinion of you on what they hear from others, i.e. your reputation. This goes for peers as much as leadership.

You have to be aware of how an org changes over time, and how things that were once not important are now essential skills for success.. and decide if any new essentials are skills that you are interested in developing.

You can still buy bikes like that. There are plenty of people still making frame sets that will work with standard drive train components, standard sized stems, and plain ol handlebars in a variety of shapes. And they will build a bike for you.

I bought a Rivendell about 10 years ago and it's probably my last bike. Is a steel frame heavier than carbon? Yes, a bit, but I don't have to throw it away after a crash, it rides like a dream, and the weight difference is less than the extra "water bottles" I carry around my midsection. Most of the weight of the bike+rider (which is what you have to haul around) is the rider, not the bike, and the frame is just a fraction of the weight of the bike!

Even though new bikes are getting more and more proprietary, I don't foresee a time when I can't buy a new Shimano cassette or other replaceable parts.

I worked for an Intel spinoff whose CEO was a former high-level Intel exec from the 1990-2010 era. Internal goss attributed much of Intel's decision to stay out of the iPhone to him... there was a supposed quote that went something like "we make chips for computers, not g*d** telephones!"

As the tale went, he was sent out to this doomed-from-birth spinoff as a "sunset cruise" to basically force him into retirement (for this bad decision) without the bad publicity of a public head-chopping.

I love the developer experience of Dear ImGUI, even though I use it through Python wrappers that confuse things sometimes. It just slices like a sword through several layers of often-pointless abstraction and puts the control over the main loop right in your hands.

And when you need to read the source to figure something out, it's just a few files of pretty self-evident C-ish code.

I was tech lead on a team with a guy like this. We sat down and had a long discussion and whiteboard sesh about a piece of code that could/should have been about 500 lines of code in half a dozen files. Walked out of it thinking that he understood the assignment and I should just step back and let him code it up.

He came back a week later with something that was about 20k lines of Node.js, all just abstraction piled on abstraction piled on indirection, hundreds of files with like one line of code in each one plus a bunch of imports. "Separation of concerns" taken to the far extreme. 100% statement coverage by the horrible kinds of unit tests that you have to write to get 100% coverage.

TBH I feel lucky I came out of that episode with my job, and it wasn't even my code!

For medical procedures, I think it makes sense to check ID - just for the potential testimonial "audit trail" in case of actual or purported malpractice.

"Are you CERTAIN that the X-ray we are looking it is of the plaintiff? How would you know if someone else showed up and claimed to be them? Is your memory completely infallible?" etc... It might not be of any real significance but poor process can make one side look like they don't have their sh*t together.

If you are working on a large collaborative project, switching between branches can mean needing to rebuild your container images. It's not something I do every day, but it happens enough that the difference between 1 minute (doesn't disrupt flow/train of thought) and 10 minutes (disrupts flow) means something.

> But it's a bit disappointing to see that it's still pretty much a one-man project.

I don't know much about this project and I have never used it. But in my experience as a developer and user of software I couldn't disagree more.

The longer something can stay a one-person project, the better! Nothing kills creativity, innovation, and velocity faster than having to make every decision by committee.

Big communities are great when a project is in its maturity and mostly needs tending and slow evolution. They mitigate the risk of a single developer getting bored and walking away, or turning into a murderous wacko, or attempting to monetize the project to death. Not naming any names.

But when something is being built from scratch? Give me a single developer with a fat internet connection, alone in a cabin in the woods with a shed out back full of Red Bull :)

You can't really have a GOAT in a creative field -- I would never ever want to diminish Nina Simone, Billie Holiday, Sarah Vaughan -- but really Ella is the GOAT. She just makes perfection sound so easy.

Listen to the live recording "12 Nights In Hollywood" and you can hear that not only is she a beautiful singer, she's an amazing entertainer who came up in a very tough school.

Marathons have been my tire for about 15 years of city and road riding, and I have only flatted once -- direct hit on a nail IIRC. I am always amazed at their longevity and reliability.

I have used unstable as my daily driver since they named it "unstable", which I don't even remember what that was but at least 20 years ago.

I have never (yet!) gotten myself into any trouble, by following a very simple principle: if aptitude (dselect back in the day) wants to remove or hold more than a handful of packages, STOP. Undo what you just did, and instead of a bulk upgrade go through marking one package at a time for upgrade. When you hit one that needs major changes, if you can't find an upgrade alternative that is sensible, leave it un-upgraded and try again in a few days.

This time upgrade has been one of the more challenging ones to track in unstable, but patience and actually reading the reasons that dpkg reports for why it wants to do something has gotten me through it.

I feel a lot of sympathy for the GNOME developers. They are 15 years past the "let's build something cool!" stage and into the long, long grind of support and compatibility and being expected to work everywhere all the time. As an outsider, it looks like all the cool kids moved on a long time ago so it's basically just people too stubborn to quit working on it and a few paid devs trying to make something happen with pretty limited resources.

That said, as a developer I have basically had enough of GNOME, and I'm porting my personal projects to ImGUI. Does it integrate in the desktop? Not really. Is it pretty? No. It just is what it is (a library for GUI app development) and it doesn't try to be everything else that GNOME does.

I don't think the meaning is anything terribly sophisticated. I read it simply to mean that if you invest money in the company, that's money that is at risk of going poof if the company folds.

If you take the money out of the company, that money can never be impacted by anything that happens to the company in the future, so the total amount "at risk" in the company is decreased.

This is, IMO, an overly simplistic take and I'm not endorsing it by explaining!

The graphical dataflow languages that are popular for music and audio programming (thinking Pure Data, Max/MSP, Reaktor etc) do this in a way that makes the value of "namelessness" a bit more clear. When you connect the output of one unit to the input of another unit, there's no need to name that linkage, but it's still perfectly clear what's flowing over it.

I really enjoy trying to think through programming problems in a dataflow style like this. It often turns the problem inside out in an interesting way. I did about half of this year's Advent of Code problems in such a system and it was a blast.

I'm not saying this is a good practice, but it's not valueless. Exceptions are failures. If you have code that is straight broken -- refers to an undefined variable, assumes something that's not true, syntax error that could make it past initial app load -- a test that at least makes sure the code is runnable without throwing an error is better than nothing.

> and quadrupled the survival at 36 months compared to placebo-chemotherapy

There are lots of ways to slice the data. I think the one I quote is probably what got the researchers so excited.

The problem is that the 36-month survival is pretty low, so even quadrupling it only increases the average survival time by the 1.6 months or whatever.

Mesothelioma is one of the worst. My mom died of it at age 53, which is way too young.

I was a grad student in Austin in the 1990s. If Dijkstra showed up for one of the regular department-wide "lunch and learn" type talks, there was a bit of a buzz among the grad students in the room... you knew he was going to pop off with a total left-field question and the results would be pretty entertaining. Free cookies AND comic humiliation from a giant in the field! It was standing-room-only.

JACK is far from perfect but one thing worth mentioning is that the API is really stable. I have been hacking on one audio app for about 13 years; in that time the GUI toolkit has deprecated the key UI elements I use, which have bitrotted to near uselessness; the primary programming language (Python) changed incompatibly and required significant work to convert the app; the predominant audio interface technology has gone from PCI to Firewire to USB. JACK's API has not changed at all that I know of. The bits of C code I wrote years ago to set up the app and connect to the server probably have the same commits attached to them that they did over 10 years ago. Love that.

I have been a fairly devoted user of Gtk in my Python programs for about 20 years. Back then, it was a clean, simple, functional toolkit that just worked.

Dear ImGUI cleans Gtk's clock in the "clean", "simple", "functional", and "just works" categories these days, and I am currently porting my biggest side project from Gtk to Imgui.

If you are trying to "integrate with the (GNOME) desktop", I'm sure you should still use Gtk, but for most purposes I don't see the point. It seems from the outside like there are few core Gtk developers left, and they are basically in life support mode for an entire desktop suite, one that is stuck between two broken display engines (Xorg and Wayland) with no way to really fix things and every desktop Linux user expecting miracles.

ImGUI is just a busy dude banging away on a single toolkit, without the baggage of millions of nontechnical users to support. As a developer, I know which one is going to be producing the good stuff.