User avatar
FeersumEndjinn
Posts: 148
Joined: Mon Nov 21, 2011 4:02 pm

Re: We need Standards!

Wed Nov 23, 2011 4:52 pm

I agree about the package manager - if r-Pi foundation is working with Redhat to optimize Fedora for the device, then the "official" package manager will be whatever Fedora uses, which I believe is RPM.

Personally I'd prefer DEB just from experience, but anything will do.
Morrolan / FeersumEndjinn

"And the lord God said unto John, 'Come forth and receive eternal life', but John came fifth and won a toaster."

Skygod
Posts: 211
Joined: Wed Sep 21, 2011 7:22 am

Re: We need Standards!

Thu Nov 24, 2011 5:26 pm

Quote from Skygod on November 20, 2011, 16:16
Since learning of the RPi initiative, I've rebuilt my PC so that it boots Windows Server and I now have Virtual PC's for Win 7, Debian, Fedora and CentOS. Trying to remember what commands to use in each environment to accomplish the same task is a 'nightmare'.


And have rebuilt again!

Fedora 16 is now the host OS. All the virtual PC's have been migrated to run under the new OS and I have also added QEMU to have an ARM environment.

ryao
Posts: 24
Joined: Sun Sep 11, 2011 3:47 am

Re: We need Standards!

Fri Nov 25, 2011 8:00 pm

Quote from navaru on November 19, 2011, 01:46
This project is new, and to ensure that we don't mess up too bad from the beginning, cause we'll eventually do, in some cases (writing a lot of bugs), we (as a community) should create some standards.

As a start we all need to find our *list of needs*, the building blocks, and come up with a list of standards on how to write a package and a package manager so we could easily find what we need written by others -- in order not to reinvent the hot water every time.

There is a pattern with humans, they find something new, they play with it, make something interesting and stop -- this is the case where someone writes a very good library with bad documentation and doesn't support it anymore, so you'll find yourself using it for a while and then ... 'oh crap, new Raspberry Pi updateds, and no library support...", and what do you do? "#include <frustration_mode>"

Also we need a style guide how to write code so we could all read it, and how to write a good read.me (documentation) <-- a must

Please feel free to post your opinion, if you don't have one, search google.

Have you considered forgoing binary packages altogether and standardizing on Gentoo?

As nice as binary package package managers are, they are the result of compromises that stem from the following issues:


The sheer quantity of software available.
The sheer number of options available when building software.
The multitude of ISAs available (e.g. alpha, arm, mips, ppc, sparc, x86) and revisions to them (e.g. instruction set extensions)
Differing ABI conventions (e.g. little endian versus big endian, how to do function calls to both normal and variadic argument functions)
Build options (e.g. Qt support versus GTK+ support, GnuTLS verus OpenSSL)
Legal issues from software patents (e.g. S3 texture compression)
Legal issues from trademarks (e.g. Firefox branding)
Distribution vendor priorities (try using CentOS as a desktop distribution to learn what I mean)

This has lead to the following compromises:


