4 ms·

> Make each application one file. [...] Make the operating system one file. Yes and yes! That's actually exactly what I've been working on with Actually Portab

by jart 6y ago

> Make each application one file. [...] Make the operating system one file. Yes and yes! That's actually exactly what I've been working on with Actually Portable Executable. https://justine.storage.googleapis.com/ape.html https://justine.storage.googleapis.com/ape.html > How could we simplify: Write a GUI bootloader Nooo. There's the problem. GUIs have always been a shitshow w.r.t. compatibility. I've pretty much come to the conclusion at this point that, if we want simple, we have to give up on wanting it with GUIs. Vendors just aren't going to ever agree. There's too much vision and financial incentive to compete. However terminals, are boring, and operating systems no longer have any reason to engineer incompatibilities. As of last year, they've all pretty much been like, yeah, we'll implement vt100 because we don't care anymore. Even Windows CMD prompt! It's great. This new consensus is going to make so much toil go away. For example, here's an app I wrote a few months ago. It's a single file TUI application. The binary runs on all the different operating systems and looks exactly the same. Truly build-once run-anywhere. It literally looks the same on Linux as it does in Windows command prompt and Mac too etc. It doesn't have any dependencies. It's about 200kb. https://justine.storage.googleapis.com/blinkenlights/index.html https://justine.storage.googleapis.com/blinkenlights/index.h... I've been using it lately testing tool, because I want these single file programs to boot from BIOS on bare metal too. I've got it working for stdio so far. So once I add a virtio ethernet driver it'll be golden. Especially for cloud deploys. Every program you compile is its own operating system which runs on all the other ones too. I call it the Cosmopolitan C Library (NOTE: this page is work in progress!) https://justine.storage.googleapis.com/cosmopolitan/index.html https://justine.storage.googleapis.com/cosmopolitan/index.ht...

causality0 6y ago
For me that would be exactly opposite of the direction I want things to go. I want more files and more editability. I want to be able to track down the audio file for that godawfully loud "CLANG!" sound Google Assistant makes and tear it out by the roots, then print it out and burn it for good measure.
- wtallis 6y ago
  The NeXTSTEP/Mac solution is to make the GUI treat application bundles as a single unit, while behind the scenes they're a transparent, self-describing directory hierarchy.
  - AnIdiotOnTheNet 6y ago
    Even on the original MacOS there were utilities to allow you to examine and edit the resource fork of an application.
cmroanirgo 6y ago
> GUIs have always been a shitshow w.r.t. compatibility. I completely agree with your assessment that vendors will never agree on a common GUI toolkit. However, if one were to think about it, anything shown on the screen is a gui of sorts. It's just that text mode was long ago standardised with the use of ascii and the corresponding cga/ega/vga drivers. > Before 1963, computer manufacturers had over sixty different ways of representing characters in computers. Machines could not communicate with one another [0] There were some wild inconsistencies with the different display drivers back in early days. It's just that no one seemed to want to standardise on renderable gui elements afaik. Every platform has redesigned the wheel, so to speak, giving us the mess we've always had. It'd be interesting to see hardware level support for UI elements, but as you suggest, we're probably too far down the road for anyone to give up their niche GUI library. [0] https://ethw.org/ASCII https://ethw.org/ASCII
- jart 6y ago
  Yeah it's pretty old. Textmode interfaces began with the teletypewriter in the nineteenth century and UNICODE began around that time too. The programming interface for these machines wasn't standardized until the 1960's with ASCII, which was extended a decade later by ANSI X3.64-1979, and then again in the 90's by UTF-8. That's the trifecta of textmode definitions which, only as of these last few years, became basically universally supported. CGA is kind of just a uint16_t[20][80] array for personal computers. See also: https://github.com/jart/cosmopolitan/blob/ea0b5d9/tool/build/lib/pty.c#L40 https://github.com/jart/cosmopolitan/blob/ea0b5d9/tool/build... You're absolutely right that the inconsistencies with textmode used to be about as awful as the inconsistencies we see with GUIs today. I'm certain things will get better if we consider that GUIs are a relatively recent invention by comparison. So it'll probably take another fifty years for widget authors to forge out a consensus that's as good and widely supported as the one we have now for terminals.
szc 6y ago
A source of inspiration for good ideas might be had by looking at how early computers worked and handled this. My understanding, from stories my parents told (both of whom were active in early computing), is those from the 1950s and 1960s that used punched cards and paper tape. Common routines would be included as a deck of cards or spliced paper tape.

by jart 6y ago

causality0 6y ago

For me that would be exactly opposite of the direction I want things to go. I want more files and more editability. I want to be able to track down the audio file for that godawfully loud "CLANG!" sound Google Assistant makes and tear it out by the roots, then print it out and burn it for good measure.

wtallis 6y ago
The NeXTSTEP/Mac solution is to make the GUI treat application bundles as a single unit, while behind the scenes they're a transparent, self-describing directory hierarchy.
- AnIdiotOnTheNet 6y ago
  Even on the original MacOS there were utilities to allow you to examine and edit the resource fork of an application.

cmroanirgo 6y ago

> GUIs have always been a shitshow w.r.t. compatibility. I completely agree with your assessment that vendors will never agree on a common GUI toolkit. However, if one were to think about it, anything shown on the screen is a gui of sorts. It's just that text mode was long ago standardised with the use of ascii and the corresponding cga/ega/vga drivers. > Before 1963, computer manufacturers had over sixty different ways of representing characters in computers. Machines could not communicate with one another [0] There were some wild inconsistencies with the different display drivers back in early days. It's just that no one seemed to want to standardise on renderable gui elements afaik. Every platform has redesigned the wheel, so to speak, giving us the mess we've always had. It'd be interesting to see hardware level support for UI elements, but as you suggest, we're probably too far down the road for anyone to give up their niche GUI library. [0] https://ethw.org/ASCII https://ethw.org/ASCII

jart 6y ago
Yeah it's pretty old. Textmode interfaces began with the teletypewriter in the nineteenth century and UNICODE began around that time too. The programming interface for these machines wasn't standardized until the 1960's with ASCII, which was extended a decade later by ANSI X3.64-1979, and then again in the 90's by UTF-8. That's the trifecta of textmode definitions which, only as of these last few years, became basically universally supported. CGA is kind of just a uint16_t[20][80] array for personal computers. See also: https://github.com/jart/cosmopolitan/blob/ea0b5d9/tool/build/lib/pty.c#L40 https://github.com/jart/cosmopolitan/blob/ea0b5d9/tool/build... You're absolutely right that the inconsistencies with textmode used to be about as awful as the inconsistencies we see with GUIs today. I'm certain things will get better if we consider that GUIs are a relatively recent invention by comparison. So it'll probably take another fifty years for widget authors to forge out a consensus that's as good and widely supported as the one we have now for terminals.

szc 6y ago

A source of inspiration for good ideas might be had by looking at how early computers worked and handled this. My understanding, from stories my parents told (both of whom were active in early computing), is those from the 1950s and 1960s that used punched cards and paper tape. Common routines would be included as a deck of cards or spliced paper tape.