My "production stuff" is listed at https://github.com/alexpdp7/alexpdp7/blob/master/README.md#other-usable-projects-of-mine
@david_chisnall @swetland oh, that is the proper version of some stuff I've been thinking of for a while.
Namely, a terminal that would also support programs that produced HTML output *or* that serve a web application. (So for example, an HTML top variant that serves a real-time web UI.)
(Likely then you could also extend that terminal to have browser functionalities, so "open https://example.com" would turn a tab into a browser.)
Somewhere, I have a small patch set for FreeBSD that adds two features.
The first is a content-negotiation protocol for pipes. This follows the model used for drag and drop and is backwards compatible if one end doesn’t support it. The sender does an ioctl to advertise a list of types that it supports. If the receiver does a read or a poll/select/kqueue wait, this returns an error indicating that the receiver does not support it. The receiver does an ioctl to receive the list of types and another to specify the desired type. The first ioctl similarly returns an error if the sender writes data to the pipe (i.e. they don’t support content negotiation). The sender then writes data according to the agreed type.
The second was ‘pipe peeling’ in the TTY layer. This let you get a second data channel to the terminal emulator (or whatever owns the server side of the tty), so you could send text for display on the normal terminal but also have a completely different stream (or more than one) for other data. You could use this to provide structured data for other rendering, accessibility data, and so on.
I also modified libxo, which a bunch of FreeBSD tools use to provide structured output, so that it would use both of these. If the standard output was a pipe, it would try content negotiation. If the standard output was a try, it would try to peel off a pipe and send structured output there as well as normal output to the tty.
I had a little demo that implemented a tiny tty server that mostly forwarded to the host terminal but accepted peeled pipes and asked for HTML that it would then send to a web browser to open, so anything that used libxo would automatically display pretty (sortable, filterable) output as well as the terminal output.
I had planned to add support for the additional channels in SSH (SSH supports additional data channels, they just needed wiring up), but I never got around to it.
There were some cleanups to do, but it gave you a very simple model for providing rich content between command-line tools (and between tools and the terminal emulator).
The entire diff was only around a hundred lines of code, implementing the same thing in multiple operating systems wouldn’t be very hard.
@datarama haha! Yes, IMHO the peak swear word in Spain is "joder" and for emphasis some people roll the R (although that's not the correct pronounciation).
However, I have to be that guy that says that then it's a homophone with "gira" (it turns/spins, or "tour" [as in a musician's tour), so that dampens the effect :(
But I think it's fun to say "Jira está hecho en Java, ¡joder!"
It is a toy program, but it was pleasant to write.
Writing the websockets was not much fuss, and writing an HTML file with a "script" tag to connect to the websocket was refreshingly simple.
For sure I will soon go into regretting writing JavaScript, but well, I haven't done any serious JavaScript on the browser programming since 2011...
I have been programming a simple elevator simulator in Python today. Then added a websockets interface and tested it with a command-line websockets tool. And then wrote a simple HTML page that connects to the websocket and fetches the simulator state.
Tomorrow I should create a graphical UI for the simulator, maybe a simple elevator controller, and perhaps a "person simulator" that has people randomly calling the elevator.
Stockholm syndrome: when the AWS console takes you to eu-north-1 when you do not have anything in that region.
But today looking at a *private* service I'm running, correlating with my experiences running non-professional publicly exposed services and...
I wouldn't feel comfortable at all running the same kind of websites I was working on in 2008-2011. At the very least, I would have to rely on Cloudflare or others that I do not like for "protection".
Likely it's just that I've become disconnected from running public websites, but I think the world is changed in a sad way :(
In 2008-2011 I was working on some public websites- some of them were even "nation-wide" "important". And I felt confident running them my moderate systems administration skills, on simple platforms, with reasonable hardware.
(For two specific projects with important customers, we did pick overpriced and overprovisioned hardware and hosting from a "serious" company, but outside that, it wasn't very different from what you would do for personal stuff.)
I had an interesting projects list as an org-mode file. The hierarchy was organic and chaotic. This bothered me so I decided to overcomplicate it:
https://alex.corcoles.net/notes/interesting-projects
It's non-deterministic, so even unrelated changes to the underlying Git repository shuffles things around, but I find the result much more pleasant than the previous version.
I have written down some notes about software development here:
https://alex.corcoles.net/notes/tech/on-software-development
(My intention is to extend and update this as I need to... right now it just collects a few things that are on my mind.)
I was copied on an email today. Someone was requesting a count from someone else, wanting to know who in a department had done a certain thing. This lovely sentence was spoken by my screen reader:
"Can you get a quick woman raising hand man raising hand medium skin tone from your department members?"
I really hate emoji.
Recently I came in contact with Next.js. I think I already tooted that I thought it was the first framework I'd seen that delivered the old promise of good integration between the code running on the browser and the code serving your application.
But these days it surprises me more it's absolute lack of support for WebSockets!
So maybe the real-time web application problem continues to be unsolved satisfactorily for me.
Around 2000, when #PuTTY first started to become popular, it brought me more and more email. At some point it became hard to answer it all, and my inbox started to grow.
Young and optimistic, I came up with a plan to fix this. I drew a line in my inbox (by sending myself an email with subject "---------"), and told myself that I'd keep the region below the line clear, and every few days, deal with a few messages from above the line, until eventually the line was at the top again.
Of course, it didn't work at all. Soon enough there was a huge backlog even below the line, and the stuff above the line was all still there. The line became part of the problem, not the solution.
It took a historian friend of mine to point out the fallacy. To answer more mail, you must spend more time answering mail. No amount of classifying, rearranging, or reorganising it makes there be less of it. You must either answer the mail or decide not to. (And once there's too much of it, only one of *those* is possible.)
This is a post about management methods that respond to any problem by spending more rather than less time moving issues around the bug tracker or kanban board or what have you.
One thing I've learned in 25 years of software maintenance is that every time you commit crap that appears to work without being sure why it works, that's going to come back to waste a lot of your time later.
@datarama (and sidenote: I think the definition of art must include some kind of intentionality; otherwise all bad software is art, because it does evoke quite strong feelings in its users: anger, frustration. Whereas good software sometimes does not cause delight because it just works.)
@datarama ah! I was going to disagree, but I agree with your second toot.
One important thing is that nothing is "lesser" because it's not art. Just like HTML/CSS rarely are "programming" (but they can be), but that doesn't make them any less important, complex, or valuable.
We like to shoehorn things into categories we think are important, when those things are important in their own right.
I wish command line tools would make an output mode optimized for screen readers. I just did a no-cache build of four containers with compose. Instead of hearing random numbers constantly shouted at me, I'd love to have Docker make NVDA say the current step when something significant changes. "Building php_dev. Health check for mysql_dev. Check passed. Building web_dev." No fancy progress bars, no always-updating percentages, no detailed output. Direct that stuff to a file if you want it.
Nice, searching on https://discover.holos.social/ reveals two toots about this. Perhaps Fediverse search can be useful.
Yesterday afternoon I started having some trouble with Ubuntu mirrors at work. 5 hours ago Canonical acknowledged the issue on their status page:
If you are having problems with stuff such as building containers (failures and extreme slowness), this might be it.
This (type `for(;;);` into the Javascript console, triggering Firefox's "script in infinite loop" detection, causing it to offer to halt all Javascript on the page) worked perfectly
and I fucking hate that it not only works but appears to be the best way to do this
https://gts.woodland.cafe/@untitaker/statuses/01KP6GBF6W0YGKZAB7400C49NA
Some networking knowledge I figured out a good while back that should be standard, but I think it's poorly understood and worth sharing:
A route *without* a gateway address means you want the system to do an ARP (v4) or NDP (v6) lookup to find the MAC address of the *destination* and send/forward the packet to that MAC address.
A route *with* a gateway address means you want the system to do an ARP (v4) or NDP (v6) lookup to find the MAC address of the *gateway* and send/forward the packet to that MAC address.
(The other being the "Sharp Tools" chapter explaining that programmers need a computer with one megabyte of RAM, 100 megabytes of disk, and a terminal much faster than 15 characters per second.)
(Wait, sometimes we still suffer from less than 15 characters per second...)
> Brooks claims that accidental complexity has decreased substantially, and today's programmers spend most of their time addressing essential complexity.
(The Wikipedia article about No Silver Bullet.)
OK, I found the other part of The Mythical Man-Month that has not aged well.
I just learned there's a tab-size CSS property. So I assume you can style code blocks so that they have different indentation under different screen sizes, or that users could adjust tab size according to their preferences.
(And maybe code blocks using tabs for indentation are more accessible than code blocks using spaces for indentation, but I have my doubts.)