Debian and Ubuntu are nice, but not exactly bleeding edge. IMHO arch is far better, and comes with an extra bonus: you can use pacman just like on MSYS2 (Windows)
I use arch btw. It’s better because we the arch users say so. I’m an arch user btw.
Linux-factory: A framework used to create custom Linux Debian operating systems
31–40 of 88 posts
Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#32Alternatives that support more than just Debian: https://github.com/buildroot/buildroot https://github.com/skiffos/SkiffOS (Based on buildroot) https://www.yoctoproject.org/
these are for embedded boards though
Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#33Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#34Debian and Ubuntu are nice, but not exactly bleeding edge. IMHO arch is far better, and comes with an extra bonus: you can use pacman just like on MSYS2 (Windows)
I use arch btw. It’s better because we the arch users say so. I’m an arch user btw.
That's not arguing in good faith.
Here's a simple example: you want hyprland, patheon and interception-caps2esc on ubuntu? Good luck!
On arch, it's just a pacman away.
You don't like how arch is perceived as elitist? Use manjaro.
Ubuntu had its place in the last century, but with most development happening on git you need a rolling release.
Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#35Debian and Ubuntu are nice, but not exactly bleeding edge. IMHO arch is far better, and comes with an extra bonus: you can use pacman just like on MSYS2 (Windows)
If you want bleeding edge Debian as a rolling release, sid is there. It's all a matter of preference.
Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#36Debian and Ubuntu are nice, but not exactly bleeding edge. IMHO arch is far better, and comes with an extra bonus: you can use pacman just like on MSYS2 (Windows)
In a lot of situations, stable is better than bleeding edge. It depends on the use case.
For example, my personal computer is running Debian Sid (i.e bleeding edge, dev track) while my computer for work is using the latest Debian stable.
Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#37default.nix in this repo doesn’t seems to work since it doesn’t include poetry and many other requirements.
Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#38There are a ton of Debian system build tools out there and people keep making new ones:
Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#39I prefer the approach of AntiX and MX Linux. Start from a clean live distro, mod it to your taste, master it to a new Live ISO. You can also start from a normal MX/antiX system and make a live ISO backup. You can also install those ISOs. Systemd is optional on MX and disabled by default. LOTS of live and remaster options on those systems. I find myself more on live than on installed systems now. It's basically like w…
How do you maintain this as new base releases are made?
Ie: Do you just manually reapply your changes every time? Or just do in-place upgrade and then snapshot that?
Personally, by the second time I did this, I'd be writing a script. Then I'd want to script the running of the script.. and before you know it you end up with a framework..
Re: Linux-factory: A framework used to create custom Linux Debian operating systems
#40Earlier quoted context omitted.
Anything with a learning curve steeper than "throw your files in a Dockerfile and call it a day" unfortunately tends to be considered "not sane". There is a whole market when it comes to making new tools for people who "don't have the time to RTFM". And then for tools helping to use those tools. (To be clear: I really like Yocto)
Any recommendations on getting started with Yocto? I want to build a custom image for a Jetson, and Yocto seems like the only good option.
I just started learning Yocto a few weeks ago, and just shipped my first embedded image. Here are a couple of learnings and thoughts:
1. Start with an empty image and build your way up. There can be some cross-effects between packages depending on what you exactly do, it's a lot easier to debug if you go step by step. The base image recipes are all listed in the documentation, start with one of them.[1]
2. Lean into Bitbake and the whole thing. The more you try to fight it, the more it fights back. I liked this guide as a starting point to get a feel for it.[2]
3. Find a way to quickly iterate on your images. Nothing worse than losing your train of thought! Since I wanted to include update functionality I added swupdate, which integrates reasonably well with Yocto[3] - although the documentation is a bit difficult to read at times. But being able to simply push an update through WiFi is really, really nice.
4. If you do some lower-level stuff you'll inevitably need to create configuration fragments. This process was REALLY opaque to me. Say you want to set build options for U-Boot - you'll have to: 1) run `bitbake -c menuconfig u-boot` to open the config menu; 2) when closing the menu, you save the configuration in the default location; 3) then you run `bitbake -c diffconfig u-boot` to generate a config fragment; 4) you copy the config fragment into your recipe-append-folder and add it to the SRC_URI variable; 5) you run `bitbake -c clean u-boot`. When U-Boot is built the next time it will apply your configuration fragment to the build process.
These were the most important things that came to mind. Hope they help, and good luck on your journey! :)
[1] https://docs.yoctoproject.org/ref-manual/images.html
[2] https://a4z.gitlab.io/docs/BitBake/guide.html
[3] https://sbabic.github.io/swupdate/building-with-yocto.html