I feel like the idea could be covered by commodore 64. Even adding basic networking in any way opens up an absolutely massive amount of un-abstracted concepts and processes to keep in one head.
That said I flippin love people re-inventing a computer into something not derived from a VAX timeshare machine from the 70s.
The main issue with older machines is that the resolution isn't great for writing. I like reasonable letter shapes, and you kind of need 640x480 for that at least.
Yeah, this was definitely a concern for me when building Mu. What do you think of the one font Mu has? It's http://unifoundry.com/unifont. I was trying to get to some minimum level of legibility while otherwise optimizing for simplicity. 1024x768 seemed like a reasonable compromise, though adjacent resolutions are also fine.
> Unifont only stores one glyph per printable Unicode code point. This means that complex scripts with special forms for letter combinations including consonant combinations and floating vowel marks such as with Indic scripts (Devanagari, Bengali, Tamil, etc.) or letters that change shape depending upon their position in a word (Indic and Arabic scripts) will not render well in Unifont. In those cases, Unifont is only suitable as a font of last resort. Users wishing to properly render such complex scripts should use full OpenType fonts that faithfully display such alternate forms.
So if your intention when choosing unifont was to support all of Unicode, it would be good to make it not too difficult to add more fonts.
I definitely prioritize supporting all languages. (I don't care about flags and emoji and crap like that.) However I don't know enough yet. The current list of supported languages is enumerated at http://akkartik.github.io/mu/html/103glyph.subx.html#L98
It's not just a matter of supporting more fonts. I need to support smarter fonts with ligatures and more. I think we could preserve the constraint of a single font and just make it smarter. But it'll take me some time to learn enough to do that.
E.g. you list Myanmar, where it's possible to construct something like င်္င္င္င္ငြေေေေေေေောာာာာာာာ, which has "nga" င, "asat" ်, "virama" ္ combined to put င်္ on the following consonant, which in this case is four "nga" င separated by three "virama" ္ to form a cluster င္င္င္င (Noto Sans Myanmar apparently supports stacking up to height 3, the fourth "nga" င awkwardly overlaps), then there's a "medial ra" ြ which puts a box around the preceding consonant without overlapping, then 8 copies of "e" ေ which should be rendered to the left of the consonant it follows and then 8 copies of "aa" ာ which attach to the right.
You're not going to encounter something crazy like this in the wild (in Burmese, there's at most one of each vowel sign on a consonant, and I don't think stacking four consonants is ever necessary) but it serves as a demonstration of the edge cases that a font needs to handle. The lookup tables end up getting quite large, which I think is one of the reasons Noto isn't usually used as one file with all scripts.
Yes, the vowel diacritics are definitely an issue. I'm familiar with Hindi and Tamil. Hindi's _matras_ are pretty regular, and Unifont is designed so you can just type a single diacritic in the same spot as a consonant and have the thing look right (albeit terrible).
Tamil, however, doesn't have this property. Does Myanmar?
At the moment a single diacritic is the extent of my ambition.
There are vowel signs that attach to the left, right, top, bottom or wrap around the preceding consonant. You could maybe emulate it by manually placing characters into a grid, but that would be very much not Unicode.
Anyways, if you could get Tamil to work with a generic approach, I guess most of the edge cases for Myanmar would be covered by that as well. (Edit: seems like Tamil only has at most one diacritic, so it would have to be more general for Myanmar still.)
I actually use a slightly modified unifont exclusively on a linux system, deleted all other fonts, disabled browser font downloading, and use firefox to get proper rendering. If you use a tiling wm, without borders or spaces between windows, then three windows of 80 columns of 8x16 font works.
sorry for the late reply, also forgot to mention that I use a fontconfig file, .xresources, other config files for i3 (the tiling wm), termimal (xst) and vim that specify the unifont font specifically.
Unifont seems very useful. Not pretty but definitely legible.
- - - -
FWIW, I ran across this the other day: "4x4 ASCII Font"
> Small fonts have always been fascinating to me, so I decided to make the smallest font possible, which turned out to be 4x4 pixels per character. The font covers the entire range of visible ASCII characters, and most are immediately recognizable.
For display from small machines I keep going back and forth between simple memory-mapped raster screens vs. emitting a stream of, say, SVG to an external "display processor" (following the "Wheel of Reincarnation": "On the Design of Display Processors" http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland... )
Unifont is perfectly fine. Linux uses it in various places, so I don't mind it. In fact, I rather like its letter shapes.
1024x768 is more than reasonable. Almost luxurious in a "small"/"personal" computing context, but in a good way. I still use computers with that resolution sometimes.
You can start with the C64 definition as a base and rewrite it expanding it (e.g. instead of 40x25 cells, 320x200 pixels on 1000 bytes pointing to 8x8 sized chars, you could provide a similarly working mode but 120x64 cells, 1920x1024 pixels on 7680 bytes pointing to 16x16 sized multicolor chars). Have four SID instead of one, 64 sprites, use a large number of switchable 64Kb regions as modules (and/or a huge disk in physical RAM) etc. You can just take inspiration from the original and see how the traditional ideas could be adapted for current hardware.
Yes, it reminded me a lot of when I first started in computing. Today we are so abstracted from the horsepower that produces our experiences, to the extent that most Software Engineers don't actually know how their code works. Not saying that is a bad thing, not saying that it is mandatory, it's just an art and science that is eroding rapidly.
I started as an 8yr old, reading computer magazines, and initially coding in BASIC in 1K of RAM. I into Z80 Assembler and Machine Code at 10yrs - learning primitives like NMI's, Display DMA and Sound IO by hand with pencil, paper, and lots of reboot-causing mistakes. It was bruteforce, but still very influential in my understanding of a then-modern computer system.
Z80 was a simple-enough chip instruction set that I still remember most the mnemonics today, and many of the architectural principals are still valid even after so much time.
> most Software Engineers don't actually know how their code works.
This is only true when you decide that the specific level of abstraction that you learned is the important one.
Sure, you knew the machine code. Did you know how the instruction set was implemented on the chip? The decode logic at a transistor logic to set the right signals to route your register to the ALU? Did you care about the equations that governed the flow of electrons through silicon?
Or did you trust the machine code to be your level of abstraction that Worked?
The world isn't as black and white as "all abstractions bad" or "all abstractions good" though. There are levels of abstraction that are objectively useful and levels of abstraction that are so separated from reality that a 3Ghz multicore computer is somehow incapable of keeping up with a human's typed input.
And the level of abstraction that is "good" changes over time and by use case. At my day job, I write both high-performance bioinformatics software and good-enough-performance web software. I do need to look at the assembly & think about the internals of the CPU when I'm trying to push through billions of reads in a timely manner. But I don't need to count cycles when I'm rendering a CRUD detail page in Django - I just need to make sure my database queries are reasonable.
Also, the idea that you can say some abstractions (presumably in wide use) are "objectively" bad only makes sense if you've already applied your subjective criteria.
You can slightly the alter the claim to "most software engineers don't actually know how their code works at a level that's relevant for them to make good software" and it becomes solidly true.
Most (web) software engineers don't know anything about assembly, CPU cache, virtual memory, or pipelining, and application of knowledge of those things would change web applications from their current abysmal levels of performance to something acceptable.
Very, very rarely is knowledge of the microarchitecture, microcode, transistors, or physics necessary to make modern software reasonably correct and performant.
Most software engineers aren't working on something that needs knowledge of CPU caches to reach performance goals. Especially (web) engineers. You can write performant javascript for years without even knowing that CPUs are pipelined, let alone the details.
Most of the few software engineers that make their living writing code that needs to be fast, do know the things they need to know to make the code fast.
I don't agree even with your altered claim. Most software engineers do know how their code works at the level that they need into order to make good software.
Oh, that last paragraph. Are you saying the way the world writes software is totally fine? You're entitled to your opinion, but I think that's too big a chasm to bridge in this text box :) I'll just say this: one pattern shared by the best programmers and systems thinkers I've met is that they took the trouble to look under the hood. I really consider this to be a non-saturating metric. The more someone looks under the hood, the better a programmer and systems thinker they are.
> Most software engineers do know how their code works at the level that they need into order to make good software.
This kind of thinking is why we can't have nice things!
If this were true we would have good software. As the world (currently) exists, we have a vast ocean of horrible software with a small number of islands of quality.
I'd argue "most" software engineers don't know enough. The fact that checking my bank balance online involves transferring 32 million bytes of information(!!) over nearly a third of a minute, or that bluetooth headphones have so much latency they're unusable for live music, despite radio waves traveling at the speed of light, or... any app written in electron, ever (or pick any other example of stuff sucking in modern life, it's ubiquitous)... these are all a result of engineers knowing way, way too little about how their stuff works.
Most people, including engineers, are idiots, slapping together components and using abstractions they have NO understanding of, stopping at an increasingly low bar of acceptability. (I make no claim to be special or otherwise a "non-idiot".)
correction: 5 million bytes of information, not 32. but still at least 4.9 million bytes too many.
> I'd argue "most" software engineers don't know enough. The fact that checking my bank balance online involves transferring 32 million bytes of information(!!) over nearly a third of a minute...
... these are all a result of engineers knowing way, way too little about how their stuff works.
The problem is that everyone has a different definition of "too much". Despite programming as a kid and now working on edge networking software at $TRENDY_CORP, I studied signal processing, distributed systems, and higher level math. I used to spend a lot of time with hardware. I knew layout engineers who used to scoff at hardware engineers that didn't know that their logic was going over the timing budget, hardware engineers who would scoff that folks writing firmware/embedded code didn't understand that their code didn't use the instruction pipeline correctly. Kernel developers who scoffed that OS developers didn't understand how kernel IPC works. And the list goes on.
The state we're in is only here because this is what the market is willing to tolerate. If you're designing the AV system for heads of state or the CEO of a large tech company, or maybe even a big esports competition, then you'll probably spend all your time optimizing for latency and jitter. If you're processing large amount of non real time data, you'll probably end up optimizing for throughput. Industrial control software usually has access to low-latency low-bandwidth links and need to work unattended for months at a time. Hardware that goes to space must be redundant and radiation hardened. Software has eaten the world, so if you're willing to take a pay cut and maybe get drug tested by your government, you'll have no trouble finding jobs with a different set of customer requirements.
The fact is, the modern internet is optimized for throughput and modern web apps are optimized for average user experience and ad revenue. Engineers working on net technologies are trying to push more through the pipe, latency be damned, because few people care about anything else. Most web developers are just trying to make their software usable enough to enable use of their product and ad revenue because very few people care enough to offer a market to these conpanies. At web startups you're struggling to make _anything_ and find anyone who's willing to pay you, let alone optimizing for some metric like latency. If you don't like this work, there's lots of fields that pay less but have different problems. You could work on MPLS VoIP networking to enable low-latency voice chat. You could work on high-throughput data transfers for research institutions to share sensor/telescope data. Avionics software has its own interesting challenges.
Personally, I'm knowledgeable and have a nerdy fixation on low latency, so I have a network of low latency services for my friends and family (along with a companion high latency high throughput set of services for bulk things like 4K video downloads). Some of my friends love using it, others like my parents barely understand the difference (except maybe that I'm not breaking up on voice chat as often). I recognize that this is my hobby and my passion but most people just don't care. I'm okay with that. I don't care about a lot of other things in life too that I'm sure somebody else cares about.
Is your contention that web applications are slow due to lack of understanding of CPU cache, pipelining or assembly? Because that doesn't match my experience at all. In my experience, web sites and applications are most often slow due to:
1. Indiscriminate use of third-party scripts and network connections, particularly for marketing cruft such as ads, analytics, and trackers.
2. Pulling in large blobs of code, particularly frameworks, because it makes things easier.
3. Back-end issues, particularly distributed monoliths disguised as microservices, delaying time-to-first-byte by 100s of milliseconds.
4. Lack of awareness of the latency and bandwidth characteristics of real users' devices.
Other reasons, too, but these are some big ones. Understanding CPU cache, virtual memory, etc. is way, way down the list, and certainly wouldn't "change web applications from their current abysmal levels of performance."
I would venture that most people who started programming back then were familiar with basic digital circuitry like adders and latches, so probably, in the sense that you might know how an engine works without being able to build one from scratch. RadioShack still sold electronics components. My early 80s alarm clock came with a full schematic.
Thanks for sharing Urbit, it's super interesting...
...and it's also awful.
I get sad when I see an idea that I like implemented to poorly. It sucks oxygen out of the room, or poisons the well, or whatever.
I think I basically want Deno with a decentralized ID / DNS system that has nothing to do with the hierarchy or Urbit... And using capability modeling for different apps... And with something like Wire Guard for end-to-end encryption... That feels like a federated version of Sandstorm.io...
Perhaps I should rename the registers to generic r1-r6. The trouble with automatically allocating registers is that you sometimes need to spill. And that means instructions need to work with either registers or memory. That feels like a very different kind of language, closer to C. You lose the largely 1:1 mapping with machine code that I was aiming for. Code generation gets more complex -- and my whole goal was to implement it in unsafe machine code (the SubX notation) and avoid metacircularity. Instead Mu makes you allocate registers -- but verifies your allocation so you have a reasonably decent experience.
I want a software stack an application developer (me) can fully understand. I don't want it to depend on a heavy opaque runtime obscuring control flow, requiring both native and VM-level debuggers, and resulting in unpredictable performance (Java/C#/JS). I don't want it to rely on GPU APIs, which expose hardware and driver implementation details (making software behave differently on different computers, and even malfunction on some hardware or with the wrong drivers installed), and lose support on newer hardware (you can't play Touhou 6 without a DX8 emulator). I don't want deep dependencies on heavyweight OSes and daemons and IPC (D-Bus desktop portals and drag-and-drop keep malfunctioning, playing Touhou or running Japanese software requires juggling Windows app locale emulators). I don't want heavyweight apps built on thick GUI frameworks or sprawling OS APIs, resulting in apps which can't run on OSes 10 years in the future (since they're missing GTK2 or Qt4 or WPF, or have an incompatible libstdc++), and also can't run on bare-metal emulators unless you install the full OS.
Maybe Mu is it. I don't know. My concern is that low level code with manual register allocations is too unproductive, and even C (not to mention C++ or Rust) is complex enough that I don't know what the compiler is doing at -O2, with or without TBAA, with or without restrict, etc.
Is it even possible to get a small understandable stack, and full Unicode support, OS-like text editing and keyboard shortcuts, system fonts, system font rendering and fontconfig, tab navigation to jump between widgets, maybe even OS file dialogs and accessibility? Lagrange is a Gemini client which depends on not much more than SDL (good), but doesn't use OS fonts rendering and text editing (bad).
It's hard. Building Mu has given me more of a flavor for just how hard it is. Some limitations of Mu:
* It still requires firmware. There's a whole lot of C down there. How deep do you want to go?
* No mouse. This is just my own ignorance. I can't get the damn IRQs and interrupts figured out.
* Doesn't work yet on real hardware. I live in Qemu. Debugging that is a whole new set of skills I need to learn.
* No networking, almost no persistent storage. Mu has a very simple and slow driver for ATA disks, but that probably won't suffice on most real-world machine configurations. There's 0 network drivers right now. I probably need a dozen to get any sort of coverage.
The stuff you mentioned around graphics and OS file dialogs, that feels easier once you're willing to put up with constraints like Mu's 1024x768 and so on. But yeah, there's major challenges on this road.
Partly due to these challenges, I've actually started to hedge my bets and make some compromises. My new project is https://github.com/akkartik/teliva which doesn't try to eliminate C, just minimize it. Linux kernel, libc, Lua (12k lines of C), some libraries for https. A gemini client is actually on my todo list there. I think I have everything I need to build it.
I was certainly aware of unikernels (on a pretty superficial level) when I started Mu. A shared goal is minimizing attack surface. However, Mu also has a second goal: minimizing the build time supply chain and making it more auditable. There Mu has more in common with http://bootstrappable.org which is building https://www.gnu.org/software/mes. In service of this goal I've ended up leaving all C behind.
As I understand it, unikernels want to let you bring your own application sources, and try to compile it to their substrate. Mu requires you to build your application for it. There's no compatibility with anything beyond the x86 instruction set (and Unicode).
That's real neat. It sort of reminds me of the high level goals of TempleOS. Pining for the days of earlyish microcomputers where you truly owned and could understand the software stack sitting in front of you on your desk.
Suppose someone plans to create a multitasking OS for a z80 based computer lacking memory protection. With the goal of saving memory and to guarantee memory isolation between processes, it is decided that the OS would actually be a byte-code interpreter capable of running multiple programs at the same time.
So, a byte-code must be chosen to the project. Brainfuck is considered at first: it is extremely simple to implement but is rejected because has very little code density. Then, Chip-8 is considered: it is simple to implement and there are many programs and tools already available. Then p-code is looked at, but it is nowhere near as popular as Chip-8 and apparently not as simple to implement. Other vm's are considered but are rejected because they are not simple or not very popular: SWEET16, ijvm and tinybasic.
Now, what is a good choice for such a situation? What is a good byte-code for such an endeavor? Restrictions are: 64kb of RAM not counting graphics or overlays for drivers that can be dynamically loaded, possibility of running 3 to 10 tasks at the same time, with a good balance of code density and performance, easy to implement and possibly with available tools or good example programs?
I've thought along similar lines a lot recently, and I think you end up wanting something like WASM, but without all the design-by-committee that comes with that. Specifically, ditch the parametric instructions, add arbitrary bit-width ints, multiple memories, a way to allocate and free memories, and hints[0]; and make the binary format simpler to parse by removing the completely unnecessary integer compression.
[0] by which I mean the ability to tag functions and variables with an indication of what they're used for so the interpreter/jit is able to replace them with an efficient implementation if one is known to it. For instance, you possibly don't even need float types, just have routines for doing soft-float arithmetic tagged such that the interpreter knows they implement IEEE floating point operations that the processor may be able to handle on its own.
56 comments
[ 3.9 ms ] story [ 111 ms ] threadThat said I flippin love people re-inventing a computer into something not derived from a VAX timeshare machine from the 70s.
> Unifont Limitations
> Unifont only stores one glyph per printable Unicode code point. This means that complex scripts with special forms for letter combinations including consonant combinations and floating vowel marks such as with Indic scripts (Devanagari, Bengali, Tamil, etc.) or letters that change shape depending upon their position in a word (Indic and Arabic scripts) will not render well in Unifont. In those cases, Unifont is only suitable as a font of last resort. Users wishing to properly render such complex scripts should use full OpenType fonts that faithfully display such alternate forms.
So if your intention when choosing unifont was to support all of Unicode, it would be good to make it not too difficult to add more fonts.
It's not just a matter of supporting more fonts. I need to support smarter fonts with ligatures and more. I think we could preserve the constraint of a single font and just make it smarter. But it'll take me some time to learn enough to do that.
E.g. you list Myanmar, where it's possible to construct something like င်္င္င္င္ငြေေေေေေေောာာာာာာာ, which has "nga" င, "asat" ်, "virama" ္ combined to put င်္ on the following consonant, which in this case is four "nga" င separated by three "virama" ္ to form a cluster င္င္င္င (Noto Sans Myanmar apparently supports stacking up to height 3, the fourth "nga" င awkwardly overlaps), then there's a "medial ra" ြ which puts a box around the preceding consonant without overlapping, then 8 copies of "e" ေ which should be rendered to the left of the consonant it follows and then 8 copies of "aa" ာ which attach to the right.
You're not going to encounter something crazy like this in the wild (in Burmese, there's at most one of each vowel sign on a consonant, and I don't think stacking four consonants is ever necessary) but it serves as a demonstration of the edge cases that a font needs to handle. The lookup tables end up getting quite large, which I think is one of the reasons Noto isn't usually used as one file with all scripts.
Tamil, however, doesn't have this property. Does Myanmar?
At the moment a single diacritic is the extent of my ambition.
Anyways, if you could get Tamil to work with a generic approach, I guess most of the edge cases for Myanmar would be covered by that as well. (Edit: seems like Tamil only has at most one diacritic, so it would have to be more general for Myanmar still.)
Wish general computing was more customizable like that...
here are a few images showing the setup and sites using unifont. https://imgur.com/a/5gAZau3
- - - -
FWIW, I ran across this the other day: "4x4 ASCII Font"
> Small fonts have always been fascinating to me, so I decided to make the smallest font possible, which turned out to be 4x4 pixels per character. The font covers the entire range of visible ASCII characters, and most are immediately recognizable.
https://simplifier.neocities.org/4x4.html
- - - -
For display from small machines I keep going back and forth between simple memory-mapped raster screens vs. emitting a stream of, say, SVG to an external "display processor" (following the "Wheel of Reincarnation": "On the Design of Display Processors" http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland... )
1024x768 is more than reasonable. Almost luxurious in a "small"/"personal" computing context, but in a good way. I still use computers with that resolution sometimes.
https://geoffg.net/maximite.html
I started as an 8yr old, reading computer magazines, and initially coding in BASIC in 1K of RAM. I into Z80 Assembler and Machine Code at 10yrs - learning primitives like NMI's, Display DMA and Sound IO by hand with pencil, paper, and lots of reboot-causing mistakes. It was bruteforce, but still very influential in my understanding of a then-modern computer system.
Z80 was a simple-enough chip instruction set that I still remember most the mnemonics today, and many of the architectural principals are still valid even after so much time.
This is only true when you decide that the specific level of abstraction that you learned is the important one.
Sure, you knew the machine code. Did you know how the instruction set was implemented on the chip? The decode logic at a transistor logic to set the right signals to route your register to the ALU? Did you care about the equations that governed the flow of electrons through silicon?
Or did you trust the machine code to be your level of abstraction that Worked?
Also, the idea that you can say some abstractions (presumably in wide use) are "objectively" bad only makes sense if you've already applied your subjective criteria.
You can slightly the alter the claim to "most software engineers don't actually know how their code works at a level that's relevant for them to make good software" and it becomes solidly true.
Most (web) software engineers don't know anything about assembly, CPU cache, virtual memory, or pipelining, and application of knowledge of those things would change web applications from their current abysmal levels of performance to something acceptable.
Very, very rarely is knowledge of the microarchitecture, microcode, transistors, or physics necessary to make modern software reasonably correct and performant.
Most of the few software engineers that make their living writing code that needs to be fast, do know the things they need to know to make the code fast.
I don't agree even with your altered claim. Most software engineers do know how their code works at the level that they need into order to make good software.
This kind of thinking is why we can't have nice things!
If this were true we would have good software. As the world (currently) exists, we have a vast ocean of horrible software with a small number of islands of quality.
I'd argue "most" software engineers don't know enough. The fact that checking my bank balance online involves transferring 32 million bytes of information(!!) over nearly a third of a minute, or that bluetooth headphones have so much latency they're unusable for live music, despite radio waves traveling at the speed of light, or... any app written in electron, ever (or pick any other example of stuff sucking in modern life, it's ubiquitous)... these are all a result of engineers knowing way, way too little about how their stuff works.
Most people, including engineers, are idiots, slapping together components and using abstractions they have NO understanding of, stopping at an increasingly low bar of acceptability. (I make no claim to be special or otherwise a "non-idiot".)
correction: 5 million bytes of information, not 32. but still at least 4.9 million bytes too many.
The problem is that everyone has a different definition of "too much". Despite programming as a kid and now working on edge networking software at $TRENDY_CORP, I studied signal processing, distributed systems, and higher level math. I used to spend a lot of time with hardware. I knew layout engineers who used to scoff at hardware engineers that didn't know that their logic was going over the timing budget, hardware engineers who would scoff that folks writing firmware/embedded code didn't understand that their code didn't use the instruction pipeline correctly. Kernel developers who scoffed that OS developers didn't understand how kernel IPC works. And the list goes on.
The state we're in is only here because this is what the market is willing to tolerate. If you're designing the AV system for heads of state or the CEO of a large tech company, or maybe even a big esports competition, then you'll probably spend all your time optimizing for latency and jitter. If you're processing large amount of non real time data, you'll probably end up optimizing for throughput. Industrial control software usually has access to low-latency low-bandwidth links and need to work unattended for months at a time. Hardware that goes to space must be redundant and radiation hardened. Software has eaten the world, so if you're willing to take a pay cut and maybe get drug tested by your government, you'll have no trouble finding jobs with a different set of customer requirements.
The fact is, the modern internet is optimized for throughput and modern web apps are optimized for average user experience and ad revenue. Engineers working on net technologies are trying to push more through the pipe, latency be damned, because few people care about anything else. Most web developers are just trying to make their software usable enough to enable use of their product and ad revenue because very few people care enough to offer a market to these conpanies. At web startups you're struggling to make _anything_ and find anyone who's willing to pay you, let alone optimizing for some metric like latency. If you don't like this work, there's lots of fields that pay less but have different problems. You could work on MPLS VoIP networking to enable low-latency voice chat. You could work on high-throughput data transfers for research institutions to share sensor/telescope data. Avionics software has its own interesting challenges.
Personally, I'm knowledgeable and have a nerdy fixation on low latency, so I have a network of low latency services for my friends and family (along with a companion high latency high throughput set of services for bulk things like 4K video downloads). Some of my friends love using it, others like my parents barely understand the difference (except maybe that I'm not breaking up on voice chat as often). I recognize that this is my hobby and my passion but most people just don't care. I'm okay with that. I don't care about a lot of other things in life too that I'm sure somebody else cares about.
1. Indiscriminate use of third-party scripts and network connections, particularly for marketing cruft such as ads, analytics, and trackers.
2. Pulling in large blobs of code, particularly frameworks, because it makes things easier.
3. Back-end issues, particularly distributed monoliths disguised as microservices, delaying time-to-first-byte by 100s of milliseconds.
4. Lack of awareness of the latency and bandwidth characteristics of real users' devices.
Other reasons, too, but these are some big ones. Understanding CPU cache, virtual memory, etc. is way, way down the list, and certainly wouldn't "change web applications from their current abysmal levels of performance."
https://wiki.xxiivv.com/site/uxn.html
https://wiki.xxiivv.com/site/uxntal.html
https://wiki.xxiivv.com/site/varvara.html
...and it's also awful.
I get sad when I see an idea that I like implemented to poorly. It sucks oxygen out of the room, or poisons the well, or whatever.
I think I basically want Deno with a decentralized ID / DNS system that has nothing to do with the hierarchy or Urbit... And using capability modeling for different apps... And with something like Wire Guard for end-to-end encryption... That feels like a federated version of Sandstorm.io...
That's what I'm daydreaming about.
https://github.com/urbit/urbit/blob/master/pkg/arvo/sys/arvo...
This is a kind of joke, isn't it?
[1]: https://en.wikipedia.org/wiki/0x10c
Maybe Mu is it. I don't know. My concern is that low level code with manual register allocations is too unproductive, and even C (not to mention C++ or Rust) is complex enough that I don't know what the compiler is doing at -O2, with or without TBAA, with or without restrict, etc.
Is it even possible to get a small understandable stack, and full Unicode support, OS-like text editing and keyboard shortcuts, system fonts, system font rendering and fontconfig, tab navigation to jump between widgets, maybe even OS file dialogs and accessibility? Lagrange is a Gemini client which depends on not much more than SDL (good), but doesn't use OS fonts rendering and text editing (bad).
* It still requires firmware. There's a whole lot of C down there. How deep do you want to go?
* No mouse. This is just my own ignorance. I can't get the damn IRQs and interrupts figured out.
* Doesn't work yet on real hardware. I live in Qemu. Debugging that is a whole new set of skills I need to learn.
* No networking, almost no persistent storage. Mu has a very simple and slow driver for ATA disks, but that probably won't suffice on most real-world machine configurations. There's 0 network drivers right now. I probably need a dozen to get any sort of coverage.
The stuff you mentioned around graphics and OS file dialogs, that feels easier once you're willing to put up with constraints like Mu's 1024x768 and so on. But yeah, there's major challenges on this road.
Partly due to these challenges, I've actually started to hedge my bets and make some compromises. My new project is https://github.com/akkartik/teliva which doesn't try to eliminate C, just minimize it. Linux kernel, libc, Lua (12k lines of C), some libraries for https. A gemini client is actually on my todo list there. I think I have everything I need to build it.
Would anybody like to compare/contrast this with https://mirage.io/?
As I understand it, unikernels want to let you bring your own application sources, and try to compile it to their substrate. Mu requires you to build your application for it. There's no compatibility with anything beyond the x86 instruction set (and Unicode).
Mu: A Human Scale Computer - https://news.ycombinator.com/item?id=21242190 - Oct 2019 (12 comments)
So, a byte-code must be chosen to the project. Brainfuck is considered at first: it is extremely simple to implement but is rejected because has very little code density. Then, Chip-8 is considered: it is simple to implement and there are many programs and tools already available. Then p-code is looked at, but it is nowhere near as popular as Chip-8 and apparently not as simple to implement. Other vm's are considered but are rejected because they are not simple or not very popular: SWEET16, ijvm and tinybasic.
Now, what is a good choice for such a situation? What is a good byte-code for such an endeavor? Restrictions are: 64kb of RAM not counting graphics or overlays for drivers that can be dynamically loaded, possibility of running 3 to 10 tasks at the same time, with a good balance of code density and performance, easy to implement and possibly with available tools or good example programs?
http://collapseos.org
[0] by which I mean the ability to tag functions and variables with an indication of what they're used for so the interpreter/jit is able to replace them with an efficient implementation if one is known to it. For instance, you possibly don't even need float types, just have routines for doing soft-float arithmetic tagged such that the interpreter knows they implement IEEE floating point operations that the processor may be able to handle on its own.
https://hackaday.io/project/173633-cpm-on-a-minimal-z80-comp...