Multiple repositories, which makes it difficult to locate software and poses security risks due to the ability for anyone to make one, including malicious third parties
Software built to cover as many use cases as possible, which can result in the omission of debugging symbols, bloat from the inclusion of debugging symbols, bloat from runtime performance optimizations, missing performance optimizations, missing features stemming from legal issues or features that are undesirable (e.g. KDE's semantic desktop), absent security features (e.g. PIC to enable the kernel to implement ASLR, SSP, etcetera) and/or slowdowns from present security features. Avoiding all issues on this list is logically impossible and the reality of that has lead binary distributions to divide big packages into many little ones, at the expense of ease of use.
Outdated software to avoid ABI incompatibility issues or for lack of testing. This mandates new software be provided through distribution upgrades, which rely on run-once upgrade scripts that suffer from quality problems due to limited testing and that will often leave a system in an inconsistent state upon failure.
Limited support for various architectures (e.g. try Ubuntu on SPARC, PPC, IA64). The support that is available results in a significant duplication of effort.
Liberal patching of packages to introduce fixes for software flaws or to provide distribution unique functionality, which can often introduce issues upstream never would. This also requires laborious vulnerability tracking to determine when things need to be backported and this often misses security vulnerabilities. A researcher recently made a tool to help automate this practice, but no tool is perfect and it is not yet certain that it will fix things.

Numbers 1, 2 and 3 often cause advanced users to compile their own software. In those situations, advanced users will often do "wget url/to/tarball; tar -xvzf ./tarball; cd tarball directory; ./configure; make; make install". That can work in the short term, but it is often the source of problems:


End-users who manually compile software must do dependency management themselves and it is easy to horribly break things.
Tools meant to address dependency issues when compiling your own packages introduce new problems, which is presumably why they are not recommended by various distributions. For instance, if you upgrade python from 2.6 to 2.7 on Ubuntu 10.04 using checkinstall and name the resulting package "python", dependency conflicts will disable apt-get.
Upgrades can break things long after the installation due to either API incompatibility or poorly handled file collisions.
Attempts to remove obsolete packages will often break things outside of the package manager that depend on them or potentially inside of the package manager if the user upgraded something in a way that did not inform the package manager of its dependencies.
Security vulnerabilities will usually go unpatched in self-compiled software because end-users have little direct incentive to update them manually, even if they installed them properly.

Even when those problems are avoided, there is still the problem of root directory pollution because things are no longer being managed by the package manager, which can lead to issues stated in #3 in my compromise list and unfortunately, users in such situations receive little help. Such problems are always "their fault", not the distribution's fault. That is despite of the fact that the design compromises taken by the distribution put them in a situation where they felt the need to do such things and I imagine that it is very disenfranchising to many new users.

Gentoo makes a few compromises of its own, but in doing that, it resolves all of the issues that stem from compromises that other distributions make. Here is how Gentoo avoids issues stemming from each of the compromises I listed binary distributions as having:


Gentoo's package manager introduces an abstraction known as an ebuild. Ebuilds are wrappers for whatever upstream provides, be it a tarball, makeself, repository (GIT, SVN, CVS, Mecurcial, etcetera). They are rather succinct and once one is written, a very small team can maintain a great number of them.
The abstractions provided by Gentoo's package manager provides defaults that users can override to make nearly all decisions that binary distributions make for them, but with far less effort. This avoids the need to break packages into smaller ones, making it significantly easier for users to find what they want, although it is not perfect. make specific options are abstracted into a global make file (with the option to create per-package env files) and build options are abstracted into system-wide and per-package USE flags. USE flags can be configured in ways that prevent the package manager from handling upgrades gracefully (e.g. a specific USE flag is needed to resolve dependencies, but it is set for package verson 1.0 and then version 1.0.1 becomes available). Experience at system administration enables users to avoid such problems while the corresponding issues in binary distributions have no resolution.
Gentoo makes it easy to resolve ABI incompatibility through recompilation, which enables software to always be up to date or close to it. It even provides a tool called revdep-rebuild, which can automate detection of ABI incompatibility issues. It is theoretically possible for the package manager to be modified in a way that permits ebuild maintainers to provide information that should enable the package manager to detect such situations beforehand, but the Gentoo developers are still considering proposals to do that.
The design of Gentoo makes it significantly easier to support multiple architectures due to the deduplication of effort provided by ebuild files.
Gentoo attempts to stay close to upstream, which makes backporting functionality largely unnecessary and the patches that are done are always sent to upstream. Usually, the patches that are done are to fix issues involved in supporting multiple architectures and/or security features. Security vulnerabilities that upstream fixed years ago are incredibly rare because Gentoo stays close to upstream.

With that said, Gentoo's package manager should enable work done on other architectures to much more easily translate into support for the Raspberry Pi than it would on a binary distribution. It should also be flexible enough to produce binaries for each individual's needs, so there is little need for fragmentation.

The primary focus of the Raspberry Pi is in education, which is an area in which Gentoo excels by making it easy to modify the system source code within the safety net provided by its package manager. You simply need to do "ebuild $(equery which package-category/package-name) unpack", make changes and then do "ebuild $(equery which package-category/package-name) merge". For some thing more permanent, you can create a local overlay (e.g. /usr/local/portage) for a place to store permanent changes. That only needs to be done once and then you can follow a simple procedure for all packages, which is as follows:


Copy the package's subdirectory to there from /usr/portage (possibly deleting things like older versions so you don't duplicate them and the changelog so you don't have useless files)
Place the patch in the files subdirectory
Modify the ebuild to apply the patch
Update the manifest file (i.e. "ebuild /path/to/modified/ebuild digest")
Run "emerge --oneshot updated-package" to install the update.

Note that in #5, the flag --oneshot is optional, but generally recommended. Portage makes a distinction between things you actually want on the system and the things that you need to have them. Everything you specify to emerge is automatically assumed to be something you want unless you specify --oneshot (or -1, which is the short version). That distinction enables obsolete packages to be removed through "emerge --depclean --ask", which is a difficult task on other distributions.

The only downside to patching software on a Gentoo system is that you need to modify the ebuilds every time a new version is available unless you explicitly tell Gentoo to use the older version, but it isn't very hard to keep your patches alive for newer versions. Gentoo will present a color-coded list of packages each time you update, so it is rather easy to watch for the ones you customized and update the ebuild to reflect your changes. Most of the time, you just need to rename the ebuild and update the manifest file. The tactic of staying at an older version is also possible, but for packages whose dependencies change rapidly, you will need to move dependencies into your overlay as time passes.

It is rather easy to create new ebuilds for Gentoo when existing ones do not exist and doing this enables people to avoid the issues that often occur when they compile software themselves. In my opinion, such issues serve as a barrier to things that are of real educational value, so avoiding them is a good thing.

With that said, there are two main compromises Gentoo makes:


It has no release schedule.
All software is typically compiled from source.

These are made to avoid the issues derived from compromises made by other distributions. In my opinion, these compromises are more natural for open source software. With that said, Gentoo does make attempts to mitigate them.

Issue #1 is only an issue because organizations rely on release schedules to coordinate regression testing and quality assurance. Gentoo does internal quality assurance via its tinderbox efforts, which attempt to automate the discovery of problems before users encounter them by compiling all software available for Gentoo repeatedly and detecting build failures. Those efforts have lead to the discovery of numerous issues, many of which have resulted in patches sent to upstream. Gentoo also marks packages as either stable, testing or masked. Gentoo will only install stable packages by default. Software updates must wait approximately 30 days before entering the stable tree with the only exception being security updates. Those updates that do enter the stable tree enter only after manual review. Users willing are able to upgrade specific packages or the entire system to the testing tree versions and they tend to detect issues that the tinderbox efforts cannot. It is practically always possible for them to recover from issues they encounter and they tend to catch issues before they reach the stable tree.

Third party organizations can implement their own fixed release schedule and regression testing practices by taking a snapshot of its tree and maintaining it independently of the main tree. This is often done by forks of Gentoo. Some examples include Funtoo Linux, Sabayon Linux and Gentoo Prefix. It is usually fairly easy to switch a fork to the main tree, which basically convert it into a Gentoo Linux installation. The only real exceptions to this are LiveCD based derivatives of Gentoo (e.g. Pentoo Linux, System Rescue CD, etcetera) and Gentoo Prefix. Gentoo Prefix is somewhat special in that it is an official fork of Gentoo. It permits the installation of Gentoo on other operating systems, including Solaris and Microsoft Windows NT, although it can be forked by others should they desire it.

Gentoo attempts to address issue #2 in the following ways:


Gentoo's package manager supports ccache, which enables packages to be recompiled rapid recompilation.
Gentoo supports distributed compilation via distcc, which can partially
Gentoo Linux supports compilation in a tmpfs, which can increase compilation speed while reducing disk IO. The feature is more a consequence of the design of the Linux kernel Linux than anything Gentoo Linux did, but it works and people do it all the time.
Gentoo has partial support for binary packages, although it is not widely known. However, there are three distinct types of binary packages on Gentoo and two of them are significantly different from their counterparts on binary distributions.

The various types of binary packages are as follows:


Ebuilds for binary packages exist when sources from upstream are unavailable. Some popular software that falls into this category are Google Chrome, Opera, the Nvidia binary driver, the Oracle JVM, VMWare Player and various video games. Packages in this category that involve Linux kernel modules do not integrate well into Gentoo or Linux in general, but others tend to work well. They usually rely on bundled libraries that would be unnecessary bloat had sources been available.
Gentoo's developers provide precompiled versions of open source software for older systems when the time taken to compile them is considered to be excessive. Open Office and Libre Office are in this category. Packages in this category are targetted to Gentoo stable and rarely work on both Gentoo testing and Gentoo stable due to API incompatibilities. They also don't integrate well with use flags, although they are entirely optional and with the removal of chromium-bin, their numbers are dwindling.
Gentoo's package manager can generate binary packages from ebuilds and avoid software compilation by making use of them. It supports the specification of a list of BINHOST servers and it will use them similarly to how apt-get uses .deb files or yum uses .rpm files, but there are some significant differences, the full extent to which I have not explored. The main difference is that the package manager will refuse to install binary packages unless they appear to be exactly what it would have produced had it compiled them. I have not fully explored how strict it is, but the areas where there can be variation are different global settings in make.conf (e.g. CFLAGS, CXXFLAGS, LDFLAGS, global USE flags, portage FEATURE settings, etcetera), different per-package settings in /etc/portage/, a different system profile (which affects USE flags, FEATURE flags, LDFLAGS, which ebuilds are available, etcetera), different ebuilds and the system compiler. You can always mimick a Gentoo installation in a chroot directory on a faster system for the purpose of generating binary packages for installation through this feature. Others just physically remote the hard drive, install it in a faster computer and then chroot into it, which is the same thing without using this feature.

With that said, I highly recommend that the Raspberry Pi community standardize on Gentoo. It is the only distribution flexible enough to minimize duplication of work while permitting everyone to get what they want out of it. *BSD fans would probably also appreciate Gentoo/FreeBSD, which replaces the GNU/Linux components with FreeBSD's counterparts. Interest in it is low, but with some work, it probably could support the Raspberry Pi provided the FreeBSD does while minimizing the duplication of effort involved in supporting multiple kernels. Anyone that wants to try Gentoo without setting up a computer from scratch can install Gentoo Prefix, which runs on most operating systems available, including Microsoft Windows NT provided Interix (i.e. Windows Services for UNIX) is installed.

I doubt that the Raspberry Pi will standardize on any single distribution, but I highly encourage people to consider what I had to say about standardization. I believe that I identified some important issues and that if we really care about education, it would be best for us to talk about ways of resolving them than it would be to fight the distribution wars. Fighting among ourselves would only serve to disenfranchise students and that will hurt everyone.

bradburts
Posts: 341
Joined: Sun Oct 02, 2011 7:07 am

Re: We need Standards!

Fri Nov 25, 2011 10:13 pm

I chuckle on each post (not at).
The truely great thing about this topic is that you get to hear heart felt views of which/what is best, which cannot be bad.
I am off to read about & try Gentoo, cause there is at least one disciple who luvs it.......
navaru a fire starter, twisted firestarter. Well done :)
PS I should add that as a matter of semantics I would disagree with the use of the term 'standard', love the discusion though.

