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.
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.
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.
A standard chipset isn't needed - but drivers and a standard way to detect the hardware is. The latter is handled by device trees - a hardware description loaded by the bootloader into memory, alongside the kernel.
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. :)
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.
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.
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.
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.
From their docs, nftables is "available upstream since Linux kernel 3.13. It supports 3/4 of the existing iptables features" - 3/4 is still a long way to obsoleting iptables.
I'll agree with you on firewall-cmd. One major problem is its documentation. They should initially provide really simple instructions on getting a base firewall (22,443,80) going... And then provide instructions on how to do zoning and what-not on the side.
I like the idea of firewalld, but what I don't like is the way you have to do things like --list--all-zones and other nonsense. The end results are good, it's just how you have to implement them that's ridiculous.
At least Ansible provides a tidy wrapper for it.
git has a reputation for being annoyingly quirky, but firewalld is leaps ahead in terms of marching to the beat of its own drum.
> Hopefully we'll have a Pi with better IO by the time it releases. :)
Are there any official plans to release a new model with, say, an on-board SSD connector or SATA port? Or is this just "Hopefully" as in "Hopefully it stops raining before I have to walk to the train station"?
Very likely the latter. All the "innovation" happens in the mobile phone SoC space. My two years old phone is already good enough. Any improvement beyond it is a nice bonus but I could easily live without. Yet the ARM SBCs are so far behind.
I'm betting at some point in the future phones have progressed so fast that it's better to just dump them into a server rack with ethernet over USB 2.0 than to actually buy ARM servers.
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.
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.
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.
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.
> 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.
> ...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.
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.
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.
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.
I have an Asus EeeBox at home (Atom N270, 1GB RAM), and besides the hard disk vs. MicroSD card, I think my Pi3 is faster than that. (If one includes the GPU in the calculation, it definitely is - with omxplayer, the Pi3 can play 1080p smoothly, while the EeeBox only gets about 5fps on 720p...)
The hybrid old-school machine you propose sounds interesting, though. ;-)
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.
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?
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 :)
> 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.
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.
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.
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.
