Hello Edoardo,
thanks for your feedback on Sculpt OS!
======================= Language Compatibility =======================
*) there is no support for Italian keyboard, I was able to find only german, french and english .chargen files, for a next update would be great to add other charger files.
You may find our xkb2ifcfg tool [1] useful as a starting point. I'd welcome a patch with a known-to-work chargen file for Italian keyboards.
[1] https://genode.org/documentation/release-notes/19.08#Flexible_keyboard_layou...
*) I can give my full support for translating document pages in Italian, this could (apparently) be great for increasing the possible audience, but Honestly I doubt that an Italian community could be created (we are quite far in the security-technological field, No comment on that, please).
Thank you for the offer, but intuitively I share your doubts.
For the highly technical target audience of Genode and Sculpt OS, I think it should be ok to assume English reading skills. Note that - even though most Genode developers are German - we don't offer German documentation either.
That being said, I don't want to keep you back from hosting and supporting an Italian edition of Sculpt OS.
======================= BEGINNER FRIENDLY OS? =======================
*) I know that this operating system is not developed to be user friendly, but it could be great to put some helps for beginners, like a graphical instruction box when clicking on certain things in Leitzentrale, a graphical example could be the following:
|------------| |-------| | depot | (when clicking on it appears an info box) --> | info | |_______| |-------|
(sorry for the bad ASCII image)
I actually intended adding such a context-sensitive help feature along with other usability improvements such as keyboard navigation, but I haven't made it a priority for now. Let's face it: there is no way to appreciate Sculpt without at least reading the documentation. Adding some hints here and there would just pretend otherwise. Making the UI fully discoverable without the need to read the manual would certainly be cool but it would be a tremendous effort. I think other topics are more worthwhile to focus on (https://genode.org/about/road-map).
======================= GRAPHICS =======================
*) Probably the best point for your os consists on its graph graphics, the idea of Leitzentrale is innovative if we confront it to Windows os or similar, a small hint could be to create the same style for the "file" part, so something which could be similar to graphviz2 output instead of "block representation".
With the nice implementation of the graph in place, this was indeed tempting. I still decided against its use for files for the following reasons:
- Giving each tab a distinct appearance avoids mixing things up. The files tab is unrelated to the component graph. Unrelated things should better not look similar.
- Whereas the component graph is interesting due to the transitive dependencies, especially when clicking on a component that uses many services, a file graph 1ooks boring because each file has merely one parent. So the graph would not be able to shine with its beauty anyway.
- The number of components is relatively low compared to the typical number of files present in a directory. So a file graph would probably become a noisy mess. I'm afraid it would look forced.
However, if you have ideas, please don't hesitate to try them out! I'd love to play with alternatives. Maybe, you could consider providing an experimental file browser as an installable package to let others like me evaluate your ideas?
*) small consideration: I find some graphical glitch in the "motif decoration" 's node in Leitzentrale (it flew up and down without any input) [Still studying this..]
If you have instructions to reproduce the issue, this would be very much appreciated.
As far as I am aware, such glitches can happen whenever a component has a dangling route. E.g., when killing a server that still has clients, the sessions of its former clients are going to nowhere. Such a client's graph node tends to behave a bit "erratic" in this situation.
======================== TERMINAL DOWNSIDE ========================
*) Using the inspect shell I wasn't able to scroll up, do you know if it's implemented? It should be better to have a scroll bar,
That's not implemented. The inspect shell will be removed at some point. Once the file browser will able to perform basic file operations like copying or renaming files, we can drop the inspect tab. See [2] for the bigger picture.
[2] https://genode.org/documentation/release-notes/20.02#Redesign_of_the_adminis...
For getting work done in the terminal, I think we should ultimately enable a feature-rich existing terminal implementation as a package. E.g., a port of a terminal based on the QTerminal widget.
[3] https://github.com/lxqt/qtermwidget
======================= DEPOT SYSTEM =======================
As I understood, depot is like a package manager and the various repositories contains various applications, Here I'll insert my ideas on it:
*) Many of those repos are inaccessible even if I am connected to the wireless network:
{ I am not able to download/fetch the following repos: [-] ehmry [-] blarson [-] rite }
*) in general there isn't much variety in the repos, many packages are the same, it would be great to extend the "candidates" list, I can contribute to the development of several CLI apps.
The list of candidates is simply generated from the public keys registered at [4]. I agree that the solution is quite poor because a user cannot really know what's behind all these strange names. If you take the articles at https://genodians.org as context into account, it makes a bit more sense because you can then draw the connections between authors and their depots. So if a developer like alex-ab publishes an article, you can follow his steps by fetching alex-ab's packages.
[4] https://github.com/genodelabs/genode/tree/master/depot
On the other hand, as you noticed, not all developers who have registered their public keys actually provide packages. So the user experience from a discoverability view point is rather poor. Maybe it would be better to remove most of the keys and implement a key-sharing feature so that one developer can ship the keys of other developers along with short descriptions about who is who, similar to a web of trust?
Anyway, if you like to be featured in the depot selection of the next release, please do not hesitate to issue a pull request with your public key and download location. Just follow the lines of the existing entries at [4].
*) I can work for inserting some scripting languages interpreter packages inside Genode
{ [-] Minised [-] lightweight Perl languages (microperl, miniperl or my customized languages) } and maybe adapt them for the OS needs and tasks.
That sounds cool. While being on the topic of porting software, let me point you to the Goa tool [5], which is geared to such work. I recommend following the article series by using the link at the bottom of each posting.
[5] https://genodians.org/nfeske/2019-11-25-goa
*) A quite interesting idea would be to add local depots, In general:
-->) We have 2 devices, (featured phones or similar) -->) The first is the client, the second is the depot server -->) through Bluetooth, BLE or even other standards (nfc??) could be cool to use the repository stored in the second phone into the first.
[ Obviously this is extremely complex to do: we should set a correct cryptographic key exchange and set an authentication rule, this could lead an ∞ of problems:
*) Hijacking or other Bluetooth attacks are possible, the worst case scenario is that an untrusted depot server can inject the device, bypassing the security authentication restriction. If this will be implemented, it MUST be well structured.
*) Not every device has the same bluetooth version, with some works it could be implemented a workaround which act like a switch statement:
{ example: switch(bluetooth_version){ case (version == 5.0 ) {do this} case (version == 4.1 ) {do that} } }
*) Obviously it must be implemented a tiny bluetooth subsystem, I suggest using Linux's one. (I have also the 2008-2009 documentation on it).
*) This idea could be a great topic for your blog, I can help with the formal verifications (pi calculus?) exposition and with other implementation details.
]
I'm afraid you lost me a little on this topic. ;-)
However, if you are speaking of a "local depot" as means to have a nested Sculpt system where a subsystem uses a different depot, that should be feasible. Should you want experimenting in this direction, you may find the depot_download and depot_deploy subsystems and their accompanied run scripts [6,7] useful to look at.
[6] https://github.com/genodelabs/genode/blob/master/repos/gems/run/depot_deploy... [7] https://github.com/genodelabs/genode/blob/master/repos/gems/run/depot_downlo...
Cheers Norman