
Raspberry Pi (2 and 3) support in Fedora 25 Beta - cheiVia0
https://fedoramagazine.org/raspberry-pi-support-fedora-25-beta/
======
TD-Linux
One big thing here is that unlike Raspian or derived distros that use its
kernel, Fedora is building their own mainline kernel. We're finally getting
close to the day where installing on ARM will be as easy as x86, with no
custom kernel or vendor patches.

~~~
makomk
Yeah, and all it took was the Raspberry Pi Foundation rolling a series of
custom chips with as few hardware improvements since 2011 as possible so as
not to set back their mainline support. For most ARM chips where features like
better graphics, power management and peripherals matter more, mainline
support is still impractical and irrelevant.

~~~
webscaleizfun
The Raspberry Pi foundation picked a chip they were familiar with as Broadcom
employees. I can't fault them for that, but at this point chips like the
Allwinner H3 & A series have better support mainlined than the Raspberry Pi 2
& 3.

I say this having tried Raspbian & Debian on each platform, and having tried
more advanced features (like VC4, which seems to crash my Raspberry Pi 3 after
a minute while scraping by & giving me 59fps). I understand the choices they
made, but a helpful vendor that incidentally creates a community that then
supplants its support would be the ultimate end game, and that is where the
sunxi community is at at this point.

Perhaps the Raspberry Pi foundation can fix VC4 and get mainline distros to
support them, but severe bugs[1] & Raspbian including non-redistributable
images[2] have tempered my enthusiasm to spend time on their SBC, as it seems
like a hot mess that could drag me down with it into a licensing & bug ridden
abyss.

