5 ms·

A project I dream about but have neither the skills to implement nor the discipline. An entire OS written just for the RPI4. With code making use of the fact th

A project I dream about but have neither the skills to implement nor the discipline. An entire OS written just for the RPI4. With code making use of the fact that we are running on known hardware, so we can optimize it rigorously. If you focused on supporting the official raspberry pi keyboard, mouse, and touchscreen you could circumvent a lot of the pains around driver issues. Then people could actually get up and running with your OS with real hardware, and you could start dogfooding it. I’ve heard people say that the software we use is up to 100 times slower than it needs to be. So my hypothesis is that if the software was written smarter, and used the fact that we know the hardware ahead of time, we should easily hit a 100 times performance increase across the OS. Also if it were possible, it would be cool if this OS supported a minimal boot mode, that could be configured to only run the bare minimum amount of apps required for a certain piece of software. So for example a game mode that ran the game, and the bare minimum amount of OS the game needed to run. And since we are in full on fantasy land we can take this one step further. Same basic concept, but with a RISC-V SBC, with an open GPU. Bonus points if you can get up and running with a touchscreen, keyboard, mouse, case, and SD card for $150

mkl 5y ago
Mouse and keyboard are as standard and supported as they can possibly be, and the official Raspberry Pi ones are ordinary USB ones supported everywhere. Touchscreens supported in Linux are supported well out of the box as well (e.g. my Dell ones). "100 times slower" sounds like nonsense to me; huge numbers of people are motivated to make software faster, so if there was that much room to improve, it mostly would have happened already.
- mysterydip 5y ago
  Yes, I recently was investigating USB keyboard/mouse usage on a microcontroller and found out it's not too difficult to implement: https://www.networktechinc.com/usb-prots.html https://www.networktechinc.com/usb-prots.html
ComodoHacker 5y ago
>code making use of the fact that we are running on known hardware >you focused on supporting the official raspberry pi keyboard, mouse, and touchscreen you could circumvent a lot of the pains around driver issues I'm afraid that's how closed, non-extensible systems are born, and later inevitably die.
- Decabytes 5y ago
  I agree. But the context of this is around a solo developer doing this as a hobby OS. And these constraints would help the project have reasonable scope assuming no-one else expressed any interest in it.
PeterisP 5y ago
The statement "the software we use is up to 100 times slower than it needs to be" is not OS overhead (which is relatively small) but about user-facing application software written to optimize development speed/cost and not performance. A reasonable game is performance focused and is spending most of the computing power directly on itself (even if perhaps not optimally and not utilizing specific GPU hardware to its full extent) and not in OS routines, so an OS providing a specific "game mode" with only the bare minimum amount of OS the game needed to run can perhaps bring a 5% or 10% performance improvement, but not 50% and definitely not 100 times performance increase. For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software. The example of this article about UnrealEngine and Vulkan is a good illustration - a game targeting the specific hardware directly could achieve the same performance (and more!), however, they are not going to, nobody is going to rewrite the game because that's expensive, so getting an OS abstraction layer like Vulkan - which inevitably adds some extra performance overhead, not reduces it - is the only reasonable way to go.
- Decabytes 5y ago
  Maybe it's because I've been on Windows for too long, but people are always complaining about how terrible Windows 10 (and soon to be 11 is) as an experience (See recent slowdown with AMD processors). That and a little bit too much time watching all the cool things people did with 1mhz processors with no L1 cache or graphics, on 80s computers. As someone who wasn't around during that time, it's easy to get the feeling that a 1.5ghz quad core cpus +.5ghz gpu should absolutely slay any program, but in my experience using the RPI4 as a primary computer it hasn't felt that way. > For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software. I think this is insightful. I agree that not everything would be 100x, but I feel like at the level of an RPI 4 even a 5-10% improvement that bumps a game into 30 or 60fps territory would be noticeable. And even a 2x improvement in regular apps would have impact.
Koshkin 5y ago
> OS written just for the RPI4 Linux and NetBSD can be configured to be as good as if they were written just for RPI4.

mkl 5y ago

Mouse and keyboard are as standard and supported as they can possibly be, and the official Raspberry Pi ones are ordinary USB ones supported everywhere. Touchscreens supported in Linux are supported well out of the box as well (e.g. my Dell ones). "100 times slower" sounds like nonsense to me; huge numbers of people are motivated to make software faster, so if there was that much room to improve, it mostly would have happened already.

mysterydip 5y ago
Yes, I recently was investigating USB keyboard/mouse usage on a microcontroller and found out it's not too difficult to implement: https://www.networktechinc.com/usb-prots.html https://www.networktechinc.com/usb-prots.html

ComodoHacker 5y ago

>code making use of the fact that we are running on known hardware >you focused on supporting the official raspberry pi keyboard, mouse, and touchscreen you could circumvent a lot of the pains around driver issues I'm afraid that's how closed, non-extensible systems are born, and later inevitably die.

Decabytes 5y ago
I agree. But the context of this is around a solo developer doing this as a hobby OS. And these constraints would help the project have reasonable scope assuming no-one else expressed any interest in it.

PeterisP 5y ago

The statement "the software we use is up to 100 times slower than it needs to be" is not OS overhead (which is relatively small) but about user-facing application software written to optimize development speed/cost and not performance. A reasonable game is performance focused and is spending most of the computing power directly on itself (even if perhaps not optimally and not utilizing specific GPU hardware to its full extent) and not in OS routines, so an OS providing a specific "game mode" with only the bare minimum amount of OS the game needed to run can perhaps bring a 5% or 10% performance improvement, but not 50% and definitely not 100 times performance increase. For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software. The example of this article about UnrealEngine and Vulkan is a good illustration - a game targeting the specific hardware directly could achieve the same performance (and more!), however, they are not going to, nobody is going to rewrite the game because that's expensive, so getting an OS abstraction layer like Vulkan - which inevitably adds some extra performance overhead, not reduces it - is the only reasonable way to go.

Decabytes 5y ago
Maybe it's because I've been on Windows for too long, but people are always complaining about how terrible Windows 10 (and soon to be 11 is) as an experience (See recent slowdown with AMD processors). That and a little bit too much time watching all the cool things people did with 1mhz processors with no L1 cache or graphics, on 80s computers. As someone who wasn't around during that time, it's easy to get the feeling that a 1.5ghz quad core cpus +.5ghz gpu should absolutely slay any program, but in my experience using the RPI4 as a primary computer it hasn't felt that way. > For software that was written in a performance insensitive way (i.e. not games) you perhaps could achieve a 100 times performance increase by a full rewrite avoiding various overheads. However, you would not really need an OS change for that, the main performance-relevant changes would be in the app itself and you can get almost all of that by running the optimized app on a standard OS - but you would need a rewrite of all the actual software. I think this is insightful. I agree that not everything would be 100x, but I feel like at the level of an RPI 4 even a 5-10% improvement that bumps a game into 30 or 60fps territory would be noticeable. And even a 2x improvement in regular apps would have impact.

Koshkin 5y ago

> OS written just for the RPI4 Linux and NetBSD can be configured to be as good as if they were written just for RPI4.