Xovan
Posts: 9
Joined: Thu Sep 22, 2011 9:13 pm

Re: We need Standards!

Fri Nov 25, 2011 11:15 pm

I love Gentoo Linux for many reasons as well as many other minimalist distributions and personally I intend to use Gentoo on the Raspberry Pi myself. However I believe that anything shipped with or on the device needs excessive documentation. The "good enough" attitude with documentation on how to use Linux software would be more damaging to the project as a whole more so than the prepackaged software's capabilities by themselves. These students need to be encouraged to experiment with the software available. Gentoo will need to be distributed in a manner that would allow humble students to reinstall the software on a whim because they are bound to break their OS far beyond what their knowledge would permit them to fix on their own.

As Gentoo goes, it would make things more simple to learn computer science however if we are to standardize anything beyond documentation we must must must make a standard method of install that would allow the students to best utilize the devices hardware while still not requiring them to be all that computer smart to begin with.

ryao
Posts: 24
Joined: Sun Sep 11, 2011 3:47 am

Re: We need Standards!

Sat Nov 26, 2011 12:53 am

Quote from bradburts on November 25, 2011, 22:13
I chuckle on each post (not at).
The truely great thing about this topic is that you get to hear heart felt views of which/what is best, which cannot be bad.
I am off to read about & try Gentoo, cause there is at least one disciple who luvs it.......
navaru a fire starter, twisted firestarter. Well done :)
PS I should add that as a matter of semantics I would disagree with the use of the term 'standard', love the discusion though.

If you try out Gentoo Prefix, I should warn you that the documentation for that is not as good as it is for the rest of Gentoo. The documentation became significantly better a month or two ago after it was criticized. I don't have time to hunt down all of the remaining issues, but if you find any issues in the documentation, please tell the developers. They are in #gentoo-prefix on freenode. You can also go there for assistance should anything go wrong. #gentoo is another option and it has several hundred more people in it, but it is not specific to Gentoo Prefix.

Quote from Xovan on November 25, 2011, 23:15
I love Gentoo Linux for many reasons as well as many other minimalist distributions and personally I intend to use Gentoo on the Raspberry Pi myself. However I believe that anything shipped with or on the device needs excessive documentation. The "good enough" attitude with documentation on how to use Linux software would be more damaging to the project as a whole more so than the prepackaged software's capabilities by themselves. These students need to be encouraged to experiment with the software available. Gentoo will need to be distributed in a manner that would allow humble students to reinstall the software on a whim because they are bound to break their OS far beyond what their knowledge would permit them to fix on their own.

As Gentoo goes, it would make things more simple to learn computer science however if we are to standardize anything beyond documentation we must must must make a standard method of install that would allow the students to best utilize the devices hardware while still not requiring them to be all that computer smart to begin with.

I agree with you completely.

On that topic, what are you thoughts on the use of disk images? The Gentoo installation procedure could be dramatically simplified if people provided a ready to use 1GB disk image with all fine tuning done in advance and documentation, which would include:


