Seneca breaks silence on Fedora Remix

Better late than never I guess. I think I downloaded this somewhere, now i've got my pi perhaps i'll load it up and see how broken it is.

If it is badly broken, how did it get released ? Or is that a silly question ?

Steve,

  That isn't a silly question.  Fedora is supposedly the primary OS for this device,

so care should have been taken by all parties involved, to ensure that it worked

reasonably well.

  Apparently from what I can gather, the foundation isn't putting much funding into

development of Fedora.  Seneca lists their sponsors, but doesn't include the

foundation.  The foundation has apparently provided one alpha board, but no

beta boards.  I don't know about production boards.

  The development at Seneca was apparently done in connection with a class,

SBR600 taught by Chris Tyler:

http://zenit.senecac.on.ca/wiki/index.php/SBR600

The problems with the Remix were found immediately upon release, and

included problems with login, and problems setting timezone.  The login

problem apparently happens if the RPi is booted without being connected

to the network to set its time/date.  So it appears that no beta testing was done

by anyone in a different timezone than Seneca, or by anyone without a network

connection at boot time.

Other problems, such as general slowness and needing frequent reboots

may have been known at time of release, but may have been deferred in order

to meet the launch schedule.  These problems may be more difficult to fix.

I believe the login and timezone problems involved simple scripting errors

involving lifetime of environment variables.

I think much of the RPi work at Seneca was piggybacking on work for OLPC,

but I think OLPC is moving to ARM version 7,  at least for its newer machines.

We have yet to be told if Fedora will continue to be the primary OS,

and if so, what level of support will be provided, particularly in the way of

security updates and bugfix updates.  The lack of any support or updates

so far is not encouraging.

The beauty of Linux and opensource is that there are flavors for all tastes and tastes for all flavors.

IMHO that's also probably its biggest weakness.  As a relative newcomer to Linux, I think the choice has delayed me from getting into Linux for years.

Zeta,

  The level of support I expect depends on what I'm told to expect.

The FAQ on this website says:

"UPDATED AT 12:05 pm GMT 15 March

Q. Why have you temporarily removed the Fedora download?

A. We want you to be up and running as quickly as possible. There are 3 Linux operating systems for the computer and when the Fedora Remix became available, we tested it on our Raspberry Pi to make sure it was easy to use.  We found issues with the username & password authentication that prevented access to the operating system, effectively making it a bit unusable. To be really clear though, this issue is to do with the software, not the Raspberry Pi board itself. We’ve fed this back to the guys at Fedora, and they’re already working on a new release.  When Fedora have fixed the issue, and element14 with the Raspberry Pi foundation have successfully tested it, we’ll bring the Fedora Remix download back to you.  Until then, we recommend the Debian “Squeeze” distribution that’s available in our Download Center."

I gathered from this, and from my understanding that the Seneca SBR600 course was only at "midsemester" when they made the original release, that they would quickly release an update with at least the login and timezone bugs fixed.

On the RPi.org forum, JamesH wrote:

"by jamesh » Mon Mar 12, 2012 8:51 pm

It's been covered before, but Fedora is the recommended/standard distro. This is because we NEED a standardised distro for the educational release - we need people to be able to say -"We are using your distro and your stuff doesn't work", rather than "I've got this random distro I made and your stuff doesn't work". In the first case we know we have a problem. In the second case, all bets are off - could be anything.  

That said, we heartedly encourage people to use whatever distro they want. Just don't expect top level tech support from the Foundation itself, on Foundation released packages. We'll try, but we cannot promise anything on other distros, the support burden is too high."

I gather from this that the foundation does intend to provide top level tech support for their primary distro.

Given the relative lack of power of Raspberry Pi's CPU and its poor support for disk storage, I expect the "best" distro for the Pi to end up being the one that is most cut down and optimized.  It's far too early to tell which this will be, but I strongly suspect that it won't be any of the usual desktop distros because they're the opposite of cut down and optimized.

For experts, a distro is probably defined by its package manager, but if a bespoke Pi distro were to base itself on RedHat, Debian or Ubuntu packages, would it still be RedHat, Debian or Ubuntu?

Perhaps not, because from a user's perspective, "normal" distros tend to be defined by their desktops.  You might think that the character of a distro could be preserved despite the slimming down, but once you've thrown out the bulk of a horrendously bloated desktop manager, what you're left with is something quite different.  A newbie user of that desktop distro may not recognize their surroundings anymore.

It's undoubtedly a contentious issue, but the big distros are probably defined by their desktop bloat.

Morgaine.

coder27 wrote:

 

 

On the RPi.org forum, JamesH wrote:

"by jamesh » Mon Mar 12, 2012 8:51 pm

 

"... Just don't expect top level tech support from the Foundation itself, on Foundation released packages. We'll try, but we cannot promise anything on other distros, the support burden is too high."

 

 

I gather from this that the foundation does intend to provide top level tech support for their primary distro.

Nowhere they said the Foundation had any intention to provide tech support for any distro. You may expect they offer some help and support when you run Foundation released packages on their Recommended/standard distro. However, the Foundation has not yet released any software package.

I don't really see why they would need to provide too much support when there is such a large following of helpful supporters creating this community.  Surely this is really what makes the Pi so special.

I have seen many other embedded Linux boards, but without a large active community they are not as attractive.  I guess, getting back to my original point, surely what is needed is one main distro that the community are throwing their efforts into.  At present that is probably Debian, so why switch over to Redhat now (or later when it is working a bit better), unless I am missing something and Redhat is the way to go...

Yeah I agree the Fedora release I tried was nothing like it seemed to be like on the websites. Buggy ( don't know about that) certainly peculiar behaviour. The partition resizing is a very good idea but takes AGES!!!!!!

They should have made a better warning in 50 point font or a progress bar so you know your new RPi isn't toast and is secretly laughing at you.

Any way I downloaded the Debian and it worked and was less wierd but still droped you to the command prompt rather than pritty pictures mode.

I'm hoping that they manage to integrate it into the Fedora 17 tree and we get it sorted out.

This is OK for a "hacker release" but not fit for kids or for the reporter who got one and then was slaged off for their lackof Skilz and reposted with slagging every one else off in the article  !!

I think the closest they got was the mention of a prefered distro which was Fedora but god knows what it is now or will be next week.

Onwards and upwards.... best we all get to gether and sort it ourselves

Zeta,

you wrote:

"Nowhere they said the Foundation had any intention to provide tech support for any distro."

I agree with you that they haven't made an unambigous statement regarding distro support per se,

at least not that I have seen.  But distro support is closely intertwined with package support. 

If for example you can't login to a distro, or if the distro requires frequent reboots, or is overly slow,

as is currently the case with the Fedora Remix,  then that hinders effective use of any educational packages.

So I don't think it's reasonable to interpret their statements as intending to provide good support

for educational packages, but not for the underlying distro.  In fact they have been providing

support for the debian distro, which is essential given the current lack of support from Fedora.

RorschachUK,  

That's very observant that the foundation has simply removed mention of Fedora.

I would have expected some sort of announcement if they are switching allegiance to Debian.     

The Seneca minutes you found from 2 May indicate plans for a F14 Remix update by EOW,

which I presume means the end of last week.  But that short schedule woudn't allow much

time for performance and/or stability improvements.  If those issues aren't solved soon,

then I think it will be difficult to overcome the lead that Debian currently has.

I'm a bit surprised that their plans make no mention of any issues from their bug-tracking system,

nor any mention of beta-testing the Remix update.  Normally I would expect an OS update plan

to be focused almost entirely on the status of issues from the bug-tracking system, and preparations

for internal and external testing.

RorschachUK,  

That's very observant that the foundation has simply removed mention of Fedora.

I would have expected some sort of announcement if they are switching allegiance to Debian.     

The Seneca minutes you found from 2 May indicate plans for a F14 Remix update by EOW,

which I presume means the end of last week.  But that short schedule woudn't allow much

time for performance and/or stability improvements.  If those issues aren't solved soon,

then I think it will be difficult to overcome the lead that Debian currently has.

I'm a bit surprised that their plans make no mention of any issues from their bug-tracking system,

nor any mention of beta-testing the Remix update.  Normally I would expect an OS update plan

to be focused almost entirely on the status of issues from the bug-tracking system, and preparations

for internal and external testing.

some more details on the Fedora Remix login and timezone bugs.

On March 16, user jojopi proposed a solution to both bugs:

http://www.raspberrypi.org/forum/general-discussion/issues-with-fedora-mix-distro-element-14-have-withdrawn-download-from-site/page-2

"The reboot was intended not to be necessary.  The firstboot script goes through all the motions of making the user's runlevel choice effective immediately.  Unfortunately, all the motions fail because the script uses the shell variable RUNLEVEL internally.  /etc/init/rc.conf exports RUNLEVEL and runlevel(8) trusts RUNLEVEL over utmp(5).  So the script always thinks it is in the runlevel it wants to be in, whether it is or not.

It is difficult not to conclude that they must not have tested that.  Even more obviously the timezone selection, which goes through all the motions of finding the correct zonefile but then forgets to copy it to /etc/localtime, so you are left in EST no matter what you choose."

But these solutions, even if incomplete, weren't captured in the bug reports, because no bug reports

were created for any of the issues causing the Remix to be withdrawn.

On March 13, Seneca student developer challahar wrote:

http://challahar.wordpress.com/2012/03/13/firstboot-time-zone-module-release-0-1/

"I had some difficulties getting my timezone module to run during firstboot. For some reason it wouldn’t run and I would get a Class Module error. Took me a week to try and figure out that error. I end up deciding to redo what I wrote and for some odd reason it worked. Who knew….. That would of saved me a lot of time. I’m sure it was some typo or some small error I accidentally made. Anyway I finally got the the timezone module to work and was able to get the graphical look to my module. However, when I select a timezone it doesn’t store the selected data and implement it. I’ve been trying a number or different things but it doesn’t seem to make any improvement on what I already have."

A month later, on April 12, challahar wrote:

http://challahar.wordpress.com/2012/04/12/firstboot-time-zone-module-release-0-2/

"I have tried to troubleshoot the problem that I am still currently battling from Release 0.1. For some unknown reason my timezone module hasn’t been able to hold the selected information and implement it within the timezone."

On May 10, Jordan Cwang made some progress on the timezone issue:

http://roottothehead.blogspot.com/2012/05/diving-into-firstboot.html

"When setting the time, it makes sense to set the timezone the system is in first, otherwise the clock gets set incorrectly.   As such, the timezone module will create the proper file at /etc/localtime.  However, later on the date and time module gets called, which uses it's own information and overwrites the newly created /etc/localtime with one matching that of the original timezone.

Now I have to start mucking about in system-config-date to find a way to bypass this bug.  Well, I did say I wanted to learn python..."

p.s.

the May 9 Fedora ARM meeting minutes are available at

http://zenit.senecac.on.ca/wiki/index.php/Category:Fedora_ARM_Meeting