|
My irl name is Steve Yocto, inventer of Yocto Linux. I named it after myself, not very creative I know. Anyhow, if you do a Linux I recommend Yocto Linux - it's the bees' nuts. Poopernickel fucked around with this message at 22:27 on Nov 1, 2021 |
#
¿
Nov 1, 2021 22:24
|
|
|
|
| # ¿ Apr 28, 2024 02:39 |
|
|
Yocto's license management is legit if you want to make sure you're compliant and that your licenses don't change out from under you. I like that I can set a "don't ever install gplv3" setting, and then be secure that it won't unless somebody intentionally forges license data on a package.
|
|
#
¿
Nov 1, 2021 22:35
|
|
|
DoomTrainPhD posted:There has been a lot of discussion on how to implement this in Buildroot. It's a highly requested feature! Model it after Yocto's with some changes. Add a config option that enables a build step after patch. The step checks to see if a recipe's license hash matches the license hash in the source tree, to ensure the recipe info is still correct. Trust the recipe author to be accurate about the license name. Fail the step if the license matches a blacklisted value (or if it's not whitelisted). Make this different for host packages, where it generally doesn't matter.
|
|
#
¿
Nov 1, 2021 22:46
|
|
|
If you're a "gently caress it, the defaults are probably fine" kind of guy then Buildroot is your jam. If you want to control everything then Yocto is what you want. Yocto has a much steeper learning curve IMO and it takes more time to get started. But it's a lot more powerful. Sometimes that's the right tradeoff, sometimes not. Also it has broad vendor support which is nice, because they can just ship a layer which will probably be a pain in the rear end for you to integrate. Poopernickel fucked around with this message at 22:54 on Nov 1, 2021 |
|
#
¿
Nov 1, 2021 22:52
|
|
|
Phobeste posted:words I solved a similar problem (manage a build tool that manages its own deps) with some black fucken Yocto magic at my last job. I added a manually triggered recipe action that downloaded all deps using the custom tool, and then updated the .bb file's license and src_uri sections based on the result. The recipe action was called manually or by CI job whenever somebody wanted to update the package's contents. It's nice having Python available to run arbitrary tasks, with full access to internal metadata. 
Poopernickel fucked around with this message at 23:15 on Nov 1, 2021 |
|
#
¿
Nov 1, 2021 23:09
|
|
|
hobbesmaster posted:you know how every python installation is supposed to have certain modules available as part of the “core” language? agreed, splitting up the stdlib was a very questionable design choice on Yocto's part. And by "questionable" I mean "dumb as hell"
|
|
#
¿
Nov 2, 2021 00:14
|
|
|
Progressive JPEG posted:i guess it depends on what made or didn't make the cut a lot of the stdlib modules are split into different Yocto packages. Like if you just install "python3", you don't get some stdlib sections like multiprocessing, io, etc. Those all live in their own packages, or can all be installed with a meta-package called "python3-modules". Usually you find this out when you're working on some new Python script on-target, and then you find out that chunks of the stdlib are missing for no apparent reason. Poopernickel fucked around with this message at 00:47 on Nov 2, 2021 |
|
#
¿
Nov 2, 2021 00:45
|
|
|
Progressive JPEG posted:btw how common is msdos in embedded environments these days pretty uncommon, Linux has mostly pushed it out. I'm sure somebody's still rocking freedos on an industrial PC somewhere though.
|
|
#
¿
Nov 2, 2021 00:46
|
|
|
CRIP EATIN BREAD posted:i never used any p-langs with yocto so i cant help This is controllable on a per-package basis in Yocto, if you ever find yourself having to deal with it again.
|
|
#
¿
Nov 2, 2021 01:26
|
|
|
the chip shortage is real, my friend that said, digikey has a bunch of attiny parts in stock
|
|
#
¿
Nov 2, 2021 06:51
|
|
|
No joke, I'm doing a Linux for a 10MHz CPU. Ten. I rate the experience 0/10 would not do again.
|
|
#
¿
Nov 2, 2021 16:01
|
|
|
It's actually more usable than you'd think with a minimal kernel and a BusyBox rootfs. Target is an armv8 running in an emulator. RAM runs at a much faster clock rate. Serial console is usable and feels "ok" but not great. Shell scripts are tolerable speed-wise. Boot time is around 90 seconds once the kernel has loaded. Poopernickel fucked around with this message at 17:57 on Nov 2, 2021 |
|
#
¿
Nov 2, 2021 16:22
|
|
|
Yocto's bbappend/layer system is good, and Buildroot should emulate it. Make it easier for users to modify recipe behavior. In today's world, you have to either: 1. jump through a bunch of hoops, or 2. fork Buildroot if you don't like how a built-in recipe does something or other. #2 is what I see most companies do, and it has a high long-term maintenance cost. Adam Buildroot, make #1 easier for your users and minimize human suffering. Do the needful T I A
|
|
#
¿
Nov 3, 2021 01:57
|
|
|
As an example, I recently found a package that had a missing dependency when built with some config options. My choices for how to add that dependency were: 1. Fork Buildroot just to add one missing dependency to a package. 2. Say "gently caress it who cares". 3. Dig into pkg-generic.mk to figure out what internal behavior I had to modify. Appending to ${PKG}_DEPENDENCIES doesn't work because it gets parsed during the recipe's call to pkg-generic. Poopernickel fucked around with this message at 02:12 on Nov 3, 2021 |
|
#
¿
Nov 3, 2021 02:10
|
|
|
DoomTrainPhD posted:submit a patch upstream. Cool, I guess that'll solve my today problem in 6 months when the next stable release comes out. Poopernickel fucked around with this message at 02:54 on Nov 3, 2021 |
|
#
¿
Nov 3, 2021 02:22
|
|
|
Meanwhile in Yocto land, you can upstream your patch _and_ fix it locally for the release you're currently using via a bbappend.
Poopernickel fucked around with this message at 03:18 on Nov 3, 2021 |
|
#
¿
Nov 3, 2021 03:06
|
|
|
DuckConference posted:the only industry standard in embedded is that your poo poo is always different from everybody else in the industry. Truuuuuuth son
|
|
#
¿
Nov 3, 2021 03:06
|
|
|
sb hermit posted:I see the reality of simply forking buildroot when a project starts, and keeping all development for a specific project on that fork, to be the industry standard. No one is going to update packages in the middle of development unless they're willing to spend a lot of real dollars to have qa go through all the testing, auditing, and qualification (not to mention pre-certification) steps when there's a material software change. I worked on a product that took around 2 years to take to market. We upgraded Yocto versions shortly before beta. I had to bump three submodules, change a couple of config files, delete one .bbappend (fix got upstreamed), and tweak another. It took one workday. Yocto is great if you want to keep your customizations somewhere other than mixed with your upstream sources. Poopernickel fucked around with this message at 05:41 on Nov 3, 2021 |
|
#
¿
Nov 3, 2021 05:23
|
|
|
DoomTrainPhD posted:In other news, I submitted a patch to bump OpenJDK 16 to 17 for Buildroot. This means Buildroot supports the last two LTS versions (11 and 17.) It's still crazy that the meta-java layer for Yocto still only supports 7 and 8 and kind of 14. nothing stopping you from submitting a patch, my dude - there's no difference there. Just like in Buildroot land, it'll happen as soon as somebody wants it enough to do it.
Poopernickel fucked around with this message at 21:10 on Nov 4, 2021 |
|
#
¿
Nov 4, 2021 21:06
|
|
|
just remember folks, the S in IoT stands for security
|
|
#
¿
Nov 5, 2021 05:24
|
|
|
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
|
|
|
Pretty much that, yeah. I'd love to use a BSD but the driver support is pretty lackluster
|
|
#
¿
Nov 7, 2021 19:24
|
|
|
How do you folks package firmware updates? Swupdate? Or some competing/homeroll thing?
|
|
#
¿
Nov 7, 2021 19:34
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
This ain't stonk chat buddy!!! This is where we out-graybeard each other about our Linux janitoring
|
|
#
¿
Nov 7, 2021 21:33
|
|
|
sb hermit posted:Sure, just give me a beaglebone and I'll get right on it 
|
|
#
¿
Nov 9, 2021 04:48
|
|
|
agreed, systemd is a Good Thing on embedded systems. It's a poo poo project maintained by the worst company imaginable (IBM), and easily 50% of it are bad and dumb things. But the other 50% really kicks rear end, and systemd-init is miles above every competitor when it comes to making a good embedded system. Really nice to have an init system that can express things like: - Service A can only run if service B running. Shut it down if Service B crashes. - Service B depends on a USB device being present and active (such as a USB microcontroller that looks like a USB UART). - Service A can't write to anything outside of /tmp, and can't exec anything. - Service C and Service A share a common /tmp, but service B can't see it. - Service C will get auto-restarted if it doesn't kick the watchdog every so often. - Service C will restart up to 10 times with a 0.5 second delay before eventually giving up. - Service A and all children can only run on CPU cores 5 and 6. - Service B is granted setcap to change its own process priority, even though it's running as a non-root user. Poopernickel fucked around with this message at 22:00 on Nov 10, 2021 |
|
#
¿
Nov 10, 2021 21:54
|
|
|
sb hermit posted:I'm just gonna make my main process be the init and install a kernel watchdog to hard reboot the system if poo poo happens hope you don't like being able to log in with ssh or a serial-console
|
|
#
¿
Nov 10, 2021 22:06
|
|
|
DoomTrainPhD posted:perché non entrambe? Why not have a bash script call your app and then exec systemd? jeezus that's the worst of every possible world, you'll have a mystery floating process that systemd isn't monitoring. And if it crashes, the kernel won't restart it like it does with PID1.
|
|
#
¿
Nov 10, 2021 22:10
|
|
|
Been playing with qemu a bit over the past couple of days. The riscv emulator is surprisingly fast. Kernel boots to a login prompt in around 2 seconds.
|
|
#
¿
Nov 12, 2021 16:39
|
|
|
somebody should make a BSD that runs on Linux and call it Linux Subsystem for BSD (LSB for short)
|
|
#
¿
Nov 13, 2021 17:09
|
|
|
that sounds nightmarish ooc, why selinux instead of systemd sandboxing?
|
|
#
¿
Dec 10, 2021 08:04
|
|
|
sb hermit posted:selinux provides very very strong type enforcement of a ton of resources. So if you want to make sure that a constellation of apps only access certain files or directories, or if you want to enforce the ability to only listen to certain network ports, and so on, then selinux is the tool for you. systemd does both of these things on a per-service basis and it's super easy filesystem limiting: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ReadWritePaths= port limiting: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#SocketBindAllow=bind-rule rather than go the selinux route, I've had really good luck with this approach: 1. run all network-accessible services as an unprivileged user 2. very limited setcap for things like changing process niceness 3. systemd sandboxing to enforce access control. Read access to /bin, /sbin, /usr/bin, /usr/sbin was blocked on all services except the firmware update service. 4. Read-only rootfs. 5. Noexec on all writeable paths. 6. For the firmware updater, put the root-needing parts into something you can wrap with passwordless sudo. Use a sudo policy that only lets the thing be launched in very specific ways, and let your non-root service launch it as-needed. Steps 1-5 were all deadass easy with systemd. Also easy to maintain going forward. Poopernickel fucked around with this message at 09:50 on Dec 10, 2021 |
|
#
¿
Dec 10, 2021 08:58
|
|
|
|
| # ¿ Apr 28, 2024 02:39 |
|
|
Afaik nobody's managed to hack that line of products, although admittedly the stakes are low if they do - just some stolen software unlocks and maybe some secret sauce binaries
|
|
#
¿
Dec 10, 2021 09:20
|
|