Hacker Newsnew | past | comments | ask | show | jobs | submit | prosaic-hacker's commentslogin

The article talks about long forgotten reasons why things are as they are.

I have heard of a, probably now apocryphal story, of field on a Multinational's paper report that was always supposed to be 0. When the IT team that did the automation of the report, discovered field was the number of bombs that fell that week on a property owned by the company during the London Blitz. Not a big consequence to the company but the story had been lost.


I am from a earlier generation. Owned a TI SR-51A last year of High school, Then a HP-29c first year of University. I vaguely remember the SR-51A had an limited equation programming : multiply by a constant and add a constant. I remember writing sort routines for the 29c using its indirect register access to treat a block of registers as an array. Bench-marked various sorts. I think minutes to sort 20 items.


About 1/4 of a Security Now podcast or 1/2 of the Amp Hour or Embedded.


I will cast my vote for mobile websites over apps on phones. For personal choice reasons I have always had a "budget" phone with less memory and storage (and less cost) than a flagship phone. I also kept them running for years.

At the end of the cycle I can barely run the base phone let alone the menagerie of apps the world would like me to run.

I have opted out of app only service such as a Loyalty programs that forced me to transfer point from a partner only if I installed an app on my phone. They have enough info on me from purchase, they don't need more. (I even offer my card to strangers in the grocery cash if they did not have the loyalty card so they would get a discount and I would get a list of products I never buy in my loyalty list. Its a small, willful act of rebellion )


I decided to operate on a older budget phone for a while when my phone died outside of my planned budget and timeline for replacing it. By far the greatest problem was managing storage space. Except for core productivity apps, if a website option wasn't offered I was never going to be one of their users.


> I will cast my vote for mobile websites over apps on phones. For personal choice reasons I have always had a "budget" phone with less memory and storage (and less cost) than a flagship phone. I also kept them running for years.

Then, unfortunately, apps are a better choice for such phones (unless the app itself is just a thin webview wrapper). These days too many websites would fry a budget phone.

Obligatory: The Performance Inequality Gap https://infrequently.org/2025/11/performance-inequality-gap-...


>>There are an amazing number of "business critical" applications that are running ancient libraries, protocols, etc.

Do you know of any examples of these "walking wounded" applications? Can we bring some attention to reduce their foot print.


I would have to get former coworkers to dig through Jira. I would not bother. These are all proprietary applications supported by dead or dying companies. Most of the original developers are retired or no longer with us. The apps get picked up by acquiring companies rinse and repeat when they chapter 11.

More useful is finding newer, supported and open source applications that can replace their functionality but that's a whole other topic around prioritization and people paralyzed by fear of change due to the amounts of money flowing through their unsupported applications.


I teach in a tech/trade vocational program where 1/2 the students are your generation. All kinds of reasons they are there. (Didn't do well in High School, College, University, Grad School, Gaming in their parents basement since they were 10)

When one of the skills click (some try 2 or 3 of the ones we teach) and they start working the says that life is happening for them. The failures, in retrospect, become steps the had to take to get where they are. Perseverance is probably good personality trait to develop.

I chose my handle to have the word prosaic in it because I did many thing in tech (and other fields), none at extraordinary levels, but all done by learning by trying things out. You don't have to be wildly successful in life, prosaic can be good enough.


Early 80's VMS had a Keep/Purge system for history of files. Everytime you edited a file a version number was bumped up by 1. There was a command, "purge", I think that set the Keep count which was default to 3.

This would have been within the contemporary Dos and disk capabilities and size of 160-360kBytes, although slow (5-15 seconds).

When Dave Cutler moved from DEC to MS I expected the Dos console under windows to get that same feature. Disappointed. A gajillion lost hours could have be saved.


We had a VMS machine in school and regret not spending more time learning from it.

It would be awesome to have application level granularity for a time traveling file system, the undo/redo mechanism could be built into the OS.

Reading up on https://en.wikipedia.org/wiki/Fossil_(file_system)


Incidentally, I was just reading https://cseweb.ucsd.edu/classes/wi19/cse221-a/papers/bobrow7... about TENEX, which offered roughly the same version numbering facility as VMS, though without the hierarchical filesystem directories VMS and Unix got from Multics. I don't know if TENEX got the idea from an earlier system. They don't mention one.

It's kind of amazing that this one paper introduced command-line completion, copy-on-write pages, load averages, and CAM TLBs.


The way I remember it, there was a SET command to set how many versions of a file should be kept, and PURGE would delete all but the most recent version. You could see the date of each version in DIR (they were listed on separate lines) but there wasn't a convenient way to open "FOO.FOR as of yesterday morning". You would have to figure out what version number to ask for and open "FOO.FOR;53" or whatever.

I agree that implementing this functionality in MS-DOS would have been relatively straightforward and acceptably efficient.

It'd be great to have long-lived transactions in a filesystem, permitting higher-level undo and redo.



Ah thanks. I didn't scroll down far enough


TL;DR Don't sweat the future, it will mess up eventually. Just Do something now that is productive for a while and don't be afraid to change you mind or your job.

Doing the same thing I have been doing since I was your age. Learning some that interest me now that could be useful.

Started out as a math and science geek: Organic Chemistry was the target. Two chance encounters: one with two real working chemists that warned me to get a PHD to get a real job. I was to impatient to do that much school so the second chance encounter was with a obsolete computer that was plotting graphs and space games on paper. Three years os CS later I was working on Flight Simulation. The 1st PC era happened and 5 years later I switched to install 1st gen PC networks. Then Unix got big and I did Sysdmin on that for a while. Then Perl programing which morph into webdev for handful of years.

Then I was "old" at least to the HR 15 guy, years my junior, who would not hire me, so I became a manager. Then there were to many managers I went back to school and got an accounting degree. Did that for a bunch of years and started teaching System Administration. Now looking for my next obsession.


I have seen the effect of tools building in several contexts. The most successful were teams that respected the process in that they each, could and would build tools themselves and would adopt other's tools.

Without the symmetry then the creators has to make sure to keep up the pace on the global progress or be label as distracted by the tool creation.

Worst case the tool creators get separated from the main production and have to maintain the core groups utilities (which will become any code they don't want to maintain).

Tools have to be short to build, widely useful, and placed in a repository that is collectively maintained.

Remember the context that created the need for the tool may move on and the existing tools will have to be upgraded. The group should have a plan how to handle that.


Thanks, that's a very interesting insight.

Chilictl, the tool in the article, is maintained by the team that also uses it the most. So we know its applications best, and even though it's original author is not around anymore, we are still very motivated to maintain it collectively.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: