Desktop Environment

I also see having a desktop environment as priority, and I have already made some progress in that direction. I have my plans along those lines, and if anyone wants to discuss details, I'd be happy to do so in another thread on this mailing list. However, I have run into some hurdles that I could use some help with. In particular, to enable easy IPC with libc-based applications, a named pipe (FIFO) VFS plugin would be extremely useful. I wrote one myself, only to discover that the VFS and File_system interfaces do not adequately support partial writes, as needed by such a plugin. With those interfaces reworked, I would happily modify and provide my VFS FIFO plugin code, as well as my Libc pipe plugin that uses it as the backend.

My other main technical hurdle for creating a desktop environment has been converting the init component into a library to allow for easy customization beyond what is possible through configuration files alone. The current method of writing a monitor component to read init's state and modify its configuration works fine for simple cases, but it has performance penalties that can range from mild to severe. The configuration parsing overhead grows with the number of child components, which isn't ideal, but the real show-stopper that I see is dynamic quota management. Each quota upgrade has to wait for a new report, and reports happen at regular intervals, usually every second. Thus multiple quota upgrades, e.g. from opening one or more new web browser windows/tabs can take several seconds. With an init library, such upgrades could be handled very quickly. I can handle this particular issue myself as soon as it becomes a high enough priority.

Hardware Support

Aside from a desktop environment, hardware support is another likely show-stopper for new users. I've been working on this myself, and hope to be able to make Genode/Sculpt usable on my new desktop computer in 2019. I accept that support for my hardware is mostly my issue, but improvements in debugging tools and documentation would help a lot with this.

Debugging

As for debugging tools, I suggest building both remote (serial and/or (W)LAN) and on-screen GDB component debugging scenarios. This would help with many other goals, and might also help make Genode more attractive to developers.

Package Management

I'd like to second and add to what ttcoder said about package management. It would be very helpful to provide a way for Sculpt users to discover and add depots. This would increase usability, and would encourage developers outside Genode Labs to write and port more software for Genode.

Currently, depots don't provide package or launcher lists. Ideally, I would like to see Sculpt have an option to fetch the latest launchers from the repositories selected by the user, allowing them to easily discover components. This would also fix the issue I've seen with Sculpt launchers expecting package versions only available locally on the build machine. Currently, when I modify a component used by Sculpt and update its recipe version, Sculpt expects my new version to be available from depot.genode.org. If a launcher list is fetched from the Genode Labs depot (possibly with a correct default launcher list provided in the Sculpt image), this problem will be solved.

Performance

All current Genode scenarios (AFAIK), including Sculpt, run almost everything on a single hardware thread. An SMP balancing component would dramatically increase performance (and likely responsiveness) on modern multi-core CPUs. If nobody else gets around to it first, I'll probably write such a component, but if anyone else here more familiar with Genode's scheduling mechanisms is interested enough, they can probably write a much better implementation than I would.

Summary

In short, I'd like to see the following things on the 2019 roadmap:
1. Rework VFS and File_system interfaces to support partial writes, as needed by FIFOs
2. Interactive local and remote GDB debugging scenarios for real hardware
3. Depot and Launcher discovery for Sculpt
4. SMP balancing component
5. Improved documentation

We don't all see eye-to-eye on how a desktop environment should operate, so I'm particularly interested in getting help with (1) so I can make more progress on writing my own, and with (3) so I can make it easily available so others can try it out and give me feedback.

On Mon, Dec 24, 2018 at 8:42 AM <ttcoder@netcourrier.com> wrote:

As a newcomer I should probably step up to the plate, while the 'first impressions' are still fresh in my mind.

I'm still making baby steps; but based on past experience I should hit the ascending part of the learning S-curve soon and become
productive.
Still have tons of documentation to read before I'll feel half-literate about Genode (it seems to be made of just a handful of ground-
breaking principles, but in practice they have such far-reaching consequences that it takes some time to get "fluent" with all
ramifications). Hopefully some of the below makes sense anyway. This much is sure -- as we say in french, if Genode didn't exist,
someone'd have to invent it *g*.

My whole C.S. perspective (and thus also this message) is haiku centric. So each question & concern will be addressed from that
perspective. Hopefully this will bring value to the discussion in at least a few of the cases, if not all. Criticism welcome.

Not much I can add (other than a deep sigh *s*) as to why people don't adopt superior technology in higher numbers.. As a frequent
'early adopter' type I've seen the same thing over time. People stick with the familiar as being "good enough".. Been guilty of that myself
too. To be fair though, people who download and run Scult/VC currently are greeted with the leitzencentral, not with a desktop (or what
in Haiku I call "a userland"); so the Genode team would need to develop a 'userland' on top of leitzencentral.. In order to go beyond the
technological demo, and instead produce a general-purpose OS demo. More on that below.

I'll now 'do my part' with Genode though: will open a micro-blog in a few days about my technical forays into Genode, my mistakes and
misunderstandings and how I solve them.. So that others will save time. Including some additional thoughts on this email thread -- to
help keep this message short(er than a novel).
Once I have more exciting news items in store, I'll give my micro-blog wider circulation, on the haiku forums (they don't have a gigantic
readorship, but they are very enthusiastic early-adopter types so likely worth the effort). Waiting until I announce "our flagship app
runs on Genode" will carry more weight.

When doing (low key) advocacy in haiku forums, I'll leverage the cultural aspect: in the haiku crowd, they/we adopted Neil Stephenson's
saying that we're using the "batmobile" of operating systems: I'll build on that by saying Genode is potentially the "UFO" of operating
systems, out of this world :-)

Will give back to the Genode community probably in a similar way I did with Haiku over the years (tickets e.g.). If I had to help out with
the "challenges" page later, I suppose it might be with the MAID-SAFE part (decentralized internet). But even if within the edge of my
abilities, I would have to get a lot of ducks in a row first. Their litterature mentions developing in something called "electron" (?) whereas
I'm most productive in C++ coding against my beloved "Interface Kit".


*******

Finding the way:

> The unconquered design space seemed vast, which was
> both exciting but also - at times - a bit paralyzing.

This might relate to a similar topic I have in mind these days: if e.g. the genode team does not come up with an "official" desktop but
leaves it to the community to do (several) implementations, we might end up with the fragmentation that is prevalent in the Linux world:
there are many "distros", which I hear are more or less (sometimes "less") compatible with each other.

The way this decision making difficulty has always been addressed in the Be/Haiku world is something like, "choose reasonable defaults",
"allow some (limited) easy customisations", and "keep power-user customisation accessible but under the hood".

On a related note, I've also noticed over the years that OS designers are often bad application designers, and vice-versa. I guess the point
I'm trying to make is something like, "if you want a rich userland, make an SDK that is a joy to use and help app developers help you" :-)

Of course any SDK design decision has to be weighted with the absolute Genode priorities: security, stability, separation.


*****

Concrete ideas for "spreading the word" on packages:

The single biggest issue I have with the 'depot' system and packages in Genode, is the lack of an introductory paragraph, explaining what
each package is about.
Small potatoes, right? Power users probably know software names by heart in their sleep? But there are lots of intermediate-style users
who don't. It does make a difference.

Do note -- said texts can be simply copy-pasted, as they are in the example below with haiku recipes. There's no word-smith work
involved at all. Just a matter of extending the depot format with a new field, and pasting pre-existing texts into that field. Especially
important, taking into account that the genode depots are destined to grow into the hundreds of packages (I'd hope) or more, over the
years.

On a secondary note, packages should probably be organized by categories, with both a one-liner label and the paragraph-length
description mentionned above.

For comparison purposes, here's a similar recipe, as done by Genode and by Haikuports:
        https://github.com/genodelabs/genode/blob/master/repos/ports/ports/arora.port
        https://github.com/haikuports/haikuports/blob/master/www-client/otter-browser/otter_browser-0.9.99.3.recipe

For how it looks on screen, see the screenshot below.

 ***

Regarding the need to "get the word out" re. the existence of packages, and the fact that people's efforts tend to remain below-the-radar:

There should be a central depot manager, with a very easy way to add third-party repos (depots).

E.g. in the example I am familiar with,
        https://www.haiku-os.org/docs/userguide/en/applications/haikudepot.html
one just has to invoke Tools > Manage Depots, add a new depot URL, and you may immediately download (and run) whatever is in that
depot.

Those URLs are not 'auto discovered' though, one still has to read up about them e.g. in a discussion forum: someone would announce
"I've created my own depot with my own app builds, here it is, use at your own risk". Then it's up to you to copy-paste the depot's address
in the depot manager. Either that or, using a terminal, I'd type "pkgman add http...some-repo-here", and pkgman downloads the metadata
and from now on "pkgman search foo" will return results also from that newly added repo (depot).

 ***

The "spreading the word" problem goes beyond just packages of course. In the haiku forums I sometimes learn about interesting uses of
the OS that get no publicity (i.e. people keep them mostly under wraps) beyond a post here and there on which I stumble by chance.

A decade back, I have memories of that kind of problem being addressed by an enthusiastic supporter setting up a full fledged blog, doing
journalist-like work, interviewing people, welcoming guest articles and the like. Maybe something like this would be needed for Genode,
by someone who wants to help but cannot code.


******

"Build it and they will come"

Now I have to tread carefully but... A sine qua none condition (for me at least) for helping to make the 'userland' happen, is a good --
strike that, a *great* -- GUI toolkit and app framework.

Qt seems to have become almost an industry standard.. But the documentation alone is dozens of MB big; at least that's how big it shows
in the haiku depots here:

        pkgman search qt5
                ...
        qt5_devel                A comprehensive C++ application development fra
        qt5_docs                 A comprehensive C++ application development fra
        qt5_examples             A comprehensive C++ application development fra

Not to mention the runtime itself:

        ~/Desktop> ll /system/packages/qt5-5.11.2-4-x86_64.hpkg
        -rw-r--r-- 1 user root 45810197 oct.  20 17:56 /system/packages/qt5-5.11.2-4-x86_64.hpkg

For that, and for other reasons I guess it will not be used by Genode as its "native" API of course. Looking at the nitpicker code seems to
confirm that in spades.

To my (biased) eyes, the Be/Haiku API (organized in "kits") compares favorably to what I have seen in my coding life (incl. Java: the JDK is
so broad and powerful.. but also of a more difficult access). There are some imperfections (BMessenger in the app kit, some aspects of the
InterfaceKit, the Media Kit) that should obviously be fixed by whoever uses that API as inspiration. But it could indeed provide some
inspiration to Genode. Developer should be able to tap classes like BButton, BMenu, BListView, automatic font-sensitive layout and the
like. Modernized, cleaned up of deprecated calls, wrapped in namespaces instead of polluting the top namespace of course. Reading the
source code of demo/scout and of sculpt/ I see lots of familiar things (repaint() is what I call Invalidate(), Window and
NitPicker_Connection seem to be what I call a BWindow ..etc) but there's a big gap to fill.

Anyway, work will start soon on 'porting' the kits to Genode.. Will do some micro-blogging about it, post screenshots (still haven't found
how to do a screen grab in Sculpt BTW.. now realizing maybe this is un-implemented on purpose, as it poses a security risk?) and the like,
in case it's of value.



==================

So in short, history hints at an interesting (but not fail-proof) recipe for adoption: make the OS "sexy" with a "killer app", such that a core
of enthusiasts will be drawn to it and refuse to use anything else.. Then make the API "sexy", so that developers will flock to it and develop
more apps.. Then build on all that energy to add features that make it attractive to a wider public too, not just early adopters.


Extending on the "genode in one year time" topic:

By year 2019's end I would be very happy if..

- I've gone "cross platform", my apps can be compiled against both Haiku and Genode with little if-def'ing, thanks to adding a
compatibility layer 'bridging' the userland API I'm used to and which (to me) is close to perfection.
- The systems we are selling are running TT-CC on Genode, customers are happy.
- I've started using Genode for non-coding day to day tasks (reading the news with arora? relaxing with Midwinter on dosbox ?).
- I've made some progress toward using Genode as a "self hosted" coding system.
- I've convinced at least a few in the Haiku community to take a look at Genode, and that working together could be a win-win rather
than a competition or a zero sum game.
- Tapping that "reservoir" of early adopter types proves to be a good idea, bringing developer and user resources to built momentum (to
both OSes).
- I wrote some code and uploaded it to chiselapp.com (probably MIT-licensed) that can be useful to others for day to day use of Genode
(lots of potential for writing apps, with the right SDK.. With the Be/Haiku API  I can build a skeleton app in a day; maybe others would
follow suit ..etc).


My 2 euro-cents,

Cedric @ TTS





_______________________________________________
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users