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 _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
