Why x86 and FreeBSD?!?

[aaronw]

I am surprised by a couple of things about this announcement. The first is the choice of going with an Intel Celeron and the second is the choice of FreeBSD. I have been working on embedded systems for over two decades. If it were me, I would choose one of a myriad of 64-bit ARM embedded boards over the Celeron, i.e. a Raspberry Pi, and two I would have gone with Linux over FreeBSD due to the much better support available. For one thing, an ARM board will be a lot less expensive than the Celeron and in the case of boards like the Raspberry Pi, will have very good support. If long term support for a board is required, there are plenty of ARM boards out there which offer it. I have several boards from pine64.com, some which have LTS. Another nice feature with the Raspberry and similar boards is their expansion via "hats". It also allows for an easy method of adding custom hardware via the PI bus. Some boards, like my Rockpro64 board also provide PCI express support. If this is anything like my current (now obsolete) Universal Devices unit, a high speed CPU is not needed and many of the ARM boards are more than capable of handling this.

As far as software goes with ARM vs X86, a very large percentage of software is available for both architectures with numerous Linux distributions providing full support for ARM, i.e. Debian, Ubuntu, Fedora, OpenSUSE, Arch, and more. I had no problem configuring a full desktop environment on my RockPRO64 board running KDE (or whatever other desktop environment one prefers). My experience with the RockPRO board shows it to be extremely capable, with support for 4K video (via HDMI) and plenty of storage with both eMMC AND micro SD and even NVME if the PCIe port is also used.

As far as FreeBSD vs Linux, Linux has much wider use, especially in embedded devices. Linux supports a much wider range of hardware than FreeBSD with many vendors actively writing support for Linux (and far fewer writing support for FreeBSD). And if you want to support a GUI or make use of graphical features via the HDMI port then Linux is definitely the way to go. While most of my embedded experience is with headless networking systems, almost all of the customers I have worked with in the past two decades use Linux. I can only think of one customer who uses FreeBSD compared to the dozens I have worked with who run Linux. Linux also has far more compatibility between different chips and platforms than FreeBSD. It will also typically be easier to work with hardware on Linux since Linux drivers and libraries are far more prevalent than FreeBSD. There is also far, far more development on Linux than FreeBSD. When it comes to protocols like Zigbee and Z-Wave, I expect there to be far better support on Linux as well since Linux provides many more consumer oriented features. Any software on FreeBSD will have been ported from Linux anyway.

I have worked extensively with embedded Linux for well over a decade, helping to maintain a small minimal distribution my employer provides in their SDK optimized for networking operations.

-Aaron Williams

[RDLSAT]

FreeBSD is an operating system for a variety of platforms which focuses on features, speed, and stability. It is derived from BSD, the version of UNIX® developed at the University of California, Berkeley. It is developed and maintained by a large community.

In addition to its Security advantage over other OS, FreeBSD provides a stability edge. FreeBSD servers have been known to run for years without issue. These are sufficient reasons for us to prefer FreeBSD over other OS.

 

 

[larryllix]

RPi was considered but the royalties on it's usage were prohibitive, apparently.

RPi runs on SD card storage which tends to fail as the SD cards have limited read/write capabilities. Also. power failures tend to leave unwritten data on memory cards, due to slow EEROM writing processes.

[Bumbershoot]

I think that the GPL license (which is a copyleft license) caused issues for UDI, ruling out Linux.  The FreeBSD license is permissive.

https://en.wikipedia.org/wiki/Permissive_software_license

 

[mwester]

I had a lengthy argument with UDI on this very topic when Policy was first being developed.

