1. Component Bundling and Abstraction in Leitzentrale
Currently, launching components requires knowing the specific hardware topology (e.g., selecting the exact Intel or AMD GPU driver, or choosing between software rendering and hardware acceleration).
It would be incredibly useful to introduce Component Bundles or Profiles in the Leitzentrale.
Abstraction: A bundle would abstract the underlying hardware. An end-user should only need to know to bind to “Graphics Stack” or “Window Manager,” not the specific driver.
Developer Defaults: Bundles could provide sensible defaults set by the component developer. Users could simply inspect and confirm these defaults, or tweak them, rather than manually wiring the graph from scratch every time they instantiate a component.
Audio parity: The same logic should apply to audio (e.g., selecting “Microphone Input” rather than hunting down the specific route between the microphone driver and the mixer).
Inspection: While this would clean up the Leitzentrale and make it much easier to understand at a glance, users should still have the option to expand a bundle to inspect or modify the individual underlying components and their specific settings.
2. Inline Component Documentation (“Man pages”)
Tied to the Leitzentrale improvement, it would be highly beneficial to have a lightweight “man page” feature built into the component model. Allowing components to include a short description or usage hint that can be viewed directly in the UI would save users from having to drop out of the Leitzentrale to consult heavier, external documentation just to understand what a specific component does.
3. Build System Ergonomics
The build system tooling could use a few Quality-of-Life improvements to reduce friction:
GPG Signature Errors: When building from a fresh git clone, signature mismatches occur because the developers’ GPG keys aren’t in the user’s keychain. The error message currently doesn’t explain this. A simple hint in the CLI output (e.g., “Signature mismatch: you may need to import the developer’s GPG key”) would save a lot of head-scratching.
Bulk Hash Approvals: When updating packages, the build system often stops on a missing hash. You fix it, run make again, and immediately hit the next missing hash, repeating this 20+ times. An option to automatically approve new/updated hashes (perhaps via a flag like --accept-new-hashes) would streamline this process immensely.
Tooling Transparency: It is currently very difficult to know what inputs make takes within a build directory, where those inputs originate, and how the recursive Makefiles interact. Documenting the flow of the build tooling—or providing a way to visualize the input graph—would make the system much more approachable for developers wanting to understand the internals.
4. Sculpt OS Runtime Feedback and Error Recovery
When transitioning from ramfs to usbfs on real hardware, I’ve noticed that packages frequently become corrupted. Currently, the only way to fix this is to navigate to the ‘+’ menu, find the component, and manually click “Reinstall.”
Suggested Fix: When a component lights up red due to a corrupted archive after a filesystem transition, the Leitzentrale should present a “Reinstall” or “Repair” action directly in the component’s context menu or error popover.
5. Documentation Discoverability
Finally, I want to offer some feedback on the current documentation structure.
Consolidation & Discoverability: The documentation feels heavily fragmented. A new user trying to figure out how to use Sculpt OS will naturally look at the main “Documentation” page on the website and try Genode Foundations, then Genode Applications, then Genode Platforms—all of which are the wrong places. Crucially, the actual “Sculpt 26.04 documentation” is completely absent from the main Documentation page. Instead, it is oddly hidden under Downloads > Pre-built Sculpt OS images > Instructions. If you don’t know it exists, it is virtually undiscoverable. Migrating this into a single, unified, searchable Wiki would be a massive improvement.
Stale References: Because the documentation is so scattered, errors slip through. For example, the Sculpt 26.04 documentation still points users to GitHub, despite the migration to Codeberg. A centralized, searchable documentation platform would make it much easier to keep references up to date.
Centralized System Configurations
On a broader scale, it would be nice to have a more centralized place for managing system-level user configurations. Currently, things like keyboard shortcuts and Wi-Fi passwords can feel scattered across different components. A central panel or dedicated configuration hub for these common settings in base Sculpt OS would greatly improve the end-user experience.
Dynamic Component Interception (Long-term)
As a more forward-looking feature, it would be incredibly powerful to have a mechanism to dynamically “plug-in” a mediator component between two existing modules directly from the Leitzentrale. By temporarily re-wiring the graph to route sessions through an interceptor, users could achieve advanced workflows without manual HID editing, similar to the current inspect functionality, but expanded:
Per-component Firewalling: Inserting a filter between a specific component and the network stack.
Traffic Inspection: Sniffing or logging a specific component’s network traffic in isolation.
Memory/State Debugging: Taking ownership of a component by inserting a debug parent node, allowing for deep memory inspection or fault injection.
This would effectively turn the Leitzentrale into a visual, runtime debugging and security policy tool.
Ecosystem Note: Android Translation Layer
Finally, I recall there has historically been some interest from the Genode team in the possibility of running an Android runtime. I was wondering if you are aware of the Android Translation Layer project ( android_translation_layer / Android Translation Layer · GitLab )?
@User123 did you ever try to run the Sculpt system or read any existing docs yourself?
For some reason your questions don’t make much sense and look more like AI slop thing.
So as not to be unfounded lets go through points you raised:
Where exactly do you see a selection between Intel or AMD GPU drivers per se? Are you talking about selecting services a component requires? Did you try to use presets and options? These are the “Profiles” and “Component Bundles” you are looking for. By carefully reading and following the single-page introduction you wouldn’t have this question at all Genode - Sculpt Operating System 26.04. On additional note: the goal of Leitzentrale is not to be “clean” but to provide a full unobstructed control over the system to a user. If you want to “clean” it, mb you don’t need that level of control at all, mb this is not the system you are looking for?
There’s an ongoing documentation scarcity and fragmentation in the project, that’s hard to deny. But once again, reading through the main 1-page article should be enough to understand how to deploy the components + each component in the depot already has a 1-line description of what is it. Yes, this is not a “man page”, but feel free to suggest how exactly it should look and work in the Leitzentrale.
What exactly did you try to build and what for? It’s totally unclear what make you are referencing to
On GPG Signature “issues” - it looks like you are not familiar with how PGP works. There’s nothing in the world that will make any public signature magically appear in your PGP keychain. Mb provide the exact build command you used and what output confused you?
What exactly do you mean by “transitioning” and “corrupted”? Where did you see “Reinstall” button in the “+” menu at all? Sorry mate, but this is a 100% AI gibberish.
You are rising a documentation issue for the second time as a separate topic - a typical thing AI would do. It doesn’t mean there’s no issue, but please read thoroughly at least 1-page Sculpt OS introduction. As with any new OS be prepared to spend some time and efforts to understand the system. Even jumping from Linux to FreeBSD is quite a journey despite of both sharing the same core Unix-philosophy. And Genode/Sculpt OS is a completely different beast: it is unusual, it requires a certain level of user sophistication to build your system and if you need more details you’ll have to read some sections of the Foundations book.
I’d suggest you to adjust you expectations here: SculptOS is not a “Generic Home OS” that tries to be “intuitive” and “user-friendly” or to be familiar to any regular Windows/Mac user. At least not at the moment. Treat is as Arch or Gentoo Linux, that you need to compose by yourself for you liking, rather than something Ubuntu-like.
Maybe you would share what exactly are you missing currently?
For a few github references on the Sculpt one-pager - good catch. Though it should be easy to see on the repositories pages where they migrated…
Leitzentrale is that place you are talking about. Also there’s no such thing as “common settings”: each setting belongs to it’s component. And if you want to suggest a different approach, then first of all you have to define what is “common”. Secondly, by coupling “common settings” together you effectively loose the system flexibility: the “common” settings require “common” components to be always deployed to make sense while leaving “other” components and settings out of favor. IMHO this is even more fragmented than the current approach.
Explain what do you mean here? As far as I can see you can re-deploy and reroute any component as you please without touching the HID files at all. You can totally deploy any “man-in-the-middle” component that will do what you want. There is already a nitpicker/wm example that does that. But if you want certain features, here’s the current situation: Per-component Firewalling: use nic_router (find documentation in the repo). Traffic Inspection: nic_router Memory/State Debugging: you can use GDB if you need (I didn’t use yet, but docs are out there).
What else do you need?
There’s also waydroid, yes. Be my guest to port any those to Genode Though you will heave to read through Applications book also to do this.
Genode team has it’s own priorities, and running Android runtime is not among them (yet?)
It is not uncommon and (I’d dare to say) even encouraged that Genode/SculptOS users port or create new components for their needs. Contributions are welcomed!
Not sure why you are so upset about suggestions about how to make things more user friendly while still retaining the same features. Yes i did read the book and articles, and I did refer to how a man page like system could be useful to have offline on the system, as the feature set grows, as it would be easier to get a quick overview/review of it features and implementations. I then referred to having a documentation of the framework instead of multiple books and scattered articles - which is not the same thing as a man page.
Yes, you can have presets and options, and yes the idea of the Leitzentrale is to be transparent and give a overview of the system, but this won’t scale, being able to toggle what you want to see in groups will give you the same overview, but now you can actually see where things point to if you end up actually running a lot of components inside genode rather than using it as a hypervisor and vm starter.
I believe I just did, let components ship a man page and add a button in the Leitzentrale to open the man page.
I don’t get why you are doing personal attacks, i just said it would be nice to add some improved feedback in the cli when building sculpt for the first time on a new system - “echo You might need to add the developer’s key to you gpg chain at $PATH”, instead of just saying hash mismatch.
Nice try, but this legit happened, i setup some stuff on ramfs while following the sculpt os article, and then when i got to the usb part, all previously added components from the presets broke, and had some error, and could not be fixed by removing the components and adding them again from the preset, but when attempting to install it from the + button did provide a reinstall button or whatever it was called. But thanks for being a toxic asshole about it.
You clearly think you need to slay some evil shit here. I pointed out there are some structural problem with the current approach, and this was just a low hanging fruit, not that i cannot figure it out myself, but that this can be done with less effort from both the users and the developers, by just making a centralised and searchable documentation, so people don’t have to ask the same questions again and again and developers won’t have to answer the same questions again and again. Ideally structured with less story telling and more short and precise.
Leitzentrale is a visual representation of the config files behind the scenes, and asking for some of these files to ref a centralised config file for certain things, say keyboard behaviour inside the base system.
Yes, you can remove a component and wire it up again to get the features, and yes you can go into the hid files and manually change the wiring, it was just a suggestion to add the same feature which the HID files has, directly inside the gui. Also, what is interesting is being able to inspect and alter the state of a component without the component being able to know it is being affected, unless it implements advanced tracking of its internal states.
nfeske did mention this in a talk at some point, so you are wrong, interest has been mentioned, and no waydroid would not be the same at all, as you might as well run a vm at this point since you aren’t running the Linux kernel. I just came with a suggestion of interesting project which help translate system calls, and other runtime features, thus not emulation.
Hope you stop hating so much and have an open heart and mind in the future.
Well, I’m upset about, IMHO, the AI-generated “list of complains and wishes” from a user that just joined and posted this as his first contribution to the project.
And while reading through those I hardly believe a real person after reading the Sculpt OS introduction, the Foundation book and actually putting his hands on the actual system could still have such misleading basis for a half of those points…
Though I admit I could be wrong about this, will see.
Now back to the points:
I don’t see any big issues with scalability so far. In worst case scenario a user would have a dozen of components deployed on top of what he have initially in Leitzentrale which would be harder more that 2 screens to scroll vertically. After all Leitzentrale is an administrative tool, that is meant to be used occasionally - most of the time user will spend in the apps. Though I’m curious, could you please elaborate more on the specific scenarios that you think would illustrate Leitzentrale scalability issue?
Also please be more specific on what exactly is your suggestion. So far it’s so abstract there’s almost nothing to discuss
Ok, this is a good one, and now makes sense. There was already a thought on that in the depot package format to include such pages, to be later presented to user somehow. I think it just lacks the priority and/or resources for implementation atm.
Sorry, mb I was too harsh on this, assuming this was AI-generated text from someone who didn’t even try to scratch the surface. At least now it’s clear what exactly you tried to build Why not create a PR if you know how to fix this?
Nice try for what? Some things are missing if you’re reporting a bug here, tbh: What Sculpt image were you using: one of the official ones or the one you built yourself? Did you take into account, that /depot on the usb doesn’t have all the packages you downloaded to the ramfs unless you explicitly copied it before switch? Also once you detach used FS (to switch to USB) you naturally loose access to depot and thus the components that were relying on it would show an error…
“Toxic asshole”, “Slay some evil shit…” I really hope you were just having a bad day and not this personality…
Though on the topic: if it’s a “low hanging fruit” from your perspective, why not offer some help and contribute to the project instead of complaining?
It’s totally possible to combine what you need into a deploy file if you like. Though, personally I don’t see much value in doing that. I believe it’s easier to follow the same configuration pattern for any component in the system, than trying to remember which configs are “centralized” and which are not.
I guess it’s an area of personal preferences rather than an improvement area.
I’m struggling to get your point here. Do you mean to be able to rewire a component without removing it? If that’s what you mean, I’d also love to see this feature just to avoid searching the same component in the menu again if I just want to alter 1 connection Though by the nature of Genode (if I’m not mistaken) the component still will be restarted, due to it’s deployment change and will cause the other components connected to it to restart too. On the other side I guess there are very few use cases for that feature. I’d bake a component connections into an option to avoid manually wiring it every time I need to deploy it. One can even have several wiring variations of the same component with different names (like a browser for banking and another one for web-surfing) with recall fs isolated from each other.
Not sure what exactly you are trying to prove. Mentioning android in a talk is not a commitment yet. Just check this year road map: Genode - Road Map. Feel free to explore previous years road maps also to see if Android port was ever planned.
Though you are suggesting to bring this project to Genode, that might be very interesting, no doubt. I’m just not sure who you expect to do this at this point?
Honestly, I can’t help but feel that you’re either trying to teach the Genode team what to do or implying that they’re doing a poor job when you point out obvious issues or suggest “interesting projects” without asking for help or offering concrete solutions and/or assistance. Especially when you lump a bunch of completely different topics into one “list of complains”.
Wouldn’t it be more productive to start and lead each concern you have as a different topic?
Otherwise, it’s unclear where exactly you want to start and what you want to achieve?
I’m sorry if you feel hated because of an attempt to clarify your suggestions and concerns to make them at least make sense.
P.S.: On documentation topic.
As I mentioned already, this project lacks the novice-friendly documentation unfortunately: even the Sculpt OS introduction is full of highly technical details that can overwhelm even experienced geeks.
But well, that’s the price to pay for having a full control over the system instead of relying on some “common defaults” that were decided by someone else for some “generic user”…
Like you said, not an issue if you have a dozen components, but if you want to use it as a general purpose OS, which is the goal of Genode, then it doesn’t stop at a dozen, you can easily have hundreds of components running at the same time. I tried to come with constructive feedback, so suggested a low effort solution to the problem, a simple folder. You then replied in a condescending manner saying I need to read the manual and there exists no problem.
–
It isn’t clear where this gets handled inside the make files because they’re recursive and I did not find any documentation of them. I believe i could do a fuzzy search for it, but was just a quick mention which a developer with deep knowledge of the build system could easily fix.
I said the package manager breaks when switching from ramfs to usbfs for presets, resulting in packages being in a broken stage when they think they are installed but doesn’t have matching hashes, i would reproduce this if it didn’t take like an hour for my 64gb usb stick to expand on sculpt os. You replied by just calling it gibberish, as if this is purely imaginary and such a thing could never happen. I used the prebuild image for sculpt os 26.04. So no, it wasn’t just that everything had to be redeployed again, the package manager straight up broke.
I mention the documentation here, as before I mentioned some man page like structure for a quick overview, not as the main extensive documentation. You then go on a condescending rant about how mentioning documentation twice shows everything I said should essentially be disregarded, and I clearly didn’t spend enough time learning the system, and all systems has a learning curve and sculpt os / genode is exactly the same. If you ask me genode and sculpt os doesn’t actually meet the formality to be considered having a technical documentation, but rather a loose structure of long guides in the format of books and articles. I was suggesting a consolidation as this would be more maintainable and users would know where to go, rather than having to go down a list of nodes. For example if you want to learn about how to use vms on the platform, it doesn’t describe it in sculpt os documentation but instead list relevant articles under Further exploration > Use GNU/Linux inside a virtual machine on top of Sculpt. Can a person eventually get there yes, but such articles will get out of date, and it requires a lot more steps, and thus more time.
I for one is not a fan of the default hotkeys to go in and out of the Lietzentale, nor how you switch to a new desktop, I don’t suggest to impose my preferences, but rather have a centralised way of dealing with it. Here I might be mistaken, but it appear vimrc also gets a special treatment, maybe we should have a config flag/folder like structure, so when passing config files to components we can select configs, and then which config folder we want to expose to the component, and if we want ro or rw.
I originally mention it could be similar to inspect, which does “insert” itself into the component, and there is a huge difference between having to momentarily rewire something, and pulling something completely out and having to do all the rewiring again. It is simply a quality of life suggestion. I am aware that the components do get restarted when rewiring them, which isn’t a problem, but some programs do have certain mitigation against debuggers, and circumventing a whole class of such mitigations by existing on a higher level could be useful.
Here I simply mentioned it in case they were serious about wanting to port the android runtime, which would involve a translation layer. Then they could possibly piggy bag on the aforementioned project instead of having to do it all from scratch.
On your final note, giving constructive feedback and suggestions isn’t telling someone they are insert bad word, but simply a potential help, as people encounter certain problems due to having different workflows. A list of complains would be stating i think something is bad, full stop. Constructive feedback is suggestions for how things can be even better, doesn’t even mean things are currently bad.
Your post scriptum again is very condescending, and implying the user simply cannot understand such technical marvel, and having full control over something can only result in what is, and no improvements can be made. Which is obviously wrong.
Ok, at this moment I’m tired of trying to discuss 8 different topics at once. No offense, mb someone else will be willing to continue here…
My constructive feedback to you on this:
It’s better to have a dedicated focused topic on something specific you want to see changed, where you can clearly explain your thoughts and ideas.
I’m sure you probably have some interesting solutions ideas, mb just struggle to express them. (E.g. point number 7 is still unclear what exactly you suggest, taking into account Inspect tool is to inspect FS only, by starting a minimal “busybox” environment to access the files )
Just 2 additional notes:
Why it looks like a list of complains is just because you rise a new topic with a number of points while some of those were already raised in older dedicated topics with ongoing discussions (like documentation) and give unclear or very vaguely worded suggestions (note how many questions I had to ask you to clarify them).
You missed my point here.
It’s not the Genode/Sculpt OS that is the technical marvel hard to understand here - it’s the computing platform itself (PC) in all its details and variations.
To gain a full control (i.e. know every part of and how it works) over the system there’s no other way for a user than to educate himself on the topic, period.
Of course it’s possible to drive a car without knowing how it works inside, but it is not a full control over the system.
Is the current documentation sufficient to achieve the goal of the project (giving a user full control over his system)? Yes.
Could documentation be improved? Certainly Yes too, but a user still have to learn the same number of subjects.
Could it be simplified or stripped down to attract more “I’m just driving” users?
Sure it could, but it will be missing the main goal. More over the current system doesn’t imply any of millions “I’m just driving” scenarios to use.
That’s why it has sculpt in the name - you have to build it towards your personal usage scenarios and/or for your personal liking.
And if you want to have a “distribution” with a specific scenario ready for “just driving” by “average users” - feel free to sculpt one and give it to them.
IMHO, it’s even easier to achieve with Genode than building your own Linux distribution.
For example, the Sculpt 26.04 documentation still points users to GitHub, despite the migration to Codeberg.
I’m always grateful whenever someone points out mistakes or inaccuracies in our documentation. However, this particular example is not an error. Please note that the current version of Sculpt (26.04) was officially released in April, before Genode’s git repository was migrated to Codeberg in May. So the steps for reproducing the official image are naturally referring to the git repository at the time of release. This is intentional.
Unlike a wiki, the Sculpt manual is not a living document but a historical record (like the manuals of all previous releases). People who want to stay on the heels of the development in-between releases can find the current version of the text in the public git repository. The links were updated to Codeberg two months ago.
On a personal note, please consider that the tone of your original posting may be perceived as impolite, which is probably the reason for the tone of @G0retZ reply. Personally, I would not even have bothered to reply to such an overgeneralized and AI-smelly statement of opinion.
A more sensible way for positively interacting with our community is to present your interests in the form of offerings, not demands. For a perfect example, topic Emacs major mode for HID makes an offering for people who prefer Emacs over Vim. How cool is that! Even though I’m not an Emacs user, it made me so happy, and it actually spawned my curiosity in Emacs! If the interest in Emacs had been articulated in the form of a demand, it would have been perceived as a mere distraction with no positive effect on anyone.
Granted, an offering is much more expensive (in terms of effort) than a demand. But it is also much more valuable.
I agree that some of the points could be more informed, like the Sculpt release day and the official migration.
I see how naming it feature requests rather than suggestions in the title can make it come across like demands, which wasn’t my intentions, but beyond that I fail to see how it is offensive.
I understand the goal is to have a historical record for each version, but this doesn’t prevent having a wiki styled documentation, or having something more searchable. One example could be https://rmk.rs/main/docs which enables one to select the specific version.
While coming with ports and offerings is definitely useful for the general development, I do think it is fair to raise a conversation about certain choices. Fragmented documentation does pose certain problems, and implementing a standard myself as an offering, is not a standard, and thus not very useful on its own. Only makes sense if a community chooses to go in a certain direction.
Exposing some additional information about components in an offline capacity is again a design choice, but I guess I could modify sculpt manager on my own and begin maintaining the documentation on my own, but again makes more sense if it is a community choice.
I could of course make the bundle/folder idea my self in my own sculpt manager, and same with exposing the already implemented reinstall feature directly on the component graph.
As can be seen, there are certain things where doing something on your own and sharing it makes very little sense, but sure you are right there are also cases where it makes sense.
But since it is offensive to come with suggestions and ideas, let me come with another one… How about an option in sculpt when you press a component you can directly open the HID file for the component instead of having to navigate to the already identified component through the file explorer gui or a terminal?
Have a nice day
Though you will heave to read through Applications book also to do this.
Why not create a PR if you know how to fix this?
menu again if I just want to alter 1 connection 
