Seneca breaks silence on Fedora Remix

Chris Tyler posted an update today.

Estimated release date is 20th, but lots of work to do.

http://lists.fedoraproject.org/pipermail/arm/2012-July/003631.html

That's a very interesting read.

Lots of problems that appear directly related to trying to force options suited to todays desktops onto the comparatively resource light Pi.

You have to wonder what PCI devices they expect to see on the Pi.

Wanting to enable SELinux seems particularly strange. If there's any educational goal left, surely we want to get kids interested and hooked on doing stuff before we teach them to hate SELinux ?

If they really want the Pi to get into schools then network boot is pretty much mandatory.  The horrors of administering classroms full of devices each with local storage don't bear thinking about.  You have to have central administration or teachers will be jumping off bridges.

1) I want it to actually scan for the PCI devices ...yes the RPi doesn't have a PCI expansion

ok, so why bother ?

but it's quite possible for a
SOC or any other part to have an internal PCI bus that the peripherals are attached to and also not all may be enabled since that GPU device does some configuring before hand so you can't just guess the config.

Certainly true that it's possible, however ARM devices tend to use AMBA for anything on the SoC. We know the RPi uses AMBA and that it doesn't have PCI, so why waste space on any PCI options ?

He says "I don't want to turn off SELinux", then implies that he will because it's too memory expensive. Not sure how to read that any other way, not wanting to turn it off seems to me a strong hint that you want to turn it on.

Yes and no. The idea of just been able to tinker means you need to be able to do your own thing with your own image.

However if you are putting these into schools you need to be able to revert these systems at least for the period of the lesson to a common system image so that you can be certain of reaching a given outcome.

Having said this failing is often the greatest learning experience....but the curiculum and the fact that they want to measure that such and such a fact was taught on such a day would probably exclude that.

I hope that this RPi don't become a boring bit of crap that's just a vehicle to drive some ones idea of curriculum and to make it EASY for teachers to pour the same stuff down everybodys' neck ...At this point you would be better off with a propper real PC that can be got for bugger all 2nd hand

True but also you need to maintain as much of the distro consistancy as posible  unless you want to be the maintainer of 1000's of mods.

"He says "I don't want to turn off SELinux", then implies that he will because it's too memory expensive. Not sure how to read that any other way, not wanting to turn it off seems to me a strong hint that you want to turn it on."

Sounds more likely he wanted to me consistant with the Distro but he feels that the memory hit is TOO big and will leave it off to me quite the oposite.

Personally it's better with it off anyway 'cos it has little relevance to a toy computer and not that much to a real one eitehr most of the time ...GRR bloody SELINUX

There's been some work done by swarren to get u-boot running. I know lots of people don't seem to like u-boot, but regardless. It does get you to a point where you can have a minimal amount of stuff on the sdcard and have u-boot do a network boot from there.

Not sure you can get to the sort of nice boot menus you could do with pxelinux & vesamenu, but it's a step in the right direction at least.

.GRR bloody SELINUX

that's my feeling too. 

I can understand wanting to be consistent with the distro, but for the educational goal I'd be wanting to remove the barriers to getting kids interested.

OTOH, carrying all the mods is the whole purpose of the remix isn't it ?  If you didn't need the mods you could just use whatever the upstream project provided ?

"

The kernel and firmware have been updated to the Raspi upstream. The

config we're using is (raspi SOC options + usb devices - non-USB devices

(PCI etc) "

Reading it again I would say that the Reference to "PCI" was more of a general sweep of the hand statement for "insert non USB devices/buses  here" rather than PCI  specificaly and exclusively.

Bored now!!!

Dennis Gilmore of RedHat explains why the Fedora Remix isn't planning

to take advantage of the RPi's floating-point hardware.  He says it's

"not likely to be a long term sustainable port."

http://lists.fedoraproject.org/pipermail/arm/2012-July/003669.html

Unfortunately Dennis' comment doesn't really make much sense, and "long term sustainable port" is pure market-speak.

Open source doesn't focus on market share nor on product life nor on some market-inspired concept of sustainability, but on community interest, and it requires a pretty low level of interest before someone makes an appropriate distribution to cater for it.  If both Pi and Via APC (and hacked Roku 2 as well in due course) would benefit from armhf, and that means hundreds of thousands or even millions of users, then hardhf will come.  It's sustainable if there is interest.

What Dennis really means is that he doesn't want to support it himself, which is totally fair  -- it's his own hard work after all.  But someone else will do so in due course, you can bet on it.

Morgaine.

I think Dennis is probably referring to the technical obsolescence of

the armv6 architecture, particularly for the education market and other

desktop applications.  Either the RPi will get upgraded soon,

or it will become irrelevant. So there isn't much point in making

a major investment in armv6 support.

I think Dennis is probably referring to the technical obsolescence of

the armv6 architecture, particularly for the education market and other