Documentation on how to flash it to a SD Card
Documentation on how to extend it to fit a larger SD Card
Documentation on how to configure a user account
Documentation on how to do localization so that the clock matches their region and software that supports localization will be in their native language.
Documentation on how to modify the network configuration to obtain a static IP address.
Documentation on how to do system maintenance, such as doing updates, installing software and configuring USE flags.
Documentation on how to configure the system to serve specific roles, such as that of a desktop (e.g. KDE, GNOME, LDXE, Xfce). Feel free to add roles and/or desktop environments to this list.
Documentation explaining how the system's components are organized, including information on the steps of the installation (e.g. the bootloader, the kernel, the partitions, the filesystem and the network configuration) that disk image enabled them to skip.
Documentation on how to debug software packages to diagnose the source of a crash (e.g. FEATURES="nostrip" CFLAGS="-O0 -ggdb3" emerge -1v package-category/package-name, run it in gdb, get a backtrace and then run ebuild $(equery which package-category/package-name) unpack to get the sources).
Documentation on how to use IRC, specifically on how to join #gentoo on freenode so that they can ask for help. We probably should also list a few IRC channels on Freenode and document how to switch between them. It probably would be a good idea to use irssi as the example in the documentation because it does not rely on X windows. It might be a good idea to make a reference to this the first item they see when they read the documentation, but that is only a suggestion.

It might be a good idea to include a few configuration files like xorg.conf to avoid possible configuration headaches.

It is also possible to offer a 256MB image that omits the snapshot of the portage tree used to build it, which shouldn't be a problem considering that the only difference it will make in the worst case is that their first synchronization will be slow as it must be downloaded from scratch. Another possibility would be to provide a few disk images, analogous to what the Sabayon Linux distribution does with LiveCDs. It would not be very hard to provide images for each of KDE, GNOME, LDXE Xfce, and a minimal system so that students can avoid waiting for a desktop environment to compile, yet be able to forgo one as part of a quick setup process when they do not require it.

Xovan
Posts: 9
Joined: Thu Sep 22, 2011 9:13 pm

Re: We need Standards!

Sat Nov 26, 2011 1:52 am

All the documentation would have to be shoved into text files or minimalist html files. That way everything that needs to be said could be said in well under 50MB. The software available could be simplified to a great extent but would still require that there are enough programming libraries with documentation available to begin programming right away. Once you start counting these chickens you'll find that it really is a tall order in the documentation department as much of GNU/Linux based software doesn't have great documentation to begin with.

Remember we cannot assume that these machines will be connected to the internet for the whole day (if at all) allowing the kids to read online documentation, forum posts, wikis, mailing lists, and chat on irc. It will probably have to be shoved in somewhere in a very small amount of space reserving plenty of space for the programs and storage of their own work.

