This is very very cool, and unlike a lot of other "hobby" OSes actually looks usable as a daily driver if your needs are basic (kids, elderly, older/cheaper hardware, etc). While for nerds computers have become these monstrously powerful things that can do everything under the sun, there's definitely still plenty of people who just want a computer to write down notes, keep a calendar, use the calculator... eg the thi…
What youre describing is called iOS on a large iPad. Everyone from 4 year olds to my 77 year old computer illiterate Dad can figure it out. This doesn't look very usable at all by someone who isn't basically a computer nerd.
Visopsys: OS maintained by a single developer since 1997
131–140 of 151 posts
Re: Visopsys: OS maintained by a single developer since 1997
#132Amazing! I find it extremely fascinating that somebody is able to create entire operating system. Not a easy task!
It’s not easy, but it’s more approachable than many realize. Much of modern operating systems are the hordes and hordes of drivers; the fundamentals aren’t terribly complicated; just lots of detail.
Re: Visopsys: OS maintained by a single developer since 1997
#133Earlier quoted context omitted.
Semantic versioning is for APIs, not for functionality. So it's for developers consuming that API (whether a library, or a service). For releases in production, use a calendar version. v2025-11-02 is a clear release tag. Add preciseness as required. There should be a SBOM/Manifest (Bill Of Materials) of the versioned major components and configuration for that overall release. For users, it depends on the type of use…
Developers are "users" (of a library, API, tool...), and "API functionality" is a subset of "functionality": what purpose would such distinction serve? For example, in end user desktop software (say a text editor), how would you indicate a security bug fix for an old version v2023-11-02 without forcing users to pay for a new version of v2025-09-15? Again, versioning is a tool, and depending on the release structure o…
If I fix a bug in the implementation that doesn't affect the API itself, the semver doesn't change.
So it works to define the versioning of an interface.
Release versioning (like vyyyy-mm-dd) is about SRE and configuration management, it's about documenting what is actually operating in production.
User versioning is about user expectations. If you're doing a security bug fix, then a) it should be free to users affected, and b) it should be documented as the reason for the release.
For a security bug fix of v2023-11-02, you can add a "hotfix" extension to the numbering so v2023-11-02.001 or equivalent.
Re: Visopsys: OS maintained by a single developer since 1997
#134Earlier quoted context omitted.
Semantic versioning is for APIs, not for functionality. So it's for developers consuming that API (whether a library, or a service). For releases in production, use a calendar version. v2025-11-02 is a clear release tag. Add preciseness as required. There should be a SBOM/Manifest (Bill Of Materials) of the versioned major components and configuration for that overall release. For users, it depends on the type of use…
Oracle used to do that, didn't they? So, amongst others, they had Oracle 8i at the height of the dot com boom (i for "Internet"), then a few years later when clustering became big news there was Oracle 10g (the g standing for "grid", I think?), and so on. Actually, it looks like they might still be doing it - I just checked, and their current version is 23ai...
There's nothing specific about the letters after Oracle's RDBMS versions, they're for marketing purposes.
Re: Visopsys: OS maintained by a single developer since 1997
#135Earlier quoted context omitted.
I would love to see that happen, but its not going to. It is the people with basic needs who need to stick to the mainstream stuff because they can get support and it does what they expect. People need bank and other complex websites to work. They want to watch online video. Kids will need educational apps. Also do not make assumptions about elderly people. Not long ago I met a woman (guess in her 70s?) who used to w…
Web browsers have three purposes: document viewer, remote paperwork machine, and cross-platform application framework. I could throw together a browser fully capable of the first two in a month. (Much less time, if you're okay shipping a prototype, which personally I'm not.) Bank websites are not complex, unless you count the business logic: there's no reason they shouldn't work in Dillo.
Can I get a show of hands for anyone else who has had multiple jobs where The Frontend People have decided that in order to show something that can only honestly be defined as "a basic document" or complete a few simple tags, the tooling necessary for the job is a React or Next.js app over 1,000 NPM dependencies, and fully reimplementing all built-in functionality from scratch in JS? The Web is simply the land of excess. Nothing is too simple to be overengineered poorly in JavaScript.
Re: Visopsys: OS maintained by a single developer since 1997
#136Re: Visopsys: OS maintained by a single developer since 1997
#137Earlier quoted context omitted.
CP/M was far more simpler.
In all probability, yes. I'm not sure how much easier it would be to develop though. Back then, most (if not all) of the operating system was developed in assembly language while there was far more to consider when it came down to performance and memory usage (which is often in conflict with each other). CP/M was also notorious for running on hardware that was incompatible with each other, relying upon the BIOS to sm…
Re: Visopsys: OS maintained by a single developer since 1997
#138Earlier quoted context omitted.
Web browsers have three purposes: document viewer, remote paperwork machine, and cross-platform application framework. I could throw together a browser fully capable of the first two in a month. (Much less time, if you're okay shipping a prototype, which personally I'm not.) Bank websites are not complex, unless you count the business logic: there's no reason they shouldn't work in Dillo.
> document viewer, remote paperwork machine, and cross-platform application framework Can I get a show of hands for anyone else who has had multiple jobs where The Frontend People have decided that in order to show something that can only honestly be defined as "a basic document" or complete a few simple tags, the tooling necessary for the job is a React or Next.js app over 1,000 NPM dependencies, and fully reimpleme…
It's a chicken-and-egg problem. The harmful consequences of Postel's principle are well-known, but the solutions are also well-known. We only need to get past a certain threshold before the problem's effectively solved, and that can be done by starting in a particular domain and working our way outwards.
Re: Visopsys: OS maintained by a single developer since 1997
#139Earlier quoted context omitted.
Developers are "users" (of a library, API, tool...), and "API functionality" is a subset of "functionality": what purpose would such distinction serve? For example, in end user desktop software (say a text editor), how would you indicate a security bug fix for an old version v2023-11-02 without forcing users to pay for a new version of v2025-09-15? Again, versioning is a tool, and depending on the release structure o…
Semver is semantic . It tells you about the changes in the API, not in the implementation. So it's relevant to the users (ie developers) of that API. If I fix a bug in the implementation that doesn't affect the API itself, the semver doesn't change . So it works to define the versioning of an interface . Release versioning (like vyyyy-mm-dd) is about SRE and configuration management, it's about documenting what is ac…
"Semantic" really means "has some background meaning", and SemVer meaning behind all the numbers is in no way limited to API versioning: I am confused if you are making a proposal to consider it only that, arguing that different schemes should be used for different types of software, or stating that this is the only thing SemVer can be used for?
On any of those points, I disagree and you haven't made a convincing argument why that would make sense.
Note that I am not saying that SemVer is the only true way to do versioning (very much not so) for all software, just that it depends on your release strategy what is most applicable, and not on the type of software you are shipping.
Re: Visopsys: OS maintained by a single developer since 1997
#140Earlier quoted context omitted.
I am intrigued. Go ahead and show us ONE 15 minute agentic ai os that runs on metal.
The parent commenter should get an Altair Z80 emulator with CP/M 2.2 and begin writting stuff in assembly. Even a simple Tetris would be a daunting task. He could even try high level languages such as T3X, which is very Pascal-like to my eyes in order to be familiar with CP/M 2.2 and after some months I would switch to Z80 assembly in order to write stuff for CP/M. These AI's would be clueless about T3X OFC, or almos…