General Improvements for Sculpt

[Norman Feske]

Hi Edoardo,

> Another few general considerations:
> the learning curve of Sculpt is pretty fast, I don't know why, but
> after few days I increased the feeling with the OS, the documentation
> played a fundamental role in it, Have you thought to implement also a
> touch screen mode for Sculpt? may be extremely interesting for
> smartphones.

Indeed. We plan to work on that throughout the year. Please have a look
at [1] (including a video) for a first glimpse.

[1] https://genodians.org/skalk/2021-01-16-genode-mobile-tech-demo

> One good point is the "inspect" shell, fast and portable, I like it,
> only one problem:
> too few tools under /bin are available, apart vim, there is not many
> things you can do with it, my idea for fixing that could be to add few
> more useful tool:

I already mentioned in a reply to an earlier posting of you [2] that I
have to disappoint you here. The inspect shell will eventually go away.
It is merely a stepping stone [3]. The system shell will prevail of course.

[2] https://lists.genode.org/pipermail/users/2021-January/007475.html
[3]
https://genode.org/documentation/release-notes/20.02#Redesign_of_the_administrative_user_interface_of_Sculpt_OS

> one idea could be the microsed implementation, it is around 25kb and
> permits to modify files through Regexp, only downside for this
> implementation: still many commands crashes (-e is an example).
> (sorry for the zip of the last time, I had not the idea of how peoples
> are suspicious on compressed files haha), the files are sed.h,
> sedcomp.c, sedexec.c and the relative Makefile;

We have a port of GNU sed already. One would just need to step up and
package a shell runtime with it, similar to the system shell.

> Another hint: upgrade the md5sum (maybe in the future) to something
> more secure, I don't know if Sculpt uses it for more complex (and
> security related) tasks but is strongly discouraged.

We kept md5sum merely as a tool to quickly calculate checksums. It is
handy when copying files from/to flaky USB sticks. It is not used for
anything important let alone security-critical.

> Final suggestion: One day I tried to install as much software as I can
> on Sculpt, the result was quite strange, I wasn't able to scroll down
> the Leitz. enviroment, do you know if is possible to do it?
> {
> the photo is
> 5ECB60B5-C98C-496D-9A9D-ECB617AD6809
> }

That's a known limitation. I agree that it is inconvenient, so I keep it
in the back of my mind. For regular Sculpt power users, it is not really
a pressing issue since the /config/deploy file can be edited directly
also (the graph is just a fancy frontend for editing this file).

> Norman,  As the first thing, I've started to port a working Italian
> layout keyboard, the current version is in the email attachment (file:
> it_IT.chargen), only problem, certain letters are unavailable (like è,
> ò, à, ù, § and £), could you try to fix it? the big works for upper
> keys is already done and tested, (everything works well).

Cool that you came up with an intermediate solution. I'm afraid that I'm
the wrong person to ask for fixes as I have never typed any of these
characters in my whole life.

Maybe - but that is just speculation - the issue lies not the chargen
file but that the font lacks those symbols? In Sculpt, we use a TTF-font
with Latin-1 characters only to keep the image small.

As a general direction, I'd encourage the creation of alternative
font_fs packages that satisfy different tastes and (Unicode-)needs. This
font_fs can then used by all components deployed on Sculpt. Sculpt does
not need to be modified for that.

> Another few things to ask:
> 
> Do you confirm that Sculpt, for now, has NO API or syscall available?

Confirmed.

> it would be pretty useful for me to write tools in C with a nice
> syscall system, my idea could be to implement a programming language
> designed only for this OS which offers both high and low-level
> capabilities, (like Inferno's os Limbo programming language), I've
> started thinking on it, if you agree, in the next days I can try to
> design the main body of it (in PURE c, the best by test).

The lowest level you can get on Genode is the use of the raw Genode C++
API. Even the C runtime lives above that.

I'd generally recommend to just use the C runtime when hosting C
programs on top of Genode. [In principle, you can of course interact
with the underlying kernel using system calls, using C. But this results
in programs tied to a particular kernel. It really goes against the
grain of Genode]

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