Why the continued separation from Linux?

I can only say, what a good job freebsd IS separate from linux! Merging with linux to create a single kernel to rule them all would be a terrible idea, I hope it never happens. Freebsd, don't ever change. Freedom is having more than one option! Vive la difference!
 
but why the continued separation from Linux [...] I feel like both projects could get a lot of good from a merging.
Technically it isn't possible to "merge" FreeBSD and Linux kernels, they're completely different in many ways. But even if this were possible: it would make FreeBSD users unhappy and it would make (distro X) Linux users unhappy.

In reality this would simply lead to popular forks of both FreeBSD and the Linux kernel in no time. Think MySQL/MariaDB, XFree86/Xorg, OpenOffice/LibreOffice, Jenkins/Hudson, Gitea/Gogs (edit) and one from before my time: Ingres/PostgreSQL ...
 
Technically it isn't possible to "merge" FreeBSD and Linux kernels, they're completely different in many ways. But even if this were possible: it would make FreeBSD users unhappy and it would make (distro X) Linux users unhappy.

In reality this would simply lead to popular forks of both FreeBSD and the Linux kernel in no time. Think MySQL/MariaDB, XFree86/Xorg, OpenOffice/LibreOffice, Jenkins/Hudson, Gitea/Gogs ...
It would probably lead to complexity that's eating too much performance for nothing, but I would follow the experiment if people tried it.
Maybe a strict modular approach based on the full I/O profile of a system component. For every distinct funtionailty, 1 implementation of both systems has to be chosen. The other system will require porting to different kernel architecture and executable format.
 
Once a buddy of mine, also engineer, and me were sitting in a bar, listening to some marketing guy from automotive whining about why aerospace is allowed to have steer-by-wire, but not they.

