Roadmap 2019

[Nobody III]

*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 at 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 at lists.genode.org
> https://lists.genode.org/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20181224/96f483cc/attachment-0001.html>