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.

FUSE proxy: https://gitgud.io/ee/gtabfs WebExtension: https://gitgud.io/ee/tabfs

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).

I have two thought experiments:

- 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.

Two major questions come to mind:

1. What will the impact be for ROCm's Navi support on Linux?

2. Does this mean they're getting more confident at handling simultaneous display AND compute with ROCm?

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.

As someone who's been using Go for a long while now, I can't help but wonder if modules and other recent changes aren't a step backwards. Maybe I'm a change-averse geezer, but modules still seem like an overcomplicated solution for a solved problem. Needed a particular version of something? Great. It happens. Add a submodule and toss it in vendor/. Why in God's name do we need to proxy source code through Google-hosted services which they've been reluctant to even open source? And at the root of it all, the GOPATH model simply wasn't bad enough to be worth replacing! You have the full source repo right there, in a predictable, semantically-useful location. When you `go get` something, use `-u`. If a package fails to work with the current upstream, vendor an old version, _or update the depending package_! Ideally, I'd only ever have one copy of source code anywhere on my computer, preferably in the form of revisions in a source repo. Contrary to popular belief, disk space and bandwidth are neither free, nor infinite, and I'd like to make good use of mine. NPM and `node_modules` are NOT designs to aspire to!

If the Go tooling insists on involving itself with versioning, dependencies, and source control, it should actually USE the source control tools to manage versioning and dependencies! It isn't rocket science to make a temp directory, clone from the local repo, check out a tag, and use that for building. Git even has facilities to check out the tree at a specific commit, no full clone required. (Granted, my view is Git-centric, but I believe that mercurial and svn also allow you to clone and check out labelled versions, especially considering those are _the basic requirements_ of an SCM.) And why do we need to verify cryptographic integrity of downloaded code bundles when the SCMs typically use cryptographic primitives to describe versions? Then to mandate a gatekeeping "sum database" on top of all that?

Finally, it is depressing to me how shut-in and closed-off the core team seems. The designs for big language changes are rarely ever proposed by the community, only by people already in the team. While (I hope) the community's input helps inform their decisions, the final module design was rsc's. Before he drafted the design document, dep versioning was a user-space/community problem, but after it came from him, then—and only then—was dependency version management truly considered for the toolchain. The generics design came from, and was accepted by the core team. Rob Pike's recent d̶e̶̶c̶̶i̶̶s̶̶i̶̶o̶̶n̶ proposal to support taking the addresses of simple types is—as one might expect—unquestionably going to be added.

The greatest thing that could happen to Go would be a community-organized and -centric fork, like Gitea was to Gogs. Even if they didn't maintain strict compatibility with each other, I know which one I'd use.

There is (yet another) aspect that the author didn't cover: internalized rejection.

Imagine you burn out during college, so you pivot and get a professional certification instead. You pass the exam and have the certificate in hand, and you start looking for jobs. You scroll and scroll through indeed, glassdoor, the job sites for the organizations that would hire someone with your certification and training, and... they all require that degree you don't have. They all require N years of experience that you haven't gotten.

How many visits like this does it take before you stop looking altogether?

I'm all for eliminating (re)CAPTCHAs, and I'm glad someone is working on the problem, but this proposal seems a little iffy on a few fronts, with two main areas of concern.

First, I don't like the idea of having Cloudflare as the sole judge of the trusted key set; a more open model like the CA-Browser forum would be much easier to trust, as it helps reduce perverse incentives (for example, forcing token manufacturers to implement/ignore features, block certain platforms, give kickbacks, etc.)

Second, it's hard to support a proposal where a full deployment would require every person on the internet to buy AT LEAST a new security token (from an Approved™ vendor), which may not even be compatible with their platform, or may be impossible to acquire (because of export restrictions, poverty, someone inventing a cryptocurrency that requires a hardware token to mine...)

That's... spooky. I was working on this exact project a few weeks ago for the VM/370 source distribution tapes (and WOW the VMFPLC2 format is a pain). Shame OP didn't preserve the on-tape file structure, it would have been interesting to see how things had evolved.

Anyway, if you're looking for more info about CP/CMS and VM/370 or the systems they ran on, bitsavers has an absolute treasure trove of manuals: http://bitsavers.org/pdf/ibm/360 http://bitsavers.org/pdf/ibm/370

I agree, my speculation is just that: speculation. I sincerely hope they can come up with a generic, decentralized way to verify professional credentials, as that could bolster certification's viability as a career path.

Elsewhere in tech, Cisco's certifications come with a sort of verification code which you can punch in to their site to check (in addition to the paper trail from Pearson and the physical certificate they mail you). If it weren't such a long-running part of their business, I'd be equally skeptical about them maintaining the certification infrastructure, as it's wildly tangential to the business of building networking equipment. As to the question of what a potential employer would do if Cisco (or Google, or a college, or a bootcamp) did shut it down their verification systems? I couldn't say, I've never hired anyone, nor have I had HR breathing down my neck to check off position requirements.

I don't trust a company like Google to act in its students' and certificate holders' best interests. It's not hard to imagine that the certifications will all be tied back to a Google account that they can terminate at any time, at their discretion. On a more Google-y note, I wouldn't want to get an email in five years telling me that they're sunsetting their online certificate verification portal, meaning no one can actually trust my claims as a certificate holder.

Thinking from a different perspective, in a majority mail-in election, could these machines pose a risk to the election's integrity? They would most likely not be undergoing the same scrutiny as electronic voting systems (which in many places is already a very low bar...), and they are most likely vulnerable to as many other problems and exploits as any other system.

Interesting! The game reminds me a bit of another industrial simulation game called "Oakflat", a nuclear power plant operations simulator for MS-DOS (and later Windows).

The DOS version can be played on archive.org, but I'm not sure if it's possible to get the Windows version anymore.

https://archive.org/details/msdos_Oakflat_Nuclear_Power_Plan...

NB: The textbook is currently free thanks to Springer releasing a selection of their material as free in response to COVID.

https://link.springer.com/book/10.1007/978-3-642-04101-3

Speaking from experience here, don't go overboard trying to grab papers to read later. Doubly so if you have a static IP. Academic resources, the ACM included, are incredibly ban-happy, and the line between good behavior and bad is kept secret.