The term “fascist” has been watered down to the point it doesn’t really mean anything the way many people use it now
I think the real standard for “fascist” has to be - how similar is what someone is doing to what Mussolini did? If there’s a genuine similarity there, the term “fascist” may be appropriate; otherwise, it isn’t
The Australian federal government is planning to build a high-speed rail line from Sydney to Newcastle (medium-sized city two hours drive north). Their solution to property rights, is >50% of the line will be underground. It will cost >US$50 billion, but if the Australian federal government wants to spend that, it can afford it. The US federal government could too, but it isn’t a priority for them
> local regulations make it prohibitively expensive
Local regulations can be pre-empted by state or federal legislation. The real problem is lack of political will to do it.
They could let you nominate an S3 bucket (or Azure/GCP/etc equivalent). Instead of dropping data from the cache, they encrypt it and save it to the bucket; on a cache miss they check the bucket and try to reload from it. You pay for the bucket; you control the expiry time for it; if it costs too much you just turn it off.
A lot of this is issues Microsoft could fix if they were sufficiently motivated
e.g. Windows lacks a fork() API so cygwin has to emulate it with all these hacks
Well, technically the NT API does have the equivalent of fork, but the Win32 layer (CSRSS.EXE) gets fatally confused by it. Which again is something Microsoft could potentially fix, but I don’t believe it has ever been a priority for them
Similarly, Windows lacks exec(), as in replace the current process with new executable. Windows only supports creating a brand new process, which means a brand new PID. So Cygwin hacks it by keeping its own PID numbers; exec() changes your Windows PID but not your Cygwin PID. Again, something Microsoft arguably could fix if they were motivated
> A lot of this is issues Microsoft could fix if they were sufficiently motivated...
They did fix it, in a sense, with WSL1 picoprocesses. Faster and more compatible than Cygwin. Real fork and exec on the Windows NT kernel. Sadly, WSL2 is even faster and more compatible while being much less interesting. WSL1 was pretty neat, at least, and is still available.
In any event, this diversion doesn't change my analysis of Cygwin. Cygwin still sucks regardless of whose fault it is. I intentionally left this stuff out of my post because I thought it was obvious that Cygwin is working around Windows limitations to hack in POSIX semantics; it's the whole point of the project. None of us can change Windows or Cygwin and they're both ossified from age and lack of attention. We have to live with the options we've actually got.
If you need a Windows build of a Linux tool in 2026 and can't use WSL, try just building it natively (UCRT64, CLANG64, MSVC, your choice) without a compatibility layer. Lots of tools from the Linux ecosystem actually have Windows source compatibility today. Things were different in the 90s when Cygwin was created.
I really dislike Notion. Its public API is full of bizarre arbitrary limitations, like a rich text database field can only contain max 100 “child blocks”, where each change in formatting consumes one child block-but its web UI doesn’t have this issue. Yes, I realise the undocumented private API that the web UI uses doesn’t have this issue either-but I shouldn’t have to, and I haven’t.
I don’t love Confluence, but at least it doesn’t do this to me.
My paid use of Claude has only ever been via AWS Bedrock (paid for by my employer) or via GitHub Copilot (one subscription paid by employer, one paid by myself)
I wonder if using it via an intermediary results in less heavy-handed moderation? I suspect the answer may well be “yes”. On the other hand, it also could be more expensive
This could be fixed with an extension to the kernel pty subsystem
Allow a process to send control instructions out-of-band (e.g. via custom ioctls) and then allow the pty master to read them, maybe through some extension of packet mode (TIOCPKT)
Actually, some of the BSDs already have this… TIOCUCNTL exists on FreeBSD and (I believe) macOS too. But as long as Linux doesn’t have it, few will ever use it
Plus the FreeBSD TIOCUCNTL implementation, I think it only allows a single byte of user data for the custom ioctls, and is incompatible with TIOCPKT, which are huge limitations which I think discourage its adoption anyway
For this use case, there would also have to be an extension to the SSH protocol to send such out-of-band information. Maybe this already exists and isn't used?
The broader problem with terminal control sequences didn't exist on Windows (until very recently at least), or before that DOS and OS/2. You had API calls to position the cursor, set color/background, etc. Or just write directly to a buffer of 80x25 characters+attribute bytes.
But Unix is what "serious" machines -a long time ago- used, so it has become the religion to insist that The Unix Way(TM) is superior in all things...
> For this use case, there would also have to be an extension to the SSH protocol to send such out-of-band information. Maybe this already exists and isn't used?
I don’t think one already exists, but it would be straightforward to create one. SSH protocol extensions are named by strings of form NAME@DNSDOMAIN so anyone can create one, registration would not be required.
The hardest part would be getting the patches accepted by the SSH client/server developers. But that’s likely easier than getting the feature past the Linux kernel developers.
The Unix way died with Plan9/9front and there are no teletypes, period. Just windows with shells running inside as any other program. You can run a browser under a window(1) instead of rc(1) which is the shell.
Architecture Astronaut! TCP is a stream protocol. A terminal program is expected to honor the stream protocol: I can use a terminal program to speak SMTP or HTTP. I can paste binary shit into it and copy binary shit out of it (some caveats apply).
If you're gonna jack some control protocol into a session which is sitting directly on the stream protocol, that's on you. This is as airtight as injecting a control protocol into SMTP or HTTP. Encapsulate the entire protocol (obviously this requires presence on both ends), open a second channel (same), or go home. It's worth noting that the "protocol" drops a helper script on the other side; so theoretically it is possible for them to achieve encapsulation, but doing it properly might require additional permissions / access.
Obviously they published a fix, since that's how the exploit was reverse engineered. This is "...what happens when terminal output is able to impersonate one side of that feature's protocol."
Which has nothing to do with terminals, because nobody runs terminals directly over TCP. Telnet wasn’t simply sending terminal bytes over TCP, it has its own complex system of escape sequences and protocol negotiation (IAC WILL/WONT/DO/DONT/SB/SE, numerous Telnet options). SSH is even further from raw TCP than Telnet was
And a Unix pty isn’t a simple stream either. Consider SIGWINCH
> Anything but the simplest tooling is not transferable between model generations, let alone completely different families.
It is transferable-yes, you will get issues if you take prompts and workflows tuned for one model and send them to another unchanged. But, most of the time, fixing it is just tinkering with some prompt templates
People port solutions between models all the time. It takes some work, but the amount of work involved is tractable
Plus: this is absolutely the kind of task a coding agent can accelerate
The biggest risk is if your solution is at the frontier of capability, and a competing model (even another frontier model) just can’t do it. But a lot of use cases, that isn’t the case. And even if that is the case today, decent odds in a few more months it won’t be
Yep. My approach has been, if I can’t reliably get something to 90+% with a flash / nano / haiku, then it’s not viable for any accuracy critical work. (I don’t know of or have the luck of having any other work.) Starting out with the pro / opus for any production classification work has always been a trick.
Ha. Sounds a lot like the one 10x vs. predictable mediocre guys with a scaffolding of processes. Aim high and hit or miss or try to grind predictably and continuously. Same with humans and depends on the loss you can afford.
Like [0] that Windows has for its console? This API has just recently finally lost to UNIX's in-line signaling, because the in-band controls can be proxied through almost anything, including literal serial line with two RX-TX wires and a common ground; the downside, of course, is that you have to build "out-of-line" signalling on your own.
If getting the current cursor position in the terminal were as easy (and as fast) as calling GetConsoleScreenBufferInfo, instead of sending "\e[6n" to the terminal and then reading input from it and looking for "\e[(\d+);(\d+)R" inside and then somehow unreading the input before that device report, yeah, that'd be nice and would allow solving a lot of problems with mere brute force. Sadly, it is not, and so most reimplementations of e.g. readline/linenoise functionality in shells and prompts (Erlang's shell went through 2 internal reimplementations just in my time using it, for example) are flying blind, hoping that their implementation of wcwidth(3) matches the terminal's one.
What I personally have in mind is something very different-a terminal ioctl which gives you an fd which speaks a completely different protocol, such as JSON-RPC - or whatever else you prefer - to avoid endless disputes over which alternative protocol to use, it could be you pass the ioctl a string saying what alternative protocol you want, and it gives you an fd if the pty master has registered support for that protocol, an error otherwise. The “other fd” could actually be a Unix domain socket. This also means the kernel code change required would be minimal - it doesn’t have to actually understand the alternative protocol, just let the pty master register a mapping of protocol name strings to listening sockets.
> This API has just recently finally lost to UNIX's in-line signaling, because the in-band controls can be proxied through almost anything, including literal serial line with two RX-TX wires and a common ground; the downside, of course, is that you have to build "out-of-line" signalling on your own.
SSH/etc is totally capable of carrying “secondary channels” - that’s how it implements X11 forwarding, port forwarding, etc - admittedly would require some code change in SSH clients/servers but the change would be modest rather than massive.
The Windows approach can’t be so easily forwarded over the network because it is defined in terms of a C language API not a wire protocol. My idea doesn’t have that issue
Could you give an outline of an example scenarios? For e.g. "print a line with a highlighted word in it" (alternative to print 'This is \e[7mhighlighted\e[m text\n'), and "print some text, move cursor to the second last word, delete it, move to the new end":
print 'This is a line of text which is being line-edited in an imaginary editor.'
if no line-wrap happened:
# move left a manually calculated amount of 17 (wcswidth?), delete
# everything to the right, reprint the rest of the line
print '\e[17D\e[Keditor.'
else:
# You need to know how much fit on the previous line, and the
# terminal's width. Let's assume 80, and that wrap happened
# after 'imagi', so 'nary' was on the next line. Move up 1, move
# right 63 (or do \r and move right 75), clear the rest of the
# screen, reprint
print '\e[A\e[63C\e[Jeditor.'
One of the problems with secondary channels is their synchronization with the main one: say you printed some text to the main fd, requested cursor position from the control fd, and then immediately printed some more text to the main fd — what cursor position will be reported?
> Chris Lattner, inventor of the Swift programming language recently took a look at a compiler entirely written by Claude AI. Lattner found nothing innovative in the code generated by AI [1]. And this is why humans will be needed to advance the state of the art.
Lots of people have ideas for programming languages; some of those ideas may be original-but many of those people lack the time/skills/motivation to actually implement their ideas. If AI makes it easier to get from idea to implementation, then even if all the original ideas still come from humans, we still may stand to make much faster progress in the field than we have previously.
I think the real standard for “fascist” has to be - how similar is what someone is doing to what Mussolini did? If there’s a genuine similarity there, the term “fascist” may be appropriate; otherwise, it isn’t
reply