Your ideas are great though and I appreciate the effort into the details. I would recommend that the desktop environment would be LXDE as it is very light on resources or alternatively (and probably better for the purposes in mind) a mixture of a window manager and midnight commander with a small help program that would basically just tell them how to use the command line in its most basic sense to get them started. Using as simple language as possible to make internationalization easy. A small note could be shipped with the device that tells them how to turn on the machine, access its basic help program, and then the rest would be left up to the documentation.

Skygod
Posts: 211
Joined: Wed Sep 21, 2011 7:22 am

Re: We need Standards!

Sun Nov 27, 2011 4:48 pm

Standards!

Virtualisation in a Linux envirnment

I've now tried using 3 different host OS's and the 'yum or apt-get updates' on the host have rendered my system unusable because of different issues regarding Graphics card or HDD RAID.

I've now been forced to go back to Win 7 as a host as M$ does seem to correctly recognise hardware and does apply the correct drivers as necessary through Windows Update. ( I'm now remembering why I gave up trying to use Linux as a mainstream desktop system )

There needs to be a 'stock' , 'base' RPi distro for each of Fedora, Archlinux and Debian (all the officially supported OS's ) which loads all of the necessary hardware drivers.

Getting the system working quickly 'out of the box' is a MUST!

The RPi is hardware but it needs to deliver an 'environment' for users. This means providing an OS image that will work with all the hardware.

This is more than most hardware suppliers would provide, because in the main, they assume that M$ Windows is the solution. I've looked at ASRock site for my MB and the only drivers are for M$ OS and all Linux updates for the distros I've tried have simply 'screwed up' my system.

My USB Wireless adapter also has issues under any OS other than Windows. Unless I install a specific driver, it will not authenticate on a WPA2 network.

Whilst the aim is to make 'computing for kids' interesting and 'fun', if they cannot get the device working quickly in the first place, it will end up with the device cast to the bottom of the cupboard as "nice idea, but I couldn't be arsed".

Xovan
Posts: 9
Joined: Thu Sep 22, 2011 9:13 pm

Re: We need Standards!

Sun Nov 27, 2011 9:45 pm

Off topic:
Good point sir, I've known people whose computers just simply would not work with linux no matter what they tried. On the other end of the stick is me who has never run into hardware issues past a phone I wanted to copy contacts from to my computer. All I had to do was install a program called gammu and was able to move my contacts from there to my computer and then to google voice greatly simplifying my communications and correspondence.

What I've found that helps as a quick 'n dirty way to find out if support exists for a device is to search the comments found in different stores websites to see if there was any mention of linux support being good. The stuff that really works will almost always have at least 1 comment about that. Failing that I google search it to see if anybody had particular trouble with it. What I've learned from experience is that if you're careful about the hardware upon which you run linux you can have an extremely enjoyable experience with it.

Now something to note is that there are computers built with linux in mind system76 and zareason come to mind immediately.

On topic:
As for the Pi, I can guarantee you that any os image designed specifically for it is going to have issues that will require the user to get documentation on the subject. Having stuff that works on it out of the box will eventually become essential towards distributing the device properly. However right now people need instructions on how to get there before the process can be automated properly. We want to make sure that we follow the recipe correctly before we experiment with the dish. Otherwise we'll have bricks for supper.

ryao
Posts: 24
Joined: Sun Sep 11, 2011 3:47 am

Re: We need Standards!

Mon Dec 05, 2011 3:59 pm

Quote from Skygod on November 27, 2011, 16:48
Standards!

Virtualisation in a Linux envirnment

I've now tried using 3 different host OS's and the 'yum or apt-get updates' on the host have rendered my system unusable because of different issues regarding Graphics card or HDD RAID.

I've now been forced to go back to Win 7 as a host as M$ does seem to correctly recognise hardware and does apply the correct drivers as necessary through Windows Update. ( I'm now remembering why I gave up trying to use Linux as a mainstream desktop system )

