Thanks for pointing this out. I'm not hating on Cockpit, but Outer Loop (with Outer Shell) has solved a lot more of the stack. Cockpit accepts the constraints of living in existing browsers, so it requires exposing a port to the internet or using some SSH port forwarding tool. Whereas I built a dedicated browser to push capabilities so that users can get a "Just point me to a server" flow.
This thread has been useful -- I think Cockpit will also work great in Outer Loop. And it will be easy to add it as an app in Outer Shell.
> it requires exposing a port to the internet or using some SSH port forwarding tool
This sentence is bizarre to me. Your SSH-based solution also requires exposing a port to the internet and installing a special tool (on both server and client!). What's so special about SSH that using HTTPS is a problem but using SSH isn't?
The industry also tried the whole "use the web browser to run native binaries" thing with ActiveX (and the unity web player I guess). The idea was thrown out along with flash and java applets for what I presume were security and portability reasons.
If you can SSH to a machine, you can use Outer Loop and Outer Shell, without having to do any sudo commands or expose anything new to the network. The browser + SSH client combined into a single app leads to nice user experiences like this. The final section of the post was saying that it's strange such a thing doesn't exist already.
> without having to do any sudo commands or expose anything new to the network.
Again I'm not understanding the distinction. I don't need to run sudo commands to install a web server, and depending on your definition of "exposing something new" to the network then either I don't have to do that either or your solution also does that.
Something is getting downloaded and run on the remote machine, correct? Why is it problematic for that something to be a web server (with SSH-forwarding I guess) instead of this custom thing?
And why install anything on the server at all if it'll just serve a binary that downloads and runs on your local computer anyway? For example, if I type `sftp://username@server.domain/file/path` into my file manager's address bar, I get the nice file browsing experience you demonstrate without installing anything on my computer or the server.
EDIT: OK, after reading through your earlier posts, I think the value proposition really is just that you've implemented a slightly better UX for proxying remote web servers via ssh, and that the "run native code" thing is an independent idea you are also pursuing. So the answer to the question "isn't this just proxying an http server over ssh" is basically yes.
I think I incorrectly read this as attempting to propose a radically new idea and not as an incremental improvement to the status quo.
> it requires exposing a port to the internet or using some SSH port forwarding tool
I think what they meant is that the SSH server can be behind your webserver and not have to have its own public IP exposed directly... but of course there are an abundance of proxy-related solutions already.
Cockpit has a "remote" host connection feature solving this exact pain-point - "Just point me to a server":
You install the Cockpit web service on one host (along with its backend and extensions), and on other hosts you may have - install only the backend of the stack (4-7 packages available via deb backports & other dist repos). The web front host is then able to access any other machine via ssh (if keys and policies permit that) and display info or manage that host. All ports aside from the web front and ssh between your hosts remain as is. It is a decentralized design.
Alan Kay once strongly critiqued web browsers. He argued for a much simpler architecture.
Your experiment somehow reminds me of the better approach that he was hinting at. I.e. I think he would appreciate your experiment as well as the neuroscience in your background.
To the author's defense: Cockpit is Linux only, and they seem to intend on making this also available on Windows and Mac.
Still, I don't see the appeal they seem to do, especially since it relies so much on SSH. The biggest use case I can think for something like this in the real world is something like first-time setup or MDM, and on both situations setting up SSH to begin with has the same level of friction they're trying to remove.
Windows has quite a lot of remote admin tools that work pretty transparently over the network though.
The issue is that they're historically never turned on or heavily restricted.
Where the user is involved though RDP is a world class remote desktop never exceeded by Linux anywhere.
If someone wants to impress me, point Claude at Wayland and get it so I can seamlessly open remote RDP from somewhere else, lock the local user session and resume it on the remote desktop, then walk back to the original terminal and continue working in that same user session. This worked perfectly over 20 years ago.
Do you mean the local session would be locked while you work unlocked from remote? That should be doable with a separate session using a dummy HDMI plug, but your original comment read to me as being able to remote in and lock the session, which is 100% possible with Sunshine
Yes: the RDP experience is even if I just walk away, when I log in from somewhere else the local session is locked and inputs disabled.
Then if I walk back to that console and log in, I can go back to using it directly.
Near as I can tell no one's solved this for Sunshine.
Edit: I will say though there must be good reasons, it's never been clear to me why this is so hard particularly when you have Wayland just compositing to one big buffer in VRAM. Surely we just want to hand the local buffer back to GDM and let the remote stream have whatever we rendered?
It's not insanely hard, I've done it before with a dummy plug and it's possible with the current implementations (essentially what you said: just a separate Wayland session). The reason it is not better supported, I would hazard, is because not many people really need their session locked when they're away - they just need to remote in.
LLM-based coding is enabling so much! The crazy weekend project now can have compilation to native code and web assembly, allow server-side or client-side rendering, manage multiple types of persistence, include adaptive compression, and do all of this without breaking a sweat.
If you’ve never written or worked in a Forth-like language, it’s not a hard system to bootstrap up. If you’ve done it before and know assembly, you can even get something that compiles to (stack-heavy and pretty unoptimized) native code in essentially a weekend. No LLM needed.
Forth-likes are almost magical in ways that are hard to describe. You start with primitives and literally build the language out of them. The interpreter and compiler are two different modes of the same REPL loop.
It’s just a very different paradigm than most programmers know.
Fuck LLMs. People should focus on actually learning stuff instead of destroying their brain and environment with LLMs. Especially a Forth is really doable.
Fuck umbrellas, people should focus on actually enjoying swimming and being at the beach, instead of destroying the environment by eventually throwing away their umbrellas.
React (and the unidirectional FRP approach in general) is the only known sane way to describe complex GUIs. It's the same approach that powers spreadsheet calculations.
Most websites are not complex GUIs though, and do not need React.
It's not "the only known sane way". In many cases, it's not even an appropriate approach! MVC, PAC, and self-contained widgets which make asynchronous calls to an API surface, are perfectly cromulent alternatives, each with their own strengths, but I've yet to see a situation where React was actually the best way to go.
React is very different from dataflow computation - it rebuilds a component subtree upon a property update; it also doesn't quite understand what "property update" means because it's defined on top of JS semantics. It's a hodgepodge of leaky abstractions and outright insanity.
I've been making GUIs (among other things) for 25 years, including 12 years using React, so you don't need to tell me how amazing it is. There's nothing particularly wrong with using React for rendering (although there's a whole lot of gotchas), the real problem is when people use React hooks for business logic - that's like you decide you need to fetch something in a middle of rendering screen.
I've found Claude Code with Opus 4.5+ to be excellent at generating test cases that exercise the different features, and even push into the edge cases. You sometimes need to nudge it into generating more convoluted cases when necessary, but then it is just nudging. I now routinely generate more LOCs of test cases than actual core code, while I used to only write very limited test cases just for the most complex areas amenable to automated testing.
I've been successful at using Claude Code this way:
1. get it to generate code for complex data structures in a separate library project
2. use the code inside a complex existing project (no LLM here)
3. then find a bug in the project, with some fuzzy clues as to causes
4. tell CC about the bug and ask it to generate intensive test cases in the direction of the fuzzy clues
5. get the test cases to reproduce the bug and then CC to fix it by itself
6. take the new code back to the full project and see the issue fixed
All this using C++. I've been a pretty intensive developer for ~35 years. I've done this kind of thing by hand a million times, not any more. We really live in the future now.
Not really: burstable (“t”) instances haven't been updated in years. The current generation (“t4g”) still use Graviton2 processors. I get the impression that they would vastly prefer cost-conscious users to use spot instances.
Ah, thank you for pointing these out! I'd missed the introduction of “flex” instance types (apparently in May last year[0] – still long overdue relative to the introduction of T4g in September 2020[1]). Curious that so far, they all appear to be Intel-based (C7i, M7i, C8i, M8i, and R8i). M7i-flex instances also cost 45% more than the corresponding T4g instances. That's sort of understandable, as the generational improvements probably bring more than 45% better performance for most workloads, but it also makes them harder to justify for the sorts of long-running,-mostly-idle duties they're being touted for.
If you're interested in the underlying technology of flex there's some reinvent talks from last year on YouTube where they acknowledge it's based on VM live migration which is I think the first public reference to AWS using migration in their products.
I suspect the burstable types were always priced too cheaply and were more about attracting the cheap market segment which they don't need now in the days of AI money.
Burstable pricing gets complex quick when adding in the option to burst to full usage. Flex seems a lot simpler which is great.
Not really. The article was written 10+ years ago, saying that one cannot use Forth in commercial products, yet Forth Inc. and MPE are still in business.
He is no Jim Keller, and the mostly[1] automated transcript makes it read cringe, but it is not at all devoid of content.
Some examples of very interesting, non-obvious content:
* Even if store ports are kept fixed (2 in his example), adding store address generators (up to 4 in his example) actually improves performance, because it frees up load port dependencies.
* Within the same core, they use two different styles of load/address address contention mechanisms which he describes as two tables, one with explicit "allows" and the other one with explicit "denies" -- which of course end up converging (I understand it refers to two different encodings which vary in what is stored).
* Between cores, they have completely separate teams which reach different designs for things like this.
* It was interesting to me to discover how isolated the different core design teams work (which makes sense)
* It was interesting to me to picture the load/store address contention subsystem, which must be quite complex and needs to be really fast.
And I stop listing, re different types of workloads, gaming workloads being similar to DB workloads, and even more similar between them than to SPEC benchmarks and so on.
Just go read the interview if you're interested in CPU design!
[1] mostly automated: at least the dialog name labels seem to be hand-edited, as one of them has a typo
Oops, sorry about carelessly throwing the "cringe" label at that. Thanks for the transcript which allowed me to enjoy the content, which I did find very interesting.
I haven't watched the video so I am not sure how he actually talks, but what read cringe to me was things like the following paragraph:
"Stephen Robinson: Yeah. So let’s, let’s break it down into address generation versus execution. So, when you have three load execution ports, you need three load address generators. And so that’s there. On the store side, we have four store address generation units. But we only sustain two stores into the data cache."
Which reads weird. "let's" repeated twice, probably a stutter, could be transcribed just once. The "So" or "And so" the interviewee uses all the time at the start of sentences can also be removed for clearer and easier reading most of the time, without loss of meaning. Some sentences can almost be removed completely as they provide no actual information. The previous paragraph could be transcribed like this:
"Stephen Robinson: Let’s break it down into address generation versus execution. When you have three load execution ports, you need three load address generators. That’s there. On the store side, we have four store address generation units. But we only sustain two stores into the data cache."
I hesitate to remove "That's there." so I left it. But everything else I removed, it makes it clearer, and I think I'm not being unfaithful to the original. Removing the duplicate "let's" is a given as it's normal to stutter when speaking, but you don't really want to transcribe that unless the goal is to transcribe the talking imperfections we all have. And all the other things I removed, "Yeah", "So", "And so", are basically the same type of thing.
I thought this was automated because it had so many of the meaningless go-to words and hesitations from the original. Now that you mention it, automated transcription would probably never have produced something this good. And otherwise we are talking about stylistic preference here, always subjective -- although I'd definitely prefer the style of transcription suggest here.
Thanks again. I read chips and cheese with interest, quite often, and enjoy it quite a lot. Keep up the good work. And sorry for the careless put-down.
You're right the things you list do contain fresh information. Though the similarity between game logic and business logic is not a new observation ... and web browser in the same ballpark too. I think it's a code size vs data size thing. SPEC programs mostly have a relatively small amount of code, gcc being an obvious exception. And I guess Blender in 2017 FP.
The white keys form a sequence of notes (frequencies) that is known as the diatonic scale. It's the foundation underlying all popular western music. It is not random or arbitrary, it has some nice dual mathematical and musical properties: intervals between the notes in the scale have special frequency ratios that sound pleasing to the ear (read Helmholtz's "On the sensations of tone" for a fascinating physically-based take on why it is like that -- he is known as "the father of acoustics", and that book contains the distillation of 8 years of deep, smart research way before we had the means or understanding we hav today). A ton, if not most, of popular music can be played using only the white keys.
There used to be keyboards with other different arrangements, which were actually extremely cumbersome and actually didn't allow very rich and interesting musical excursions like modulations (look up "microtonal keyboards"). Today's standard keyboard and tuning is a compromise between those fundamentally mathematical and perceptual acoustic relations (the tonic, the fourth, the fifth, the sixth, the major and minor third, the "sensible" or subtonic...) and the ability to perform those trans-tonality excursions. A fully regular keyboard like you propose would lend itself more easily to those excursions, at the cost of being less apt at the foundational diatonic model and most popular music.
Interestingly also, the notes used by modern keyboards and all modern instruments, and to which we are all so accustomed that we thing it "just is", is an imperfect compromise that needed a lot of selling back in the day, much of which was done by Bach (the compromise scale is called the "tempered scale", and Bach authored the arch-famous "Well-tempered clavier" pieces to show it off -- impossible to perform on keyboards with other tunings).
And of course, there is a tradition factor. English isn't written like this because it's optimizing for any easily describable or measurable optimization metric, more like it minimized a socio-perceptual function covering many centuries of UX.
Finally, if you want an instrument where all keys are equal, you can always move to a fretboard based one like the guitar. Funnily, it has a one-semitone-short jump between strings 3 and 2 that will throw off the desire of full regularity... again due to diatonic leanings. A bass guitar is fully regular, even when they add a 5th and 6th string, so that may fulfill your wish of a fully regular instrument... and it sounds awesome! Just can't do the same things as a piano or a guitar.
I agree, the white keys on a piano represent a diatonic scale, but because today’s pianos are rarely tuned to anything other than 12TET, there are few interesting mathematical relationships between notes in practice (and pianos are normally tuned with high notes sharp and low notes flat because that’s how piano strings tend to produce their partials anyway).
Also worth noting the black keys represent a major pentatonic scale and the major pentatonic scale is how many of the earliest bone flutes are tuned.
>Interestingly also, the notes used by modern keyboards and all modern instruments
Vast majority of fretted instruments since the death of the lute are untempered.
Edit: Which is not to suggest that lutes were tempered. Lutes and other tied fret instruments allow for unequal fret spacing so you can temper one string at the cost of more notes being more off from the temperament on other strings, or the frets being at an angle so you could find a bit of a compromise. But often they were EDO or in the ancient tradition of fretted instruments, close enough for rock and roll.
I never heard someone describe a tuning system as "untempered", but I guess it would mean something like just intonation -- which sounds really great for playing anything in a specific key but falls horribly apart if you try to change the key (which is why it has seen very little use since the renaissance).
Equally divided octave (EDO) with no tempering which is distinct from Equal temperament. Tempered scales are generally EDO with tempering. Other methods like just intonation don't really need to be tempered and generally are not in my experience, but it has been years since I was into just intonation and may just not remember. Historically speaking, the advantage of justly tuned scales is there is no need to temper it because it is already just and perfect, things may have changed in 20th century as far as just intonation is concerned and tempering, don't recall.
Edit: ET and EDO are essentially the same in the case of most fretted instruments, I am dredging long forgotten stuff from memory here and somewhat off above.
Edit2: Refreshing my memory some and seeing how much things have become muddled in my head over the years. Clearly I did not even consider what came out of my memory and just regurgitated it verbatim. ET scales are not tempered but do not mean EDO. Guitar and the like are both ET and EDO. ET and EDO are untempered in the sense that notes are not shifted slightly away from the EDO/ET as they are on the piano and many instruments.
I don't see how you can divide the octave equally and not end up with equal temperament: that's exactly what equal temperament is!
> Tempered scales are generally EDO with tempering.
That's not historically accurate. EDO wasn't used until very recently (about the middle of the 19th century I think), tempering was used way before that.
For example, the first widely used temperament (which became popular in the Renaissance) was the quarter-comma meantone, which shrinks each fifth (from the natural 3/2) so that the major thirds are perfectly 5/4. The name "quarter-comma" means that the amount of shrinkage is 1/4 of the "syntonic comma", which is the difference you get beteween going up 4 fifths (e.g. C->G->D->A->E) and a major third plus 2 octaves (C->E->E->E). Those final Es can only be the same if you shrink the fifth or stretch the third (or both). What this tempering does is shrink each fifth by 1/4 of the difference (so that going up 4 fifths closes it) and doesn't touch the major third. That means the major thirds are beautiful, and the fifths are a little off. For a chosen key, that is -- everything sounds horrible as soon as you try to change the key too far away from the chosen key.
In the Baroque period a lot of other temperaments were invented, the Werckmeister temperaments were very widely used in (what is today) Germany for example (a lot of people believe Bach had one of these in mind when writing the Well-Tempered Clavier). Those temperaments were also defined by how much each fifth is changed from the "normal" 3/2, but each fifth was to be changed by some different amount in some complicated way.
It was only much later that EDO (12-TET, or "equal temperament") started to be widely used. You can think of it (and people do!) as a "temperament" because it just means you shrink the fifth from the "normal" 3/2 = 1.5 to be instead 2^(7/12) =~ 1.4983, so that going up 12 fifths lands you exactly 7 octaves above (since 2^(7/12)^12 = 2^7). That also means that the octave is divided exactly equally, because going up 12 fifths goes through every one of the 12 notes before going back to the original note.
EDO on fretted instruments goes back to at least the 16th century and was essentially the standard well before the mid 19th. Equal temperament is an EDO scale whose divisions approximate justly tuned scales. The western 12TET scale is not actually 12TET or 12EDO, we temper the scale itself and tweak some notes to make it work better unless you play fretted instruments and then it is up to the guitarist to make small adjustments in their playing technique so their untempered 12TET is in tune with the pianos tempered 12TET.
> The western 12TET scale is not actually 12TET or 12EDO, we temper the scale itself and tweak some notes [...]
I think you and I must be using words differently. To me (and to Wikipedia, and everything else I've ever read, including[1] which I just consulted to make sure I'm not crazy), 12TET is a way to specify by how much you have to multiply the frequency of the first note of the scale to get the other notes' frequencies. Wikipedia[2] has a table with the numbers for 12TET (the column "Decimal value in 12-ET"), but it's very simple: you just multiply the value of the preceding note by 2^(1/12). If you take 12TET and adjust/change the notes a bit, then it's not 12TET anymore.
> EDO on fretted instruments goes back to at least the 16th century
I'd love to see a reference for that. I just consulted [1], it has a chapter called "Non-Keyboard Tuning" and it doesn't mention that (although admittedly it spends most of its time talking about violin, with a ton of references to stuff that Mozart said). The book does say that equal temperament was known for centuries before it was used, but the people who first discovered it simply didn't think it sounded good.
[1] "How Equal Temperament Ruined Harmony (and Why You Should Care)" by Ross W. Duffin
Try the wikipedia pages for Equal Temperament and Musical Temperament, they explain all of this.
Here is a 1688 Stradivari[1] guitar with fixed frets and a EDO octave, they were reasonably common by that point. Much of the information regarding this is looking at the fixed frets that many lutes and guitars had applied to their soundboard and comparing that to how composers used those fixed frets, either the tied frets adhere to the scale of the fixed frets or they are out of tune. The history of EDO/ET in fretted instruments goes back to at least Vincenzo Galilei[2] (father of Galileo) who developed the rule of 18 for fret spacing. If memory serves we have a few early steel string instrument (cittern, bandora, orpharion) from around ~1600 with equal spaced frets and this orpharion[3] looks it but it is difficult to tell from that photo. Going back earlier things get more difficult since we have so few intact and unaltered instruments but we do have a fair amount of ingravings and art plus writing on the topic such as Galilei's.
There is a paper going into great depth on all this that is just out of reach in my memory and I can't seem to trick the search engines to give it to me, I will post it if I remember/find it. No time to dig more right now.
If you remember and have the time, please do! (And thank you for the links you already posted).
I see now that everything I read about this was way too focused on keyboard and violin, since I had never heard any of this about fretted instruments. I'm glad I get to correct a bit of my understanding, so thank you. Now I'm left wondering about wind instruments.
Western theory is focused on the keyboard with violin as second fiddle, the rest of the instruments do their own thing unless they are forced to kowtow to a piano or violin. Each instrument is ultimately tuned to the physics which dictate how it makes sound and this is part of why our tempered 12TET works and why we see the rise of the big orchestras of unlike instruments with the move away from meantone, it provides a compromise which works quite well for all instruments with the exception of the brass (with the exception of the trombone) who are forever out of tune (sort of).
Part of the reason beginners sound bad is because most instruments have to bend notes to be "in tune," I can teach anyone to play a chord on the guitar and get them having each note sounding clearly in a couple of minutes but my DMaj will sound better than theirs simply because I have played that DMaj thousands of times and my fingers have learned to adjust the pressure on each string in just the right way to make it sound "right" just as the woodwinds learn to bend certain notes and the brass learns to live with being out of tune.
Also part of why the lute became such a dominant instrument is that it could retune in ways other instruments can not, which was a major advantage for the working musician back in the days when every city had its own idea about tuning; nudge a few frets, retune a few strings and accept that certain notes were now out of bounds and you could play with anyone like you were playing in your native tongue. As tuning became more standard the lute started to die.
Meantone Temperaments on Lutes and Viols might be of interest to you, it is aimed towards lutenists and violists but has some more general stuff as well and I think does a good job of showing the compromises the lute (and viol) had to make in moving away from equal temperament.
I don't really think brass is forever out of tune, I love the brass and used to play trumpet but the brass section is more under the influence of the physics of its instrument than anyone but the pianist but the pianist is "in tune" because western theory is built around the keyboard.
To offer something better than this mess and correct. Fretted instruments are tehnically unequally tempered do to the physics the string, the fret board is EDO but in fretting the string we stretch it and raise its pitch. Fretted instruments use various compensation tricks to lessen this effect but most notes are off from both 12EDO and 12TET, we get the open string and the 12th fret but the rest are off by varying amounts.
Thank you for offering something clearer than the mess I made. Been 25 years since I studied this stuff and finally learned to just accept (and love) the modern standard.
Such a needlessly negative article. PCIe 5.0 is early, peripherals are scarce-to-non-existant, and existing rigs are not infinitely flexible. Otherwise, it all looks pretty good to me. Even buying one of those may prove worthwhile as new graphics cards and SSDs are released.
I'm so grateful to him, his early work was a massive influence for me as a kid. I lent one of Dewdney's books to a neighbor friend's dad, an architect, and he gave me my first paid gig as a programmer. Can't overstate the influence in my career.
Also, I distinctly remember his column showing how to generate text based on statistics learned from an existing corpus. It has come to mind more than once in this last period of LLM magic -- the essence was already there.
