FreeBSD derivatives

[kpedersen]

What's the point? Complexity exists. It exists for a reason. Big systems (such as FreeBSD) are intended to be used in a huge variety of use cases and workflows. There is not a single configuration that can be used for all these situations.

I would actually suggest that FreeBSD is so general and so complex that it is impossible to make a meaningful GUI. Actually, I suppose the universal GUI for it is configuration text files.

The Hercules emulator is a really interesting challenge for this. The config file i.e here:
http://www.hercules-390.org/hercconf.html

And the enjoyable attempt at a GUI here: http://ollydbg.de/Jason/index.htm

Yes, it is a really good attempt but it gets to the point that the config file is more "user-friendly".

Now consider that much of FreeBSD's configuration is done using scripts (sh/csh) rather than static configs (.ini, .xml, etc). Yes we could weaken it (aka systemd) so we could ease the job of creating GUIs. Or we can keep it powerful and just stand our ground and tell people who don't want to learn, to try Microsoft Windows or macOS instead. They were only ever going to be happy with these anyway.

Besides, I don't think these guys even *want* a GUI. For example they would not be satisfied with an i.e ncurses GUI. No, they want "modern" gimmicks and nothing more. And that is fine. Windows provides perfectly here.

 

[LucNix]

Lots of replies since my last time here. I am lazy enough that I don't want to click that +Quote button a couple of dozen times so let's just do this usenet style:

> If that's all a reasonable description of your wants and needs,

Not in the least.

> But perhaps I'm mis-characterizing your viewpoint.

Very much so.

> Nothing of this has anything to do with code.

Yes, it does. I'm asking about compatibility, especially the compability of newer OS releases with old binaries and vice-versa. (That was absolutely all I wanted, but it got lost in the hate storm.) And multiple replies (until the thread was clearly no longer taken seriously) refer to ports. Ports are source code. What am I supposed to do when something doesn't build? Fixing code is way beyond all my capabilities unless any of those applications is written in shell script which a seriously doubt is ever going to be the case. I'm sure that some maintainer is likely to want to have a look at the problem if I'm building a recent app version on a recent FreeBSD release, but just as sure I will be told to go kick rocks in any other case.

> and while configuring you will gain valuable insights that often apply
> to other Unix-like systems as well, including Linux.
> Insights that will help you solve problems

I most definitely don't want to solve problems. The mere suggestion that there will be problems is off-putting enough.

> I do get the impression that LucNix and teo were just trolling.

Trolling is very absent from my list of potential hobbies. Then again, I can't seem to appreciate any of your replies. I find you one of the most unpleasant people here.

> We spend far too much time, here, worrying about people bitching about their own shortcomings
> in implementing FreeBSD or why it doesn't work just like some other OS.

No "other OS" works the way I want. I thought that maybe FreeBSD could be it, but now I see it isn't. That's OK. I checked, it isn't, mission accomplished.

> Spent more time researching "help vampires" than on the original issue

That only tells me more about what kind of person you are. I suspected it already. Don't worry. I do not intend to keep coming here.

> They were trolling for decades to have a GUI. As soon as one came along,
> they got bored and disappeared

I suspect they "disappeared" because the problem was solved and they just got busy using the thing the way they wanted. But it's just a wild guess.

Wait. No. They very probably just wanted to royally piss people off. Yes. That is a lot more likely. See? I'm learning!

> Theo de Raadt was probably correct in his statement...

Whoa. There should be something similar to Godwin's Law about bringing up Theo de Raadt in any conversation.

> ... It means you can keep the software clean and correct

Too bad Terry Davies is no longer around to witness the exploding popularity of his TempleOS.

> Because they cannot get themselves to work with a CLI.

I have a screen session with four or five terminals open every day. Sorry to burst your ego-stroking delusion that I am this very specific kind of stupid.

> imo it's one of the reasons Ubuntu came up so fast.

That IS true. I mentioned Ubuntu myself in one of my posts. In a very positive sense.

> both are good examples of absolutely lobotomizing functionality

Wow. Just wow.

> Qemu's GUI doesn't expose any actual features, other than perhaps turning the VM off and on.

That really sounds beautiful. I never realized Qemu was so awesome.

> Many years ago, a colleague gave a presentation. It was about an extremely
> complicated system (also an extremely powerful and efficient and fast system),

Oh, look! Suddenly KISS is not so cool anymore? Huh!

> The single largest cause of usage problems was human misconfiguring it

Yes. It's imperative that the underlying design never be blamed for anything.

> We had extremely good documentation (man pages, install guides, even books),
> and dedicated training classes, both for users, and for the vendor's support staff.
> In spite of that, bad things happened

