Hello!! I wanted to talk about the softwares we use every day, and their "embedded" alternatives Like the core shell software like ls, cat, grep, tar, etc. We usually get those from GNU coreutils. or the way in which we remotely control our systems, which is normally done through OpenSSH. well for both of these, theres smaller more minimal alternatives! Theres busybox, which has a cute name UwU and has all the same programs, but is super tiny because it is a single program that shares code between tools to eliminate code duplication. And for SSH, theres this cool thing I found called dropbear that offers both server and client components. matt.ucc.asn.au/dropbear/dropbear.html
These things are obviously meant for embedded use, but my question is: does that really mean anything?? Like.. what are you really losing with these? Would operating systems/distros really suffer if they actually switched over to these? How much work would really be needed to make things compatible if they wouldn't be? Didn't Debian switch its /bin/sh to dash? That seems to be working out in the end.
Also, can u think of any other cool "embedded" alternatives that could be useful replacements for their bigger brothers, OwO?
Your boyfriend's dick in your ass and mouth (in that order) every night, you vile furry.
Joshua Rivera
Ok so embedded is basically systems that are really tiny and have very limited resources. Like let's say you wanted to run Linux on your router or something. That's a place where "embedded" software would be used. But my thought is whether these smaller softwares are actually viable outside of that space. Could the GNU/Linux ecosystem benefit from using lighter, smaller tools? or are there enough missing features and whatnot to make that a bad idea? Also a lot of this smaller software sounds really cute ^.^
Adrian Lewis
There is generally no reason to have less features on a PC (all long as the program is sane enough), however, if you don't need some feature(s) then smaller/more lightweight alternatives can be better. On embedded devices and other resource-constrained environments, it ofc wouldn't make any sense to include unneeded bloat. But busybox is very useful to have for recovery environments in PCs.
Less-complex software is 1) Easier to maintain 2) More portable 3) Easier to switch to/from (For example, SystemDick is trying to devour all and it gets added as unneeded (and unwanted) dependency to some progs. As result you might be forced be used of SystemDick) 4) More reliable, fault-tolerant and less there are less bugs 5) Easier to audit, Less likely to have backdoor Botnet (it's harder to hide it) 6) Less-complex programs are also (probably) faster, more power efficient
If you are interested in a more bare-bones systems, you should check out Alpine Linux ( alpinelinux.org/ ) Alpine uses busybox and it doesn't install GNU utilities by default (they are available in the repos, however).
Have you got more imagery like this floating in that head of yours? I'd like to know, for curiosity's sake.
Asher Walker
I like the idea of alpine but I wish it at least had manpages. Even when you install them they're not for every tool and the docs are usually a generic "POSIX" page that isn't nearly as helpful as a regular manpage. Maybe Gentoo would be a better choice. It does use GNU coreutils, but you can choose a different libc and compile all your packages with certain flags (if I don't use KDE why should my programs have KDE integration?) These are the main ones for me.
I run Gentoo on my desktop (might replace Void with Gentoo on my laptop. But I am also considering Alpine) Gentoo is very nice distro, but if you have low-end system then you probably want to use distcc to compile your packages and/or use CloverOS ( wiki.gentoo.org/wiki/Distcc ), ( cloveros.ga )
Some tips and other things that I wanted to mention: First of all, you should compile the kernel yourself. Genkernel sometimes messes up (but you can use genkernel to build your initramfs, but dracut is also available in the repos).
Install gentoolkit (nice utilities for working with Gentoo) install app-portage/eix (for faster package searching) install app-portage/euses (to lookup USE flags)
Install app-portage/layman to manage overlays (= 3rd party repos) Just run layman -L to get list of available overlays, mask all of the packages from that overlay (add */*::OverlayName to your /etc/portage/package.mask) then add the overlay with layman -a OverlayName , run layman -S to update the overlays and then unmask the packages you want to install in /etc/portage/package.unmask (idk if you have used gentoo before, but overlays often seem to confuse those who are new to gentoo)
I don't normally give tripfags attention but you actually talk about Zig Forums instead of LARPing for attention so I'll break my rule. I'd advise being less of a faggot though. That trip will eventually bite you in the ass if you catch the attention of the wrong autist.
These applications are intended for use in an environment that rarely changes and where there are minimal resources. A general purpose computer generally doesn't have those requirements. So storing two versions of a lib doesn't cause a problem. You _can_ use them on a general purpose machine but there really isn't much point.
You lose the ability to modify the software and have it back up and running quickly for the most part. Embedded software is designed to be used as a whole where the tools in most OSs are designed individually. Upgrading and auditing the software becomes a harder/longer task if you're having to re-audit all of the code every time you want to change it.
Depends, best answer I have is "more than it's worth when better options exist already". The current way of doing things works well enough. You develop bleeding edge stuff in a general purpose environment, take the things that work best, cut all the bloat, audit it, then package it together for an embedded system. That's the main difference between the two; Embedded software is intended to run for many years without changes/updates and is expected to function until the death of the hardware it runs on. General purpose software is designed to be changed quickly/often and will probably do so many times before the hardware it runs on finally gives out.
Also, it's worth noting that in the "good old days" embedded software was generally found stored on things where you only got one chance to get things right. When you're attempting to squeeze everything you can out of a small ROM chip you aren't going to be in business long if you allow bloat or badly written software to get through. It's why optimization has become a bit of a lost art. There isn't a problem of storage anymore so people just shit out something that works and call it good. I've watched the quality of the average programmer's code go down my entire life and I mainly place the blame on the fact that we have so much storage on systems these days. When the average PC sports 8-16GB of RAM with TBs of HDD space it's easy to hide bad practice.
Nobody who comes from an embedded background wants to use weenix for their embedded. The problem is it has all the momentum in that market. If there was a good free RTOS for ARM embedded linux wouldn't be a thing.
Sebastian Gonzalez
I get that a lot! well: thats kinda what the point is. "embedded" software like the ones mentioned in the OP would probably have better code quality and less bugs, on top of being smaller, which as you said doesn't mean much with how much storage we have today, but it appeals to my autism uwu and of course is better practice.
umm, isn't Jewgle Fuchsia an RTOS? Could that be stripped of its GUI and used for that purpose? Of course the best option, although its not really an RTOS would be something based on seL4. You don't get much higher quality than literally mathematically verifying the code's correctness.
I'd like to embed my shotgun into your incontinent boypussy and pull the trigger until your corpse resembles a Pollock original. I will then release a detailed, step-by-step guide to the public domain and procedurally generated fag corpses will take the art world by storm.
anyway, I guess this is sort of a software minimalism thread now, so any suggestions/recommendations would be great! I will say that as far as shells to be used interactively, busybox's ash implementation and mksh are the two smallest, yet still usable without losing your mind. dash I think is the actual smallest, but has no tab completion or history so it's a pain for interactive use. also as cool as they look, avoid using htop or screenfetch to get the amount of ram your system is using. Both of those programs use quite a bit themselves and over-report the number. I recommend just using the free command if mem usage is all you need, or whatever the BSDs use (they don't have free it seems) What's the best practice and most /minimal/ option for serving files over a network/networks btw? I'd prefer something with encryption, so no NFS (as comfy as it is). SSHFS looks great! but apparently pretty bad for setups where more than one person is working with it at a time. Samba? FTPS/SFTP with vsftpd?
Austin Morgan
I would just use scp if you need to move just a couple of files into another computer or setup vsftpd. Don't Samba and SMB have a lot of security issues?
y-your pic is so lewd! OwO Well I meant file serving as in being able to “mount” stuff over a network or share entire directories, like for a NAS. idk about samba security issues. I know from a course I took that if you have the NETBIOS features enabled they can be used as an enumeration tool, but I thought you could disable that. I did see that SMB can be encrypted though.
Try out BuildRoot on one of your old Raspberry Pis that you don't use anymore. It's basically an automated Linux from scratch for embedded systems and petty good for making set and forget servers. buildroot.org/
