Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Essence: Desktop operating system built from scratch

nakst.gitlab.io

Post reply on HN
Print view View original

281–290 of 299 posts

Re: Essence: Desktop operating system built from scratch

#281

Post by sedan_baklazhan »

tekknik wrote: post #271
sedan_baklazhan wrote: post #266

Earlier quoted context omitted.

Thanks. It looks like complexity increase deliberately aimed at maintaining market monopoly. I can't rationally believe than tens of thousands of pages of documents are needed to display just a (however complex it is) UI. It's a UI engine, after all, and nothing more.

With file system access, media APIs, and networking, the browser is more comparable to a full fledged operating system than a UI framework.

It is not merely "comparable". It is in fact hundreds or thousands of times more complex, as it turns out (and it still consumes OS API's). I don't find it adequate.

Re: Essence: Desktop operating system built from scratch

#282

Post by cryptonector »

ninjanomnom wrote: post #245
cryptonector wrote: post #235

Earlier quoted context omitted.

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

I don't see why "size gained if deleted" "does not [care about links]".

What I've learned in my experience with ZFS, Lustre, and other filesystems is that the user simply cannot get what you're asking for, not with any kind of real reliability. For distributed filesystems (like Lustre), the kind of thing you're asking for is simply ETOOHARD or ETOOSLOW. It's very easy to insist on a solution, and very hard to get one.

Re: Essence: Desktop operating system built from scratch

#283

Post by ncmncm »

phendrenad2 wrote: post #77
gk1256 wrote: post #24

I like the UI, but I'm disappointed to find that the author is using orthodox C++ instead Modern C++

For the kernel, or for the user-mode applications? C++ features aren't very useful for kernels. Presumably the author is more familiar with C and "C with classes" C++ and someone can rewrite the user-mode apps in modern C++ later.

It is foolish to assert that "C++ features aren't very useful for kernels". C++ features are useful for programs, particularly big programs. Kernels are big programs.

Re: Essence: Desktop operating system built from scratch

#284

Post by ncmncm »

ani-ani wrote: post #33
__float wrote: post #27

Earlier quoted context omitted.

What do you mean by "orthodox C++"?

" Although the operating system is written in C++, most C++ features are avoided ." From https://gitlab.com/nakst/essence/-/blob/master/help/Contribu...

Yes, this is kind of stupid.

Certain people have been doing this sort of thing forever. It was never a good idea. Whenever you probe why they thought it was a good idea, all the reasons (where they are expressible at all) turn out to depend on falsehoods. Most usually, though, it amounts to laziness about learning anything new.

You can see effective use of Modern C++ in SerenityOS, to excellent effect.

Re: Essence: Desktop operating system built from scratch

#285

Post by ninjanomnom »

cryptonector wrote: post #282
ninjanomnom wrote: post #245

Earlier quoted context omitted.

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

I don't see why "size gained if deleted" "does not [care about links]". What I've learned in my experience with ZFS, Lustre, and other filesystems is that the user simply cannot get what you're asking for, not with any kind of real reliability. For distributed filesystems (like Lustre), the kind of thing you're asking for is simply ETOOHARD or ETOOSLOW. It's very easy to insist on a solution, and very hard to get one…

> I don't see why "size gained if deleted" "does not [care about links]".

Deleting links does not give you any additional storage space beyond the minimal amount taken up by the link itself.

As for existing filesystems, yeah they're going to have problems as they're built on filesystems that for the most part are polling. I'm not insisting on a solution or saying existing filesystems need to use this though, this is all in the context of a greenfield project. Switching something like linux to use an event based system instead would be a major project.

As for distributed filesystems where every file does not own all its own bits, that's just a different way of measuring and doesn't have any major problems for the concept.

Re: Essence: Desktop operating system built from scratch

#286

Post by guerrilla »

lproven wrote: post #244
guerrilla wrote: post #155

Earlier quoted context omitted.

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

Nope.

Wow that's sad. And I just noticed Nautilus doesn't even indicate which folders are open... Why have we gone backwards with all this...

Re: Essence: Desktop operating system built from scratch

#289

Post by lproven »

guerrilla wrote: post #286
lproven wrote: post #244

Earlier quoted context omitted.

Nope.

Wow that's sad. And I just noticed Nautilus doesn't even indicate which folders are open... Why have we gone backwards with all this...

I wonder the same thing.

I do not like GNOME 3 at all myself. A lot of the features that the developers are proud of – things like CSD, no menu bars, that big empty wasted panel with no indicator icons, the clear empty desktop with no desktop icons and so on – are the specific things I do not like.

I still use Unity on Ubuntu. One of my machines has the latest version of the Unity remix on it: https://ubuntuunity.org/

... but little regressions are accumulating. I can't empty the wastebasket from the dock any more; the volume control works but mousewheel control is now reversed (down is up, and up is down, although I have "natural scrolling" turned off); Firefox doesn't support the global menu bar any more; and so on.

It seems to me that a lot of modern desktops are removing features, or changing features (like the disappearance of menu bars), because people today don't know how to use them. Since they don't know how, they don't use them, so they feel that these features are not important, so they remove them.

Similarly, Windows 11 has now lost support for vertical taskbars. KDE has it but it's broken, as it was in GNOME 2 and now is in MATE. Cinnamon has a crude form, but it can't arrange status icons in rows, only in columns, which wastes a huge amount of space... but I suspect they've never seen a vertical taskbar, so they don't know how it should work.

https://imgur.com/gallery/fLeAy

Re: Essence: Desktop operating system built from scratch

#290

Post by yencabulator »

ninjanomnom wrote: post #285
cryptonector wrote: post #282

Earlier quoted context omitted.

I don't see why "size gained if deleted" "does not [care about links]". What I've learned in my experience with ZFS, Lustre, and other filesystems is that the user simply cannot get what you're asking for, not with any kind of real reliability. For distributed filesystems (like Lustre), the kind of thing you're asking for is simply ETOOHARD or ETOOSLOW. It's very easy to insist on a solution, and very hard to get one…

> I don't see why "size gained if deleted" "does not [care about links]". Deleting links does not give you any additional storage space beyond the minimal amount taken up by the link itself. As for existing filesystems, yeah they're going to have problems as they're built on filesystems that for the most part are polling. I'm not insisting on a solution or saying existing filesystems need to use this though, this is…

Deleting the last link does. All the links are equal, any one of them could be the last one remaining.
Post reply on HN