Software environment for robustness

[jwatte]

Hardware is cool and stuff, but I think a standard software environment will be just as important (and just as much work).

Thinking of the micros of the 80s, the fact that the OS was in ROM was great for robustness.

I imagine the RPi could be similar by providing a standard kernel and services, then an extension mechanism, then a user level environment. Booting would load in that order, with the option of starting without extensions to "recover" the system.

This is NOT init, or service. It's something else, and it probably needs a simple GUI for installation/uninstallation/management of extensions, and perhaps some simple auto-discovery mechanism. Config files are likely to confuse and break things. Make it simple to use and robust against user error!

Also, make the kernel and services and base system read-only. Mount only tmp, var and home writable. Perhaps symlink use/local to var/local? Some mode for system updates could write to the read only parts, but that should be very uncommon and not used to install third party software or extensions. Also, the user should never need to be root!

Opinions?

[jamesh]

At first its going to be a pretty standard Linux with drivers to access to GPU features - the Raspi team won't have the resources to do anything too fancy. That doesn't mean someone else cannot do it though....that's the point. You can use it how you want. It's a learning platform.

Since the whole of the system is stored on the SD card, it should be easy to have a spare card somewhere that gets you back to square one. Or have an SD card that boots to console, or one that boots to a GUI, or one that runs a specific app. The world is your lobster.

[ShiftPlusOne]

I don't understand what benefits of this are meant to be.

[jwatte]

The muffled of the 80s were not just products, but also a mindset and a community. The fixed software interface, the quick "clean slate," the self-contained-ness, and the robustness against user error were huge benefits for a learning device.

Multiple SD cards is not a solution, because that assumes an external device to copy SD cards on. If all you have is a single Pi, how do you guard against user error? How do you provide a single, known software interface so that a learner can type in a program from a magazine and expect it to work 100% of the time? For a robust device with a useful community of neophytes, these features are important! Fixing the (default) software stack may seem limiting to a power user, but would actually be a huge enabler.

[jwatte]

Also, the whole thing about extensions is to support customizations that auto-load during boot, without editing the "read only" base system. A cheapo alternative would be having rc.local start each script in some folder in turn, unless some key is held down. Do it as user, not root.

Another part of robustness I want to re-iterate: Fix the user/root separation! Let non-root users bind to any tcp/udp port. Remove the need for user installed software to ever become root or use suid.

[ShiftPlusOne]

I'll be honest... all of that makes me cringe.

[jwatte]

Why? How would that not help the goal of fostering a community of newbies learning how to make computers do their bidding?

I'll go so far as to say that the fragmented, haphazard, fragile, ill defined morass of incompatibility that is Linux today discourages neophytes rather than encourages them. And I am a die-hard fan using Linux to make a living since 1995!

[obarthelemy]

My take is
- rewriting a card is very easy. any PC with a card reader, which means almost all netbooks/laptops, and $5 for the desktops.
- redoing a whole OS or packaging system is too much work
- there will be standard/community packages of tools and libs, and projects/apps will run against those. the R.Pi will not be powerful enough to run all packages at the same time, but swapping "pesonnalities" is at most a card swap, at best a reboot, away.
- most activity will be apps-, not os-focused, with little chance to FUBAR the R.Pi.

[Emanuele]

I understand some of your points. It reminds me of:

http://www.slax.org

I have it on all my USB flash drives and I think it works well. It lives very well on a FAT32 partition too, which I think is a very good feature.

Despite the merits or the demerits of this approach, I think obarthelemy is right when he writes:


- redoing a whole OS or packaging system is too much work


Even starting from slax, it would take a lot of effort. Even more time consuming would be mantaining it. And the reaction from ShiftPlusOne is a good hint that most of the community would not be behind it.

[jamesh]

Quote from jwatte on August 14, 2011, 02:31
Why? How would that not help the goal of fostering a community of newbies learning how to make computers do their bidding?

I'll go so far as to say that the fragmented, haphazard, fragile, ill defined morass of incompatibility that is Linux today discourages neophytes rather than encourages them. And I am a die-hard fan using Linux to make a living since 1995!


I see no reason why someone could not create a app that simple emulates, for example, a BBC micro on boot of the Raspi - no Linux environment to worry about past the boot process. Not a huge amount of effort. I think Eben want BBC basic on the device anyway!!

I use the BBC micro as an example for obvious reasons, but you could provide any environment you want. However, I doubt that Raspi as a company could produce something appropriate in a sensible timescale. The community could though....hint hint.

[ShiftPlusOne]

Quote from jwatte on August 14, 2011, 02:31
Why? How would that not help the goal of fostering a community of newbies learning how to make computers do their bidding?

I'll go so far as to say that the fragmented, haphazard, fragile, ill defined morass of incompatibility that is Linux today discourages neophytes rather than encourages them. And I am a die-hard fan using Linux to make a living since 1995!


You haven't been running the same kernel since 1995, have you? =P

The greatest strength of linux is it's flexibility and direct access to all the components. At the same time you have a clear separation between root and user, which prevents the user from accidentally braking the system. You can grab any programming book and start coding straight away without the need to su/sudo anything and if the code doesn't run 100% of the time, then the problem is with the code, not the system.

The moment you start crippling the software to protect the users from themselves is when you take away the flexibility that makes linux great. I mean bricks are solid, unfragmented, robust and will always behave exactly as you expect, but they don't make very good computers. This is why people complain about mobile phone manufacturers. They cripple the software and hardware and the user has to jump through hoops to jailbreak or root the system and get the expected functionality.

How much simpler can you make linux?
1) Turn on the computer.
2) Launch the IDE for the language you want to learn.
3) Use the learning resource of your choice to start coding.
Easy and no root access required. Chances are that a newbie will not be able to mess up the system without root access and they won't need root access to do newbie stuff.

[abishur]

It also helps that for anyone experienced enough, they can manually enable root login and just use the root account. That way you have root/user separation for anyone pretty new to linux and needing that extra layer to keep from royally messing things up, and the more advanced user who knows the risk but uses root anyways.

[stuporhero]

You could write protect the SD card? At the very least Micro-SD > SD converters have such a switch. When you're done with that drop some storage onto one of the USB ports and you're away!

[obarthelemy]

if you wirte protect the whole SD, you have a problem with log files. you might be able to not log anything, or put logs on a seprate partition, and mount the os partition as read only.

[Gert van Loo]

First: the SD-card write protect is a software feature. That is: The WP signal goes to the CPU which then can decide to honor or ignore the WP status. It is not hard on the card!
I am not sure you want write protect. The majority of the file system will be on the SD_card. A novice user who accidentally trows the switch would get into big trouble and probably not understand why the system no longer works. That is exactly the user you are trying to protect with it. Experienced users would understand the error but not need the protection. So I suggest to do without. (It would also cost you one of your precious GPIO pins...)