Software Bloat

I'm not as sure I'd include busybox. The reasoning, is more of 2 parts; one being that busybox does not seem to be constantly growing in other areas. The other part, is more of the base foundation of what busybox looks more of intended to be used for system recovery. In that case, what busybox includes would make sense.
 
I'm not as sure I'd include busybox. The reasoning, is more of 2 parts; one being that busybox does not seem to be constantly growing in other areas. The other part, is more of the base foundation of what busybox looks more of intended to be used for system recovery. In that case, what busybox includes would make sense.

or busybox ;)
busybox also has a clearly defined 'area' which it targets and it has not expanded outside of that and its purpose was not met by any existing tools.
 
busybox also has a clearly defined 'area' which it targets and it has not expanded outside of that and its purpose was not met by any existing tools.
Even busybox grows. Its size today is 2.1 MB. When it was released in 1999, it was meant to be a complete bootable system that fits on a 1.44 MB floppy. Today, a full implementation of it (over 200 UNIX utilities) doesn't even hold a candle to the 413 MB of 13-RELEASE mini-memstick.img, the minimum that it would take to have a complete bootable FreeBSD system that can also be used as a rescue disk.
 
Hehe, just like systemd is working on doing :rolleyes:
To see what's happening here, it's enough to write one single "unit file" for systemd and read the docs to find out how. I've never seen such opinionated and arrogant docs before. They talk about "bad habits" when it comes to daemons forking and maintaining pidfiles.

Mind you, that's how a Unix daemon works, ensures only one instance runs, and offers a reliable way to detect it's up and running. And that's done in a self-contained way with no external dependencies.

But no, systemd people think that's a "bad habit". They recommend to just fire up the daemon non-forking, with no checks whatsoever for success before moving on to the next in the start sequence. And if you want some checks, they recommend to call some systemd API from within your daemon or use dbus. A sane software developer should just refuse to do this crap in his daemon. See also https://forums.freebsd.org/threads/...ailable-on-a-remote-machine.82395/post-538484

I wouldn't call that "feature creep" (it's more than questionable in terms of features what that pile of crap is doing), but certainly dependency creep.
 
But no, systemd people think that's a "bad habit". They recommend to just fire up the daemon non-forking, with no checks whatsoever for success before moving on to the next in the start sequence. And if you want some checks, they recommend to call some systemd API from within your daemon or use dbus. A sane software developer should just refuse to do this crap in his daemon. See also https://forums.freebsd.org/threads/...ailable-on-a-remote-machine.82395/post-538484

I wouldn't call that "feature creep" (it's more than questionable in terms of features what that pile of crap is doing), but certainly dependency creep.
That portion, I wouldn't consider that portion to be feature creep, even though I may not agree with their point of view. It's more of; why does the service manager (or at least I consider that part to be in the service manager) need the systemd-home, or the logger, or the init, or the device manager (udev), among others.
 
To see what's happening here, it's enough to write one single "unit file" for systemd and read the docs to find out how. I've never seen such opinionated and arrogant docs before. They talk about "bad habits" when it comes to daemons forking and maintaining pidfiles.

Mind you, that's how a Unix daemon works, ensures only one instance runs, and offers a reliable way to detect it's up and running. And that's done in a self-contained way with no external dependencies.

But no, systemd people think that's a "bad habit". They recommend to just fire up the daemon non-forking, with no checks whatsoever for success before moving on to the next in the start sequence. And if you want some checks, they recommend to call some systemd API from within your daemon or use dbus. A sane software developer should just refuse to do this crap in his daemon. See also https://forums.freebsd.org/threads/...ailable-on-a-remote-machine.82395/post-538484

I wouldn't call that "feature creep" (it's more than questionable in terms of features what that pile of crap is doing), but certainly dependency creep.
😩 I think FreeBSD has been doing a better job than Linux in fighting dependency creep - and is seeing some success in the init system. Fighting the dependency creep in the ports tree - that's a losing battle, but still needs to be done, IMHO.
 
