Live data from Hacker News

Visopsys: OS maintained by a single developer since 1997

visopsys.org

131–140 of 151 posts

Re: Visopsys: OS maintained by a single developer since 1997

#131
post #6
post #4

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.

iOS is tremendously more complex than it used to be. Still relatively easy to use but it has definitely lost the simplicity edge.

Re: Visopsys: OS maintained by a single developer since 1997

#132
post #51

Amazing! 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.

Here is a dumb question. In an OS with user-space drivers, can't many existing drivers be wrapped and repurposed? Does this shorten the path to mainstreaming more new OSes?

Re: Visopsys: OS maintained by a single developer since 1997

#133
post #76
post #74

Earlier 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…

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 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

#134
post #74

Earlier 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...

Exactly.

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

#135
post #90

Earlier 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.

> 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 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

#137
post #84
post #60

Earlier 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…

There's some really great documentation out there on CP/M, Kildall struggled initially with the hard disks. While large parts of CP/M were written in assembly, parts were written in PL/M as well.

Re: Visopsys: OS maintained by a single developer since 1997

#138
post #135

Earlier 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…

This would simply not be possible, if basic web browsers were more popular. The React / Next.js app wouldn't run, and then the users would complain, and the Frontend People would try to say "just use the WHATWG VM", and then the Enterprise People would say "we've blocked that so people can't play video games at work: fix your end" (ignoring that they only blocked programs named chrome.exe, and everyone's got Firefox or a renamed Chrome installed), and then the Frontend People would have to fix it because that's what the client demands. (For B2B, at least, but B2B is lucrative enough that best-practices proliferate.)

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

#139
post #133
post #76

Earlier 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…

I can see how you are using the multiple versioning schemes to achieve certain goals, but that does not make your approach "one true way".

"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

#140
post #125

Earlier 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…

Wait, I'm confused. Why would I use an obscure language that no one knows about, or could find a book on, when I could just have the AI write Z80 assembly, or even have it make a Z80 C compiler for me? (You laugh because you haven't tried it)
Post reply on HN