If you're talking about applications that can be made to act how their namesake predecessors did 30 years ago, sure. The Unix mindset is all about that.
But don't be fooled into thinking that anything on a modern Unix-like system hasn't been modified, patched or rewritten from scratch at some point in the last 30 years. More than once. Even /bin/false has a changelog.
Slightly pedantic, but according to core-utils GitHub, false.c has not been changed in 21 years. But true.c, which is what false.c is based on, has been changed as recent as 4 months ago.
I couldn’t resist looking it up, and found the results mildly interesting.
Most changes are updating the copyright year.
After that, it's pretty much (or maybe completely, I haven't checked exhaustively) for the --help and --version flags, not for the core part of exiting with a certain exit code.
Sure, but we have been running the same Linux command line tools now for the 30 years ive been on Linux. None of them have had any noticable bugs and none of them have been replaced, until maybe now recently with some rust versions that are still not default.
They are incredibly actually. We dont have that in software engineering anymore. We add features and bloat to all modern software until it needs to be replaced.
Kind of sad isn't it? I had some lengthy discussions with someone who worked for Atari in the 70s/80s and the amount of magic they worked with limited hardware was something else.. Sadly I was a young drunk and don't remember much of what he said.
Yeah accurate. I got a few node projects and more rust projects. The few node projects get more security vulnerability than the rust ones. And most time it's just OpenSSL and rustls, which is kinda expected from such important packages
If you're talking about applications that can be made to act how their namesake predecessors did 30 years ago, sure. The Unix mindset is all about that.
But don't be fooled into thinking that anything on a modern Unix-like system hasn't been modified, patched or rewritten from scratch at some point in the last 30 years. More than once. Even /bin/false has a changelog.
Slightly pedantic, but according to core-utils GitHub, false.c has not been changed in 21 years. But true.c, which is what false.c is based on, has been changed as recent as 4 months ago.
I couldn’t resist looking it up, and found the results mildly interesting.you mispelled super interesting
You misspelled misspell 🤪
The true author, so to speak.
Most changes are updating the copyright year.
After that, it's pretty much (or maybe completely, I haven't checked exhaustively) for the --help and --version flags, not for the core part of exiting with a certain exit code.
It is committed long-term maintenance that separates a road from a desire pathway.
It is committed long-term maintenance that eventually makes software solid enough to be someone else's substrate.
/bombast
Survivorship bias
yeah, I bet there was a bunch of crap written 30y ago too, the difference was no npm or github
Not quite 30 yet but maven was released 2004 and still going strong.
Thanks. Now i feel old :(
https://lemmy.world/post/46520928/23602686
Survivorship bias. We only see the "good old programs" because the bad ones didn't make it until now.
Yes
And while not exactly applicable for the computer example but generally everytime this example is brought up
ROMANS DID NOT HAVE 40 FUCKING TON TRUCKS
Much less so 100s per hour
Roman infrastructure was/is impressive no doubt
But not that impressive
Yeah, the damage curve is exponential by axle weight.
Not quite, but fourth power may as well be.
Sure, but we have been running the same Linux command line tools now for the 30 years ive been on Linux. None of them have had any noticable bugs and none of them have been replaced, until maybe now recently with some rust versions that are still not default.
They are incredibly actually. We dont have that in software engineering anymore. We add features and bloat to all modern software until it needs to be replaced.
Kind of sad isn't it? I had some lengthy discussions with someone who worked for Atari in the 70s/80s and the amount of magic they worked with limited hardware was something else.. Sadly I was a young drunk and don't remember much of what he said.
Nah. The dumpster fire known as gcc still survived until this day.
There's a reason why almost every new optimization/language starts with llvm.
Good point. Same thing with music for example.
*30 days
What are you guys doing to your JS packages for them to last so long?
No using in production, I guess
That Roman road is in absolute shit condition. It used to have 2 more layers on top of those rocks, a gravel layer and a stone block finish.
That Roman road also didn't have thousands of multi-ton vehicles rolling over it every day.
That javascript hole was probably caused by a bicycle.
Looks like a user error to me
Yeah, so not ideal, but still workable despite being built off ancient technology in an ancient time.
Who spilled the 55 gallon drum of sulfuric acid out front, and "forgot" to clean it up?
I suppose there was a big fire. Sulfuric acid would have eaten the steel reinforcement, leaving the asphalt alone, more or less.
30 months!??!? Are you trying to get hacked?
I watched whole videos about repaving with used bricks and why we don't do that for all low-speed roads globally is just beyond me.
Until Y2K38 😱😱😱
time_t is in libc headers, just rebuild and good to go
I'm an old-school JavaScript developer, that's why I use Angular!
Jquery user here..
whippersnappers
that's a blast from the past I want to forget.
*scripter
COBOL system written 50 years ago...JS package at release.
Yeah accurate. I got a few node projects and more rust projects. The few node projects get more security vulnerability than the rust ones. And most time it's just OpenSSL and rustls, which is kinda expected from such important packages
Really, that's some well-crafted street.
Software quality apocalypse continues to worse ( the bar was already low )
And now they are being released 100x faster by AI
sudo-rs