TrueOS Finishes Porting Scripts To OpenRC

[aht0]

well, that's not a really common situation for a LEDE system, so yeah, I hope it made sense for your usecase.

None really. I just played around with it. LEDE sources allow for switching between C standard libraries, though by default packages/images are built by using musl. I wanted to see how far the differences would go and would it build.

I'd say the main differene is caused by musl-binaries being much smaller on average compared to glibc-based binaries.

Most cases on x86 hardware you place the LEDE "firmware" on a USB flashdrive or sdcard, it does not write anywhere near enough to wear them out.

Since I was messing around, I did not want to cause needless extra wear on flash media. Mech drives also tend to be faster than USB flash and SD-card. At least decent 3,5" drives.

SAS RAID controllers are for fast-ish data storage, not for "superior IO". If I want superior IO I install SSDs or NVMe SSDs in dumb RAID0.

Well. Next SCSI iteration should beat NVMe.

http://www.scsita.org/library/presentations/STA%20Roadmaps%20-%20August%202015,%20with%20notes.pdf

Agree. Problem is, from certain sizes upwards, SAS RAID would be cheaper to use and have. Larger PCIe SSDs are fucking expensive. And there are only so many PCIe slots/lanes on motherboards.

None forces you to use a software that actually points out if there are issues for you to go and fix. You can always change its timeout to something much shorter, alter this in the systemd config DefaultTimeoutStartSec=

I could. But some service that would otherwise start at 1:15 would certainly fail, if I modified the period to something like 10 seconds. Counter-productive.

[aht0]

I love OpenRC but it boots significantly slower than Systemd and with a BSD kernel, well... think I'll take a nap while I wait.

Someone needs to throw wads of green toilet paper (aka money) at the project and mandate everyone use it, in the name of fatherland security or whatever. Russian trolls are trying to influence our Linux distributions! Shuttleworth met with Putin!! Oh noes!!!

That's the only way nowadays.

I tried timing boot of a most recent 11.1-RELEASE (old traditional boot).

19 seconds from 2,5" 5400rpm laptop drive (ZFS). Seems acceptable. It's not like I could get cup of coffee done with that time.

[Yndoendo]

... boot time is important to only home users, and even there, to the portion of it.

Embedded solutions do need a fast boot system, specially in Life Safety systems.

[aht0]

Embedded solutions do need a fast boot system, specially in Life Safety systems.

Umm.. You want to have linux on a smoke detector? Why? Afaik it's simple electronics, including optical sensor and small PCB.

[Yndoendo]

Umm.. You want to have linux on a smoke detector? Why? Afaik it's simple electronics, including optical sensor and small PCB.

Multiple remote sensory input devices tied to a master managing headless end with one or two fall-back systems, either through hardwired or wireless communication or both.

So in your scenario, a Fire Panel. Since they currently only communicate limited information versus being able to communicate directly with individual fire fighters that can get real-time information about what is going on at each level of a multi-story building. And assign in calculating which path the fire is taking and or came from.

But that is just one real-world solution that open RTOS (BSD / Linux) can assist moving forwards from current thought. And yes, I would classify a Fire Panel as an embedded solution.

[aht0]

Such systems are ON 24/7 365 days a year. How fast it would boot is utterly meaningless because you do not normally worry about it shutting down or rebooting, except for scheduled inspections in every n'th year.

One similar system at my workplace (does automatic fire suppression, opens up smoke-escape windows, warns about which floor/section/room did have which alarm etc) is fully automatic, always on and not running any real operating system as we understand them at all. It's just electronics and okay, firmware somewhere in it which allows (re)programming/scalability and adjustments. I queried the guys who did set it up. Has to be as dumbed-down, slim and foolproofed as possible. Systemd does not fit there anywhere - it's frankly flat-out dangerous for such use case.

[starshipeleven]

Systemd does not fit there anywhere - it's frankly flat-out dangerous for such use case.

Can you please stop casually shitting on systemd?

