Live data from Hacker News

Todd C. Miller – Sudo maintainer for over 30 years

millert.dev

311–320 of 337 posts

Re: Todd C. Miller – Sudo maintainer for over 30 years

#311

Earlier quoted context omitted.

> 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 m…

> 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 b…

> 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".

Re: Todd C. Miller – Sudo maintainer for over 30 years

#312
post #225

Earlier quoted context omitted.

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’…

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".

Re: Todd C. Miller – Sudo maintainer for over 30 years

#313
post #264

Earlier quoted context omitted.

> 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 m…

> 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…

> 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?

Re: Todd C. Miller – Sudo maintainer for over 30 years

#314
post #127

Earlier quoted context omitted.

I’d broaden that slightly to say you should try to have as few mechanisms for elevating privileges as possible: if you had tooling around sudo, dzdo, etc. for PAM, auditing, etc. I wouldn’t lightly add a third tool until you were confident that you had parity on that side.

Privilege escalation (superuser capabilities) and RBAC ought to be viewed differently, IMO. There's a place for true superusers, such as auditing, where no stone should be too heavy. But mostly for securing systems, we want RBAC, and sudo is abused as a pile-driver where only a mallet was needed. Polkit is more of a proper policy toolkit.

That’s a valid choice. I’m just saying that you should pick ideally one tool for that class of work. For example, if you support one tool for Mac and Linux users that’s probably worth more than supporting two similar tools even if one of them is better.

Re: Todd C. Miller – Sudo maintainer for over 30 years

#315

Earlier quoted context omitted.

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 appl…

> 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.

Re: Todd C. Miller – Sudo maintainer for over 30 years

#316

Earlier quoted context omitted.

The GPL is a good idea. It's our socieconomic system that isn't.

GPL is a response to the copyright law, which was created for the big corporations to extract rent from ordinary people. It's copyright law which should go away.

GPL is much more than that. It is distributing the means of production to the tech workers.

rms is the Marx of the 20th Century. GPL is freedom from corporate oppression.

Re: Todd C. Miller – Sudo maintainer for over 30 years

#317

Earlier quoted context omitted.

> 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 appl…

> 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 occ…

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).

Re: Todd C. Miller – Sudo maintainer for over 30 years

#318

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. 1: https://www.sudo.ws/releases/devel/

"Done" software is a myth they tell to young developers so that they can sleep easy at night.

Keep selling your bosses that myth. Nobody here believes you though.

Re: Todd C. Miller – Sudo maintainer for over 30 years

#319

Earlier quoted context omitted.

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.

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”

Post reply on HN