desktop applications.  Either the RPi will get upgraded soon,

or it will become irrelevant. So there isn't much point in making

a major investment in armv6 support.

I don't think Dennis meant that, since ARM9 is even more obsolete commercially than ARM11 and yet is still deemed worthy of FOSS support.  There is no concept of device obsolescence in that commercial sense in FOSS, everything is supported no matter how old if there is community interest.  And community interest in ARM11 is of course growing rather than shrinking because of the recent influx of cheap boards with ARM11 cores.  ARM is different to Intel in that respect, older cores are often used in embedded devices where leading edge computing is not the requirement.

It was just a personal judgement by Dennis, which he should have phrased as "Maintaining that additional architecture doesn't scratch my personal itch so I won't", which is how FOSS works, and he's probably not getting paid to do more than just scratch his personal itch.  It doesn't go more deeply than that.  Either someone else will step in and maintain an ARMv6 hardfp distro for ARM11 because they personally feel it would be useful, or it won't get done.  How modern a core is doesn't come into it.

Morgaine.

I agree with the itch scratching concept. Also if their emulation is good enough I'm sure that it doesn't form a problem in terms of numbers of bugs whic is the issue for them especially since they have plenty elsewhere!!!

Does any one know the potential improvement in real terms of getting HardFP working ...Surely over the whole OS this isn't more than say 5%...probably not worth the hassle?!?!

John

Morgaine wrote:

>ARM9 is even more obsolete commercially than ARM11 and yet is still deemed worthy of FOSS support.

but there is an important difference.   Fedora considers ARM9 worthy of continued maintenance, presumably

because not much work is required.  They are also willing to provide continued maintenance for ARM11

because it piggybacks on their ARM v5 distro without much additional work.  They draw the line at building

out a whole distro specifically for ARM V6, which is very costly.  Not only does it require more build-farm

resources than they have available, but the C compiler has never before been used in ARM 11 mode, which Dennis notes has unique floating-point support, so there are an unknown number of compiler bugs to fix

or work around.

>There is no concept of device obsolescence in that commercial sense in FOSS, everything is supported no matter how old if there is community interest.

I think there is a cost/benefit ratio involved.  If an older device is difficult to maintain and there is insufficient

community interest, it will get dropped.  GCC for example drops support for a number of architectures in

every major release.  Ubuntu has already dropped support for ARM 11 and older.  Fedora may follow suit

before too long.

John writes:

>Does any one know the potential improvement in real terms of getting HardFP working ...Surely over the whole OS this isn't more than say 5%...probably not worth the hassle?!?!

See the RPF front-page story on switching to Raspbian because of the perceived (but not quantified) benefits.

Not only does it require more build-farm

resources than they have available, but the C compiler has never before been used in ARM 11 mode, which Dennis notes has unique floating-point support, so there are an unknown number of compiler bugs to fix

or work around.

Not sure I buy that argument, Raspbian seem to be doing OK. 

If they're simply not interested, for whatever reason, they should just say so and move on instead of inventing arguments.  If Raspbian didn't exist then the argument may hold more weight, but you can't use something like that when a one or two man outfit has already proved it can work.

I see your point but the move from been the one and only reason for a project (Raspbian) to been one platform of many

(Fedora on Rpi(Senica)) means a change in attitude and any changes do need to work and be consitant with the larger mass. I do like the principle that the platform must be able to build it's self on that platform...the project is in effect eating it's own dogfood. Putting it simply if aint good enough to compile it's self it aint good enough to ship.

In this instance though I will also agree with you that this is an excuse, you could compile using an NFS store. I use this method and it's much much quicker than the SDCard aand obviously saves wear and tear on it too.

Also it'll be interesting to see how Raspbian is maintained in the future, will the enthusiasm continue ?

BTW does any one know if they build the Raspian Distro on  a PC or an RPI??

I see your point but the move from been the one and only reason for a project (Raspbian) to been one platform of many

(Fedora on Rpi(Senica)) means a change in attitude and any changes do need to work and be consitant with the larger mass.

But that's the thing, Raspbian is Debian-on-RPi. Conceptually it's no different than someone doing a hard-float ARM11 Fedora. I'm reasonably sure Debian ships more packages than Fedora too.  Sure, Raspbian isn't an official Debian port at this point either, but I got the impression a while back that it was possible it could become one.

BTW does any one know if they build the Raspian Distro on  a PC or an RPI??

They built their own farm using these MX53-START-RMX53-START-R which are a bit better than the Pi in that they have 1Gb RAM and SATA.  You can essentailly take a RPi sd-card image, tweak it to use u-boot and an appropriate kernel and boot it directly on one of these. So while not exactly the same you can get a more capable build environment that's very close to native, but without all the problems of true cross compiling from a totally alien arch.

There's some photos of their build cluster on the other forums, only one I could find is a few posts in http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=4256&start=225