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.
In consumer banking, there is a pretty popular software called Finacle developed by Infosys. It was originally a TUI called Bancs2000 and was written in C and Pro*C. It could basically accept input as fast as one could type. With a few months experience, you would be blazing fast. Then they replaced it with a web based component and called it Finacle - and everyone hated it at first. The replacement wasn't particularly slow by standards of a web based component, just that the users were spoiled by the combination of muscle memory supported by TUI speed.
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.
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.
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 alluded in the post, we should all have switched to Plan 9 decades ago. Everything behaves like a file, which means you get a mountpoint for web stuff (https://man.9front.org/4/webfs), and use another application that reads and writes files on top of that (https://man.9front.org/1/mothra).
I fear the current web is too complicated for that. All hope is lost, the web cannot be salvaged.
> 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...
That's basically uzbl. The core version has no tabs, no bookmarks, no history, and is extensible in whatever language. Seems it's been abandoned, though.
* > 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.*
Is that not what your OS's 'native' web view API is?
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 just moved my bookmark management out of my browser because I wanted to use unix-y tools to deal with them. CLI instead of a GUI afterthought. I think you're absolutely right. I'd love to access browser history at CLI. And management of open tabs.
Caveat _extremely_ emptor: This code works on my machine, and I have no recollection of how it came to be that way. There are undoubtedly bugs, both obvious and subtle, in both halves. The Go side is a pile of garbage (in no small part because of the countless interfaces it has to implement).
It is EXTREMELY unlikely that either the server or extension is compatible with its original counterpart. The filesystem layout itself has been reorganized more along the lines of /sys conventions.
It's not particularly deep or thoughtful, I just realized that the browser interface is not a good place to manage a large list of links. Almost anything else is better. I have tried a few different browser-based bookmark management tools, and they have always been lacking somehow.
I started using Obsidian recently, so I am moving my bookmark archive into there. It's neat because you can right-click>copy a bookmark folder, then paste into Obsidian as markdown links, with the page title as the link text (I think it's Firefox doing this, but not sure. I had to get a "copy as markdown" extension for Chrome). I also use the multi-select "bookmark tabs" feature, and Firefox Sync to move tabs between devices. These three things in combination enable me to make closing tabs a regular, routine thing, because I now know that I can find them again when I need them. Instead of going into the black hole of my bookmark toolbar, they go into an Obsidian vault, a single folder full of markdown files. This means I can use my normal CLI tools and text editor (keyboard instead of mouse is a big part of the appeal here) to search, sort, and organize things.
The detailed organizational principles vary based on the purpose of the bookmarks, and I think that's mostly a personal thing. I don't have some sort of well-defined technique, but for example I now put the "project research link dump" into the "project notes file" (where it obviously belongs, but I was too lazy to do this previously). I have a few different "optimistic learning links" lists, like one for productivity software tools, which I might randomly browse when I have some down time at work. Another for interesting-but-not-important-for-work videos on math, physics, CS.
Now, instead of thousands of links and hundreds of folders, my bookmark toolbar can be used for just a handful of "webpages that I use frequently" - the intended purpose of the bookmark toolbar, as far as I can tell.
Well, now I want to expand on this a bit in a blog post, but I'll have to come back to that.
That's a good point. Browsers are desktop environments with a built-in application runtime. Maybe it's the "Inner-platform effect."
It's an interesting idea to pull bits of the browser back into the system, or alternatively to write a desktop environment that's also a web browser (ChromeOS?).
A former coworker used Plan9 at a previous job, and he said it was cool how you could draw a rectangle on part of a terminal, and pipe that text (as it changes) to another process. Maybe rethinking GUI (and web in particular) from a unixy/plan9y perspective is a worthwhile exercise.
I grew up on Windows, and then there was the browser, and now everything is just the browser.
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?
It 100% is true that using ReCAPTCHA on privacy-oriented browsers can make ReCAPTCHA unbearable. As a Firefox user, I relate to others who've faced CAPTCHAs where the images fade-in unbearably slow, and even after painstakingly selecting the correct images, it will fail and say "nope try again", repeating the cycle.
A couple of years ago, a web site I was using at the time started to use a relatively obscure service that appeared to inspect or fingerprint the user agent in various ways, as well as tracking browsing activity, in order to determine if the user should be locked out of the site until a captcha was completed.
Although I suspect it was supposed to be transparent, it still ended up being a disaster for many of the users, especially the non-technical ones. The web site's support forum was full of complaints from what seemed to be legitimate, long-time users and customers.
Even benign and reasonable user agent variations from the "norm" seemed to cause problems for this particular system. For example, I recall a default Chrome installation working well enough, but adjusting its configuration to harden its security or privacy seemed to confuse the web site's blocking system.
In my case, I had to keep around and use a dedicated ancient browser installation, since newer ones seemed to trigger repeated challenges for some reason I could never figure out.
The challenge page even had a report-a-problem form, but I don't know if anyone or anything actually considered the submissions.
Even the web site's administrators seemed to have trouble figuring out why legitimate users were getting flagged repeatedly by this system they were using.
I ended up just not using that web site any longer. The hassle wasn't worth it.
Where I usually get tarpitted is by Cloudflare. I'll pass the (automated) CAPTCHA, the page will reload (still as if I had passed), and … it'll be another CAPTCHA. I'm pretty sure these usually amount to a passive-aggressive demand for cookies/storage, but I just vote with my browser & go back/somewhere else.
Cloudflare deep down greatly discriminates against shared IPs. If you have a real honest-to-goodness IPv4 address that doesn't change, you'll hardly ever encounter anything.
But if you are behind any sort of carrier-grade NAT or otherwise sharing IPs, you're a second-class netizen, sucks to be you.
I'm behind your typical non-CGNAT residential NAT, for v4. (Was v4 only for the longest time, but Verizon just recently rolled out a v6… so we'll see if that changes anything, I guess.)
If you encounter it relatively often with VPN off, I would do a full scan/check of all devices (including wifi phones, etc) and update all software, as you may have a bot virus or similar. If you DO find one, clean it up and then turn your router off for a few hours or whatever is necessary to get your ISP to give you a new IP, heh.
But, haha fool you, CF now gatekeeps some unholy percentage of the web, so the "somewhere else" list is going to get smaller and smaller with no recourse, as best I can tell. Maybe disposable Firefox containers for your specific situation, but only maybe
> 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?
This is definitely good question. With the “Managed Challenge” feature it seems to degrade gracefully — if you have, say, a positive profile with Cloudflare, an iOS device where it can use PAT, etc. you never see the prompt but eventually it'll fall back to the same CAPTCHA you're seeing today. It'd be useful to confirm that this is how Turnstile works as well since some fraction of real people will definitely hit that on a daily basis.
> There are apocryphal stories of Google tar-pitting users with it, but I have never seen it in action.
That used to be the case when using Tor; I remember having to rotate exit nodes to get recaptcha to load at all.
These days the situation is a lot better, I've been able to pass Google captchas through Tor every time I tried this month. Seems like they even fixed audio-based captchas, so you no longer get instant-blocked if you try to use them.
Of course, all this could be reverted tomorrow, and there would be absolutely nothing we could do about it...
I have been personally tarpitted. It's not infinite, but it has super slow loading tiles, a comically large number of rounds you have to keep doing, and it has decided to fail you from the beginning meaning you wasted your time.
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?
Unfortunately, because we get enough trolls and spammers as-is, and I don't even want to imagine what happens if we lift that restriction as well. Sorry!
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.