Live data from Hacker News

Essence: Desktop operating system built from scratch

nakst.gitlab.io

241–250 of 299 posts

Re: Essence: Desktop operating system built from scratch

#241

Earlier quoted context omitted.

These days it's easier to create an OS from scratch than a web browser.

Lately I was tryong to understand the exact reason "why". Why are modern browsers so ridiculously complicated? Rendering a (albeit confusing) content is a PDF-like kind of job (or am I wrong?) What is the exact complexity here (except for JS compiler, which is again just a compiler)?

> What is the exact complexity here

There are hundreds of standards spanning thens of thousands of pages. Some of them are obsolete, some of them are not, most of them interact with each other in complex and non-obvious ways.

An attempt to measure the scope is here: https://drewdevault.com/2020/03/18/Reckless-limitless-scope....

And that's before we get to things like Javascript or WASM.

Another measure is the count of WebAPIs. A modern browser ships six to seven thousand APIs: https://web-confluence.appspot.com/#!/confluence All these APIs are available via Javascript

Re: Essence: Desktop operating system built from scratch

#242

So first off: Very cool. Amazingly polished, and self-hosting! Especially since it looks to be an actually-independent project with POSIX as an optional compat layer. I feel like the features that are unique are mostly in 3 groups: 1. Features that shouldn't be unique to this system. Tabbed windows have occasionally happened on other systems, and probably should become more common, and there's no reason it shouldn't…

> Features that only work if you have really tight integration ... Programs updating file name when you rename from the file manager ... Even systems like MacOS are going to struggle MacOS has actually had this one in the bag for a couple of decades now (likely due to their really tight integration).

File watching API is a thing on most OSes. It's up to the app to actually use it and offer a nice UI flow around it.

Re: Essence: Desktop operating system built from scratch

#243

If you want a fleshed out demo [0], we had the author present at our conference recently. Worth a watch. [0] https://media.handmade-seattle.com/essence/

Thanks for the link. Appreciate the amount of work that has gone into this, very well done to the author(s), super work. Stunning attention to detail - font choice on install, dynamic file renaming, open file highlighting, tabbed windows with apps inside. These felt so intuitive to me as I watched. Vector based UI - excellent choice! Watching the demo brought back memories of OS/2 and BeOS in terms of aesthetics and…

Free Pascal is already ported to many different operating systems. But to get the VB-like Lazarus IDE and component library across, you'd also have to port QT. Hm, QT itself is also already ported to many different operating systems, so...

Re: Essence: Desktop operating system built from scratch

#244

If you want a fleshed out demo [0], we had the author present at our conference recently. Worth a watch. [0] https://media.handmade-seattle.com/essence/

Does MacOS not highlight open files in Finder the way that it used to work back in MacOS 9?

Nope.

Re: Essence: Desktop operating system built from scratch

#245

Earlier quoted context omitted.

You're assessing the feasibility here making the assumption that a polling pattern would be used but this is exactly what an event based pattern is perfect for. As long as files are modified through the os you can propagate changes upwards and only update folder metadata when required. This is what the parent meant by moving the cost upfront. If your only option is polling you're right but we're talking abou an os fr…

There's a lot more to it than that. For example, two links to a file in the same directory shouldn't count as doubling the space it consumes in that directory nor all its parents -- that's an easy case to consider, but there are others that are much harder.

Adding different kinds of measurements of size doesn't particularly increase the difficulty of tracking it here, just adds some more fields to the metadata and maybe some additional events.

To take an example of size data types from another thread, let's imagine you want to track 2 kinds of size: size as read sequentially (A) and size gained if deleted (B). The first cares about links but the second does not. Every folder would track the size of sub-directories by listening for size calculation events firing on the contained files and folders. A lowest level folder would listen to the events of all its files and update it's own size metadata, this triggers another event that any parent folder is listening to, repeat. A link would just listen to the event of its linked file or folder and would only indicate size updates as relevant to the size data type A. This information gets propagated upwards normal.

