or busyboxHehe, just like systemd is working on doing
or busyboxHehe, just like systemd is working on doing
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.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
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.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.
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.Hehe, just like systemd is working on doing
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.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.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.
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.There is also bloat when Devs refuse to use the right technology or layer to do things.
… Fighting the dependency creep in the ports tree - that's a losing battle, …
Some distributions are well known of adding unnecessary dependencies to packages. This is very common in deb and rpm based distributions.Is there really a sense of losing?
What's an example of the creep?
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…Some distributions are well known of adding unnecessary dependencies to packages. This is very common in deb and rpm based distributions.
Well, personally I consider any port relying on python a shit showStrigi/baloo/nepomuk/akonadi/zeitgeist/tracker ?
Strigi/baloo/nepomuk/akonadi/zeitgeist/tracker ? …
I would say that memory became cheap and software became bad. Its a fact not an opinion.Software did not became bad. Memory just became cheap.
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 doStrigi/baloo/nepomuk/akonadi/zeitgeist/tracker ?
gvfsd ?
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.But I was used to writing C64 assembler programs in the tape player buffer
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.I mean, what's an example of "dependency creep in the ports tree" (assuming ports = FreeBSD ports).
Sounds to me like you simply shouldn't use KDE/Plasma[...] dependency of x11/plasma5-plasma-desktop in packages. That dependency recursively pulled in a few others, and I could not stand that dependency creep.
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. Now it's on to setting up Poudriere just right so that KDE compiles and upgrades the way I want.Sounds to me like you simply shouldn't use KDE/Plasma
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.
How about Wayland being on by default? I have yet to find a single reason to need this.I mean, what's an example of "dependency creep in the ports tree" (assuming ports = FreeBSD ports).
deskutils/recoll ???
Is it functional as a drop-in replacement? or is it some work to accomplish that?