The main reason safety-critical stuff does not run Linux (systemd notwithstanding) is that safety-critical stuff needs to be real-time (Linux is not) and it also lacks safety certifications to ensure it does not lock up randomly or that it can ALWAYS recover from that (Linux was never aimed at that stuff so it does not, even if it is perfectly fine on its intended target usage). Plus the fact that in 99.999% of such stuff you don't need anywhere near the complexity of Linux kernel, and can get by with far far simpler stuff (there are also open RTOS solutions but they are not Linux.

And also because it's hard to run Linux in a microcontroller system with (far) less than 32k of RAM like most of the devices you look at.

[starshipeleven]

I'd say the main differene is caused by musl-binaries being much smaller on average compared to glibc-based binaries.

Yeah, Musl is chosen for that reason. Glibc binaries should theoretically run better, but in most embedded stuff the performance difference is negligible.

Since I was messing around, I did not want to cause needless extra wear on flash media. Mech drives also tend to be faster than USB flash and SD-card. At least decent 3,5" drives.

Well, maybe you didn't have fast SD/USB around, but with 30 bucks you can get things that pwn a mechanical drive with 80 MB/s random read/writes (sure a mechanical drive can do better on sequential, but most loads are not sequential).

Also, LEDE is designed for embedded devices that can't replace the onboard flash. It does only write configuration on flash, everything else is done in RAM.

Agree. Problem is, from certain sizes upwards, SAS RAID would be cheaper to use and have. Larger PCIe SSDs are fucking expensive. And there are only so many PCIe slots/lanes on motherboards.

That's still "large storage size", not "superior I/O". Any half-decent full-ATX board has enough pcie for at least a NVMe RAID0, which is pretty much the most you can realistically want (again with mdadm raid, not "hardware"-actually-firmware-based-software-raid like motherboard's "RAID")

I could. But some service that would otherwise start at 1:15 would certainly fail, if I modified the period to something like 10 seconds. Counter-productive.

You can then change the service's unit file.
Type=oneshot
This disables the timer for that service.

[starshipeleven]

Umm.. You want to have linux on a smoke detector? Why? Afaik it's simple electronics, including optical sensor and small PCB.

Half-serious IoT is usually Linux-based stuff, smoke detectors per-se are not IoT and that's not gonna change, but for example they can be enhanced by adding some info-gathering stuff running Linux on the side (in the sense of adding another separate board or circuit to the same device, the actual smoke detector circuit does not change), so they can gather any data their manufacturer thinks is worth it.

That's how you can monetize your customers, which is very popular nowadays.

Besides, Qualcomm is running their modem systems with an hybrid RTOS (on one core) + Linux (on another) making an "Arduino Yun"-like arrangement, where the Linux kernel runs a basic router, webinterface and I/O for the modem system that would be plain unable to do that on its own, like for example it emulates serial ports, ethernet ports, CD (for installing drivers) and SDcards (if the dongle has an SDcard slot) over the single USB port of a 3G/4G dongle, by using the Linux USB-OTG (or "usb-gadget") functionality.

EDIT: also Huawei does the same.

[Yndoendo]

Such systems are ON 24/7 365 days a year. How fast it would boot is utterly meaningless because you do not normally worry about it shutting down or rebooting, except for scheduled inspections in every n'th year ...

I never said anything about Systemd, just boot times are important. Time to reboot and bootstrap is time that you cannot capture reportable incidents. 5 minutes down can mean life and death.

Life Safety systems are designed to RUN 24/7 365 not be ON 24/7 365. They are just like every other computer; firmware / system updates, hardware changes, and configuration changes which require a reboot.

I occasionally deal with Fire Panels and major of the systems run propriety protocols across 3-wire or 4-wire RS485, solid wire only and at least 18 gag. They are more reliable hard-wire Security systems, requiring Fail-Safe wiring; AKA Normally Closed connections.

Fire Panel technology is quite bad and it would be a good place for a new company to get a foot into with better technology. How many smoke detectors do you know that inform you about the particulate count in the aerosol? That would let you / software know if the smoke was building up or dissipating instead of a concentration above X. Nor is there really any redundancy with the main head-end, still the same old master/slave setups. Once that line is cut you don't know what is really going on, just that there is a systems fault.

By the way, my life safety design motto is, "Communicate Of Things where the Internet cannot be trusted".