Noooo... Bad things happened in a complicated design??? Who could ever see that coming?

> an empty piece of PC board, and on the left a big unsorted pile of resistors,
> capacitors and transistors. This was the traditional way of managing the system.

What, no valves? That's impressive.

> Now, if you have an appliance (like a refrigerator), you just plug it
> into a wall outlet, and it starts working.

Now, that's the kind of KISS I can appreciate.

> These days, you need a manual bigger than a 17-inch gaming laptop
> just to be able to use the the damn refrigerator

But I bet it has WiFi!

> The Hercules emulator is a really interesting challenge for this

What, Hercules? Those are some of the easiest computers in the world! You just feed it some data in printed form into a slot and it will give you answers to anything. I saw that on Batman.

> And the enjoyable attempt at a GUI here: http://ollydbg.de/Jason/index.htm

That is a VERY nice GUI! Seriously. Stellar job. I am absolutely bookmarking that page.

> Windows provides perfectly here.

It absolutely did in 1995. Sadly, never again. Rather the opposite.

Relax, people. I know you hate me. I can take a hint. Thank you to those who helped me. That will be useful. Ta-ta.

 

[Professor_Fate]

Weak projects do everything they can to attract users, strong projects don't have to. One great thing about Theo De Raadt and the OpenBSD project in general is that they have principles and they won't back down from them, no matter what. I'm not sure I can say the same thing about any other project. I'm pretty sure when we started running FreeBSD servers in the '90s it wasn't marketing itself as a general purpose OS. You see what kind of posts it's lead to ever since. Rather than demand it be converted to Windows why don't people simply use Windows? I use Windows for all my desktops and I love it. I don't know if they're trying to impress anyone but I guarantee you their friends won't think they're 1337 because they can move a mouse in FreeBSD.

 

[yuripv79]

One great thing about Theo De Raadt and the OpenBSD project in general is that they have principles and they won't back down from them, no matter what.

I don't know if they're trying to impress anyone but I guarantee you their friends won't think they're 1337 because they can move a mouse in FreeBSD.

Though seeing OpenBSD having X in base, they might be impressed with moving mouse there?

 

[zirias@]

Fun fact for Brian546, OpenBSD has X11 in base, FreeBSD doesn't.

Not sure whether FreeBSD was always thought as a "general-purpose" OS, but it certainly is one. Using something on the desktop is orthogonal to these ideas of automated (complex) configuration, that would certainly go against some principles like POLA.

 

[aht0]

I would like to know beforehand which files sysutils/desktop-installer will modify ? Is this possible ?

Do a trial install, try it, then go through configs. It will add comments above config entries it has added to the files.

Or just look at that package in github and go through script line by line.

 

[aht0]

For servers FreeBSD has always been paramount and you can see the worldwide marketing position of FreeBSD system usage at less than 0.03 percent. In what sense do you mean the desktop computers?

Web user agents all too often think FreeBSD's systems are Linux. Seen it a lot.

Sometimes there's legit reason, user is using Linux binary through Linux ABI, sometimes not, other than I would guess they just classify anything with X11 in user agent string as a Linux.

 

[astyle]

LucNix : Do you even realize you changed your tune as this conversation wore on?

KISS is something that I despise. "Keep it simple" is a weasily way of saying "keep it crude so it's less work for us," and the "stupid" part is a weasily way of conveying that anyone who disagrees is automatically stupid, i.e. a dirty trick to discourage different opinions. Make no mistake, I'm saying that the wording in "KISS" is deliberately dishonest. Manipulative. Patrick Volkerding used that word when I used Slackware and I didn't like it, and I abandoned the otherwise awesome Slackware because I was absolutely sick of satisfying dependencies manually. Bloody hell. If you don't want to build it, don't. You don't owe us anything. But please choose your words more wisely.

^--- from Feb. 26

Oh, look! Suddenly KISS is not so cool anymore? Huh!

^--- from March 1

Yes, it does. I'm asking about compatibility, especially the compability of newer OS releases with old binaries and vice-versa. (That was absolutely all I wanted, but it got lost in the hate storm.) And multiple replies (until the thread was clearly no longer taken seriously) refer to ports. Ports are source code. What am I supposed to do when something doesn't build? Fixing code is way beyond all my capabilities unless any of those applications is written in shell script which a seriously doubt is ever going to be the case. I'm sure that some maintainer is likely to want to have a look at the problem if I'm building a recent app version on a recent FreeBSD release, but just as sure I will be told to go kick rocks in any other case.