Actually, a lot of electric/electronic control is happening, and it started earlier in large vehicles (trucks) than in small passenger cars. For example, at home I have a 2005 International model 4300 truck (6 wheels, weight about 12 tons), and throttle control is completely electronic: the "gas" pedal just controls a little potentiometer. Except that this "little potentiometer" is hardened against all manner of danger (waterproof, contains electronics), and costs about $400 as a spare part, which makes perfect sense. But this allowed a clueless technician to add a remote throttle (this is a crane truck, so you often want to adjust the engine RPM while not in the driver's seat) by adding relays to switch the potentiometer to one installed on top of the crane. Complete and utter hack, but it worked.

The interesting thing is how incredibly well these systems are engineered. Being a software person, when repairing that crazy relay crap under the dashboard, I started by download the electrical documentation of the truck (thousands of pages), where they have detailed documentation of how to install a remote throttle the right way. Now the dashboard has a standard-conforming "remote throttle enable" switch, there are two locations on the crane where one can adjust the RPM, and if one does something like touch the clutch or brake pedal, or take the parking brake off, the remote throttle immediately disables itself. But then, the control module in the truck costs $13K to replace if I were to damage it, roughly as much as a small car.

It's part of an Airbus since the 80s(?), ...
Just like big commercial trucks has been ahead of consumer vehicles in using automation, aerospace has been far ahead of automotive. Just because (a) there is so much money in a big airplane, a few M$ for a better control system is easy to justify, and (b) at the size of an airplane, a small improvement in weight or efficiency is worth it, given how much fuel they consume, and how expensive the pilots are.

But then, Airbus (and more recently Boing) have had their share of better control and automation going wrong occasionally. This leads to the following old and nasty joke: If you listen to the cockpit voice recorder, the last words of the pilot before a fatal crash are always "oh shit". Except on an Airbus plane, where they are "what is it doing now".

A pilot friend of ours (rich Silicon Valley engineer, owns 5 or 6 airplanes, some with two jet engines) has the following cute little sayings about airplanes: (a) If it's not Boing, I'm not going. (b) Helicopters are just 10,000 parts temporarily flying in close formation. (c) I can't understand why anyone with a parachute would ever jump out of an airplane that is still working correctly.
 
  • Thanks
Reactions: mro
Technically it isn't possible to "merge" FreeBSD and Linux kernels, ...
Agree, it wouldn't be possible while maintaining the existing source code. Theoretically, I would be possible to write a new kernel that takes the best ideas from both. In practice, given that software engineering is done by humans, and humans have egos, ideas, and sociological interactions, I don't see this happening in the foreseeable future.

Remember in the 90s, there was an attempt to create a merged Unix, taking the best ideas from BSD and SysV and making them compatible? I forget the name of the company, but it was big (employed hundreds), the biggest investors were IBM and Apple, and they were located on De Anza Blvd. in Cupertino. I think the only thing to ever come out of that was the Motif GUI.

Speaking of that: In threads like these, we always focus on the kernel, and come up with (correct) answers like "it isn't possible to merge FreeBSD and Linux kernels". The reason for that laser-like focus on the kernel is that it is the most complex and most important single piece of software. But it is also not very big, nor does it take a large amount of human effort to write and maintain. If you look at a usable desktop computer (be it Windows, MacOS, or a Unix flavor with the desktop environment du jour), I bet at least 90% of the engineering effort goes into user space programs, utilities, the GUI, and the standard applications (mail, word processor, spreadsheet...) that come free with it. It could actually be 99%. The kernel gets much of the attention, but the rest is actually more important.
 
But then, Airbus (and more recently Boing) have had their share of better control and automation going wrong occasionally. This leads to the following old and nasty joke: If you listen to the cockpit voice recorder, the last words of the pilot before a fatal crash are always "oh shit". Except on an Airbus plane, where they are "what is it doing now".
 
That only happened because the pilots then in the chairs didn't react to the plane's behavior at all.

"One alarm after another lit up the cockpit monitors. One after another, the autopilot, the automatic engine control system, and the flight computers shut themselves off." From the Wikipedia page.
 
"One alarm after another lit up the cockpit monitors. One after another, the autopilot, the automatic engine control system, and the flight computers shut themselves off." From the Wikipedia page.

A perfectly fine reaction to a failure of the pitot tubes. The plane did everything correctly.
 
I have read too many a crash reports and post crash analysis to absolve any brand. If you dig down to the root cause, you start yelling at increasing volumes "Who greenlit this s#!7???" But in the end it often is some beancounter or clueless manager. If it was not human induced.
 
Remember in the 90s, there was an attempt to create a merged Unix, taking the best ideas from BSD and SysV and making them compatible? I forget the name of the company, but it was big (employed hundreds), the biggest investors were IBM and Apple, and they were located on De Anza Blvd. in Cupertino. I think the only thing to ever come out of that was the Motif GUI.
Metaphor? OSF
 
Metaphor? OSF
And the name of the company that implemented it all? I can remember what their building looked like, and what street corner it was, but I have forgotten the name.

By the way, who is this guy Alzheimer that everyone keeps talking about?
 
Actually, a lot of electric/electronic control is happening,
I do know that.
I did development on similar things.
But you may misunderstood me.
I wasn't saying 'It's impossible to do', I was (wanting to) saying:
'I wouldn't trust my life on something like this being part of a crucial safety-related module within a consumer products.'

There is a difference between construction site vehicles, or aerospace (also medical equipment) on the one hand, and consumer-garbage like automotive on the other.

The crucial point is the process of quality management coercibly needed for this.

And I mean real QM, not this paper tiger you have in all kinds of consumer industrys, side-tracked everytime it collides with project's schedule, cost money, or become uncomfortable in another way;
until accidents happen, only producing promises to get even more QM, but not the comprehension it's useless to have any if you don't adhere them.

Explain some automotives manager what all needs to be done to get approval for something like steer-by-wire in aerospace, and especially - that's the hardest part for them - to keep their greedy sticky fingers in their pockets afterwards, not doing even the slighest change (cost reduction) on it, and nothing of any new variants is going into market until the whole process of approval is done again.
They go very pale before you even finished.

That's exactly why we don't have steer-by-wire in cars.
The process of approval to guarantee its saftey is too expensive for them, since they cannot scamp some cheap tinker-crap, and regulations are not be soften in such crucial saftey points, thanks god.

I did development of safety related electronics.
And even there are regulations, and QM I spent a lot of my time to check if no genius realized some fancy cost-reduction idea behind my back.
In one case one got through, foxy slipped my eyes.
The next weeks we couldn't do any production much, but had several red cars with blue flashing lights all over europe, several millions € of damage, and only by incredible luck not a single person was injured - for a cost reduction of some few hundred bucks.

Nobody needs to tell me "regulations kills diversity."
 
Be patient, opening poster. You'll get an answer on page ten.
gr... - Cath, you do know this forum long enough to know that's not true.
Usable answers occur on the first two pages, which in this case also already happend; any thread is offtopic on page three at the latest, and being hijacked as a complete off-topic playground at page four; especially when its original topic is of no much use, as it was in this case. 😁
 
No. Relativity and time dilation is key here. It sums up to about 40 years SHIP TIME, but that is still billions of years earth time.
In younger years at university we did such science-fiction fantasizing, too.
Can be a funny evening, especially when beer and weed is involved.
But it all does not stands remotely when it comes to face real physical facts.

Engineers as computer scientists know more about physics than most common people - most of us had to make some credits in physics, when studied at universitys; at least we 'nerds' are more interested in physics.
But we didn't really studied physics.
So all this almost plausible sounding scifi-fantasys are consisting of three kinds of things:
- real physics, which makes the skeleton of the idea, and are used for prove
- not-yet-proven-it's-completely-impossible-but-may-be-theoretically-possible-sometimes-in-the-future pseudo physics
- left out parts, not looking at all pieces togehter for a complete picture

Example with your mentioned case - not wanting to piss you off (nobody wants to piss off an admin btw), but being pretty sure about you're are open to reasonable talk; and without calculating anything for real (don't want to);
but calculating real values within real equations always prove, it's impossible.
So:
To get ship's time to 40 years, while the rest faces billions, you need to get to app. 99% lightspeed (or something), which already is only hypterthetical possible.
For to get there you need:
An engine, that is not invented yet, and highly doubtful it ever will (Something that produces some kind of continous nuclear explosion by fission as propulsion... - please fire it up first, when you are at least around Jupiter {where your first ten years traveltime are gone for just to get there.})
Way more you'll need large - gigantic - amounts of fuel.
Many miss that fuel is the very most mass you need to accelerate.
The more fuel you need, the more fuel you need to get it moved - it's exponential.
Don't be astonished when you come to such numbers like "way more fuel as our whole solar system contains of mass..."

