Note: this page tends be neglected and is only updated occasionally. The links to the left are where the useful bits are hiding. For the past 30+ years I’ve been the maintainer of sudo. I also work on…
Note: this page tends be neglected and is only updated occasionally. The links to the left are where the useful bits are hiding.
For the past 30+ years I’ve been the maintainer of sudo.
I also work on OpenBSD, though I’m not as active there as I once was.
In the past, I’ve made large contributions to ISC cron, among other projects.
Reading the release history[1]. I'm kind of shocked that sudo gets active development and monthly releases. I would have thought that something this old and venerated would have been "done" long ago.
"Done" software is a myth they tell to young developers so that they can sleep easy at night.
Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention. Heck, I even have tools I no longer use that people asked me to keep available because they do, and they’ve been chugging along for over a decade, no bugs or maintenance necessary.
Just today I saw a report of Adobe discontinuing a tool in use by professionals because it is done and they don’t know what else to add.
https://mastodon.social/@grishka/116005782128372247
“Software is never done” is a myth they tell to keep extracting money from you.
A lot of the time, failing to to finish software indicates a badly defined scope.
You might have written software that is "done" if you compile it with a single compiler version and don't use any OS hooks/APIs and don't care if future changes breaks your software. I.e. it's done if you think that people will stop needing to use it at some point in the future.
A tool like sudo can never be done because it integrates with the constantly updating OS and will always need maintenance.
It's a bit ironic that digital goods, which are arguably the only products which once compiled can be stored, used, and copied perfectly bit-for-bit, are also the only industry that seems to have this problem with being unwilling to call a product "done".
The reasons for software churn are economic, cultural, and psychological, not technological.
> unwilling to call a product "done"
Unlike modern physical products, software often has a contiguous lineage, with less individual hard cuts between releases, that e.g. necessitate setting up a new production line for each iteration.
Of course you can call individual releases "done" but then you also have to accept that the same realities apply to it that it's utility will decay over time same as e.g. household appliances do, where you also wouldn't use one that's 40 years old.
Calling a software project as a whole "done" (and claiming that it doesn't have bugs and doesn't need maintenance) would be akin to Apple saying the iPhone (the whole product line/smartphone niche) is "done".
> Of course you can call individual releases "done" but then you also have to accept that the same realities apply to it that it's utility will decay over time same as e.g. household appliances do, where you also wouldn't use one that's 40 years old.
Physical appliances decay because of wear and tear, which digital products are uniquely immune to.
Replacing and fixing physical wear and tear is more like having to occasionally clean your logs folder, or reinstall your OS. Admin maintenance on a specific installation, not updates to the product from the developer. The product itself stays the same.
Software churn, updates that change the product itself and not just the way it's run, are more like General Electric requiring you let one of their employees into your house to paint the appliance a new color every month.
> Calling a software project as a whole "done" (and claiming that it doesn't have bugs and doesn't need maintenance) would be akin to Apple saying the iPhone (the whole product line/smartphone niche) is "done".
Which seems like it would be fine? What do 95% people use their smartphone for, that an iPhone from 10 years ago was not already able to do? Besides, this comparison is a bit circular as software dropping support is often the part that forces consumers to upgrade hardware.
Hardware products without software churn do in fact get used basically forever. When they do break, they can also be replaced with the exact same product, without all the issues that running old software gets you.
Apple could make a forever-iPhone that lasts 10 years, or 40 years. But it's more profitable, competitive, exciting, and convenient to release a new product line every year (while turning old hardware into e-waste via software updates).
I'm not saying it's better or worse that things are this way, but it does cause some problems and should not be presented as inevitable.
All that you say is true in a world (or for product categories) that has reached a technological plateau.
The point about household appliances that I was trying to make wasn't about individual appliances decaying (= breaking down), but about the utility of a model decaying over time, as it e.g. becomes uncompetitive because it has worse energy efficiency than it's modern counterparts (or in the case of refrigerators uses harmful greenhouse gases).
Physical goods would work the same way if they could be retroactively re-manufactured to different specs in situ for free.
I always had this: "Only dead software needs no maintenance" in the back of my head, and similarly "bug free only means it's not been used and vetted enough"
While probing into this, I think there could be a case where software is mostly done: when it is shipped with the hardware and run in an isolated environment.
The mentioned tools are probably not distributed in binary form for different OS, I assume, otherwise that statement _cannot_ be true.
> failing to to finish software indicates a badly defined scope. In my first job there'd even been a contractual penalty if you are not done in time. And this company produced examples of "finished" software, that controlled warehouse material flow, sometimes running on 20 yrs old MCU. (which of course meant they could not extract money of these customers, because the software ran too good)
Not a great example as that "done" tool (whose currrent iteration barely functions) will be made unavailable after a few years.
That tool is still very much in active use in my industry, and we'll need to figure out what to do with some 10000 fla files that we need to occasionally edit and republish (hint: the solution probably involves a certain Swedish software repository).
> Just today I saw a report of Adobe discontinuing a tool in use by professionals because it is done and they don’t know what else to add.
Yeah, I'm sure the reason stated by the customer support is the real one, and not the lack of profitability from that tool among a shift of focus towards AI[0] as reported everywhere.
https://techcrunch.com/2026/02/02/adobe-animate-is-shutting-...
> for over a decade, no bugs or maintenance necessary
I'll believe it when I see it. Keeping something running for a long time is a lot easier task than building something that can be run in an ever changing world.
Given that it's that old I'd wager that it isn't runnable on/compileable for ARM64 without some kind of maintenance. And if it's written in an interpretable language there is a good chance that the underling interpreter/runtime are EOL by now.
> A lot of the time, failing to to finish software indicates a badly defined scope.
And a lot of the time finished software becomes unused because it sticks to scopes that don't match up with reality/user needs anymore.
> I'm sure the reason stated by the customer support is the real one
Oh, but it's so much more beautiful than that! You're really underselling it! It's not "the reason stated by the customer support", it's:
The reason snarkily paraphrased by a Mastodon post Which quotes a Twitter post Which quotes a Bluesky post Which tells a story about a conversation with an Adobe customer service rep.
Surely that tongue-in-cheek Mastodon post increases the information that we have about this incident by exactly Zero.
Yeah, I have a relatively simple script with webUI for organising photos and videos I take on my NAS.
Over the years I’ve had to upgrade the ffmpeg dependency, which resulted in breaking changes a couple times and maintenance.
I’ve also had to spend nearly a whole day fixing the webUI when iOS’s wonderful liquid glass came out.
Liquid Glass changed dimensions and viewport measurements for fixed position elements, amongst a whole host of positioning related bugs:
https://stackoverflow.com/questions/79753701/ios-26-safari-w...
Many of the bugs were fixed in 26.1, but still, I had to fix it to use it.
I was surprised that not much of the entire web was broken, but a cursory search of commits showed that the WebKit/Apple team took the approach of coding in site specific hacks for popular sites (eg instagram, google search!) for iOS 26.
Maybe I’m not looking in the right places, but I rarely see fixed position elements in modern web layouts— I imagine that’s why you didn’t see more disruption.
They may not be used in layouts, but they can be present in cases like keyboard open (if you wanted to attach some controls above the software keyboard for example); or just ever growing compatibility hacks.
> not the lack of profitability
What “lack of profitability”? They just reported a record quarter. Adobe shoves full Creative Cloud subscriptions down everyone’s throats; buying one tool, especially when it’s not one of the flagships, is uncommon. What exactly are they losing by just letting Animate be?
> And if it's written in an interpretable language
I have never ever ever had to change shell, Ruby, or JavaScript code because “the underling interpreter/runtime are EOL”. Never. That code keeps happily running, doing its work, with whatever version of the interpreter I have available in whatever box.
> And a lot of the time finished software becomes unused because it sticks to scopes that don't match up with reality/user needs anymore.
So what? That’s perfectly fine. Do you drink milk out of a baby bottle? Do you ride a bike with training wheels? It’s perfectly fine to build a tool for a purpose and a time and place and let it exist there for the people who care for it. That’s also true of video games (which, lest we forget, are software). In a world where people are constantly complaining about software updates moving shit around, removing features, and adding crap they don’t want, plenty of people appreciate that the things they like continue to work as they always have.
> What exactly are they losing by just letting Animate be?
Maintenance cost (which you claim doesn't exist) of the engineers that they are planning to staff on other project they are assuming will be more profitable. Of course that's just a bet and not a sure thing.
> I have never ever ever had to change shell, Ruby, or JavaScript code because “the underling interpreter/runtime are EOL”.
I think we are living in different realities. Almost every (open source) project that I encounter that's 10+ years old isn't runnable without changes.
> Do you drink milk out of a baby bottle? Do you ride a bike with training wheels?
Do you still drive a Ford Model T?
its really funny people are so adamant on this while software written for linux 1 still work on linux 6. it is a developers choice to burden themselves with every changing foundations... maybe not the wisest choices in the long run to go for easy things in the short run..
> Yeah, I'm sure the reason stated by the customer support is the real one, and not the lack of profitability from that tool among a shift of focus towards AI[0] as reported everywhere.
Yeah, although "finished" software is antithetical to this always have new features to push onto your customers subscription model, so it's not entirely unrelated.
Having said that I still find it strange. I can imagine it might not be able to ride on the AI bubble, and perhaps animators are especially vocal about not wanting AI in their tools. But even so, why would that make Adobe Animate unprofitable? They do have a subscription model, and customers, so people are paying for this product.
Compared to other digital art, the data for vector animation takes relatively little space to store. It also requires much less resources to render than other forms of video, and rasterized video output should compress really well compared to alternatives, especially with modern codecs that are not only optimized for regular film. So surely it shouldn't be that expensive to maintain for them compared to all their other projects.
> But even so, why would that make Adobe Animate unprofitable?
Sorry, I wasn't precise with my wording. What I meant to say was "less profitable than the perceived AI opportunities they could do with the same engineers".
Ah, ok. Even then switching Animate into "maintenance mode" should be doable on a shoestring budget methinks but whatever, the more Adobe hurts itself the better tbh.
That tool, BTW, is essentially the authoring side of Flash rebranded.
> Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention
And how many of these tools are mission critical to the point that they are installed on almost every Linux box in existence, probably invoked tens of billions of times per day, both by humans and software, and the entire world would be in deep goddamn trouble if there was a serious security flaw that doesn't get fixed immediately?
Because that's what `sudo` is.
And no, such software is never "done".
You’ve moved the goalposts so far away, they’ve left the breathable atmosphere. Look at your condition, it’s over 50 words. I didn’t say “all software can be done”, I just said that it’s not true that software is never done. It’s not a universal truth that applies to all software.
There's a difference between software that's "done" (it never needs updates, ever) and software that's done (it only needs maintenance for security and platform churn).
The former is extremely rare; platform churn alone will usually demand updates, even if your code is otherwise airtight. Forces generally beyond your access will demand that your code is able to conform to platform standards. The demand this places can be very variable and depends more on the platform than you. (Windows has low platform churn since it's possible to futz with compat features, Linux is extremely variable on your codebase, MacOS is fairly constant and from what I know about mobile phones, you're basically signing up to forever maintenance duty).
The latter is much more common; sure, sudo still gets updates but most of those won't be new features. Specification wise, sudo is "done". It does what it needs to, it's interface is defined and there aren't going to be any strange surprises when I run sudo between any system made in the past 10 years or so.
The problem is that when you're selling software, demanding compensation for the former is a hard sell since it's things customers won't see or necessarily care about. Demanding compensation for the latter is much more obviously acceptable.
I’m not sure truly ‘done’ exists on systems that interact with other systems unless it’s an entirely closed loop.
I reckon closed-loop systems can be ‘done’ every bit as much as hardware systems can be if the design, debugging and implementation are disciplined enough.
> platform churn alone will usually demand updates, even if your code is otherwise airtight. Forces generally beyond your access will demand that your code is able to conform to platform standards.
Platform churn updates are a failure to limit scope and dependency. If you stick with stable standards like C99/POSIX/X11/SDL, test strictly and build liberally etc., then who cares what the Web/Qt/Metal people are doing?
> MacOS is fairly constant
Except when they killed all 32bit games a few years ago with Catalina.
I think that GP meant that MacOS has a constant nonzero rate of platform churn. I might be wrong though!
Oops, yes, I meant a constant non-zero rate. It's slightly above mobile phones, where the developer is treated as the problem that needs to fix itself.
Stuff written for one version of MacOS will probably work for the next few versions, but there's just as likely a chance that Apple has decided that you need to do a full on update of all your older tools. Things like dropping Rosetta, 32-bit from the kernel and so on and so forth. There's not really any recourse, unlike Windows and Linux where you can usually finagle a workable solution without having to resort to updating everything all the time (so platform churn exists, but a user can theoretically choose to avoid it).
This is unlike phones, where there's basically no real expectations for when you need to update stuff, so it becomes a case of "you need to test every version". The lack of respect for tool stability is just one other reason why the mobile ecosystem is the user-hostile hell it is; this platform churn pretty much is one of the two roots of why mobile apps are Like That. (The other being that running your own choice of tools is treated as a privilege, not a right.)
The OpenBox WM is a respected piece of software, commonly used on minimal Linux desktops, that has been "done" since at least 2015.
Keep selling your bosses that myth. Nobody here believes you though.
wireguard is relatively "done"
Of all the things to pick, software which needs to be secure and is actively attacked is the worst one.
So like sudo
"relatively" is just a word added to done and the fact that there is a qualifier precludes the word from bearing truth.
Out of curiosity, what changes would it have at this point?
I'm not intimately familiar with Wireguard, but there are some things that are almost universally applicable:
- It should run on an maintained OS (which should run on available hardware), so whatever changes are necessary to keep pace with that
- It may want to add optimizations regarding newer CPU architectures
- It uses a compiler, so whatever changes necessary to stay on a maintained version of the compiler
- It uses cryptography, so whatever changes necessary to stay up to date with latest cryptographic research to provide a secure solution, as well as updating cryptographic libraries to not be exposed to CVEs found in them. It also exists in the context of one/multiple jurisdictions, so possibly also changes to comply with interference in sound cryptography (let's hope not).
And all of those are just part of the things to keep up with the world around you evolving. Of course there may also be bugs to fix in the code itself, and/or new ones created by doing any of the changes above.
Even their definition of "complete"[0] includes "active maintenance" and "still much to do".
It uses Curve25519 for key exchange and ChaCha20-Poly1305 for symmetric encryption. There aren't many hardware primitives that would speed it up, although AVX2 and similar would help process ChaCha20.
> It uses Curve25519 for key exchange and ChaCha20-Poly1305 for symmetric encryption.
For now.
> There aren't many hardware primitives that would speed it up,
For now.
> although AVX2 and similar would help process ChaCha20.
So, there's at least a bullet point for experimental branching.
Also, the WireGuard Tunnel Manager on macOS is far from done.
pros and cons to this approach, like the CVE introduced in sudo 9.1.14 (June 2023) fixed in 1.9.17p1 (June 2025). https://www.cve.org/CVERecord?id=CVE-2025-32463
But also sudo has A LOT of features that 95% of people don't use. Just checkout `man sudo` to get a sense for this. And it includes plugins like the popular visudo plugin. You can see from the release cadence that real improvements continue to be made. Though it is a bit more work to secure a moving target.
I was wondering the same thing. I would have thought every possible combination of parameters would have been tried by now. I guess it just goes to show you that your code is never really complete.
> I guess it just goes to show you that your code is never really complete.
Yes and no, feature bloat usually justify themselves innocently and once you go down that slope there is no return.
The hardest thing to do in software is commit yourself to a set of feature and protect it from any "helpful additions", naming might be the second hardest.
It seems to have features I was not aware of. I would not have guessed that it contains anything networking-related.
Feature bloat is the last thing you'd want in security relevant software.
Sudo’s networking functionality is infuriating too, because if my system’s DNS is broken, I get to wait 60 seconds for sudo to work, during which time I can’t even ctrl+c to cancel!
(It has to do with sudoers entries having a host field, since the file is designed to be deployed to multiple servers, which may each want differing sudoers rules. It’s truly 90s era software.)
I really prefer the design of run0.
Yeah, silly as it is, I guess it didn't even occur to me that sudo had a developer or maintainer, or was even a "program"; to me it has been one of those things that has and always will exist and I had just assumed it evolved and came about alongside Cro-Magnon man.
But of course, that's silly. Of every piece of software has to be written. I should probably throw the guy a few bucks, considering his code runs in basically every big script on the planet.
https://github.com/sponsors/sudo-project
Can donate there.
My bank account is basically empty but I will contribute a few bucks.
Contributed immediately.
Thanks to sudo-rs: this stolen valor project made me want to financially support the original author.
how does the metaphor of stolen valor (in my understanding: claiming accolades or military credentials/decorations that one never received) apply to that project?
I don’t know anything about the history here; it’s a genuine question.
Authors of useless rewrites do:
* skip the hard part: designing, getting user feedback and designing again;
* get straight to the fun part: coding in their favorite language after a well-established and proven design;
* get to call themselves "creator of XXX-rs", where "XXX" is a well-known brand and "-rs" is often overlooked.
would it be better if they didn't skip the hard part? (i.e. if they re-designed it from first principles) does something being hard to do make it more virtuous?
would it be better if they didn't have fun coding it? is something worse if it was fun to make?
A security-focused rewrite of a security-critical program that removes insecure features and prevents whole classes of vulnerabilities from being introduced in the future is hardly “useless”.
I meannnnnn…
Pedantically, the “stolen valor” metaphor absolutely doesn’t fit here; you’re just griping about the “sudo brand” being used in another project’s title (which … citation needed, and so what? Is “doas” not committing theft but “sudo-improved” is?)
More generally, that’s an easy case to make against any software you don’t like: “it’s just reimplementing $whatever and trying to pretend to be the original therefore it’s unethical”. Some rewrites are good, and a huge benefit of the act of rewriting is that you do have a clear blueprint and understanding of the requirements (hell, Linux was a rewrite). Should the original creators of a thing be the only people who can ethically rewrite it? Where’s the line here?
For the love of God, drop the culture war BS. We get it, you don’t like Rust.
You don’t get to act so self-righteous when you do absolutely nothing to justify the assertion that sudo-rs is “useless”.
I look forward to hearing your argument that doesn’t end in “the memory safety footguns of C are massively overstated”, or “there is no value in having a sudo alternative that ditches antiquated, insecure functionality”
I like Rust.
I hate the virtue signaling.
I think the rise of the open-source redistributor groupie has been an interesting cultural revolution. I wonder if it will persist. Even 10 years ago, the idea of Free As In Speech dominated the idea of Free Software. Today, the greatest enthusiasm on Hacker News and Reddit is for something like Meta's Llama license (which cannot be used by people or corps with sufficient numbers of users). It certainly seems like someone out there could go out and propose the Microfree License which only applies to sufficiently non-rich people.
For my part, I want none of it. I find this reduction of a significant philosophy to some kind of base tax-and-distribute mechanism distasteful. I don't like communities were this stuff is big and they always want to run some taxation scheme where they redirect money to their own personal pet projects. It is fortunate that modern tools are good enough to build personal insulation from this stuff.
Imagine the farce of Apply HN repeated continuously. Simply awful.