AFAIK, Windows offers the best compatibility with old binaries. Vice versa - that's not gonna work ANYWHERE, not even on windows. This has been an issue for as long as computers were around. Nobody, not even the almighty Uncle Sam with all the money and brains, can make the most recent version of AutoCAD run on Windows 95.

Also - I'd suggest you think about the "hate storm", LucNix - what do you think provoked it in the first place? There are good and bad ways to ask for help.

 

[zirias@]

AFAIK, Windows offers the best compatibility with old binaries.

I'd argue FreeBSD is on an almost similar level (with backwards compat in the "DEFAULT" kernel starting at FreeBSD 4 (!) and ports/packages available for compatibility in userland), without the headaches of Windows going the extra step of even supporting apps (mis)using undocumented stuff plus an heritage of poor design from the old days....

IMHO, Linux can only dream of this level of (binary!) backwards compatibility.

Vice versa - that's not gonna work ANYWHERE, not even on windows.

Definitely, that just makes no sense.

 

[Whattteva]

LucNix : Do you even realize you changed your tune as this conversation wore on?


^--- from Feb. 26

^--- from March 1

I think the quote from March 1 isn't really him changing opinion though. He's just being sarcastic.
Probably pointing out that the person he replied to (whom supposedly loves KISS) no longer does so or is contradicting himself in the quoted statement.

 

[LucNix]

I think the quote from March 1 isn't really him changing opinion though. He's just being sarcastic.
Probably pointing out that the person he replied to (whom supposedly loves KISS) no longer does so or is contradicting himself in the quoted statement.

Thank you for the surprisingly intelligent and, most of all, not deliberately hostile comment. I wish the entire conversation had been like this.
"they might be impressed with moving mouse there"
That's just mean. Just mean. Contributes nothing to the debate. It's just tantamount to name calling.

I agree that my "vice-versa" wish is more difficult, but it didn't have to be impossible. Developers make it impossible. There is new Windows software that runs on Windows 95. It's rare, but it exists. Do you REALLY need to require .NET, for example? (If .NET exists for Win95 just pick another example and stick to my real point.)
Can't you use older libraries, kits or platforms? Why do developers insist on being so "hip" all the time?
I am committed to software that is not available on newer Debian so I run an old release, and a lot of new software now require GLIBC_2.28. I think I have GLIBC_2.24 or GLIBC_2.26, don't remember exactly.
Honest question: let's see if someone wants to reply without sarcasm and hostility:
Is it really not viable to compile the package based on GLIBC_2.24, GLIBC_2.22 or GLIBC_2.18 so more people are covered? Will newer systems, I mean, those with GLIBC_2.28 installed, NOT be able to handle applications built for older versions of GLIBC?
Honest question. I have zero knowledge of C coding and compilation.

From my point of view, the upshot is that so-called open source software has an expiration date, programmed obsolescence. It reeks of sabotage even. When Apple or MSFT do anything that even resembles programmed obsolescence, they get all kinds of criticism. Free software gets away with it every time. In fact, it is encouraged.
Yes, you can count on that software you like for many releases. Just update your repository and get the newer versions. But what if the project is abandoned and I don't know the first thing about compiling and have no interest in learning? I lose the software, that's what if. That's happened to me and I feel betrayed by an entire culture. I was told I would be able to use the things, but look, I am not anymore. And the answer is always the same: "It's free software, just get the source and update it yourself." That's very mean. It's like telling a regular citizen to buy or build his own bus or train when a regular line is deactivated. We can't. We can't, and developers often mock us. It's a modern version of "Let them eat cakes!"
I am not blaming FreeBSD, I am blaming an entire culture. For a moment, I thought that maybe some corner of the free software realm had taken this into consideration and taken measures to mitigate the problem. So it doesn't exist. Yes, I should have known better. The entire culture works that way, across the entire spectrum. But I do have a point. I think machines are supposed to serve us. "Robot" is a Russian word that means "slave." Software is supposed to serve users. If there is a culture that keeps killing existing software because "the old has to go" as if software was an athlete or runway model, then the culture is going against the purpose of software and machines. This culture should change its mindset and create approaches that let old software survive.

I know a lot of people will hate my ideas because they violate a cardinal rule of free software:

1. Existing capabilities are sacred, new capabilities are profane.

1a. You can and should always brag about whatever capabilities your free OS of choice has today, especially to get the point across that it is a capable, finished and suitable tool, or even that it is just as good or even better than any other that may be compared with it.

1b. You must however never say, suggest or imply that any NEW capability can or should be added to your free OS of choice, which could be construed as the blasphemous notion that the OS is not impeccably perfect or that it could be made better in any way. Worship the past and present, revile the future.