There needs to be a 'stock' , 'base' RPi distro for each of Fedora, Archlinux and Debian (all the officially supported OS's ) which loads all of the necessary hardware drivers.

Getting the system working quickly 'out of the box' is a MUST!

The RPi is hardware but it needs to deliver an 'environment' for users. This means providing an OS image that will work with all the hardware.

This is more than most hardware suppliers would provide, because in the main, they assume that M$ Windows is the solution. I've looked at ASRock site for my MB and the only drivers are for M$ OS and all Linux updates for the distros I've tried have simply 'screwed up' my system.

My USB Wireless adapter also has issues under any OS other than Windows. Unless I install a specific driver, it will not authenticate on a WPA2 network.

Whilst the aim is to make 'computing for kids' interesting and 'fun', if they cannot get the device working quickly in the first place, it will end up with the device cast to the bottom of the cupboard as "nice idea, but I couldn't be arsed".


Having "a 'stock' , 'base' RPi distro for each of Fedora, Archlinux and Debian" depends on the distribution vendors. With that said, the Raspberry Pi is very specific hardware in that after one person makes an appropriate kernel .config file, all Raspberry Pi hardware would work.

As for your issues, get the output of "lspci -n", go the the following webpage and do a search based on it:

http://kmuto.jp/debian/hcl/

It should tell you whether or not driver support exists. Here is a site that explains how to compile your own kernels:

http://kernel-seeds.org/

It was written by a Gentoo Linux user for Gentoo Linux users, but the advice there works for all distributions, although you should read your distribution's documentation on how to install a custom kernel to avoid problems with the package manager. With that said, I highly recommend that you try Gentoo Linux. I have found it to support a much wider range of hardware than other distributions. This is primarily due to its source-based nature, which permits greater flexibility in configuration and updates than binary distributions can provide..

Of course, no OS is without its drawbacks, but I think that Gentoo Linux could be a good fit for you. With regard to virtualization, Gentoo Linux does well as both a host OS and a guest OS, provided that you properly configure the kernel. If you want to run virtual hardware, I suggest either VMWare Player for desktop use or KVM for server use. KVM can also be used as a desktop, but KVM targets businesses.

Quote from Xovan on November 27, 2011, 21:45
Off topic:
Good point sir, I've known people whose computers just simply would not work with linux no matter what they tried. On the other end of the stick is me who has never run into hardware issues past a phone I wanted to copy contacts from to my computer. All I had to do was install a program called gammu and was able to move my contacts from there to my computer and then to google voice greatly simplifying my communications and correspondence.

What I've found that helps as a quick 'n dirty way to find out if support exists for a device is to search the comments found in different stores websites to see if there was any mention of linux support being good. The stuff that really works will almost always have at least 1 comment about that. Failing that I google search it to see if anybody had particular trouble with it. What I've learned from experience is that if you're careful about the hardware upon which you run linux you can have an extremely enjoyable experience with it.

Now something to note is that there are computers built with linux in mind system76 and zareason come to mind immediately.

On topic:
As for the Pi, I can guarantee you that any os image designed specifically for it is going to have issues that will require the user to get documentation on the subject. Having stuff that works on it out of the box will eventually become essential towards distributing the device properly. However right now people need instructions on how to get there before the process can be automated properly. We want to make sure that we follow the recipe correctly before we experiment with the dish. Otherwise we'll have bricks for supper.

My general rule of thumb for x86 based systems is that if it can run System Rescue CD, it can run Linux:

http://www.sysresccd.org/

System Rescue CD is a Gentoo Linux derivative meant for system recovery. Many Gentoo Linux users use it to install Gentoo Linux. It requires an i586 processor, so if you wanted to install Gentoo Linux on something older than that, you would need a LiveCD that supports it. So far, I have not encountered a system that cannot run it.

The LiveCD installation method won't work for the Raspberry Pi, but there are other methods for installing Gentoo. It should be possible to install Gentoo Linux in QEMU on a raw image through a netboot like the Gentoo Handbook suggests, configure appropriate for the Raspberry Pi (CFLAGS, CXXFLAGS, kernel .config), flash the image to a SDCard and then boot the Raspberry Pi off it.

User avatar
esbeeb
Posts: 111
Joined: Sun Feb 05, 2012 12:23 am

Re: We need Standards!

Mon Feb 20, 2012 6:04 pm

I've read all the viewpoints, and I think a middle ground can be found here, between them all.  I'll probably get blasted, but how does this sound for a workable, reasonable, middle-of-the road solution?

Firstly, expect that each RPi user can afford 2 SD cards.  This is reasonable since they're easily $10 or $15 if you watch for sales.  We're not expecting them to own like 6 or 10 SD cards.  This allows easy swapping of SD cards, facilitating easily trying out both choices below.  Whew, now it's not such a big deal to find one perfect, one-size-fits-all solution.

Secondly, The RPi foundation can (and will, it seems) "officially" support 2 Distros: Debian, and Fedora.  On the downloads page, these are clearly labelled as, say:

-"RPi OS - For Beginner Users (Fedora)"

-"RPi OS - For Experienced Users (Debian)"

The newbies will appreciate the extra user-friendly "spit-polish" that goes into Fedora, and can easily choose that.  The more seasoned techies will appreciate the larger selection of packages, and apt-based package management of Debian, and can easily choose that.

That's it: only 2 OS choices officially offered by the RPi foundation.  Not one choice, which would be too controlling. Not 8 distro choices, which would be too confusing to newbies.  This is the middle ground.

This might all sound obvious.  But please bear with me:

Thirdly, to further greatly help facilitate the choosing between these 2 choices, there should be an RPi-specific website looking like:

"Ubuntu Apps Directory" https://apps.ubuntu.com/cat/

and/or:

"Fedora Apps" list: https://admin.fedoraproject.org/pkgdb/apps/name/list/

...which would allow users to easily see before installation if the software they want will be possibly easily installable (in a reliable manner, because it's easily installable from the respective GUI-based package manager). And please, let's ignore for the moment the potential ability to install from unofficial repositories, and tarballs, as that can be much less reliable and maintainable over the longer term.

The feature here that newbies will love is that these online package directories are searchable, using generic terms like "word processing".  They might not know what "Abiword" is, but they do know a term like "word processing," and can thereby find and easily try out Abiword.  This is a great "dissolver of perplexity" for newbies faced with the overwhelming number of software choices!

This provides a reasonable, manageable amount of OS choice, with searchable, online, friendly-formatted package listings.  This will help RPi users make an informed, sensible choice which suits their needs, be they newbies or geeks.

Whoever disagrees with me, that fine, please directly go ahead and make your own unofficial RPi-optimised distro!

User avatar
grumpyoldgit
Posts: 1452
Joined: Thu Jan 05, 2012 12:20 pm

Re: We need Standards!

Mon Feb 20, 2012 6:15 pm

Why would someone who disagrees with you have to create their own distro? What makes your suggestions official?

oninoshiko
Posts: 76
Joined: Sun Jan 29, 2012 9:16 pm

Re: We need Standards!

Mon Feb 20, 2012 8:30 pm

EEP! gentoo.

I've used it and, as I recall, because of it's "source based nature" the installation takes forever. Particularly X11. That's on a two core machine at over 1Ghz.

The thought of asking users to install gentoo on a single-core, 700Mhz ARM is cringe-worthy.

User avatar
esbeeb
Posts: 111
Joined: Sun Feb 05, 2012 12:23 am

Re: We need Standards!

Mon Feb 20, 2012 9:43 pm

Touchy!  It's not my idea to just support Fedora and Debian.  I thought that was the RPi foundation's official "party line", which I was trying to support.  Actually, it now seems that they will only officially support Fedora: http://www.raspberrypi.org/archives/676

If I had my way, it would be Debian as 1st choice, IMHO  But that's cool.  Fedora is decent also.  I agree that Gentoo is right out.

Anyhoo, my suggestion to have an RPi-specific online "app directory" still stands (as a "dissolver of perplexity" for newbies).

Consider, for example, how Ubuntu's online app directory shows up to 5 stars, as rated by users, along with oftentimes pithy reviews.  Although they should be taken with a grain of salt, I think these stars and reviews are VERY helpful for newbies to QUICKLY zero in on the 2 or 3 obvious, realistic apps to try out first (which can be easily installed, tried out and possibly uninstalled from yum, all in a matter of minutes).

Leaving it to newbies to Google around to try to find up-to-date, quality info on specific software (once they know it's name, which is half the battle), will probably just make their heads spin.  An online app directory helps get around that.  Of course, reading Wikipedia summaries is also a runner-up method.

I don't know who said it first, but someone said something salient like "we live in the age of the "Software Store"."

User avatar
esbeeb
Posts: 111
Joined: Sun Feb 05, 2012 12:23 am

Re: We need Standards!

Sun Feb 26, 2012 4:34 pm

I'm opening the idea of an "online app directory" to a new Forum topic...

http://www.raspberrypi.org/for.....ory#p45268

Return to “General discussion”