Hacker News Reader

Comment by MontyCarloHall | Hacker News Reader

>However, the value was mostly gone by the mid-to-late 1990s, and the few remaining issues were cleaned up before 2010 — shockingly late, but still over a decade ago.

Anyone running a shell that still requires the x-hack is deliberately maintaining a legacy system, at which point the onus is on them to get modern tooling working on their machine.

View on HN

Being forgiving towards the user is one of the important principles of programming. Because the user may not be able to “upgrade” his system.

Windows 95 is still very much alive.

Embedded-like systems are a thing.

Yet asking for windows 95 support on most open source bug trackers will get a reaction between being laughed off the tracker or "do it yourself, but we'll reject the PR if it makes too much of a mess". I don't see why legacy commercial Unix deserves any higher level of support these days.

Did not say so. Only that if one does do it, one is being understanding.

Did not say it has to be done.

Just because some projects (OSS or not) decide on a certain policy doesn't mean that the policy is necessarily good, or that any other projects should follow suit. Whether or not this is a reasonable stance depends on the project and the target demographic.

> Being forgiving towards the user is one of the important principles of programming. Because the user may not be able to “upgrade” his system.

Yes. If there is one thing I wish I could drill into every programmer's head, it's that not breaking stuff for your users is the #1 most important thing. There is one of you, and there may be many thousands of users. You putting in the extra effort means saving thousands of times of effort from your downstream users. Sometimes breakage unavoidable, but those instances should be rare, extremely well communicated, and felt as a failure to be learned from and avoided in the future. I don't care how ugly it makes things for you, your users are paramount.

This isn’t even a moral principal - design systems and projects according to this discipline and you yourself will be repaid in extra robustness and less work in the long run, as well as happier users. Plus it is fun coming up with work around for obscure corner cases.

> not breaking stuff for your users is the #1 most important thing

I would say that's #2. #1 is to never cause data loss.

this is a perfect example of how UN*Xoids like to enamor themselves that they are the last bastion of responsible devs maintaining the 30 year old system that was never good to begin with from breaking

Outside of very specific situations that you'll know if you're in them, when are you expecting someone to simultaneously (a) insist on running ancient software that they can't update to decades-old standards and (b) run your new software?

> Windows 95 is still very much alive.

Can you share any examples/use-cases? I'm not doubting you, I'm just very, very curious.

In 2011 a customer I worked with was using Windows 95 still in a test bed for their legacy equipment. The test software they had was written for it, and it still worked, so no need to go through the massive pain of updating. But even that was 12 years ago and we expected it to fall apart any day...

A friend of mine still helps out a number of local businesses running their old MS-DOS Point Of Sales terminal software, as well as old high end printing hardware at a print shop. It works, and replacements aren't worth the CapEx as they're doing just fine. Migration has real costs, like losing the customer database for a mechanic's garage or buying a new 6 digit printer for the print shop.

I get what you're saying, but the fix to support that old shell is literally two characters. If you don't want to support it, it would be good courtesy at least to print an error and abort, lest the buggy behaviour ends up damaging the user's system.

Agreed. Abort with a clear message on unsupported systems. In this case, non-POSIX shells.

The alternative is to bundle all the dependencies, including the shell interpreter into some maximally portable setup.

I think telling your customers who rely on older systems to go pound sand is a good way to lose customers. Not to mention a bit callous.

Sure but if those customers are 1% of your revenue and 30% of your tickets then they're customers you want to lose and it's not particularly callous to want to feed your family.

Sure, but that's not the case for every business.

I'm not saying that everyone needs to keep legacy support in mind. I'm saying that just taking the attitude of "it's old, too bad" is not good blanket practice. It all depends on what you're doing.

> it's not particularly callous to want to feed your family

The callous part is taking a disdainful attitude toward those customers.

> The callous part is taking a disdainful attitude toward those customers.

I guess I thought it was obvious that most of the the time someone doesn't want to support legacy it's for this reason, not because of disdain for them.

That's what disdain is though (in a very literal sense), not feeling that someone is worth your time or consideration.

Your disdain of legacy clients might be profitable or understandable or even morally just, but it's still disdain.

> disdain somebody/something to think that somebody/something does not deserve your respect or interest

OED. You can respect someone but know their business isn’t worth your effort.

I get the sense that a lot of words have become generally mapped to "good" and others generally mapped to "bad" and it becomes difficult to have a nuanced conversation, especially around the not-uncommon situation where you disagree with or even dislike someone without holding the opinion that they are a bad person.

> it's not particularly callous to want to feed your family

Callous is callous regardless of your motive. It might be justifiable to be callous if that's what your business circumstances demand, but that doesn't change the effect on those customers.

> it's not particularly callous to want to feed your family.

Jesus Christ, you just put x in front of the variable!

Weirdly tho the legacy business is often a lot higher than the growth business at any point in time. It is often the case that orgs won’t break down the costs this way, but if growth has a lot of potential in the future, legacy is paying off previous growth bets now. So don’t piss off half your profits because you are more focused on what to you is the bright shiny new thing that you have high hopes for.

Nonetheless, having read the fine article, I will stop using he x construction, which I find myself typing from time to time just out of habit.

The thing is, that's working like partially taking antibiotics. In B2B, you often end up with a customer on an old, customized system making 10% of your revenue. Dropping that often isn't an option.

Most recent MacOS is still shipped with bash 3.2.57 FWIF. Since default was changed to zsh they would likely never bump bash. So you never know.

That's still a 2014 release--definitely modern relative to the releases talked about in the article.

That was a licensing issue. It's pretty much guaranteed Apple will never ship a newer version of bash.

up until last year I was supporting a system for a client that would only run on Solaris 2.5.2 from 1996 or so. (finding working versions of the hardware was becoming _really_ hard). The system was retired last year, replaced by something that costs several million dollars, but until then I had no choice.

There are other things like that out there. I think I recall seeing something on HN fairly recently abut a controller for some CNC machine that was running an early version of MSDOS. Again, replacing with something more modern was very expensive. These things exist and the users aren't necessarily being wilfully malign in not upgrading

Reply on news.ycombinator.com