So what I want is likely to never happen. But if it does happen one day, whoever has it will GLOAT about it from the top of the highest mountain. Or roof, whichever is more convenient. Until it happens, dirty heretics like me who dare propose the improvement will be burnt on a stake with extreme prejudice like a witch.

 

[bsduck]

"Robot" is a Russian word

Actually, Czech.

 

[Deleted member 56028]

1. Existing capabilities are sacred, new capabilities are profane.

It depends. You can add new things without breaking existing capabilities that works as expected and doesn't have unfixable bugs in the long run. If something doesn't change and works as expected, it doesn't need a version bump to make anyone happy, only the OCD kids have the hurry for version bumps.
Running forward breaking everything just because "the old is too old" and adding new features just for the sake of being new isn't wise, actually is very stupid. We can use the consolekit as an example, but this is another long kind of conversation.

 

[mer]

Running forward breaking everything just because "the old is too old" and adding new features just for the sake of being new isn't wise, actually is very stupid.

I wish I could say more but this says it all in my opinion.

 

[ralphbsz]

From my point of view, the upshot is that so-called open source software has an expiration date, programmed obsolescence. ...
When Apple or MSFT do anything that even resembles programmed obsolescence, they get all kinds of criticism. Free software gets away with it every time. In fact, it is encouraged.
Yes, you can count on that software you like for many releases. Just update your repository and get the newer versions. But what if the project is abandoned and I don't know the first thing about compiling and have no interest in learning?

You are correct, and it is for logical reasons. Let me use two extreme cases as examples. One: You have a long-term relationship with a vendor of systems and software; your company has used them for the last 30 years as the main provider of computing. They sell you a software package for $100K, with an additional annual maintenance/service/license contract of $10K/year. Every 3 month you get a minor upgrade, ever year a major upgrade, you get an 800 number to call for service and support. Once a year the salesman comes to visit, to see whether you have additional needs, and to explain their roadmap and plans for the future. After 4 years, they tell you that this software is obsolete. Two: In her spare time a college student in Elbonia writes a useful program, and posts it on Github. Another unpaid volunteer creates a FreeBSD port/package for it. For the next 4 years, those two people do occasional maintenance on the program, for example updating it to changes in the underlying infrastructure (OS, library, ...). After 4 years, they simply lose interest in it; perhaps one of them now has a family and doesn't have time for their coding hobby, and the other one has a paying job that is incompatible with working on free software.

What do you do in case one? To begin with, you will not be blindsided by the end-of-life, as the vendor will have given you ample warning. Matter-of-fact, they will probably work with you to get you a working solution. I've been in this situation both as the customer and the vendor, and solutions may include giving you a deep discount on a successor product, or giving you free consulting services to transition you to another solution. But even more important, a good vendor will have your compatibility and roadmap issues in mind. For example, IBM introduced the model 1401 (the first mass-produced computer) in 1959. When it introduced the 360 series of computers, it deliberately made it so existing (binary) 1401 code could be executed on the 360 (and later 370) machines. I think the capability to run 1401 code ended in the mid 2000s, about 40-50 years after the 1401 was first sold. Similarly, compiled 360 code can still be run today on IBM mainframes (now called the z series), about 60 years later. Why does IBM go to all that effort? Because they know that their customers need to have a long-term data processing solution, and a long-term relationship with a supplier that solves their computing problems. The world is not about selling one software license and then running away quickly, it's about getting a customer for life.

The large vendors also know that the anger of their customers would be terrible, and they would not have long-term customers if they stopped supporting their products, and more importantly supporting their customer's workflows. They also instill this customer-centered ethos in their employees: Any employee who screws over a customer is pretty much guaranteed to lose their job.

Now contrast that with free and open source software. When that college student from the example above has a baby and doesn't want to spend her time on updating her program for new OS versions, what are you going to do? Fire her? She never got a paycheck from you in the first place. Refuse to pay the license fee or service contract? It was free. Force the two programmers to go back to doing maintenance? That's slavery. But the good news is that you don't need to do this anyway. To begin with, binary compatibility with older versions is commonly maintained. You can for example run the old binary in a kubernetes pod, packaging it with libraries that match it in age. Alternatively, source code compatibility is usually much better than binary compatibility, and you can usually re-compile/install from the same source against modern libraries and OSes. And if that compile/install fails, it can usually be adjusted with a small amount of effort. That's one of the reasons that the source code was given away for free (without payment), to allow others to use it in new fashions, for example on newer platforms. You happen to refuse to do this work (because "no coding"), that's your choice.

That's happened to me and I feel betrayed by an entire culture. I was told I would be able to use the things, but look, I am not anymore.