[1] -
[https://github.com/raspberrypi/linux/issues/1354](https://github.com/raspberrypi/linux/issues/1354)

[2] -
[https://www.reddit.com/r/raspberry_pi/comments/56e3vh/has_an...](https://www.reddit.com/r/raspberry_pi/comments/56e3vh/has_any_user_of_pixel_actually_read_the_license/)

------
mwambua
I'm pretty excited about this! I started using f22 after using Ubuntu for a
number of years, and I was particularly impressed by its package management. I
personally find yum/dnf easier to use than apt and slightly more transparent.
F24 has been an exceptional release and I look forward to running 25 on a pi.

Hopefully we'll have a Pi with better IO by the time it releases. :)

~~~
astrodust
It's nice that it's a unified command (yum vs. apt-get, apt-cache, etc.) and
the commands do seem less obtuse. I've been using Fedora since the first cut,
and by and large it's always been pretty great.

The one thing I'd like to see ported over is ufw, as that's one thing about
Ubuntu to envy. firewall-cmd is downright annoying and bizarrely designed.

~~~
seanp2k2
IMO just learn the real iptables commands. They're seriously one-liners with
just a few args, and then you'll know how to set up a basic firewall on most
distros.
[https://fedoraproject.org/wiki/How_to_edit_iptables_rules](https://fedoraproject.org/wiki/How_to_edit_iptables_rules)
is the fedora guide. There are others. Here's how to disable firewalld:
[https://fedoraproject.org/wiki/FirewallD#Using_static_firewa...](https://fedoraproject.org/wiki/FirewallD#Using_static_firewall_rules_with_the_iptables_and_ip6tables_services)

Note here that if everyone just spent the 5 minutes it takes to learn the few
basic iptables commands, we wouldn't have ufw and firewalld and firehol and
vuurmuur and Crazy Bob's Super Simple VBA-to-XML iptables rule generator.
Every attempt at making iptables "easy", I consider harmful, as it's a basic
systems administration skill that people continually hurt themselves by not
learning. iptables is not hard, but all of these wrappers _make_ it hard by
introducing their own dumb syntax while adding complexity and quashing any
hope of a standard interface between distros to control networking rules,
which iptables already was before they tried to "fix" it.

~~~
beagle3
I used to hold the same opinion as you, but I've recently changed my opinion
of firehol; it's a little higher level than ufw and friends, and highly
encourages good practices which are easy to forget or get wrong if you
iptables all the way.

I've realised that when I noticed that the comments I wrote for others on my
iptable configs were comparable in length and content to firehol (but not
verifiable or executable). Unlike ufw, firehol actually saved me significant
time and effort even though I know (and use) iptables directly.

~~~
ktsaou
nice you like firehol. iptables is still very hard in certain context. Try for
example to setup a load balancer for non-sibling IPs, with client affinity, or
use SYNPROXY together with NAT. I have spent 3 weeks in fulltime to handle all
these cases properly in firehol.

~~~
beagle3
Thank you very much for firehol, it is great! Haven't had time to use netdata,
but it looks great as well!

------
alxmdev
Excellent! I tried out Ubuntu MATE 16.04 on a Raspberry Pi 3 a few months ago,
and I was pleasantly surprised by how well it runs. The 1GB RAM is an
unfortunate limitation, but even so the Pi is a viable little desktop. Great
to see upstream kernel support and official releases from major distros.

~~~
swiley
I've done quite a lot of homework on a Pi3 I got for free from someone who
didn't want it. They're actually a functional desktop.

~~~
paulmd
They _work_ as a desktop but you're better off using something designed around
the task. SD cards are not really designed for heavy random writes on a long-
term basis and can be sensitive to corruption during brownouts that don't
necessarily trigger a full system dropout. The GPU was primitive even for its
day and has not gotten better with age. There's no SATA or USB 3.0, no GigE,
and everything runs across a single USB 2.0 bus.

For desktop or server use, the Pi is in the same price range as systems built
on laptop chipsets (Kabini, Baytrail/Cherrytrail/Goldmont, etc). These can
easily be had for sub-$150 normally and sub-$100 if you shop around. That's
about the same price as the Pi once you factor in all the _other_ things you
have to purchase to get your "$35 computer" to boot. They are are lot faster
and a lot more fully-featured. You can easily get SATA, GigE, USB 3.0, and you
can even get ECC RAM on the AM1 platform. Also check out the Liva series from
ECS and the ZBOX series from Zotac.

Of course if you have the cash you can also look at a NUC or BRIX or other
mini-PC but those are aimed a little higher in the market.

Also it's kinda sad to hold up an Intel product as a positive example of open
source, but it's much better than the Raspberry Pi. You are still reliant on
binary blobs to boot the hardware to this day. The graphics stack is open
source, the ThreadX-based VideoCore OS RTOS the GPU uses is not, and the
documentation/drivers are restricted to usage only on official Raspberry Pi
hardware.

~~~
khedoros1
A lot of people seem to want something like a more-powerful Arduino that they
can interface to a few I2C or SPI sensors, run some relays or servos, and
embed into a project. Use your old cell phone charger, buy a microSD for $5,
borrow a keyboard and some time on an HDMI TV to configure wifi, then just
access it through VNC.

Before the Pi3 with it's built-in wifi, it was also common to connect the Pi
to a laptop with an ethernet cable and access it that way.

For some people, one of those cheap X86 systems would make more sense, because
they're trying to use it as a desktop or to do something that benefits from a
higher-power CPU (real-time object recognition comes to mind). For a lot of
others, a little ARM board hits a few important points: it's small, doesn't
use much power, is easy to re-flash if it gets corrupted, is actually
available in their country, is generally easy to adapt Arduino code to work
on, and has a huge community around it focused on learning, experimentation,
and building things.

There's a nice little niche that it and similar boards fill.

~~~
paulmd
Yeah, it's nice for some embedded use-cases too but don't forget there's also
BeagleBone Black and some other tools that fit that use-case as well. Or just
a Bus Pirate in some situations. Depends on what you want to do. It's nice for
some video things that really whale on the GPIOs.

The "it's easy to reflash" thing really grinds me because it's just as easy to
image any other type of disk too. Yeah, the BIOS is on the disk too, but that
actually increases the chance of an accident since you can nuke it out with a
disk operation. It's legitimately hard to nuke a conventional BIOS unless
you're trying, and in theory UEFI should block writes of invalid firmware
images (one of the rare happy side effects of the cryptographic signing).

"using your old cellphone charger" is one of those things that sounds great in
theory but you should actually never do in practice. The Pi takes a lot of
power and needs much more voltage stability than a charging circuit. Using a
random charger is asking for corruption issues because the SD card will
silently fail writes.

For object recognition, check out the Jetson TK1 and TX1 boards. They're more
expensive than a Pi but CUDA GPU acceleration buys you a LOT more performance
and you still fit into a tight power budget.

~~~
khedoros1
> Yeah, it's nice for some embedded use-cases too but don't forget there's
> also BeagleBone Black

Agreed, along with dozens of other {Fruit} Pis, Udoos, Odroids, etc. I like
the BBB because it has those separate processors that can be used for tasks
with real-time priority.

> it's just as easy to image any other type of disk too.

In theory, yes, but there's something nice about popping out a microSD,
putting it in the adapter it came with, and sliding it into my laptop to re-
image (or a USB SD card reader, to image a disk from a Pi host directly). SDs
are small, easy to move between machines, and SBCs tend to have their OSes
distributed as image files.

In contrast, to take a backup image of the computer that I just bought, I
needed to download + flash an OS on a USB key, boot, and copy/compress a 256GB
disk onto a USB hard drive. It's a lot more steps, a lot more hardware, and
there's not a place that I could just download the bare OS image, if I
happened to lose the backup. It's just all around a less convenient process.

> [...] sounds great in theory but you should actually never do in practice.

...but that almost everyone _does_ in practice. I haven't personally had an
issue with it over 4 years of use.

> For object recognition, check out the Jetson TK1 and TX1 boards. They're
> more expensive than a Pi but CUDA GPU acceleration buys you a LOT more
> performance and you still fit into a tight power budget.

A lot of the people especially interested in this are working through a
university or technical school class, where the coursework assumes use of a
Raspberry Pi, specifically (there seem to be lots of courses like that in
India and the Middle East).

When it seems like the use-case fits, I try to point people to other hardware.
A lot of people that I talk to about the Pi are from poorer countries though,
where a lot of the time "cheap computer" takes precedence over "capable
computer". I hear what you're saying though, and I agree: There are a LOT of
SBC options out there (and none of the Rasperry Pi computers are necessarily
the best technically-suited for most things) and some very nice hardware a
couple of price brackets up.

~~~
paulmd
> ...but that almost everyone does in practice. I haven't personally had an
> issue with it over 4 years of use.

And lots of people have problems with it in practice. Here's a Reddit thread
on SD card corruption. #1 top voted and most commonly suggested way to rectify
it? Get a better power supply.

[https://www.reddit.com/r/raspberry_pi/comments/3how8w/pi_kee...](https://www.reddit.com/r/raspberry_pi/comments/3how8w/pi_keeps_corrupting_sd_cards/)

If you have a name-brand phone charger it'll probably be OK. So will a decent-
quality one from Adafruit or another reputable supplier that's intended for
this use. But "use a random charger you have laying around" is terrible advice
that significantly contributes to the Pi's issues with SD card corruption.

> In theory, yes, but there's something nice about popping out a microSD,
> putting it in the adapter it came with, and sliding it into my laptop to re-
> image (or a USB SD card reader, to image a disk from a Pi host directly).
> SDs are small, easy to move between machines, and SBCs tend to have their
> OSes distributed as image files.

You can pop out the SSD or HDD and put it in a USB docking cradle and treat it
just like a big SD card. A USB 3.0 docking cradle costs a grand total of $15,
so there's no reason not to.

And in contrast, the thing with the RPi is that many people find they need to
"pop out the SD card and reflash it" _a whole lot_. The Pi is really bad about
SD card corruption and the community has a blase attitude about it.

[https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=1275...](https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=127512)

Sure you should keep backups, but with the Pi I found myself _needing to use
them_ every two months or so. That's an unacceptable level of reliability for
desktop or server applications.

> In contrast, to take a backup image of the computer that I just bought, I
> needed to download + flash an OS on a USB key, boot, and copy/compress a
> 256GB disk onto a USB hard drive. It's a lot more steps, a lot more
> hardware, and there's not a place that I could just download the bare OS
> image, if I happened to lose the backup. It's just all around a less
> convenient process.

You're making this sound difficult, but the ironic thing is you have to do
most of those steps to flash the RPi's SD card with an OS image anyway. Oh
wow, downloading an image file and burning it to a USB stick with Rufus, what
a struggle. So much harder than downloading an image file and burning it to an
SD card using WinImage.

You can store a backup image anywhere you want. Backing up across the network
to your desktop computer works just fine. Linux has had Samba for like two
decades now and can mount Windows file shares no problem.

In fact you can even take an image of a running filesystem if you want, so you
don't even need to do the disk image thing. Wouldn't be my first choice but
it's possible.

> I hear what you're saying though, and I agree: There are a LOT of SBC
> options out there (and none of the Rasperry Pi computers are necessarily the
> best technically-suited for most things) and some very nice hardware a
> couple of price brackets up.

It's not even "a couple price brackets up": I paid $75 for my ECS Liva. I paid
$85 each for a pair of Liva Xs with the 2/32 configuration. That's within the
expected price range to get a basic Pi system going after adding a SD card,
high-quality adapter, etc. And you also get GigE, USB 3.0, mSATA, x86
compatibility, etc.

There's other -alikes with eMMC available too, and I'd rather do eMMC than a
SD card.

~~~
khedoros1
Use the Pi for what it's marketed as: A cheap computer to learn programming
on. It's meant to be tinkering-friendly and cheap before reliable, and I think
it does those well. I think you put too much emphasis on reliability and too
little on convenience, easy access to hardware-specific help from a large
community, and the ability to easily talk to external hardware in a
microcontroller-ish way. There are things I would always use an ARM SBC for.
There are things I would _never_ use an ARM SBC for (but that other people
apparently would/do).

I'll keep the ECS systems in mind for future recommendations, though. For
anyone that doesn't need the hardware interfaces and doesn't have some
external requirement (from a class, etc), they look nice. Do you have a
reliable source for the 2/32 Liva X systems at the $85 price point? Amazon and
Newegg both are more expensive, at the moment. Slickdeals had a $40 MIR listed
(bringing $115 down to $75), but that was last March, and doesn't help me much
if I want the hardware now.

------
eschaton
Hope this will eventually lead to Fedora on RPi3 with arm64. Like everyone
else they say "maybe" and "it only has 1GB RAM" with no consideration of the
other reasons to support 64-bit ARM.

~~~
annnnd
Exactly! One reason (though somewhat unpopular around here ;) ) is MongoDB
which requires 64 bit OS to use more than 2GB data.

> We currently only support this as a ARMv7 device like the upstream Raspberry
> Pi Foundation. I realize that aarch64 support is now upstream.

I was unable to find any info about that... Anyone know more about it?

As far as I am concerned, the whole "RPi3 is 64bit" bit is stretch at best and
a blatant lie at worst. What does it matter that you have 64 bit CPU when
drivers (WiFi, BT, camera, accelerometer) are only available for 32 bit
kernel?

EDIT: looks like aarch64 support is still not available:
[https://github.com/raspberrypi/firmware/issues/550](https://github.com/raspberrypi/firmware/issues/550)

~~~
nullr0ute
aarch64 IS available. The firmware supports it when the appropriate options
are enabled and the upstream 4.8 kernel supports it. The upstream kernel
drivers for the Raspberry Pi, when built as a 64 bit kernel. A lot of the out
of tree drivers (video offload etc) have issues with 64 bits mode.

The reason Fedora doesn't currently support it is purely the amount of time
available in the Fedora 25 cycle and best output for the time investment, also
a single image can boot on either the Pi2 or Pi3 so less confusion for the
average end user where it makes no real difference (same reason as the Pi
foundation). Look for aarch64 support in Fedora 26 :)

~~~
annnnd
> aarch64 IS available. ... A lot of the out of tree drivers (video offload
> etc) have issues with 64 bits mode.

"Out of tree"? You mean like BT? Yes, I agree completely... But that's "NOT
available" in my dictionary!

I don't care if there is a kernel which works with the CPU if I can't use the
most basic of functionalities that RPi provides (BT, WiFI, accelerometer...).
I'd be happy to be corrected, but you'll need to supply some citations.

------
andrewchambers
Running plan9 on a raspberry pi 2 is so fast. It ruined linux on a raspberry
pi for me, software currently is so heavy weight.

~~~
pjmlp
When I installed GNU/Linux for the first time, a Slackware 2.0 in 1995, I had
a Pentium 75 with 4 MB with a 512 MB HD....

Now compare with a PI or the modern GNU/Linux distributions.

------
willvarfar
What's really needed is RTOS capabilities so that the Pi can be better used in
robotics projects.

(I don't have a Pi, I have an Arduino redbot. I couldn't find any Pi robots
available when I was shopping around:
[http://williamedwardscoder.tumblr.com/post/136598180858/wher...](http://williamedwardscoder.tumblr.com/post/136598180858/where-
are-all-the-raspberry-pi-robots)

Proggit discussed it and pointed to the lack of RTOS:
[https://www.reddit.com/r/programming/comments/3zf04e/where_a...](https://www.reddit.com/r/programming/comments/3zf04e/where_are_all_the_raspberry_pi_robots/)
)

~~~
TickleSteve
FreeRTOS and others have already been ported to RPi:

[[http://www.osrtos.com/rtos/freertos](http://www.osrtos.com/rtos/freertos)]
[[http://www.stevebate.net/chibios-
rpi/GettingStarted.html](http://www.stevebate.net/chibios-
rpi/GettingStarted.html)]

------
ekianjo
Why does every raspberry install recommend dd instead of the cp tool? Cp does
the same thing and has a much better syntax.

~~~
snuxoll
GNU coreutils' version of `cp` supports copying to block devices, but not
every other implementation does (busybox's doesn't, for example). `dd` is
explicitly required to support block devices by the POSIX specification, `cp`
is not.

~~~
ce4
Why not just use cat? cat $image.file > /dev/$BLOCK_DEV

~~~
snuxoll
cat has issues with partial reads and is not suitable for copying files, let
alone images.

------
rocky1138
I apologize for my ignorance, but why is the original Raspberry Pi not
supported?

It would seem if the announcement has been made that it will never be
supported, a note as to why would make sense. Unfortunately, the news release
didn't include one.

~~~
nullr0ute
ARMv6 core, Fedora (and a lot of other distros) only support ARMv7 and newer.

~~~
rocky1138
Yes, but why?

~~~
nullr0ute
Because ARMv6 is EOL by ARM, has a number of architecture issues and
design/toolchain bugs. Until the RPi came along there was literally no other
non low end phone devices that had the ARMv6 design in them. Fedora made the
decision that ARMv6 wasn't worth the effort in supporting and the performance
hit that would affect the ARMv7 devices (at the time based on toolchain
optimisation). The original Raspberry Pi was announced long after that
decision was made and it was decided that it wasn't worth the effort to
support ARMv6, even 5 years on from that decision it's still the right one to
have made, and most other distros have had the same discussion around ARMv6
and still made the same decision to not bother with ARMv6 support.

~~~
rocky1138
Perfect, thanks!