You may have also missed the fact you need three phases of flying, besides the travel at almost lightspeed, you need to accelerate to get there, and also you need to brake down, or you'll see you target for a extremely small moment only (if even at app. lightspeed) before raced by - to whatever comes beyond, missing it, which means the whole point of this adventure would be missed.

I didn't looked up the correct value, but astronauts are being exposured to something about 4G for several minutes; I am no physician but I highly doubt a human body could survive exposed to that kind of acceleration for very much longer. (It's a simple calculation: How long do need to accelerate with 4G until you reach lightspeed. Don't be astonished if it takes a while.)
Accelerating even more makes your space traveller reaches its target as a very flat mummy.
At this point often the total fantasy starts:"yeah, well, when we have gravitational compensation..."
One can only calculate with what is given for real.
Anything else is pure fantasy.
End of story.

Others may ask:
"Does this all will have some useful point, anyhow?!"
Yes.
Here it comes:

This all "travelling to the stars" is kind of human longing for there must be better place.
It's very old.
It's very human.
It's "just simply leave all our problems behind" - instead of solving them.
It's avoiding.

This is absolutely okay, as long as two things are understood:
1. It's fantasy. It will never happen.
Good stuff for books, movies, TV, computer-games (I love such games), nice rubbish-talk with friends,
but of no real practical use whatsoever.
2. It will not solve any problem.
In contrary, every engineers knows: unsolved problems will cause more.
And that's exactly why I made the effort to post this long story,
'cause I know there also some who contradict.

The point is, you cannot run from problems caused by issues you're carrying inside yourself.
You will take them with you anywhere you go.
(Some may think:"Hey, that's similar like 'FreeBSD must become more Linux.'" - You see, I'm still in topic, even if a bit farther *cough* 😁)
Unless you solve them.
But if you solved them, you may also stay, no need to go anywhere else anymore.

It's kind like a messy (someone having an disorder not to discriminate useful things from useless junk, so get rid of nothing, and drowning everything including himself in his own garbage) dreaming of, his problem would be solved if he just moves into a new, larger house, where everything is empty, and clean.
Of course this cannot work.
He will bring all the garbage into the new house - continue his madness.
Or he leaves it in his old home. For that he need to be capable of getting rid of the useless junk.
But if so he doesn't need to move into a new house. He simply needs to get rid of the useless junk.

Dreaming of setting of to another "paradise planet" is quite similar.
If we don't solve our problems here - greedy exploitation of resources, including humans - travel to another planet will not solve that. We would bring our unsolved issues with us, and destroy that planet the same as we did with ours. (Or you may dream of some hypterthetical personal paradise; for that you don't need no space travel, you only need to get some land, and found the perfect nation - wouldn't be the first one; also not the first who failed.)

So before it makes any sense to travel somewhere else, we must first solve our problems here.
And when we did, we also can stay here.
 
Back
Top