As you say, there's a lot of details here but I'm not coming up with any blockers that would invalidate the pattern. It's a very flexible system and I've written this sort of propagating update before with future features all being simple to add. If you can think of any blockers I would be very happy to hear them so I can design around it next time I touch a project like this.

Re: Essence: Desktop operating system built from scratch

#246

Earlier quoted context omitted.

Then you get into semantic arguments: If a directory contains 2 1GB files, does the user care that 99% of their blocks are shared, or that just an under-the-hood implementation detail, and the user wants to know that there are 2GB worth of files in there?

Really, there should be two file sizes: "how much space this will take if I copy it to other filesystem" and "how much space will be freed if I delete this"

Don't forget "How much of my free storage/broadband data will be used up when I attach this to an email?"

Re: Essence: Desktop operating system built from scratch

#247
post #180

Earlier quoted context omitted.

"labor of love To scratch an itch To explore an idea" that by no mean is a bad thing, it just means doing things for themselves, to express, to learn etc, typical of creative work. People do that all the time. However in OSS there is this thing when people feel they need to present their work as useful to others eventhough clearly what drives their work has nothing to do with other peoples' needs, it's just their itc…

And that is a problem because...? Remember that one of the original motivators behind "Open Source" is scratching your own itch.

> the original motivators behind "Open Source" is scratching your own itch.

that's what I said, and you repeated it, as if it's some new insight or supports some argument.

Is there not an issue in OSS where thing that should not be used in commercial context, are used in commercial context, they break, then people blame the adopters for expecting too much from OSS? Rarely the other side of the coin is addressed which is creators (not all of them) went out of their way to promote adoption of these things.

Here is an analogy: art design chair sold as office work chair. Of course if you are smart you would not buy them because over time the ergonomic would kill you. But that doesn't mean no one would. When some gullible people buys these chair, you say: idiots. However, I bet you also think about the people who made these chairs paid for TV commercials that never show the ergonomics of the thing, and question their responsibility.

Now replace "art" with "hobbyist software"

Re: Essence: Desktop operating system built from scratch

#248
post #214

Earlier quoted context omitted.

On a related note, why a filesystem and not a database? I get the feeling that a filesystem ultimately is just a .. poor man's database. Except that it's quite crappy and there are no proper transactions, many things are impossible without TOCTOUs, many a bug (including security ones) have been due to race conditions around filesystem operations. I guess path->{metadata,data} with no transactions is a simple abstract…

Afaik, it's been tried and abandoned for some reason. see WinFS https://en.wikipedia.org/wiki/WinFS

Not fully abandoned, mainframes and microcomputers use database like filesystems.

Re: Essence: Desktop operating system built from scratch

#249

Earlier quoted context omitted.

> Features that only work if you have really tight integration ... Programs updating file name when you rename from the file manager ... Even systems like MacOS are going to struggle MacOS has actually had this one in the bag for a couple of decades now (likely due to their really tight integration).

Doesn't even Windows do that? Rename a file in File Explorer, and the app that has it open pops up a dialogue saying "File So-and-so has been renamed.", or some such. But maybe that's because the app has to do the work of keeping track of it (though probably via hooks into the OS / Explorer), so it's not fully automatic? Can't recall if all apps do it, think I've only noticed it in a few.

windows back then, used to do that. I think XP / 7 days.

Re: Essence: Desktop operating system built from scratch

#250

Earlier quoted context omitted.

I think the vector based UI should be on the list somewhere. Really smart solution to the HiDPI problem that gives you easy arbitrary scaling without any awkwardness

I genuinely have no idea why vector-based UIs have not become common already in at least one of the major OSs’

Low-resolution monitors and laptops remain widespread [0], and vector-based UI just doesn't look that good on those (either blurry or misaligned). I'm doubtful that HiDPI will become the mainstream standard anytime soon outside of smartphones and tablets (small screens). Cost increases quadratically with screen resolution as a function of production yield, so low-DPI hardware is likely to remain the cheaper option that many people will continue to choose.

[0] See for example: https://www.amazon.com/bestsellers/electronics/1292115011 https://www.amazon.com/bestsellers/electronics/565108/

Post reply on HN