I'm sure you were NOT told that you would be able to use these things, in particular there was no guarantee made that you would be able to use them for a long time. You were given something for free. Try reading the contract that you and "FreeBSD" signed when they delivered the software to you: does it say anywhere that you'll get long-term support? Matter-of-fact, is there even such a contract? Having unrealistic expectations of it doesn't help. And complaining about your unrealistic expectations not being met is unethical.

And the answer is always the same: "It's free software, just get the source and update it yourself." That's very mean. It's like telling a regular citizen to buy or build his own bus or train when a regular line is deactivated.

You borrowed someone else's bicycle, and drove it for a while. Now the tire is out of air, which is normal wear and tear on bicycles. You are complaining that the owner of the bicycle is not coming to fix the tire and inflate it. Did it occur to you that a decent human being would be repairing the bicycle, and at some point return it to the owner as good as when they borrowed it? Or perhaps offer to reimburse the owner for the wear and tear?

In the case of trains and buses, you pay for the service, and that gives you an expectation of the service functioning. What we're discussing here is free software; you should not have any expectation of getting something for nothing.

Where you are right: There is an expectation in the FreeBSD community that users are technically skilled enough to install, configure and maintain their systems. Part of that maintenance (if you use ports) is doing updates to the source code and compiling things. Let me give you a vehicle-related example: Many small private (GA) airports in the US have a car parked at the hangar, so when someone lands there, they can take short car trips in the area. The protocol is that you refuel the car and leave it with a full tank, and you only use it for short trips. Open source works somewhat similar: The protocol is that you use it, and contribute a little bit to keeping it working.

I am not blaming FreeBSD, I am blaming an entire culture. For a moment, I thought that maybe some corner of the free software realm had taken this into consideration and taken measures to mitigate the problem.

Matter-of-fact, FreeBSD does a better job than most (all?) other free OSes to support long-term usage. Ingredients into that include publishing release roadmaps long ahead of time, identifying LTS releases, and putting a lot of effort into frictionless upgrades. This works pretty well for the base OS. With ports/packages, the FreeBSD project has much less control, as they don't have the manpower needed to do long-term maintenance on the myriad of packages. When you go to GUI/DE use of FreeBSD, you are at the mercy of the volunteer maintainers of those ports/packages.

I think machines are supposed to serve us. "Robot" is a Russian word that means "slave."

In the early 1980s, I managed to get a German translation of Capek's play about Robots from the university library. The word is actually a play on "worker", perhaps "serf" or "servant", not on "slave". What Capek called robots is what we today would call androids. It is an interesting example of early science fiction.

Software is supposed to serve users.

If you want to be served, then please pay for the services.

If there is a culture that keeps killing existing software because "the old has to go" ...

On the contrary, FreeBSD tries to do the opposite, as much as possible within the ecosystem of free / open source software. And the reason for EoLing software is not that "the old has to go", but usually that support is becoming too tedious, and better alternatives exist, such as recompiling from source.

EDIT: Fixed the quote formatting at the bottom.

 

[astyle]

"Robot" is a Russian word that means "slave.

Not true. yes, the word is present in the Russian language, but no, it does NOT mean "slave". Any native speaker would attest to that.

 

[LucNix]

Not true. yes, the word is present in the Russian language, but no, it does NOT mean "slave". Any native speaker would attest to that.

Someone has pointed that out already. You just couldn't miss another opportunity to say that I am wrong.

 

[LucNix]

You are correct, and it is for logical reasons. Let me use two extreme cases as examples. One: You have a long-term relationship with a vendor of systems and software; your company has used them for the last 30 years as the main provider of computing. They sell you a software package for $100K, with an additional annual maintenance/service/license contract of $10K/year. Every 3 month you get a minor upgrade, ever year a major upgrade, you get an 800 number to call for service and support. Once a year the salesman comes to visit, to see whether you have additional needs, and to explain their roadmap and plans for the future. After 4 years, they tell you that this software is obsolete. Two: In her spare time a college student in Elbonia writes a useful program, and posts it on Github. Another unpaid volunteer creates a FreeBSD port/package for it. For the next 4 years, those two people do occasional maintenance on the program, for example updating it to changes in the underlying infrastructure (OS, library, ...). After 4 years, they simply lose interest in it; perhaps one of them now has a family and doesn't have time for their coding hobby, and the other one has a paying job that is incompatible with working on free software.

