general improvements for Sculpt
Edoardo Mantovani
mantovani.edoardo18 at gmail.com
Mon Jan 25 20:51:36 CET 2021
Thanks Norman and thanks Josef for the documentation,
I'll work on my ideas in the next few days, I'll put you at the
current as soon as I can .
Regards,
Edoardo Mantovani
Il giorno lun 25 gen 2021 alle ore 14:38 Norman Feske
<norman.feske at genode-labs.com> ha scritto:
>
> 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
>
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users
--
Edoardo Mantovani
Independent security researcher
email: Baseband at cpan.org
Urbino, Italy
More information about the users
mailing list