Blog

Where 1.1.x Is At

Networking kind of mostly works, multithreading sorta works, graphical programs almost kind of work ….

It’s basically everything that a real OS needs to be but only in it’s rawest form and with a lot of bugs/limitations remaining to fix.

There aren’t many drivers, but it should still work on real hardware (hopefully any recent 64-bit RISC-V compatible) as well as in emulators (RVVM for current desktop testing) and is being steadily improved.

Some useful programs like a vi implementation have been ported and a new package manager has already been designed but these are limited and not

Where I’d Like To Be

Obviously I want to have a full desktop system with a bunch of hardware drivers and some useful network programs and some games and system tools ready for an imminent 1.2 release, but perfecting all of these aspects will not be possible in the short term.

What To Expect In Upcoming Releases

Either the next releases will be in-development 1.1.x versions without much release engineering or will be a stripped down 1.2 release with only the most critical features perfected.

• No games/multimedia apps yet
  • Games are important for stress-testing features and for making technical demos “fun”, but aren’t the top priority while I’ve got more critical features to finish
  • I might break this rule to sneak some simple “toy” games in especially if it’s useful for testing, but don’t expect much in the way of colourful 3D action yet
• More system tools
  • A formal test suite is needed to plan more reliable releases
  • Performance monitoring & debugging tools are needed in order to do more testing in-place
  • Other basic tools need to be written to demonstrate the desktop system: a menu of some kind, a file browser, a terminal etc.
  • These will all be released soon in an early state
• Some focus on text & fonts
  • The system should start to become more useful for code editing
  • A built-in documentation system will be implemented that should help explain each release (rather than repeating things in blog posts)
  • A visual style of the OS will start to arise in this time, but as per previous post this won’t have a great focus on consistency (e.g. more critical apps might use simpler fonts etc.)
• More driver groundwork
  • I don’t have time to finish drivers for every device I want to make usable but I can probably finish some stuff like PCI bus & flexible interrupt handling while completing other tasks

Performance-First

There are security problems, visual problems, input/”feel” problems, compatibility/driver problems, deployment/packaging problems etc. to deal with when designing a system like this. But it’s important to remember that none of these matter unless the desktop system is fast enough to run apps.

Traditional Design

The desktop system doesn’t have any particularly crazy design constraints and isn’t intended to prove any new models of interaction. Just basic desktop computing stuff first, plenty of time to worry about more interesting innovations later.

Networked Architecture

The desktop system is designed networking-first, this helps both to test networking functionality and enables more opportunities for supercomputing applications in the future.

This doesn’t mean the protocol is perfectly designed, just that the system is definitely designed for network operation and that this isn’t an unsupported mode of operation.

Inconsistency Epiphany

My desktop experiments in the past have been inspired by old computer systems and I originally tried to design towards a particular style to match the level of consistency in older operating systems.

I eventually realised that focusing on consistent look-and-feel would hold the platform back and would limit the usefulness of ported software and of any other people’s experiments on my platform. After all the interface you might want for a heavy duty CAD program or game might not overlap at all with the interface you’d want for a text editor or a file manager, and something inbetween like an office suite would probably need some other balance of standard & customised features.

So with this in mind the design will be a little more similar to X11 than I originally intended, and should gradually allow more and more customised desktop environments as well as very diverse kinds of apps.

Mixed-Mode Client/Server Rendering

Some GUI systems do all the layout & rendering stuff within the application (client-side widgets) while others defer more of it to the GUI backend (server-side widgets).

Neither of these approaches are good enough for every use case, sometimes one or the other method may be faster depending on the kind of app or the mode of operation, and both have pitfalls.

So the only real solution is to have some basic facilities like simple font rendering built-in and to have other things like more advanced font systems controlled fully on the application side. This allows simple apps to avoid wasting space or reinventing wheels while also supporting more advanced apps that might have unusual methods of interaction.

Optimised For Minimalist Apps

The system should eventually be useful for all kinds of programs, but should generally be optimised to ensure that the simplest visual apps like administration tools and wireframe/stick-figure/CAD-style rendering work reliably over a network connection.

Designed To Work Across Operating Systems

The desktop system is intended to help prototype real apps for my OS and also to be useful in ad-hoc supercomputer setups, this means that both in the short term as well as the long term it’s very important to try and allow running the desktop system on other platforms either for testing in-progress apps or for interoperability in real-world use.

Anti-Aliasing & Alpha Blending Can Be Added Later

These techniques are pretty easy to demonstrate but can take a little while to optimise properly, so I want to avoid any unnecessary tinkering until I have a reliable system together. For now the rendering functions are intentionally kept simple at the cost of not looking as pretty as a full-featured version, while I focus on more critical features like stability & input management.

The main problem organising a better launch with demos is obviously that bugs in the new code keep popping up when I get something new working.

What the bugs look like at the moment is just that the system will stop responding sometimes especially when under load testing desktop code. This is likely a scheduler/wakeup issue which I should be able to resolve in time, but is very frustrating for now as everything works and then it just … Doesn’t.

My old “caveman” font has been ported over to the new desktop system, performance has been improved dramatically so window management is fairly smooth now, a few bugs remain with freezing when running on the new kernel but those will be addressed in time (probably a thread wakeup issue, just need to find the exact circumstances which are causing it…). For now videos will be taken running on Linux.

The junkie pieces of shit who murdered my mother at Moruya hospital, the people who kicked me out of my rental punitively straight afterwards or the people who have called the police on me repeatedly ever since her death while I’ve been trying to re-launch my business.

That behaviour is completely unacceptable and unforgiveable, and has made me really lose confidence about trying to launch products in Australia. I’d much rather be trying to launch products in Egypt where people might hope to at least treated with some basic dignity & privacy despite all of that country’s problems.

Mum prepared me for these circumstances and she taught me to just keep focusing on my own work and try to filter out other people’s bullshit, but it’s been incredibly difficult while I’m trying to launch a business and people are just spreading unfounded rumours about me and trying to make me feel unsafe at home.

This code isn’t integrated into the OS (yet), this is just my previous experimentation which I intended to test further on tablet computers (unfortunately broke my good one before getting very far!).

The “caveman” font I designed for this experiment may be reused in the OS, and the basic window management stuff is already further ahead in my new desktop system, so this is just an early prototype of the upcoming desktop demo from a few years ago.

This prototype also includes some animation effects which may be replicated in the OS, in particular it shifts windows into view nicely when the keyboard pops up then puts them back again afterwards if they haven’t been moved by the user. But this was only a prototype designed on third-party platforms, the real thing is coming later…

But been working on scripting for the desktop system, this will make it easier to make simple demo apps and also might be useful for business software in the longer term.

Just came across this article, might give this OS a try some day (not today…).

https://linuxiac.com/vitruvianos-0-3-debuts-as-haiku-inspired-linux-os/

A new thrdinfo program and system call have been added. These are very limited for now but will be improved over time to show CPU usage levels and other things. A graphical version will also be developed later.

Window resizing, moving & closing mostly work properly (including communication of events with client programs). Screenshots still look horrendous with the background not updated properly between interactions, but getting closer to running real apps.