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'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.
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.
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.
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).
- Imagine the exact same software was used, instead by the localities' fire & rescue departments. I don't suspect anyone would complain about trying to put ambulances as close as possible to populations that tend to need medical care. As far as optimizing a locality's resource use by analyzing historical data, this is the best they can do.
- Next, imagine a case where the software was just flat out wrong, all the time. Would any departments buy it?
I don't have a real solution. If we're limited to exploring software fixes instead of societal ones, my best shot would be to take the algorithm and flip it on its head, reframing the purpose. Instead of "predicting" crime and putting officers where crime is known to exist, why not put them where crime isn't yet known to exist? If officer-visible crime is committed in equal portion by all populations, this at least has the potential to reduce bias.
It would make me much less comfortable having police roaming around looking for crime, as they tend to find—or invent—what they're looking for... but maybe it'd be better to spread that discomfort equally than to limit it to disadvantaged communities.
Finally, I could be easily convinced that the algorithm is more impartial than where officers would choose to spend their spare time on their own[1]. Of course, that depends on being fed accurate crime data, which the article (correctly, IMO) suggests does not exist.
1. eg. if there's a sudden smattering of crime in a white/affluent neighborhood, I suspect any reasonable algorithm would recommend patrols there more readily than the officers would otherwise.
That was similar to my thought. In Vim, I have persistent undo and Undotree set up so that I can go back to the state of a file at any point in my process, so long as it hasn't been changed by any other program. I wonder if there's a way to tie that and git together? Maybe checking in the undo file?
I've found that "Todo apps" are generally useless for me. The list gets too big, or it has limited support for priorities or dependencies or whatever, so I built my own.
Its philosophy is built around the fact that I'm only ever going to be working on one major, todo-worthy task during a given minute. There's no reason to inundate me with dozens of things I could be working on when I'll only ever be doing one. And most of the time, I'm ambivalent to what I'm doing — if I need to consult a Todo list to remember it, clearly it's not something I'm actively working on, since I don't (yet) need help remembering those.
It's been very effective when I can use it (it needs a few tweaks so it can accept tasks from multiple sources, rather than one singular list). The core workflow is to jot down a task name and a priority in a text-based, line-delimited list file. Then, when you have time to do something, the app parses the list of tasks and selects exactly one at random, weighted by the priority. At that point, you have four options:
- Defer the task and roll for a new one (which increments a counter on the task, and does not guarantee that you'll actually get a different task!)
- Log some time on it, and optionally roll for a new task (again, not guaranteed to be different)
- Mark it done, and roll for a new task
- Exit the app
It knows about repeating tasks, start and due dates, dependency trees, and "stints", which are just a log of the time you spent on a particular task. It can filter tasks based on how much time you have to work vs. how long you estimate it will take, whether there are unsatisfied dependencies, etc. There's even an option that tries to assign you tasks that try to keep your "mood" steady. You can optionally annotate tasks with a mood tag (which is just a float), with the idea being that tasks with positive values are pleasant, and ones negative values are unpleasant. If it assigns you a mood-tagged task and you work on it, it adds the value from the tag to a global mood variable, and the default priority scheme tries to keep it around 0. In other words, when you do something pleasant, it builds up a buffer so you can handle something unpleasant. Or, if you do something unpleasant, it tries to reward you by giving you something pleasant to do.
The crown jewel is the LISP-y functional priority language that implements these dynamic tweaks to the priorities. For example, I have some rather daunting tasks that entail a lot of repetitive, monotonous work. Since it knows when I've been working on it, I can script it to de-prioritize those based on how much time I've spent on them lately.
It's technically open source (it's a TUI app written in Go), but I'm hesitant to post a link here since it's not robustly tested, the code isn't pretty, and the README is written in a sarcastic, derisive tone. I'm hoping to rewrite it after I finish up a library I'm working on to make it a bit more generally useful.
Frankly, the biggest mistake of my career thus far has been starting it. I didn't get in to a university, so I bumbled around for 6 years at a community college. In the middle of it, I managed to get a 6-month stint at a help desk (which I needlessly proud of, and then promptly fired from). Went back to the community college, burned out on trying to get an associates and transfer, and tried changing course to getting some sort of certification. Ended up with a CCNA (which expires later this year), but it turns out nobody near where I live wants to hire a network technician or engineer without a diploma, and my savings aren't enough to move.
So now I'm in my mid twenties and I've only just managed to get an (unpaid, remote) internship thanks to a sympathetic small business owner whose pet technical project is falling behind schedule. Every time I open the project management tool, I feel a vague sense of unease because I'm socially tone deaf and I can't tell if I'm breaking some unspoken rule about "don't word this message this way because you'll sound too confident for an intern speaking to the senior developer," or "don't make a comment on this task because it's assigned to an intern on a different team and you're not supposed to go out of your lane."
I've been writing code of some sort for 11 years, and using Linux daily for 8. Every day I wake up in my childhood bedroom and send my one remaining friend a message. Sometimes she even replies. Then I have the pleasure of spending most of the day fighting with some stupid self-inflicted issue, like why Ethernet broadcast breaks every week on OpenWrt, or why Pulseaudio uses 200% CPU when I try to get it to communicate with a certain cgroup, or what I'm going to use when Fedora 33 hits end of life and I have to get some other DE set up to replace GNOME.
I've dug myself into a labyrinthine, unsatisfying, inescapable hole. So if I could do it all over again... I wouldn't, because, like a ball on a hill, I'd end up right back in here.
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.