yeah. It’s the first genuinely interesting SBC I’ve seen in a long time. They have high speed breakout interconnect boards as well that can theoretically provide even more functionality down the line when/if 3rd parties start making stuff for it.
Comes with a really interesting audio system as well.
2 GB of RAM is not enough to run Windows 10 (maybe it could run Windows 7, Windows XP should run fine if drivers work), and if you have to run Linux in any case might as well go ARM, since 95% of all desktop software written for Linux is already available for ARM (and most other software worth having also require a significantly more powerful PC).
The main advantage here is that you can install what you want instead of some random customized debian or community ports with shoddy driver support, and it will be much faster than anything on an arm sbc that costs $35.
There are plenty of theoretically better arm SBCs out there than the raspi but none of them are very popular because support is garbage.
This is an atom sbc, which means we know it will work, and we know it will work much better than a raspi for the exact same money. That is what makes this exciting,
It is absolutely worth the money if you’re in the market for the same reason anyone is in the sbc market, because it will steamroll anything based on arm.
You seem to be mistaken on what a driver actually is, and more importantly, how the Linux kernel driver support works. “Shoddy drivers” on ARM are almost invariably due to the manufacturer of specific components not providing enough information to write a working driver in Linux. This will not be different at all on the Atomic Pi.
RPi was not designed to be fast, but rather an efficient computing machine. Still, not that far behind:
RPi Model 3 B+: 1.4 GHz Quad 64-bit ARM CPU, 1GB DDR2 memory, 7.5W max power draw
Atomic Pi: 1.92GHz Quad 64-bit x86 CPU, 2GB DDR3 memory, 4-15W power draw
Of course something like the ODroid XU4C for $50 has them both beat in raw performance (though not power):
Not to mention the Odroid does have a dedicated separate GPU.
An SoC is not only it’s CPU - in fact most CPUs have a 100% well defined driver in mainline kernel already. The issue is with a lot of the peripherals, where most have shoddy support, with or without x86 architecture.
Sorry, as just demonstrated it will not steamroll much of anything actually. I do not think this will fly very far, but if you still believe strongly about it, you do you. If you want to play with it it’s only 35 bucks.
I would like to take this moment to add that I think it’s great that people develop these kind of boards, and I love to see new attempts at the same old formula.
The point I wish to make is that this will most probably not have the same support as an X86 chipset like the B450-I does, so do not have unrealistic expectations about it. I’ve been burned myself once or twice on new hardware and I want you to enter this with a realistic mindset.
Again, if you can spare the 35 bucks it’s nice to try it out, but most probably the main use will still be home servers for this, not desktops.
The rpi 3 is about six to eight times slower than this particular atom cpu in integer and FP raw. you can’t compare core counts and frequencies across completely different uarches. Arm is much slower clock for clock except on tasks where you have hardware acceleration on the SoC.
Doesn’t matter to the end user if it doesn’t work because of closed firmware, lack of documentation. or if it doesn’t work because it isn’t in mainline kernel. If it doesn’t work it doesn’t work.
in addition to the cpu performance being much better, the intel igpu performs far better than the onboard graphics on the rpi SoC. You can reasonably play indie games on this thing if you want.
This thing WILL perform much better than an odroid or a raspi, with better ootb software support. There’s a reason similar systems (e.g. latte pandas) usually command a much higher price.
It’s not bad to be wrong, just don’t be dishonest.
For context here, I own a raspi 3 and a few other arm SBCs.
They’re all very close to useless for nearly anything. Might as well spend less and get a pic dev board or an arduino if you need gpio, and the server applications are nothing that can’t be done as a secondary application on something else with how tight the constraints are. Most of them barely function past booting and lighting an LED. Bad for MCU stuff, bad for server stuff, bad for embedded stuff.
I also have some similar x86 SBC platforms, none of which I have any gripes with. They can do anything a modestly spec’d embedded x86 system would be expected to do. No performance issues even for indie games, in home streaming, HTPCs, or render clusters. They basically come through on every promise arm SBCs fail to deliver. They are also typically a bit pricier.
This one is exciting because it’s $35 for something any reasonable person knows is much better hardware than what’s on most arm sbcs.
You pretty much nailed it when you mentioned effeciency.
One of the reasons ARM is so prevalent among embedded devices is due to it’s effeciency where x86 chips are rather lacking. Not to mention that ARM, generally speaking, is pretty damn good at maintaining their architecture in the Linux kernel. You’d be pretty surprised at how much work they put in.
I never tried doing anything super heavy because I didn’t have anything at the time. I was mostly referring to YouTube and the like. Which I think most people are fine with. I have some higher quality rips now I’m sure it would struggle with just not sure at what point it would finally fall on it’s face.
yeah that was my experience. Youtube worked ok for the most part, but any rip at any bitrate worth watching, whether over the network or on local media would shit itself and crash openelec.
even worse, I was using a usb IR reciever and even when I tried transcoding down to 720p it would buffer or skip frames when you used the remote because of the split network/usb bandwidth, and crash if the file was too long a runtime.
also had issues with audio desync when frameskips happened (which they did often)
Tried just about every codec, container etc to try to get it working.