What do you do in case one? To begin with, you will not be blindsided by the end-of-life, as the vendor will have given you ample warning. Matter-of-fact, they will probably work with you to get you a working solution. I've been in this situation both as the customer and the vendor, and solutions may include giving you a deep discount on a successor product, or giving you free consulting services to transition you to another solution. But even more important, a good vendor will have your compatibility and roadmap issues in mind. For example, IBM introduced the model 1401 (the first mass-produced computer) in 1959. When it introduced the 360 series of computers, it deliberately made it so existing (binary) 1401 code could be executed on the 360 (and later 370) machines. I think the capability to run 1401 code ended in the mid 2000s, about 40-50 years after the 1401 was first sold. Similarly, compiled 360 code can still be run today on IBM mainframes (now called the z series), about 60 years later. Why does IBM go to all that effort? Because they know that their customers need to have a long-term data processing solution, and a long-term relationship with a supplier that solves their computing problems. The world is not about selling one software license and then running away quickly, it's about getting a customer for life.

The large vendors also know that the anger of their customers would be terrible, and they would not have long-term customers if they stopped supporting their products, and more importantly supporting their customer's workflows. They also instill this customer-centered ethos in their employees: Any employee who screws over a customer is pretty much guaranteed to lose their job.

Now contrast that with free and open source software. When that college student from the example above has a baby and doesn't want to spend her time on updating her program for new OS versions, what are you going to do? Fire her? She never got a paycheck from you in the first place. Refuse to pay the license fee or service contract? It was free. Force the two programmers to go back to doing maintenance? That's slavery. But the good news is that you don't need to do this anyway. To begin with, binary compatibility with older versions is commonly maintained. You can for example run the old binary in a kubernetes pod, packaging it with libraries that match it in age. Alternatively, source code compatibility is usually much better than binary compatibility, and you can usually re-compile/install from the same source against modern libraries and OSes. And if that compile/install fails, it can usually be adjusted with a small amount of effort. That's one of the reasons that the source code was given away for free (without payment), to allow others to use it in new fashions, for example on newer platforms. You happen to refuse to do this work (because "no coding"), that's your choice.


I'm sure you were NOT told that you would be able to use these things, in particular there was no guarantee made that you would be able to use them for a long time. You were given something for free. Try reading the contract that you and "FreeBSD" signed when they delivered the software to you: does it say anywhere that you'll get long-term support? Matter-of-fact, is there even such a contract? Having unrealistic expectations of it doesn't help. And complaining about your unrealistic expectations not being met is unethical.


You borrowed someone else's bicycle, and drove it for a while. Now the tire is out of air, which is normal wear and tear on bicycles. You are complaining that the owner of the bicycle is not coming to fix the tire and inflate it. Did it occur to you that a decent human being would be repairing the bicycle, and at some point return it to the owner as good as when they borrowed it? Or perhaps offer to reimburse the owner for the wear and tear?

In the case of trains and buses, you pay for the service, and that gives you an expectation of the service functioning. What we're discussing here is free software; you should not have any expectation of getting something for nothing.

Where you are right: There is an expectation in the FreeBSD community that users are technically skilled enough to install, configure and maintain their systems. Part of that maintenance (if you use ports) is doing updates to the source code and compiling things. Let me give you a vehicle-related example: Many small private (GA) airports in the US have a car parked at the hangar, so when someone lands there, they can take short car trips in the area. The protocol is that you refuel the car and leave it with a full tank, and you only use it for short trips. Open source works somewhat similar: The protocol is that you use it, and contribute a little bit to keeping it working.



Matter-of-fact, FreeBSD does a better job than most (all?) other free OSes to support long-term usage. Ingredients into that include publishing release roadmaps long ahead of time, identifying LTS releases, and putting a lot of effort into frictionless upgrades. This works pretty well for the base OS. With ports/packages, the FreeBSD project has much less control, as they don't have the manpower needed to do long-term maintenance on the myriad of packages. When you go to GUI/DE use of FreeBSD, you are at the mercy of the volunteer maintainers of those ports/packages.

You sound like a lawyer in a courtroom making up out of thin air the notion that I am violating some contract with FreeBSD.

I am not demanding anything, I just came here to ask questions and do some terrain reco. After a bunch of hostile replies, I criticized a pervasive practice and made it clear that it is pervasive in the IT culture and industry.

Your entire post amounts to a pretty convoluted way of saying that capitalism is king. Pay up or GTFO.

> With ports/packages, the FreeBSD project has much less control,
> as they don't have the manpower needed to do long-term maintenance
> on the myriad of packages.