There is also bloat when Devs refuse to use the right technology or layer to do things.
JavaScript Devs that I work with thinks that is a good idea to filter Elastic Search results in js instead of do the right ES call. Hoo they refuse to learn ES !
And because of that ES will be replaced with a full costly solution in tier company.
So to solve the lack of developers courage, the solution impact architects, security, lawyers (for the contract) and the company loose end user data.
Draw your solution in a paper, if there is more arrows, squares or circles that the existing case, you do not solve something, you just ask unknown poeples to solve it for you.
 
There is also bloat when Devs refuse to use the right technology or layer to do things.
The "right" technology will depend on a lot of things. The budget, the customer, the delivery timeframe, the required quality (man on the moon and back again or a website to advertise tennis balls), the available human resources, security requirements, etc.

Sometimes "good enough" is exactly that. Not perfect.
 
Is there really a sense of losing?

What's an example of the creep?
Some distributions are well known of adding unnecessary dependencies to packages. This is very common in deb and rpm based distributions.
 
Some distributions are well known of adding unnecessary dependencies to packages. This is very common in deb and rpm based distributions.
Quite often the choice is either disable some feature or accept some additional dependency. As a packager, this is a problem. You don't want to draw in everything possible, but you do want to provide your users with a "sane" feature set…

edit: Giving your users an easy way to build/package themselves, with different build-time options, like FreeBSD ports do, isn't a perfect solution, but makes this problem more bearable. A port maintainer should try to make everything optional in the port that's optional with upstream source.
 
This is not always the case.
My little BSD program is a single source file.

But I was used to writing C64 assembler programs in the tape player buffer or on the 1000 bytes of video memory
 
Strigi/baloo/nepomuk/akonadi/zeitgeist/tracker ?
gvfsd ?
Ports are a collection of 3rd party software, so upstreams decide on what to depend. If dependencies are optional, ports should reflect that and I'm fine with it. If not, there's unfortunately nothing a port maintainer could do 🤷‍♂️

When porting x11-wm/fvwm3, I had a hard time deciding whether to enable Go (the language) by default. It enables a very nice new module, but that has all its Go dependencies linked statically and therefore is somewhat large. But as it's self-contained and doesn't imply runtime dependencies, I decided to include it in the default options…

But I was used to writing C64 assembler programs in the tape player buffer
It's indeed amazing what you can hide in these few bytes. For example, I once created a checksummer (for these type-in listings to verify you typed correctly) located there, with a collision-robust algorithm (using a 16bit LFSR) and display directly to the video hardware ;) – didn't even need all the bytes.
 
I mean, what's an example of "dependency creep in the ports tree" (assuming ports = FreeBSD ports).
For example, Xorg being something that virtually every DE depends on. Recently, FreeBSD ports stopped specifying that runtime dependency outright in its packages, but that does not change the API's on either side of the dependency. I still remember the silly graphics/tesseract dependency of x11/plasma5-plasma-desktop in packages. That dependency recursively pulled in a few others, and I could not stand that dependency creep. This is partly why I was so motivated to switch to ports and ditch packages.
 
[...] dependency of x11/plasma5-plasma-desktop in packages. That dependency recursively pulled in a few others, and I could not stand that dependency creep.
Sounds to me like you simply shouldn't use KDE/Plasma :p

When I see screenshots of FreeBSD users running KDE/Plasma I sometimes get somewhat jealous - they look gorgeous. But those dependencies... not for me. So I simply use something like i3 or XFCE.
 
Sounds to me like you simply shouldn't use KDE/Plasma :p

When I see screenshots of FreeBSD users running KDE/Plasma I sometimes get somewhat jealous - they look gorgeous. But those dependencies... not for me. So I simply use something like i3 or XFCE.
Well, I like KDE, so that was the motivation for me to switch to ports. And that was liberating - I was able to disable the silly dependencies I just described. :p Now it's on to setting up Poudriere just right so that KDE compiles and upgrades the way I want.
 
I mean, what's an example of "dependency creep in the ports tree" (assuming ports = FreeBSD ports).
How about Wayland being on by default? I have yet to find a single reason to need this.

Same, but to a lesser extent, Dbus is on by default too. It's not even optional in at least one port where it is not needed. I can see more of a use for Dbus, though I personally do not need it.
 
Back
Top