|
DoomTrainPhD posted:And if I get hit by a bus then there's no core group of maintainers that will take over lol. out of curiosity, what's your mental model of the yocto design team? It's pretty heavily funded by Intel and is part of the Linux Foundation.
|
#
?
Nov 5, 2021 05:26
|
|
|
|
| # ? May 4, 2024 14:52 |
|
|
The Management posted:maybe someone who isn’t Google could come up with an embedded linux base OS that can do over-the-air automatic updates and keep an lts release maintained. https://en.m.wikipedia.org/wiki/Azure_Sphere
|
|
#
?
Nov 5, 2021 06:16
|
|
|
also, for people who don't know or simply forgot, Google did indeed release a version of android meant to be optionally headless and designed for 3 years of over the air updates when the product is FIRST released https://en.m.wikipedia.org/wiki/Android_Things There was an image for raspberry pi and it was ok. The idea is that vendors would take this image and develop their apps on it. Updates would be "cheap" since Google would just provide updated versions of the underlying OS to fix security issues. After some time with few-to-none industry backers, google changed its focus from low powered devices to smartphone-class devices before deprecating it completely
|
|
#
?
Nov 5, 2021 06:23
|
|
|
Poopernickel posted:out of curiosity, what's your mental model of the yocto design team? It's pretty heavily funded by Intel and is part of the Linux Foundation. Eh, it’s… fine. The core set of packages that are maintained by the developers are pretty decent. Yocto tends to do well because it’s easy for a corporation to make a layer with their bootloader and kernel and chuck it at developers.
|
|
#
?
Nov 5, 2021 06:50
|
|
|
Poopernickel posted:No joke, I'm doing a Linux for a 10MHz CPU. Ten. the slowest system on which I’ve booted NetBSD so far was a 16MHz 68020 and its performance was perfectly acceptable like, it’s slow, but it’s about as slow as it was back in the day, it doesn’t give me a “this should be faster on this system” feeling (like trying to boot in 8MB did, once it got to the point of running /etc/rc…) I really kind of feel like the embedded world is overlooking the BSDs these days, they can even restrict any source changes they make
|
|
#
?
Nov 7, 2021 08:17
|
|
|
fuckin love netbsd
|
|
#
?
Nov 7, 2021 18:32
|
|
|
what else is there to do?
|
|
#
?
Nov 7, 2021 18:33
|
|
|
eschaton posted:
it's less that we overlook it and more that we're fundamentally at the whims of what happens to be supported and has drivers and so on and so forth. if soc/som vendors had good netbsd bsps and no or bad linux bsps we'd use them probably
|
|
#
?
Nov 7, 2021 18:40
|
|
|
Pretty much that, yeah. I'd love to use a BSD but the driver support is pretty lackluster
|
|
#
?
Nov 7, 2021 19:24
|
|
|
lackluster is putting it politely
|
|
#
?
Nov 7, 2021 19:28
|
|
|
like honestly i think the thing that separates embedded dev isn't language or domain but a much tighter environment of constraints in what tooling you can use, what choices you get to make, what choices you can make, and also the business processes. embedded devs are a department of engineering in the same way that electrical and mechanical are. we are not in charge. we don't rule anything. we get input in what to do as much as the electrical folks get input in what to do. a lot of our poo poo is backwards and manual and some of that is our fault but not all of it
|
|
#
?
Nov 7, 2021 19:28
|
|
|
How do you folks package firmware updates? Swupdate? Or some competing/homeroll thing?
|
|
#
?
Nov 7, 2021 19:34
|
|
|
i have a "homebrew" method which is to set up two root partitions that are mounted read only and then a leftover that's writable, and software updates are partition images of one of the root partitions and you just write to the partition blkdev after you hash/sigcheck the image. then once you're done writing, you hit a bootloader arg to flip the boot target and reboot. it's homerolled, which is bad, but it's dead simple since you're producing those disk images anyway in buildroot or yocto or whatever. it could be more efficient but you can usually keep those images small. you mount them readonly to prevent changes getting made that get wiped out during update. there's a certain amount of bind-mount fuckery for files that want to be in /etc but need to be configurable like a hostname cache or whatever but it's not that bad. fake e: the whole separated write-then-switch-bootarg thing also really minimizes the vulnerability to loss of power events bricking systems, and the a/b thing lets you recover from failed updates if you want if you can correctly identify when the update has failed, which systemd can help you do
|
|
#
?
Nov 7, 2021 19:40
|
|
|
Phobeste posted:Words I homerolled something similar to swupdate before I knew it existed, now I'm wondering what other solutions are out there.
|
|
#
?
Nov 7, 2021 19:47
|
|
|
Poopernickel posted:I do something similar usually. But how do you package the firmware for deployment? Just download a .img.gz? Do you ever have to deal with bootloader updates too? oh, i take the image and zip up image, hashfile, hashfile sig and distribute that. on the shipping device it's a 384 meg image that zips down to about 100 which is basically the same size as the electron app lol. bootloader updates we Try Very Hard To Avoid, so far successfully aside from some random dtos that we just kind of grit our teeth and mount the requisite fat32 partition and gently caress around in
|
|
#
?
Nov 7, 2021 19:50
|
|
|
i mean it sounds like you probably know this already but the single most important thing about an embedded device update mechanism is that it's reliable and bug free. possibly the only important thing. it can be inefficient. it can have a gross mechanism. it just has to never ever ever ever in all your testing fail in an unexpected way because that's a bricked device that you're shipping back. you know you have a good update system when you have not touched the code in it for years. you keep it as separate as you can and you keep it as dog loving simple and ideally dependency free as you can and you beat the poo poo out of it in testing and then you don't ever touch it lol
|
|
#
?
Nov 7, 2021 19:56
|
|
|
Phobeste posted:oh, i take the image and zip up image, hashfile, hashfile sig and distribute that. on the shipping device it's a 384 meg image that zips down to about 100 which is basically the same size as the electron app lol. This is essentially the problem that swupdate tries to solve, standardizing the way you package and install updates.
|
|
#
?
Nov 7, 2021 20:26
|
|
|
Poopernickel posted:How do you folks package firmware updates? Swupdate? Or some competing/homeroll thing? mender. there is no better option.
|
|
#
?
Nov 7, 2021 20:36
|
|
|
Phobeste posted:i have a "homebrew" method which is to set up two root partitions that are mounted read only and then a leftover that's writable, and software updates are partition images of one of the root partitions and you just write to the partition blkdev after you hash/sigcheck the image. then once you're done writing, you hit a bootloader arg to flip the boot target and reboot. This is what mender does but better.  It mandates two root partitions and a data partition You use mender-artifact to create mender images and sign them with a ECDSA-P256 key The .mender images are lzma or gz compressed There are 20 different stages of which you can run scripts or programs for checks while updating if you so choose There’s automatic roll back support. There are delta updates with the professional version if you so choose. It can be ran as a server-client or in standalone mode. Personally we have two root partitions, a data partition, and a factory partition that holds things that should never be overwritten (ssh keys, calibration info, etc.) Use mender, it has excellent Buildroot and Yocto support, and supports uboot, grub, or uboot + grub. Edit: If using uboot you do have to patch it with the mender patches, which may be a bit of a pain and generally takes a few hours. Using Grub is plug-and play for the most part. FlapYoJacks fucked around with this message at 20:43 on Nov 7, 2021 |
|
#
?
Nov 7, 2021 20:36
|
|
|
does mender function with devices that aren't internet connected in a way that actually retains any of its advantages
|
|
#
?
Nov 7, 2021 20:43
|
|
|
Phobeste posted:does mender function with devices that aren't internet connected in a way that actually retains any of its advantages Yes, you can run mender -install /path/to/update.mender and it works the same way. The online part makes it easier to deploy updates and manage devices though.
|
|
#
?
Nov 7, 2021 20:44
|
|
|
that's kinda cool, i'll look into it. edit: probably gonna prefer swupdate because it's open source but w/e
|
|
#
?
Nov 7, 2021 20:45
|
|
|
Yeah, it’s a really good update service and I wholeheartedly recommend it over any other software update package provided you have enough space for two root and a data partition. I also highly recommend a persistent partition for things like ssh keys and VPN config files. Although the way I setup my devices is a factory reset is basically: mkfs.ext4 /dev/mmcblk0p4 and a reboot.
|
|
#
?
Nov 7, 2021 20:48
|
|
|
Phobeste posted:that's kinda cool, i'll look into it. edit: probably gonna prefer swupdate because it's open source but w/e mender is also open source? It’s written in go under the Apache 2.0 license. https://github.com/mendersoftware/mender
|
|
#
?
Nov 7, 2021 20:50
|
|
|
that's nice. what about it is better than swupdate?
|
|
#
?
Nov 7, 2021 20:51
|
|
|
eschaton posted:I really kind of feel like the embedded world is overlooking the BSDs these days, they can even restrict any source changes they make on the other end of the freedom scale does anyone have any experience with the proprietary ones like qnx?
|
|
#
?
Nov 7, 2021 20:54
|
|
|
Phobeste posted:that's nice. what about it is better than swupdate? “Better” is subjective. Swupdate doesn’t demand you conform to an A/B system setup and is far more hands off. This is either a good or bad thing. Mender is written in go, which is fine, but the binary is a bit big at 5~MB iirc. If space is at an extreme premium then swupdate is the way to go. Mender also demands you use A/B updating and their patches to uboot or mender-grubenv if you are using grub. It’s not bad, but it does take some setup/integration time. I also forgot to mention, but mender does have a plugin system for pushing updates that aren’t strictly A/B, like running bash scripts, installing RPM/OPKG packages, or updating docker containers. It’s quite useful. FlapYoJacks fucked around with this message at 21:05 on Nov 7, 2021 |
|
#
?
Nov 7, 2021 20:56
|
|
|
Never used QNX, but I've worked at two companies where somebody evaluated it and said "nah" for price and driver compatibility reasons. It feels like Linux will displace it once PREEMPT_RT is all done being merged into mainline. Poopernickel fucked around with this message at 21:12 on Nov 7, 2021 |
|
#
?
Nov 7, 2021 21:06
|
|
|
“PREEMPT_RT will be in the kernel soon!” said every year, for the last 10 years.
|
|
#
?
Nov 7, 2021 21:09
|
|
|
Lol true, but it's Real Close This Time. The patch-set is growing smaller and smaller, and a bunch of prep work for it has been merged into mainline over the past few kernel versions.
|
|
#
?
Nov 7, 2021 21:12
|
|
|
Anybody ever try out Xenomai? I've been itching to experiment with it but never had a good opportunity yet
|
|
#
?
Nov 7, 2021 21:15
|
|
|
Poopernickel posted:Never used QNX, but I've worked at two companies where somebody evaluated it and said "nah" for price and driver compatibility reasons. a blackberry recruiter reached out to me with a job that’s actually decent pay for remote and my location but… does qnx have a future outside of automotive?
|
|
#
?
Nov 7, 2021 21:16
|
|
|
hobbesmaster posted:a blackberry recruiter reached out to me with a job that’s actually decent pay for remote and my location but… does qnx have a future outside of automotive? Nope. Don't make plans that expect it to be popular 3 years from now. Go for it if you don't give a gently caress about the company's long-term prospects. Maybe RIM could make it work if they open-sourced it again and sold consulting services though. Poopernickel fucked around with this message at 21:21 on Nov 7, 2021 |
|
#
?
Nov 7, 2021 21:19
|
|
|
Just don't get paid in stonks unless you can sell them quarterly.
|
|
#
?
Nov 7, 2021 21:22
|
|
|
well, 3 years is a decent tenure at a tech company
|
|
#
?
Nov 7, 2021 21:22
|
|
|
4 if you have RSUs that are worth good monies.
|
|
#
?
Nov 7, 2021 21:24
|
|
|
Poopernickel posted:Just don't get paid in stonks. i like the stock 💎 🙌 🙈 or whatever the gently caress the meme is I actually bought a share along with one of a bunch of the other meme stocks. that did not go well, but loving dillards and build a bear of all things made the entire thing a break even.
|
|
#
?
Nov 7, 2021 21:26
|
|
|
This ain't stonk chat buddy!!! This is where we out-graybeard each other about our Linux janitoring
|
|
#
?
Nov 7, 2021 21:33
|
|
|
yeah embedded Linux is not the best path to figgiesland
|
|
#
?
Nov 7, 2021 21:35
|
|
|
|
| # ? May 4, 2024 14:52 |
|
|
hobbesmaster posted:yeah embedded Linux is not the best path to figgiesland Agreed, it’s not the best path, but once your in and have a decent network of people you can make very good figgies.
|
|
#
?
Nov 7, 2021 21:37
|
|