That detail was never lost on me. In my utopic(?) proposal, nobody would HAVE to upgrade anything because the system would support existing binaries indefinitely. Maintainers wouldn't have to be upgrading packages or ports all the time because old versions still work. You may not have the latest and greatest, but you have something that does the job. Imagine the massive amounts of time that would be saved. Of course updates may be desirable especially from the security angle, but most package updates would not be strictly necessary. Many package upgrades could be skipped with mininal to no impact, and whoever cannot afford to upgrade the system for whatever reason would not be left behind. It's a problem in the culture. We see similar trouble in Web development. Web standards were supposed to be universal and always compatible, but look at the mess it is today. We are forced to upgrade our browsers. "But then I'm going to lose my precious extensions! They make my experience dramatically better!" Nobody cares. Shut up and upgrade, to hell with your extensions. The user experience has become the least relevant component in the whole equation. The user bows and kneels to the machine industry. It's a perversion.

At least I like your account of IBM's approach to the problem. I was not aware of that, that is exactly what I want, and if IBM has been doing that for decades then my idea is not really stupid. It's neither new nor stupid. IBM has been doing just that. Of course, capitalism. The "free" costs no money, but it costs a lot of time. The prevailing culture just chooses to embrace an approach where everybody has to sweep the desert's sand for eternity.

P.S.: sometimes I wonder if that mentality is cultivated on purpose to make sure developers and maintainers are necessary, i.e. to create and preserve jobs.

 

[kpedersen]

Is it really not viable to compile the package based on GLIBC_2.24, GLIBC_2.22 or GLIBC_2.18 so more people are covered? Will newer systems, I mean, those with GLIBC_2.28 installed, NOT be able to handle applications built for older versions of GLIBC?
Honest question. I have zero knowledge of C coding and compilation

No. Its not possible to link a program against three different libc implementations and have it dynamically choose one. We are ultimately dealing with raw byte offsets and sizes and if these become unaligned, the result is failure. (And C has ABI compatibility. Other languages are even worse). You could create a package that has three copies of a binary (one for each C library, kind of how Android NDK works) but then you need more infrastructure. Asking that from free projects is not useful and only prolongs the inevitable rather than solving it.

A better solution is a chroot(8) or jail(8). FreeBSD is remarkably good here; including the i.e compat8x ports. There are blogs online detailing how they are still running binaries as early as 4.x

But honestly, the best solution is keeping software simple (i.e KISS) because then it drags in less libraries that can possibly break as they are updated.

Software lifespan and digital preservation is difficult. *Especially* in the area of graphics and "high level" software. I spent many years of my life (and a PhD) trying to solve this and I still wasn't entirely satisfied with my solution for even a tiny subset of the larger problem.

 

[astyle]

ralphbsz makes some fantastic points... To cut the crap, you come here to complain about how FreeBSD does things not to your liking.

I am not demanding anything, I just came here to ask questions and do some terrain reco. After a bunch of hostile replies, I criticized a pervasive practice and made it clear that it is pervasive in the IT culture and industry.

Come on, FreeBSD is something you download for free. And it's really on you to make the the best of it. If you come in with criticism of in-house practices, you get chased right out that house. It's like walking into a bar and criticizing it for being an establishment that serves alcohol and contributing to drunk driving problems. Come on, not even cops do that. But if you walk into a bar and start saying shit about alcohol it serves - patrons are not gonna take that sitting down. There's a reason the bar has patrons.

 

[ralphbsz]

A better solution is a chroot(8) or jail(8).

You are correct. But sadly, our industry has settled on an adequate solution, which is Kubernetes/Docker/Flatpack/..., which is mostly: Find the executable you want to run, package it in a box with all the libraries (and often a copy of the OS itself) that happen to be compatible, run it in some virtualization layer. It's heavyweight, inefficient, and a management nightmare. But it is intellectually simple, and the resources it wastes (CPU cycles, storage space) are those that are cheap today, while human brains are in short supply and expensive.

But honestly, the best solution is keeping software simple (i.e KISS) because then it drags in less libraries that can possibly break as they are updated.

That solution is good, but doesn't scale far. Some software systems by their nature have to be complex. For example: An operating system that can serve a huge variety of different workloads (batch jobs, interactive use, high-CPU and -GPU graphical tasks, but also real-time interrupts) can not be simple, and will have many parts. So keep it as simple as possible, try to modularize things, but no simpler.

 

[kpedersen]

You are correct. But sadly, our industry has settled on an adequate solution, which is Kubernetes/Docker/Flatpack/..., which is mostly: Find the executable you want to run, package it in a box with all the libraries (and often a copy of the OS itself) that happen to be compatible, run it in some virtualization layer. It's heavyweight, inefficient, and a management nightmare. But it is intellectually simple, and the resources it wastes (CPU cycles, storage space) are those that are cheap today, while human brains are in short supply and expensive.

Indeed. That said, Docker is just the glorified chroot approach. Albeit the Linux specific lxc flavour.

