EFruit

Oh, those kinds of columns. I thought we were talking text columns, and I was about to relate.

I work at a small business. Despite computer software being about the literal opposite of our business (plants), the founder built an entire suite of interconnected tools that runs off MS BASIC for Xenix, on a single HP machine running SCO OpenServer. The machine has so many customizations, self-scheduling cron/at jobs, odd nooks for files, weird tweaked programs, and special conventions that if a server with a dedicated hostname qualifies as a pet (as opposed to cattle), I'd be THIS THING'S pet.

The system handled EVERYTHING. Accounting, payroll, pesticide management, inventory, attendance, business contacts, shipping label printing... all out of a bunch of terminal menus (which are actually text files with control codes that get `cat`ed out).

But by God, the most horrifying part of it all are those BASIC files. They're IMPENETRABLE.

Firstly, I don't believe this version of BASIC supports named functions or subroutines. At all. But that's fine. MS BASIC being what it is, the interpreter only can deal with a certain number of characters per logical line, and that includes data definitions.

This version of BASIC (like so many others) includes its own serialization format and record/file access scheme. You declare the layout of the data file you want, open that file, and BASIC will handle (most of) the rest.

So when the founder started hitting the internal line limit while defining the data file's fields, he would cut the names of the fields down to fit more on that one line. Over time `30 AS EMPLOYEENAME` became `30ASEMPLNAME`, which became `30ASEMNAME` which became `30ASAF(1)`.

Every cent we transact, and every employee's timecards still flow through this old system, some even using bona fide Wyse terminals. To reiterate, this man was, first and foremost, a farmer. His contraption is terrifying, but commands immense respect. It's lasted 30-some years with continuous tweaking and refining, and we still have yet to replicate even half of its functionality. (Though there are other organizational issues that are making that difficult.)

On a personal note, aside from the calcified codebase and occasional spelling errors, it's a stellar business application. It's fast, mostly coherent, and keyboard-driven in such a way that experienced employees can navigate it faster than the terminal can refresh. We've been working for years to replace it, but at the same time, there's a lot our newfangled Angular+PHP+MySQL replacement could learn from it.

> I read a paper a while back which introduced a different algorithm with tighter bounds on regret

Got a link or cite for that paper? It sounds interesting.

I've been following Keygen for quite a few years (but alas, no projects suitable to try it), partly because of the excellent docs about licensing schemes, and partly because licensing systems (and the breaking thereof) have been a recurring interest to me ever since punching in a building's worth of XP keys and wondering, none of these boxes are connected to anything... how do they know what I typed in is valid?

For that reason, Keygen shocked me when it first came out as a public(!) licensing platform... how could they get away with documenting their secret sauce?

Cheers to you ezekg, and may transparent licensing schemes prevail.

If they won't let us SEE their standards, let alone collaborate on them, we should just write our own.

Membership for FOSS developers: $0 Membership for anyone even tangentiality related to a massive corp: Call us for pricing details.

Fund the whole organization by gouging megacorps.

Perhaps I'm in the minority here, but I would like to see the entirety of HN's codebase posted as-is, no redactions, cleanup, etc.

The entire site is officially moderated by ~2 people, and autonomously by the community. Whatever secret sauce they're using, that should be proof positive that it works. Keeping it a secret deprives countless communities of best-in-class tools and knowledge.

Would it be detrimental to HN? In the short term, possibly (gaming the voting ring detector comes to mind), but it's hard to say what kind of impact there would be without knowing what goes on under the surface.

Yes, see the sibling comment, and for the love of all that is holy, heed the warnings. Use it at your own peril, and even then with caution and distrust.

I use a deeply modified fork of this every day. My changes have been:

1. Rewrite the backend in Go (I'm nkt qualified to audit the C version, and having Web Stuff™ interact directly with an unaudited C filesystem daemon makes my skin crawl)

2. Modularize it quite a bit to make it easier to add endpoints like...

3. Rudimentary Tree-Style Tabs support

4. Desperately try to improve the performance enough to navigate a sizable session (I have not yet succeeded)

Even after all this, I've come to the conclusion that the relationship is backwards: the filesystem representation needs to drive the browser, not the other way around.

It's my considered opinion that some hero needs to step up and build a browser that exists to render one tab and nothing else, shelling out for everything more complex than scrolling. Then the power users cwn supply their own tab/bookmark/window/filesystem schemes using whatever glue they prefer, be it python, node, shell scripts, Windows Explorer...

As much as I _despise_ modern ReCAPTCHA, I have always been able to pass the challenge eventually; it has never flatly rejected me with no recourse. If I made a mistake or was insufficiently human for it, I got a new challenge and tried again. There are apocryphal stories of Google tar-pitting users with it, but I have never seen it in action.

If this judges the browser more than the user, what do I do when the browser fails? Do I refresh the page hoping for a different batch of invisible challenges? Do I submit a ticket to CF customer support... despite not being a customer?

wrt. Discord and their stance on "self-bots", what is the demarcation point between their (web) app and my computer?

Is using a screen reader a self-bot? Is a non-screen reader Firefox add-on that uses the API a self-bot? What if I write an add-on that keeps track of Discord-specific state via it? What if that add-on exposes an API to read my DMs? What if it exposes an API to send them?

Raymond's blog always hits a note of morbid fascination. At times it almost feels like schadenfreude. "Neat, but thank God I didn't have to be the one that wrote/discovered that."

Their IRC setup is profoundly disappointing. Joining their channel redirects unregistered users to a designated quarantine room that blocks all messages.

Why on earth do I need to manage YET ANOTHER account just to ask a question, get a response, and leave?

I have logged more pages turned and books completed on a stationary recumbent bike at my local YMCA than anywhere else in the world. Some earbuds to drown out the radio (and others' grunting), an ereader with far more content then it should ever carry... I was set.

I've tried to replicate it at home to no avail, however that sort of bike (with a desk add-on) makes for a decent place to do my usual computer work.

I wish the underlying theory to this whole class of software was more accessible. It seems like these logical systems can do such amazing things, but I'd be remiss to integrate any of them without some degree of understanding of what they're doing under the hood; what their limitations and failure modes are, etc. As it stands, it's all far too magical for me to trust.

Frankly, I'd be thrilled to have a Firefox fork that is designed to show exactly one page, specified by the command's sole argument, and do nothing else. All the "tab" stuff and bookmarks could be offloaded to shell scripts.

Taken even further, you could modify the browser to expose git-ish hooks (for example, calling .browser/hooks/request-file when fetching a resource could allow you to implement request blocking).