My usual question for small cheap boards is: what will happen to OS support in 3 years? Is it using regular distro or is this a custom fork which will likely be never updated? The website says:
> The UNIHIKER comes with a Linux operating system based on Debian and various built-in features, which will be upgraded from time to time.
... don't expect OS upgrades here. If you want to play with it for a while then put it away forever, go ahead and do it; but if you want to build something long-term, better find a different board.
Why does it need continuous, perpetual support? Most devices like this get built, software installed, and never updated again. When is the last time you updated the ECU software in your car? I built a small arcade cabinet using an old raspberry pi 2b. Once I built it I've never needed to upgrade anything on it. It works fine and plays all the old games. I have backups of the SD card in case anything craps out.
Few years ago, you built your arcade cabinet, and decided to put some nice launcher like RetroPie. It works fine for a few years, and then your friends tell you about Pico8 support.. nice, it is supported by RetroPie release! not nice: retropie requires ubuntu 18.04 or later.. let's hope your device supports it.
Few years ago, you built a weather station. Sadly, the weather backend you had was discontinued. You found a great new one, and it even comes with SDK and sample code! Sadly, the SDK requires python 3.8 or later. Does your device support it?
Few years ago, you built the home automation server. But recently, you got the set of remotely-controllable disco balls for each room which use FOOBAR protocol. Good news: Linux kernel supports FOOBAR protocol since 5.14. Bad news: your device kernel is much older.
Few years ago, you built the smart controller. You don't want to manage your infra, so you decided to go with AWS IOT, it is super each if you only have a few devices. But AWS announced they are dropping AWS IOT.. does your OS support newer system?
There are definitely cases when you set up the device once and never have to touch it again, but there are also a lot of networked things out there, and you often want to control them..
If there's a vulnerability in any of the software or firmware that connects and interfaces with anything over a network, there's the possibility of something worming it's way in or out of it.
For something intermittently used like a game box that might not matter. For IoT-focused hardware that is connected to the internet continuously by design where, say, a malformed TCP packet could cause a buffer overflow in the network stack that wiggles it's way into root code execution by chaining through a bunch of unpatched vulnerabilities on a "never updated again" system? That's a problem.
No matter how elegant you seem to be, you'll always be running like half a dozen versions in the wild.
For any large deployment that kind of work will be on your shoulders anyways. Stuffing in security updates or whatever to that isn't crazy
Unless you're saying you want multichannel overlapping upgrade schedules where you have some NxM cadence matrix to test and support (as in ssh x+/-{1,2,3} AND your software x+/-{1,2,3} etc).
I've had to make and manage automated test rigs for those types of deployment as well.
That's an entire room full of whatever machines your deploying and a full time job.
Anyways, this stuff is hard for the out in the wild devices. Putting security updates in a monolithic release package is really the easier way to go and at that point it's on you.
In most cases, yes, in all cases, no. There's a lot of variants of "enumerate all devices on a private network if you visit a malicious webpage" exploits.
Connections are only part of the danger. Browsers need to access the internet and they can have security bugs. Also, people download files and the programs that process them have bugs. People download programs and those can be dangerous.
For the kernel, it is important that it protect against dangerous programs running on the system to keep them isolated.
Because as an industry, we are bad at our jobs. The network facing software has critical security vulnerabilities. Even security folks accept that as the way of the world.
At the point the software is released it has (hopefully) no known security vulnerabilities, which is a reasonably secure situation to be in.
However, eventually some of them will become known, and that is not safe.
There are plenty of reasons not to want your IOT bulb to be insecure that are unrelated to people mining crypto.
A pwned IOT lightbulb can be used to help DDOS sites. It can relay DDOS traffic, eating your own bandwidth. It can be constantly probing the other devices on your network looking for vulnerabilities, until it pwns something else and is able to slurp down your passwords and credit card numbers.
Are you seriously suggesting that having an actively malicious computing device inside your home network is no big deal?
If it has a camera, it can be used to steal your security keys if it can see the power LED on your device (or potentially even just if something connected to your device has a power LED).
But a "critical security vulnerability " depends on the use. My daily driver? Yes, I want all of the security updates. A raspberry pi for playing arcade games that I occasionally scp a ROM over to? I really don't care if someone hacks in.
We, as an industry, are bad about pushing "every device that is on the internet needs to be as up to date as possible all the time" when it reality there is a lot of unimportant stuff on the internet.
It's like locks. I wouldn't secure my house with a bike lock, but it's fine for my bike. My bike is less full of important stuff.
At best, that means you're externalizing the costs, i.e. now your device is part of a botnet and becomes a problem for other people. But of course that assumes that it doesn't become a problem for you as well; a compromised device on your network is a great launching point for local attacks and a way to send illegal traffic out through your internet connection.
Ah yeah, I need to stop working at random notice, because some CVE bros have to immediately update all my things to hedge the risk of organized crime targeting my $0 value data like I'm that casino.
Meanwhile in reality, no one gives a f about the rPi you use for your Guinea pig feeder.
The "security" industry is unfortunately full of corpo-authoritarians. Once they realised a lot of the population can be forced to do anything if they can be convinced it's for "security", they've been doubling down on that.
Well, a common thing with open computing resources these days is cryptominers. Sure, you don't care about updates, until someone puts a miner on it and you have to go in and try to fix it. It wouldn't matter that your single device doesn't have enough processing power when there are tens of thousands of similarly vulnerable devices to hijack.
Because that is the nature of these SBCs. They aren't some generic queryable platform running UEFI. Instead you have a bespoke OS fork for each individual board. This means that vendors need to give a lot of attention to the software because there isn't a foundation or company taking care of all SBCs at once. The device becomes obsolete very quickly if you can't install recent software. SBC performance hasn't increased much. There are still plenty of boards with A53 cores that have been used for more than a decade.
First, this advertises this as a PC which have longer lifetime and higher security requirements than embedded.
Second, embedded systems have reliability requirements. Something will not work and will need support and updating to fix. The big advantage of normal distribution is that somebody has probably already fixed it.
Third, devices get repurposed. My five year old Raspberry Pi has had multiple jobs, and when it is done running Home Assistant, I'll find some other use. Plus, with normal distribution, I can easily install the packages I need.
All software have many dependencies (IMO for very wrong reason), if you can find a way to build a static system where nothing need to be updated good for you, but I doubt that this is the majority of use-case.
Will this device be able to load any web page in one or two decades? It would likely be slow, but the impossibility would be a pure software limitation.
It's dead on arrival; currently runs Debian 10 with custom patches and binary blobs. It's an RK3308 so not entirely impossible to run on a normal distro, but you'd have to bring your own firmware and device tree etc.
This is designed as an embeddable component for learning, prototyping, and OEMs. A lot of people here are just sniffily dismissing it as 'DOA' when what they mean is 'I would not want to maintain this.'
No, it's DOA. Embeddable components need support too. As do OEMs and prototyping scenarios.
It is presented as a viable commercial product, but it actually is an old SoC with no ecosystem. If anything, it teaches people not to use this type of thing.
The only way it would not be e-waste is if it had a future, and it doesn't and that's why it's bad. At this price point there are so many community and commercial alternatives that do have an ecosystem and support it's just pointless and most likely an attempt to dump overstocked Rockchip parts. Even an ancient i.MX 6 is a better choice.
Dude, Debian 10 goes out of support in a year. Debian 12 already released.
It's 4 years out of date at release, why would you want that for "learning and prototyping", let alone start a OEM device with soon unsupported software versions.
In my opinion the vendor supplied OS distros are to be taken as just a starting point, nothing to rely on more than the time needed for the port of one of the well established distros (Armbian, DietPI, stock, etc) to appear for a given board, which often happens quite fast when driver blobs and lack of documentation don't get in the way (the RK3308 used here is well supported along the WiFi chip). My usual approach when looking for a board is to check first if there's some support from the above distros, or wait.
It may seem odd, but it's just the same reasoning we're used to in the PC world translated to the embedded world: whoever would expect Gigabyte, Asus, etc. to create and supply the Linux distribution that runs on their PC mainboard?
If you want to play with it for a while then put it away forever, go ahead and do it; but if you want to build something long-term, better find a different board.
I think it depends on what you want to do with it.
If you're building something that won't access the network, or will be isolated to the LAN, then it's fine.
Not everything needs or wants to be connected to the internet.
depends on whether you care about vulnerabilities or not, I suppose. Presumably that lighting controller talks to something. If it talks to a local network only and it's impossible for external traffic to reach it, maybe not such a big deal. If that's not true it might be significant. That's also true of all IoT junk anyhow, it's all running some linux variant under the hood and security / updating is rarely a major concern.
This is actually one of the reasons I like bluetooth/zigbee/z-wave/IR/etc. so much - it puts a significant barrier to attacking devices even if they don't get patches. Of course, you still should pay attention to security and update them if possible because local and/or proxied attacks are still a thing, but it's much less likely to get hit.
Slightly unrelated, but I wonder what is a preferred OS for similar boards: a buildroot or yocto -based system vs a full-blown Debian-based distribution with desktop and package managers?
When I looked into (now deprecated) Jetson Nano I was surprised to find out there was no straightforward and documented way to build your own system and cross-compile for it. Is that because for many people using SBCs means doing everything on the target (e.g. compiling software), or am I missing something?
I just get the kernel and grab the stock Debian userspace for the architecture. Vendors like to do horrible stuff to their sample distros.
I’ve also tried Yocto and Buildroot and frankly they’re not that great. Yocto’s build system is so complicated it could take months to fit all your custom layers together to get a working image. Every vendor of every layer has their own conventions and you have to manage patch sets on top of patch sets to get some things working. Buildroot works better but still has a rigid vision for what an embedded Linux system looks like and how it fits together.
The beauty of Linux is that once you get to libc the interface is identical no matter what board you’re using so there’s no reason to build everything from source. And if you want something like Yocto you’d be better off building rpm or deb packages from a basic layer and then using eg multistrap to build a root filesystem.
It's not just small cheap boards. It's small expensive computers, too: I was burned just like this with the Sony VAIO 720P and the PlanetComputers Gemini PDA. Awesome hardware, pretty good drivers for the current kernel/distro, and then ... nothing.
> The UNIHIKER comes with a Linux operating system based on Debian and various built-in features, which will be upgraded from time to time.
... don't expect OS upgrades here. If you want to play with it for a while then put it away forever, go ahead and do it; but if you want to build something long-term, better find a different board.