That solution is good, but doesn't scale far. Some software systems by their nature have to be complex. For example: An operating system that can serve a huge variety of different workloads (batch jobs, interactive use, high-CPU and -GPU graphical tasks, but also real-time interrupts) can not be simple, and will have many parts. So keep it as simple as possible, try to modularize things, but no simpler.

True to an extent. There is functional complexity required to get the job done but there is also adding superfluous "fluff" in addition to existing complexity. I feel FOSS struggles with this balance a little.

 

[ralphbsz]

Your entire post amounts to a pretty convoluted way of saying that capitalism is king. Pay up or GTFO.

On the machines that I own and control, I use a variety of operating systems. Most of them (Linux and FreeBSD) are free. I do not pay up or GTFO, I instead pick the solution most appropriate to the problem. I even complain about things loudly. For example, my current FreeBSD complaint is that either I'm dumb (that's a real-world possibility), or else FreeBSD's port of apcupsd (the thing that controls my uninterruptible power supply) is broken: During a power outage, it correctly shuts the computer down, but then it fails to turn off the UPS, which runs out of battery, and then refuses to restart when power comes back. And two evenings of reading documentation and messing with config files haven't fixed it yet. Similarly, a few years ago I complained that OpenBSD's file systems are not up to my needs, and I moved to use FreeBSD and ZFS. And then I discovered that FreeBSD's 802.11 stack isn't usable as an access point in my environment. I complained very loudly about that, including to Kirk (the father of all BSDs) and to Sam (the main owner of its 802.11 stack at the time), and followed their advice to buy a commercial AP.

And sometimes I also buy things for money. For example, my main daily driver computer is a Mac, running MacOS. I use it because after weighing the tradeoffs, I decided that I want neither Windows (which other family members use, again for good and logical reasons), nor Linux/*BSD (which many colleagues at work use), nor a Chromebook. For my sensibilities and usage patterns, the Mac is the best solution.

But the really important thing is: I complain about technical problems, I try to work through them, and I try to contribute to the projects (there is for example a significant number of lines of code I wrote in Linux kernel modules, and a bit of my money in the bank account of the FreeBSD foundation). I accept the reality of how open source / free software works, and don't complain about that.

sometimes I wonder if that mentality is cultivated on purpose to make sure developers and maintainers are necessary, i.e. to create and preserve jobs.

Most FreeBSD contributors (both developers and port/package maintainers) are unpaid volunteers. The same is not true for Linux, where the overwhelming majority of software is developed by paid professionals.

 

[ralphbsz]

I feel FOSS struggles with this balance a little.

Sadly, that makes sense: Much of FOSS is developed in organizations that don't have a strong (and old) culture of engineering management. As an example, RedHat started as (a) a distribution packaging company, which had relatively few developers, plus (b) a place where many Linux developers got a paycheck, for doing what they were doing anyway. Many of these developers were one-man-shows or small groups, whose decision making is engineer-driven. As an extreme example: Do you think any manager at RedHat will tell Lennart how to exactly implement systemd? Absolutely not. What they did tell them: Please fix the init system, the current one is making our paying customers really mad, so Lennart did "the best he could" (whether he got it right or not is a question that stirs up lots of emotions).

The common sense of "let's not do this neat and shiny thing" is sadly uncommon among engineers. I count myself as part of the problem, not part of the solution.

 

[kpedersen]

The common sense of "let's not do this neat and shiny thing" is sadly uncommon among engineers. I count myself as part of the problem, not part of the solution.

Heh, indeed. Plus there is the element of if you like a bit of software and enjoy working on it, we just keep adding more and more.

However, and perhaps I will not manage to explain this well but if there is a "touch" of a commercial company involved in some software, it tends to remain a little lighter. For example:

• Red Hat's packages are quite spartan in terms of optional features. Where i.e Debian versions of i.e GDB might pull in perl, python and lua hooks, the RHEL versions have all that compiled out. So Red Hat can minimize the amount of support required I imagine. Unless you *need* those features, this is quite nice. Less package dependencies as a result.
  
  
• The UNIX userland hasn't got some of the cruft that GNUs alternatives have. Possibly because the companies involved back then knew that if they add more and more features (and non-standard), they will need to provide more unnecessary support to their customers.
  
  
• StarOffice / IBM Symphony compared to OpenOffice and LibreOffice were cut down. They didn't have so many rendering engines and themes and all that weird stuff.
  
  
• Codeweavers Crossover Wine. Possibly some of it is statically compiled instead. But their implementation tends to require less dependencies than the one typically pulled from a package repo.

Not always the case obviously. Nero Burning Rom and Microsoft Windows are good examples of uncontrolled sprawl in commercial software.