In a nutshell, the stated problem is fear of the GPL license.  One can argue the point (as I did), but the fact remains that even if nothing UDI does triggers the undesirable parts of GPL, there are still costs associated with legal advice to ensure same (costs that largely don't exist if one goes with the BSD license).

The technical criticisms remain -- while it's true that FreeBSD has a stellar history as a network device, it's just different enough from Linux to make things difficult, and some things (the very things I wanted the Polisy to be able to do) actually impossible.

I'm not the only one who's shifted their technical work away from the UDI ecosystem because of FreeBSD -- but the blame, ultimately, lies at the feet of Richard Stallman and the horrible GPL license, not with UDI.

[xlurkr]

I'm not a programmer, but it seems to me that if you think of eisy/Polisy as an appliance (once set up), and focus on the software interfaces it provides, its OS becomes largely irrelevant. If you want to program a Pi in Linux to do something with the devices that are controlled by your eisy/Polisy, you are more than welcome to.  And if you set up your networking right, it should be nearly as fast as if it were all running in the same box.

-Tom

[aaronw]

To me, this would make the product could be made a lot less expensive. A lot of the products I work on basically are networking appliances, mostly firewalls, 4G/5G head ends, etc. though these are typically much higher end (and not consumer oriented). Right now ARM basically owns the embedded space for devices like this as well as Linux. While there are other processors out there, they make up the minority (i.e. Intel, Risc-V, etc.) I expect Risc-V to make a lot more inroads in the future, but it will take a few years.

As far as the GPL is concerned, it should not be an issue unless the product is actively linking against GPL code. Generally this is not an issue. The majority of libraries are typically fully compatible with proprietary software, using LGPL, Apache, MIT, BSD, or numerous other licenses. Some libraries are under multiple licenses and there are some, i.e. Qt, which require buying a commercial license for some features.

There's nothing inherently bad about the GPL license as long as you are aware of it and the variations of it. Don't link or include GPL code in your product and you're fine. Using fork/exec with GPL code is generally fine. LGPL code is generally fine as long as you're using dynamic linking (there's rarely a good reason for static linking) unless you're modifying it, in which case you need to be careful but even this is doable. If the modifications add features which depend on proprietary software you may have a problem.

In general, however, there's generally no need to make any changes to LGPL code anyway.

It's also fairly easy to tell what license various libraries are under. In my Linux distribution if I search on a package it tells me what license that package is under so it's easy to tell if something is under GPL or not. rpm -q -i [package] | grep ^LICENSE will tell me the license it is under, for example.

If, for example, I want to know the license of /usr/lib64/libraw.so.20, the following command gives me the information: rpm -q -i `rpm -q -f /usr/lib64/libraw.so.20` | grep ^License

Also, for any major functionality on FreeBSD I think it would be difficult to avoid all GPL/LGPL software, especially if a GUI is involved (i.e. via HDMI ports).

[TRI0N]

On 1/24/2023 at 1:49 AM, RDLSAT said:

FreeBSD is an operating system for a variety of platforms which focuses on features, speed, and stability. It is derived from BSD, the version of UNIX® developed at the University of California, Berkeley. It is developed and maintained by a large community.

In addition to its Security advantage over other OS, FreeBSD provides a stability edge. FreeBSD servers have been known to run for years without issue. These are sufficient reasons for us to prefer FreeBSD over other OS.

 

 

Um... No actually UNIX® is NOT maintained by a community. It's owned by The Open Group which you MUST pay a license fee to use it even you just want to put in on your packing box like "UNIX®". It is not maintained by any community. It was also not developed at Berkley either. It was developed at Bell Labs which eventually was bought by AT&T and once their Motorola CPU Dreams came to a halt they sold it.

TRI0N

Edited January 28, 2023 by TRI0N

[lilyoyo1]

On 1/26/2023 at 5:06 AM, aaronw said:

To me, this would make the product could be made a lot less expensive. A lot of the products I work on basically are networking appliances, mostly firewalls, 4G/5G head ends, etc. though these are typically much higher end (and not consumer oriented). Right now ARM basically owns the embedded space for devices like this as well as Linux. While there are other processors out there, they make up the minority (i.e. Intel, Risc-V, etc.) I expect Risc-V to make a lot more inroads in the future, but it will take a few years.

As far as the GPL is concerned, it should not be an issue unless the product is actively linking against GPL code. Generally this is not an issue. The majority of libraries are typically fully compatible with proprietary software, using LGPL, Apache, MIT, BSD, or numerous other licenses. Some libraries are under multiple licenses and there are some, i.e. Qt, which require buying a commercial license for some features.

There's nothing inherently bad about the GPL license as long as you are aware of it and the variations of it. Don't link or include GPL code in your product and you're fine. Using fork/exec with GPL code is generally fine. LGPL code is generally fine as long as you're using dynamic linking (there's rarely a good reason for static linking) unless you're modifying it, in which case you need to be careful but even this is doable. If the modifications add features which depend on proprietary software you may have a problem.

In general, however, there's generally no need to make any changes to LGPL code anyway.

It's also fairly easy to tell what license various libraries are under. In my Linux distribution if I search on a package it tells me what license that package is under so it's easy to tell if something is under GPL or not. rpm -q -i [package] | grep ^LICENSE will tell me the license it is under, for example.

If, for example, I want to know the license of /usr/lib64/libraw.so.20, the following command gives me the information: rpm -q -i `rpm -q -f /usr/lib64/libraw.so.20` | grep ^License

Also, for any major functionality on FreeBSD I think it would be difficult to avoid all GPL/LGPL software, especially if a GUI is involved (i.e. via HDMI ports).

That's a lot of generalities. While this isn't my forte, reading what you wrote was enough to want to avoid using it if that was your sales pitch. 

It's not like the path udi took made for a prohibitively expensive product. Compared to the cost of other controllers, the eisy isn't that expensive. Look at the cost of an rpi4. Are they really saving much of anything? 

I'm quite sure UDI did their homework and took the path that they felt was best suited for their business