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_layouts
> *) 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_administrative_user_interface_of_Sculpt_OS
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.run
[7]
https://github.com/genodelabs/genode/blob/master/repos/gems/run/depot_download.run
Cheers
Norman
--
Dr.-Ing. Norman Feske
Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth