hpr-knowledge-base/hpr_transcripts/hpr3439.txt

Episode: 3439
Title: HPR3439: Linux Inlaws S01E40: The One with the BSDs
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3439/hpr3439.mp3
Transcribed: 2025-10-24 23:31:37

---

This is Hacker Public Radio Episode 34394 Thursday, the 7th of October 2021.
Today's show is entitled, Linux in laws S0140.
The one with the BSDs, it is the 40th show of monochromic and is about 97 minutes long
and carries an explicit flag.
The summary is the other one operating system to rule them all.
This episode of HPR is brought to you by an honesthost.com.
Get 15% discount on all shared hosting with the offer code HPR15.
That's HPR15.
Better web hosting that's honest and fair at an honesthost.com.
This is Linux in laws, a podcast on topics around free and open source software, any associated
contraband, communism, the revolution in general and whatever fans is your tickle.
Please note that this and other episodes may contain strong language, offensive humor
and other certainly not politically correct language you have been warned.
Our parents insisted on this disclaimer.
Happy mom?
Thus, the content is not suitable for consumption in the workplace, especially when played
back in an open plan office or similar environments.
Many miners under the age of 35 or any pets including fluffy little killer bunnies, you
trust the guide dog unless on speed and qt rex's or other associated dinosaurs.
This is Linux in laws, season 1 episode 40.
The one with the BSDs, good evening Martin, how are things?
Hey Chris, things are fine, it might be on the warm side for the UK.
I hear you have some water in your direction.
Indeed, very much so, I think yet we have a limit too much of water running around and apparently
you still have to turn down the heating in the UK for sure.
Excellent, but this is not a show about weather for some strange reason.
This is a show about open source software and tonight we have a special treat because we
do have a selected panel of BSD people on the show.
So without further ado, why don't we do a short intro round then why don't you go first?
Hi, my name is Dan Langel, I got involved with open source software in about I think it is
1995. Someone gave me some free BSD CDs and an old computer and that got me a firewall because
I just got an ADSL and things have just gone downhill from there. Mark, you're next.
Hey, sorry about the accent, I'm French in case this isn't apparent.
I'm Marcus P, so I've been working with open BSD since 1998.
I've been doubling in open source software for a bit longer and at that point I got
an amiga and I wanted to install something on it and the only operating system with
the instance in selection and instruction was open BSD and with the rest is historic, as
I said. Patrick. I had been using Linux for about nine years. I started using open BSD four years
ago. I think the main reason I was ever interested in exploring other operating systems is
just finding an interface that I was happy with. I see. It's about sums me up.
A true defect on the show. We love this. Nia, you're next.
Hi, my name is Nia Alari. I've been a net BSD developer for the past three years. I've
been using net BSD for the past six years and I work on some quite strange and diverse areas of
system, probably mostly known for my work on the audio stack and graphics related things.
And last but not least, Martin, my co-host, how did you come to BSD? Mr. Visher?
Sorry, I was on mute.
Yes, BSD is obviously something for my university days, which is many, many, many years ago, but
yeah, not forgotten. Let's put it that way. What about yourself?
Perfect, perfect, perfect. I actually came across BSD when I was still almost
child for wonder of a better expression. We had a BSD system running in the
polytext where I did my first degree, but you're talking about at least 30 years back.
I've been using free BSD as a matter of fact for about 10 years in the shape shock and
awe of an operating system called macOS, but we're going to go, but we're going to go into
these details in a minute before we kind of discuss this kind of thing on a technical level.
What would the current, well, maybe we should check some more light basically before we,
as I said before, we go into the details, we should check some light on the history of BSD.
In terms of initially there was system five, that was the prime evil, I'm tempted to say,
unique system back in the 60s, late 60s, I'm a rat, and then the broken software distribution came along,
and then we arrived at open BSD, free BSD, nut BSD, dragonfly BSD, and I'm sure that I forgot
of view of BSD flavors. So, volunteers first, who can talk about the history of BSD?
Or wants to talk about the history of BSD? Well, I can do some parts, there is some stuff that I
know about, but I haven't actually lived, which is the origin of BSD, which is basically,
as far as I know, Thompson went on sabbatical from Bell Labs at the time, and he came to Berkeley,
and he worked with people there, and they started this thing, which was BSD.
And he became free 86 BSD a few years later, as the first try of being an open source software,
but he didn't quite work, because there were still parts that were actually owned by Bell Labs,
and so, lawsuit problems ensued, and this gave a little gap where a guy in Finland called
the new StarVets managed to sneak in and create Linux, more or less. And when the lawsuit was
resolved and the parts which were missing were actually written, I think that was when free BSD
started, so I live people from BSD to talk about that. At the same point, some people decided to
port it to other platforms, this was the origin of a net BSD. Among net BSD developers, this was
this guy called Fyodorette, which had something of a temper, and it ended up in a foight between
Theo and the other people, the other funding favors of net BSD, let's say. And Theo got
out here from the project, and he decided to fund his own projects, which is how open BSD started.
Interesting. All these different BSD flavors, and of course, there's also a dragonfly BSD,
which we may go into in a minute. All these different BSD flavors, free BSD, Open BSD, and net BSD
have different kind of focus areas, if memory, if my failing memory or failing memory,
rather, is anything to go by. Maybe somebody from the panel, basically, or due to the fact that we
have actually different panel members of the different flavors on the recording session, why don't we
kind of shed some more light on the focus areas of these different flavors of the BSD operating system?
I actually use some free BSD at work quite a lot, despite working on net BSD in my free time.
From my perspective, free BSD is marketed much more towards high performance service usage,
even though the other BSD is a good choice for that as well.
At work, we actually use it for embedded devices, and net BSD is also a great choice for that,
and it has lots of tooling for working on embedded devices, and routers, and things like that.
I think net BSD has kind of an interesting history of being focused on supporting lots of
platforms, but also just as a platform for research and interesting ideas, and it's achieved
a quite good balance of performance security, as well as having some very unique and interesting
design decisions like Rump, for example. What is Rump? Rump is a kind of model for how
kernels can be almost dissected, I suppose. It's possible to run parts of the net BSD kernel in
user space, or on bare metal for bare metal applications. You can use net BSD drivers, or
I think the GNU heard people were looking into using net BSD drivers in their micro kernel,
just by using a net BSD Rump kernel as a service, and it's quite a unique design, and I don't
think there's anything else quite like it that exists as far as I'm aware. So it's not a true micro
kernel, it's more like a hybrid approach. I suppose it's a monolithic kernel that's also a library
operating system. Wow. Okay. Given the fact that library operating systems, sorry,
I reckon not everybody in the in the in the year and and share a relationship,
it's an operating system expert. Maybe we should explain what library operating systems are.
Somebody volunteering from the audience, or should I basically take a shot at it?
Okay. I'd be interested in seeing what you have to say. Okay, in that case, yeah, let me
let me make the few mistakes, and then you can correct me in philanthropic apps.
Library operating systems. Essentially, you take a small kernel like structure as in code base,
and package the operating system on top of it, meaning that normally an operating system is
divided into kernel user space, a library operating system basically has the operating system
services co-located to the application. Library operating systems typically do not differentiate
between the kernel and the user space, leaving the door wide open to all sorts of interesting
and funny security challenges as well. Let's put it this way. But library operating systems do
have a few advantages. For example, you do not have a context switch between user and kernel space.
The packaging can be quite compact and dense because you are essentially building a full
application stack, including the operating system just for one purpose. So, library operating
systems have found quite a significant following, I'm tempted to say, in the area of embedded systems,
where you typically have only one app running on your stack. Now, where did I go wrong?
I think that's a very good explanation. I would also add that with something like Rump,
there's the ability to use parts of the kernel as a user space application. So, for example,
you can use the file system drivers to mount a file system without touching the kernel at all,
really. And also, there's quite a large test suite for NetBSD that takes heavy advantage of this
by running device drivers and so on as Rump servers in user space to test them.
Now, in that case, I've written that this is quite significant in the embedded space because
that is typically the area where library operating systems and unique kernels are used in
if I'm a self-correct.
Yeah, I suppose so, but I think the biggest use of Rump currently is a testing tool,
just to ensure the continued stability and reliability of the operating system, I suppose.
Okay. Now, speaking of, of embedded systems that has typically been in a domain for something
called Linux, the Raspberry Pi's of the world and other single board computers typically run
some sort of Linux operating system. Is there any opinion on the panel with regards to the
BSD penetration of the sector? And I'm almost tempted to say that there is of course another
embedded space called MOBA where, funny enough, freeBSD has gained a significant following,
although I reckon not many people know it because if they're using something called iOS,
essentially, they're using a small micro kernel, which with a stripped down freeBSD
with a personality on top of it called QNX or something, not QNX, sorry, I'm lacking the
acronym here, but it's essentially something based on something called Apple called Darwin,
if I'm completely mistaken.
I think parts of QNX are using the netBSD networking stack. I mean, if you look in their
copyright statements, there's a lot of netBSD foundation copyrights. And
yeah, I think iOS is probably mostly freeBSD, but there's bits from everywhere in there probably,
especially if you go digging deep into where every single tool comes from.
Same goes for I reckon generally speaking, Tim goes for Darwin generally speaking,
or the foundation of something called OSX. And just to say this goes back to something called
Nexus OS, Martin, we do not have cloud units on the show, do we?
Not today, no, we don't know. Martin, you want to shed some light on Nexus and the history
of maybe I should do this? No, no, you go for it. Yeah, excuse me, don't upload, yeah,
you're the best second one. No, I mean, there is, of course, something called Nexus,
that a certain guy called Steve Jobs came about, or kind of invented whatever you want to call it,
or came up with rather, it's probably the next expression. When Steve as he left Apple or had to
leave Apple for a wonderful better expression in the mid 80s, he set out and found the company called
Next. The idea was to provide education systems pretty much based on an open source stack to the
masses. Hence this next queue was born and it was running something called Nexus. So what Steve
and the engineers did was essentially take a micro kernel in the shape of Mark 2.5 or 3, I can't
even remember, put a free BSD personality on top of it and put on top of that stack a windowing
system and some other components. So after a few years, Apple decided to buy Next, Next computers
or whatever the name of the company was at the time. So Steve Jobs was reinstantiated as a CEO
and pretty much so OSX, what we know now as Mac OS was born. And over the last 30 years,
that hasn't really changed. I mean, you have different CPU-E architectures. I mean, the first
of was power PC, then Apple moved to Intel and now they are back to risk architect called
Apple Silicon, which essentially is an ARM core, heavily customized of course, but still running
OSX as it used to be on the lower layers back then. So Apple actually has gone full circle here
and if you take a look at as we just discussed at iOS, essentially is a stripped-on version of OSX.
So going back to the embedded space from original question, many people actually use BSD
without knowing it, given the fact that indeed the rest is pretty much Linux dominated.
What is the panel's opinion about BSD in the embedded space and where do you see this going?
I think there is something that needs to be said about licencing issues there.
Because basically, unless I'm mistaken, I let the other people in the panel voiced their own
opinion. One reason we stick with the BSD is not only because of technical issues,
but because we do believe in free software where you can take your piece of software and use it
anywhere, including commercial products. And that's a good point on some aspects and that's a
bad point on some of OSX. The big difference between BSDS, as in permissive licensing and
something a couple of licensing, of course, as probably the majority of all listeners do know,
Linux's license under something called GPN public license, whereas in the BSD operating system
family is license under either two or three clause BSD, which happens to be a permissive license.
So without going into details, because there was a show recently on set licensing issues,
done by us. The main difference is basically that the BSD license
prescribes anything, and hence the term permissive license, because as Mark rightly pointed out,
you can do pretty much whatever you want with the code, whereas in the GNU,
public license alongside any similar copy-left license extra prescribes, a couple of things,
namely, for example, that you have to publish any modifications that you made to the code base.
So you are obliged to publish, to make the source code available of your code base once you've
touched GPN license code base. That is, of course, not the case with the more permissive licenses,
like the BSDs, because these license simply can just say you have to give the original
author credit, you have to incorporate a copy of the license, and that's pretty much it,
apart from that you're pretty much free to do whatever you want with the code.
Any other opinions on the embedded space before we move on?
I don't really like talking about licensing too much, because it's quite a controversial subject,
and people get very upset with you, but I think in my ideal world, everything would be public domain,
but we don't live in my ideal world. I'd also just add that if you look up the history of GPL
enforcement, if you, in particular, a name I would look for is Robert Landley, who worked on
busybox, his opinion was after suing lots of different companies over the GPL, he didn't get any
useful code out of them, it was mostly just terrible stuff. I would add something on the more
technical side of the embedded space, say in the ARM world, in Linux on ARM there's lots of
like custom vendor kernels and things like that that a lot of people are very upset over and
think are very buggy and bad, and I'd just say in the BSD world that kind of doesn't exist,
everything is mainline, everything is in the mainline kernel.
What exactly does that mean?
I suppose that everything is developed and integrated into one tree, and the contribution
process is generally not very difficult, like I've heard some absolute horror stories where it's
taken years for patches to be accepted into the Linux kernel. I'd like to think that we're a bit
better at that.
Existing it called the loadable kernel modules is what Linux supports. I know at least one,
I know OpenBSD doesn't support those, but I think that is what kind of makes things like you know
approaching NVIDIA drivers possible, was you know OpenBSD, possibly the same with the other BSDs,
but I know OpenBSD isn't really kind of this, there's no technical course facility or it's
not engineered to kind of really allow that kind of deep system integration, you know, driver
for body drivers like that.
I think modules are used much more often on FreeBSD. On NetBSD they're quite well supported,
but mostly everything is in the main kernel binary, and you only use modules for things like
Linux compatibility would be a good example. You have to load the Linux compatibility module
if you want to use that.
Now that's very interesting subject, maybe you can elaborate on that because
yes, BSD does support a little compatibility layer.
Yeah, it's a thing that exists in FreeBSD and that BSD, although I think the implementations
are quite different, and it's just a layer that can translate Linux schools to BSD syscalls.
It's fairly straightforward really, I think.
Including fancy stuff like control groups and namespaces?
I think for my purposes when I'm using Linux compatibility, I'm using it to play games.
I don't know too much about the more advanced side of things there.
The reason why I'm asking because these are the two control mechanisms where they allow
something called containers to run on Linux, because these are the kernel mechanisms you need.
BSD systems, correct me if I'm wrong, have something to call jails?
Yeah, jails are a FreeBSD thing. The other BSD is mostly just have virtual machines currently
is my understanding. I hear alumos supports Linux containers.
I can talk about FreeBSD jails for days.
I can give us the abridged version, please.
Basically, pardon me, FreeBSD jails have been around for about at least 10 years,
others can correct me. They're built into FreeBSD.
They're designed for you to be, their original purpose was to allow someone to run different
versions of the same web server all on the same host instead of having to have 10 hosts,
she could put them all on one host, for example, and what I do with it in one example is I run regression
testing. So I have, I think, seven jails each one is running a different version of Postgres or
MySQL. They could be running different versions of FreeBSD if I wanted to, but basically I run all
that regression testing in a jail. The easy way to think of a jail is it's an elaborate CH route.
So it's not actually true virtualization, but basically when you're in the jail,
you can't tell you're in a jail, but you can if you look in certain spots. Basically,
I treat a jail as a complete FreeBSD instance, and I put in that jail things that I want to run
in there and have it completely isolated from everything else. Another interesting thing about
jails when you're in admin is if you're the cis admin of the host, you can see everything in
every jail. If you do PS, for example, you see all the processes running in every jail, or you can
pick one jail and see only the processes in that jail, which means theoretically that if you
have a break in into a jail, you can see everything they're doing in the jail, but they can't see you
at all. They have no concept of anything outside the jail whatsoever. So think of a jail as being
a light virtualization, but it's not virtualization. Yes, because the beauty with containers is actually,
you can limit their resource usage. So for example, you can tell a container running on Linux,
basically only use so many CPU slices. You can you can confine their main memory. You can
basically control that usage and all the rest of it. So these are the main difference between
the change route environment and true container. You can limit CPU in a jail. You can. Okay. Yes,
you can say use this one CPU and that's it. You know, isn't any other CPU. I think there are other
controls you can add to the jail, but I don't do it because I've never needed to. Someone else
might be able to elaborate on that. Anybody using jails? I don't know. But you're off by about 10
years, basically, I just looked it up and the initial paper from Pauline Camp was dirty back from 2000.
It's been around for 20 years now. Wow. Okay.
Interesting. To give you an idea, I've got I think eight hosts and probably 80 jails spread
amongst those hosts. I tend to put my database servers in a jail. I tend to put
individual websites into a jail if they're self-contained. I have one server that's running two
web servers, each one in a different jail, because one is running engine X and the other one's
running Apache. Right. Jails are persistent as in everything that you write to the file system
in a jail stays where it is, whereas containers basically use something called, for example,
a union file system, which is a definition of formal. So if you stop a container unless you
explicitly mounted, for example, an external mount point to a container in terms of basically,
you make a portion of your file system visible inside the container. Every other change inside
the container is lost to you. So if you stop the container, your flow persistence enabled the
container and its data has gone, unlike Jails, I understand. You could design a jail like that by
having it by using ZFS. And I think many many many people are running Jails on ZFS. It's much easier.
You just give each jail their own ZFS file system. And what you could do is when you stop the jail,
you do a rollback on the system it was using your back to where you started.
You can do that with a clone. And then just roll it back to where you were when you started.
You haven't lost, you haven't lost anything. Sorry, you've lost everything that was in the jail,
but you still had the original file system that you started from. Which NASA leads us to very
important topics, file systems on BSD. Any takers? I just wanted to add about the running multiple
databases thing at the same time. Well, multiple database versions I suppose. And I think that was
originally the reason Jails were developed for free BSD. But it's kind of strange from a net BSD
perspective because the package manager kind of allows doing that without any operating system
level isolation. It's all done in the package manager. Sorry, I just wanted to add about that.
I think you're talking about Postgres there. And we had that problem on free BSD for a while,
but I think it's gotten much better. It's actually installing them into different
directories. And I haven't tried it lately. But yeah, I do run Postgres in different Jails.
I think that's the point to be made here. We are talking about actually different operating systems,
but you're focusing on the kernel that all the BSD are usually a full operating system with some
differences. Like, for instance, net BSD has got their own package manager with some kind of
virtualization. If I remember correctly, some views that still return that you're using.
And we have some stuff that's been developed in user and in OpenBSD like OpenSSH, for instance.
And in most cases, if you only look at the kernel and the specificities of the kernel,
you're going to miss quite a lot about what's going on. It's a big difference compared to
the way Linux works. Well, usually you've got your kernel and you've got your distributions.
The major BSD, the net BSD, free BSD, or Open, I don't know much about Dragonfly.
Sorry, I won't talk about it all that much. But usually, you have to take the whole system.
It's not just the kernel you have all sorts of stuff that use the basic mechanisms. Like,
for instance, on FreeBSD, you've got their new package manager and Pudrier, which uses Jails a lot.
Things like that, OpenBSD, and things like that on netBSD. You can't just talk about the
kernel most of the time. All you are missing has the phone in my opinion.
Indeed, and I do apologize for focusing way too much on my favorite obsession named
for this girl's. Just a quick question, because when the full disclosure I'm still using
every now and then I'm still using FreeBSD and I'm using Pods as the main package manager.
Apparently, there's more package management in BSD than Pods.
And Latin me, please. I use Pudrier to build my own packages and I run Pudrier in a jail.
Basically, if you want packages that use non-default settings, basically, if you're doing
Make Configure, Show Configure, or tweaking any of the settings, each package has its own set
of settings, and they have a set of default values. So if you want to change that,
you can't use the project-provided packages. So you either build your own packages
using Pudrier or use ports. For those unfamiliar, a port is a set of files that allows you to
create a package. It's like the set of meta instructions that say you get the source from here,
you build it using this mechanism, you put these files there, etc. So a port allows you
to create a package, but once you've got that package, something made from ports and something
made from Pudrier is indistinguishable. It's the same thing. It's just two different ways of
getting to the same goal. So both Pudrier and ports use the ports tray. If I can add a bit of
history, that's something that we started in OpenBSD, more or less. Like around 2005 or something
like that, you had ports on all 3BSD, and most of the time, if you wanted to have an application with
a current stuff, you used to have to check out the port 3, compile what you wanted, and that was
it. You had everything working when you were lucky. At that point, Tio decided that it would be
a good idea to actually have binary packages, a bit like Reddit, RPM at that point. So we started
working on making sure that when you compile stuff, you always got the same package. There was some
problem compared to that, and also making sure that you could specify options in a reasonable way.
I know that Dan has been working a lot on the infrastructure to make sure that you get all options,
and all the tables is ready to ports correct. Then I think I was a bit early, but I started working
on ways to build packages, industrially, on OpenBSD, and soon after that, that is Darosan,
did something on 3BSD, we've put a year on package. So we moved more or less to having a port system,
where you could compile everything by yourself, and you had to compile everything by yourself,
to a binary package system, where it would be easy to build something, and you would only compile
stuff if you really wanted to tinker with it, but you could use a binary package like Conway
that for instance. I mean, this is the main difference, because if you take a look at your
typical Linux distribution, apart from maybe Debian or Arch, I'm talking about the Red Hat and
the Ubuntu software world. These are backed by companies, and for example, OpenSooza goes without
saying, let have a corresponding build infrastructure in the background that basically do packaging,
and that goes for CentroSN Fedora as well. I'm just kind of summarizing them under the Red Hat
and Rada. Let's put it this way. How do the BSDs address these infrastructure issues?
All of the BSDs have a packaging system that descends from free BSD ports, but they've all diverged
in very different ways and have very different feature sets. And in that BSD, for example,
well, it's the only BSD that doesn't actually use the term ports in that BSD. It's package source,
and it produces, well, packages. And I think the infrastructure is very different across
BSDs because the different packaging systems have different focuses. For example, package source
works on lots of different operating systems, and free BSD ports has also retained lots of
customization features, but I think OpenBSD is very focused on producing binaries. So they
don't put as much focus on to customizing the build or providing lots of tools for
building from source because that's not true at all. We provide all the tools that you need
to build from source. We do have some customizations options, but usually we do some kind of,
let's say distribution work like we have some options that you can use very easily,
which are called flavors most of the time. And if you want to do something else, you can still
tinker and you can still build binary packages, but you might be on your own if you run into issues.
If you look at how free BSD and OpenBSD do stuff, we are actually very similar
for one very simple reason, which is that the people who mostly, we did most of the work on OpenBSD
and free BSD ports are basically me and Batista Usain. We talked a lot together. So we don't have
the same tools that we wrote almost everything, but we share most of the concepts you will find that
our packaging tools are rather similar and most of the changes that we did in OpenBSD
happen in free BSD as well. Like having a staging area to build packages that's a
one common point, trying to have really able dependencies and stuff like that. That's also
something that we share. I know what BSD does. You didn't diverge all that much. The thing that
maybe is the biggest difference is that it's probably easier for you to build stuff that's
widely different from official binary packages. We've got any pointers in the resulting package
that something strange was going on, maybe. But there are lots of common points. We all do the
more or less the same thing. We all use a huge make file to build a port, for instance.
And we still have more or less the same steps. You always will do make fetch,
make patch, make configure, make build and make and style more or less. So if you want to think
here with ports on all free BSD, you always always have the same options at this point. After that,
what you do with your ports, there might be some differences. I know we have different bulk systems.
But going back to Mark's point that brings up a very interesting subject. If I take a look at
the supported architectures, I see a significant difference between the likes of free BSD,
open BSD and that BSD. So for example, free BSD seems to concentrate mostly on
interface architectures, whereas open BSD supports many more CPU architectures. And that brings,
of course, up a very interesting subject, namely if you get distributed binary packages,
who takes care of the corresponding build to chain in terms of either you do cross-compiling,
or somebody has to provide an infrastructure where you can package as and build packages on.
Free BSD has a package build farm. Every set of packages gets built every two days or so,
and it takes about that long to build the entire set of ports. There's roughly 45,000 ports,
give or take a few thousand. And those are all built. Now, it varies upon what sort of
architecture you get. I'm just looking at a patchy here. And they build for free BSD 11 down to
free BSD 14 on different packages such as Armed 6, Armed 7, Power PC 64, I386, MIPS,
I may be repeating, but you can see all these packages listed. And they're all the same version.
I see 2.446 and I see 2.448 on the newer ones. So it may take, once a new version is committed to
the ports tree, it may take two to four days before that package is available from the free BSD
infrastructure. But if you want to build it yourself, you just refresh your copy of the ports tree,
CD user ports, dub dub dub Apache 2.4 make package and you can build your own package.
In my case, I have Poudre set up to run Nightlay. I have a list of packages and a list of the
options to use for those packages. And every night, I get about 28 different trees built.
Wow. Basically, free BSD 11, 4, 12.2, free BSD 13 and a whole lot of different
settings because I have different needs for different things. And that all runs over night
every night. Interesting. Because I can record. Sorry, Chris, I need to go shortly.
It's very fascinating so far. I have some of them. I have one question before I need to go.
I'd like to have the panel's opinion on the single's technical reason. As in, obviously,
clearly, not everybody is using free BSD out there. We have mentioned ports, we mentioned deals,
but for each of the panel members would be the single technical reason to choose free BSD.
Free BSD. Well, sorry, any BSD.
I can't just squeeze that out. Now it's the case for the time to make the case for your
version of BSD indeed. But all these people go ahead. Yes, thank you Martin. Sorry, all right.
I've answered this question many times in the past and I've summarized it for myself
in response to questions I've received. And I can't say that it's a single technical thing,
but it's a combination of things all of which are technical, which from a cis admins point of view,
makes my life much, much easier now that these technologies have come together.
Number one, ZFS. I've been using it for about 10 years. Okay.
Hopefully integrated into free BSD for that time. And it is the single best thing for me when
it comes to using directories. I've told people that when you go to do a make-deer, consider
ZFS create. Just it's a different way of thinking of things. Should this be a separate fall system?
But the next thing is a PKG, the packaging system. And on top of that, it's Poudreur that allows me
to build my own packages with my own settings, including my own private ports, all seamlessly,
and it doesn't make any difference to the operating system that they're using my packages,
as opposed to free BSD packages. And I keep thinking there is a third thing in there
from memory, and I just can't remember what it was, but I'll leave it at those two.
I can go next. I'm going to start with saying that we have more or less some of the same
technical reasons, like our packaging system is about working well. Functionally, it's the same
as free BSD, and we have built tools that work just as well. It's called dpb instead of Poudreur,
but we have built about every three days, official builds, and I can rebuild my whole system
in about two days and make a start work. I don't have that many machines,
so it takes about that time. One very nice feature of PKBSD, which doesn't exist anywhere,
that's for an hour, it's called pledge. This is probably something you haven't heard about.
It is a beautiful idea for making processes, commit to not doing things they should not do.
Like for instance, at the start of a program, you are going to say, I pledge to only do
input output on open files, and I go with them in memory and nothing else.
And after that, your process is going to get killed whenever it tries to open a new file,
or do a network connection. It's very similar to stuff like GR security or
Capsicum and free BSD. The main difference is that you don't have to specify all the system calls
that you want to call or not call. You are just going to say, okay, I want to use this
subsystem, or that subsystem and everything, and it's beautifully interfaced with C library.
And also, it goes for granularity, sometimes smaller than system calls.
Like for instance, anybody who's played with kernel knows that
higher control is going to be a huge kernel form when you look at drivers and shit.
And for instance, with pledge, you can say, okay, I don't want to do anything with device drivers,
but I have to handle TTYs. I need to be able to set TTYs to blocking, non-blocking,
echo, whatever that stuff, and nothing else. And you can do that.
But more or less, we have about everything in the best system using pledge.
And all important ports have been converted to use it as well. So if you have any kind of bug,
any kind of, let's say, ruptured intrusion in your software and tries to do something
that it shouldn't do, pledge will force it to abort in many, many, many cases.
So as far as security goes, I think it's very beautiful features.
And I hope that at some point, other people are going to port it to something else, maybe
free BSD, maybe Linux, that would be a good idea. Even though I don't really see it happening,
because Linux is a jungle, it's not really something where you can actually make something happen
at the time, for the time being, I think. Interesting perspective. Who wants to go next?
So I'm going for open BSD. From what I've been able to tell over the last few years,
there's a fair number of small features in open BSD that have been clearly conceived,
probably at least in part out of a desired desire to kind of minimise the amount of
tech support requests that get posted to the MISK, the MISK modem list, and probably other lists
on that site. So things like fee install are being a very step-by-step thing. I think open BSD
is the only one that ships with window managers by default out of the BSDs. I think...
No way. Possibly not, I might be wrong. Sorry, who is that?
On BSD ships with a window manager too. By default. Yeah, CTWM.
CTWM. Okay, okay. So we're doing our own window managers by default.
We have a CWM and the old F, FVWM if I remember correctly.
There's any web. So, I mean, yeah. So, but apart from that, the command line,
utility is very simple. I mean, anyone who's already familiar with the typical kind of Unix-like
commands, like the general fastest commands, will probably find open BSD very easy
in general. So interesting. If I can add a snide remark, when you look at macOS usually,
you are looking at the kernel and saying, blah blah, it's free BSD more or less. And when you look
at user-run, then you try to start from the command line, you figure out that you've got something
that is hopelessly updated. Like most commands haven't been updated for about 20 years,
human pages are crap completely out of that and everything. The user interface, the graphical
part is nice, but if you want to do any kind of actual administration, like not Windows and
administration, but real stuff, in my opinion, macOS is crap. It's a very proprietary approach to
something called a Unix-like operating system, yes, I agree. When you said, when you look at this,
you're using that, when you look at that, you're using this. It reminded me of the Netflix story.
When you're selecting a movie on Netflix, when you're browsing them and looking at the little
bits and pieces that describe the movie, you're on AWS. Once you press play and you're streaming a
movie, that's all free BSD. Yes, that's a matter of fact. I think the last remaining person without
pointing him out is Nia. Nia, do you want to share anything?
Yeah, I think the most standout points for NetBSD would be from my side would be
it has excellent support for ARM as like a first class architecture. So if you have any small
ARM devices, I would recommend trying NetBSD out on them because it's just cute and fun to use
and it's nice to try different things. We've already discussed the big technical things like
ZFS, but I'd also bring up things like say the different firewalls the BSDs have. I've tried
several of them. I think NPF is quite nice. There are lots of different firewall options if you
use the BSDs. I've already brought up all of the things like I think NetBSD has a very good balance
of performance and security features, but also I'd just say it's a good option if you want to
really experience like a classic Unix system. Okay, one of these different flavors and varieties
have their pros and cons. Needless to say Linux actually over the years has brought quite a few
concepts from the BSDs of the world. The Berkeley packet filter comes to mind. Needless to say,
but that's another story from another episode. What I'm interested to hear is actually how
does the community as in the panel present on this episode perceive the more and more forthcoming
for one of our better expression integration with components. Let me shall out one example.
If you take a look at the GNOME project, it's more and more than we're moving towards system D,
which is one of these standards in it architectures running on Linux these days.
So it might be very difficult in the future to part GNOME to something called BSD.
Any takes any opinions on this? Are you saying that in order to have known we're going to have
to have system D? Pretty much if I read the writings on the walk correctly. Speaking of writing,
if anyone wants to become familiar with system D, they should read a book by Michael W. Lucas
called Savage by system D. And that should give you a good introduction to system D and what
you can be in for if you start using it. I would be more worried about things like GTK 3
becoming dependent on system D because GTK is kind of in loads of, I mean it's in both the main
Bra web browsers and loads of other kind of graphical apps. I wouldn't say, good
GNOME is kind of nice to have on accessibility point of view, but it's not quite the end of the world.
I don't see why software has to become reliant upon system D. I know system D is much bigger than
rc.d for example, but I don't see why software should become reliant upon rc.d. rc.d is a way
to start your damons and stop your damons and interact with them and get them the configuration
settings they need. But you can also run those damons without rc.d. No, but that's not
a problem at all actually. I've been talking with people who are porting GNOME and OpenBusD
and it's indeed an issue. It has nothing to do with starting services. It has everything to do
with stuff like looking at user configuration and shit like that. It's been traditionally very
difficult on unique systems to do that kind of stuff portably from a graphical interface
and it seems that apparently system D kind of makes it easier in some cases and you are starting
to have some GNOME-based libraries which are depending on this stuff to fully work.
And this is indeed an issue. There was some project to try to do some kind of system D
stubble library to be able to still run all those GNOME support libraries if you are not running
system D, but I don't know why this is going on. So good on current.
Money we're having to patch in lots of stuff that they've removed like console kit support
which is basically portable log-in-d really. It sounds like poor design decisions.
Yeah, but we're talking GNOME and GTK. Have you looked at the code recently? If you're trying
to find anything in the jlib code or game for instance, it's a complete nightmare. It's a
direction versus a direction. Well, for starters, doing object oriented work in C, it's
completely crazy. And the system D is a big blob of shit as well. So yeah, what do you expect?
But more or less, it works for them at least. And you have this in my opinion, a huge
camp of Linux people who just want to be Windows. Interesting. So you're moving to the same
kind of interface. And instead of having a huge jungle of 5 deaths to be able to run on
anything, which is to be the case 20 years ago, if you looked at the exam code 20 years ago, for
instance. Now you have this huge blob system D which offers you some interface which say,
you want to look at user, you want to look at configuration, you want to look at the
10 time and everything. Come on, I've got the API for that. So we are going probably to need to do
something about it at some point. On the other side, I think that when it becomes necessary,
there's going to be some people who are going to say, okay, it's not possible to no longer have
new non-version running on BSD. So yeah, we have to have some kind of stop library that works for us.
And possibly we'll get something that's the best of both worlds, which means that we will still
have somewhat secure systems. Because system day is joke. And I'm saying this seriously,
what do you expect? You are going to learn the whole set of things that have access to the full
system as a set of shared library under root, which makes absolutely no sense whatsoever to
anybody who is doing any kind of secure coding. And on the other side, you want to have a
simple interface that allows you to do modern stuff that Windows has been doing for 10 years
with all the security rules that entails. So maybe we'll get some shims that actually provide us
with the same interface, but with some amount of security. I don't know.
Leonard Petring, if you're listening, don't go near the BSD people. Just might to send
on the whole stuff, but jokes aside. Okay, just in case he doesn't know, he's very
definitely hated by a lot of us. It's really, yeah, it's really a shit show. I still don't
understand how the Linux people manage to get that cool going and all of the shit, come on.
The stuff about logging, starting with numbers and you can become more than that's not his issue,
come on. It makes absolutely no sense whatsoever. He's not a proper developer.
I reckon this whole thing goes back to the fact that, okay, if we just go there for those people
who don't know it, Leonard Petring is still working for Red Hat. So I think if I recall correctly,
if Fedora was the first Linux that had system beyond board, there was quite a few.
It turned to the time when we were talking about six, seven years back.
Canonica had something called Upstart, the likes of Arch at the time and all the rest of the kind
of other distributions were still relying on the system V in it. But over time, people perceived
the advantages of system D, which has progressively becoming, I'm tempted to say, this was
Army knife of Linux for doing all sorts of things as a main advantage with regards to packaging
and kind of using functionality in terms of having a single API as you just pointed out a couple
of minutes ago to avail of system services and to inquire about system states as the way forward.
Hence, more and more distributions adopted it until such time when a few distributions
said this is not our game enough of it and forked. And death one in the Debian world probably
would be the best example for this. But of course, the problem is that more and more sub-systems
I'm tempted to say for one of an expression here, like Nome and some other code basis
rely on system D to function properly. And I'm just curious. With, I mean, in the Linux world,
Nome has quite a steady hold with regards to desktop space. For example, Ubuntu's standard
desktop is based on no, is based on no shell. I take it, it's quite different than the BSD world.
Maybe somebody can, okay, handshets are more light on kind of the window management aspects of
of BSD and if there's any staggered that the BSD people have, maybe it's that's worth discussing.
You brought up Red Hat and I think that's a good, good thing to touch on because Red Hat
are funding a lot of these very large open source projects now which allow to like coordinate
changes and push things that well Red Hat employees want into the open source space.
I think they used to probably used to be more counterbalance there. Like I think
some micro systems used to have a lot of involvement but of course they're dead now and
they would have of course if things have to run on Solaris, they have to be portable.
In net BSD's case and in open BSD's case we both ship Xorg as part of the system and
there's the question of what we're going to do in the future if say I think a big worry for me
personally is if GTK goes ahead and says okay we've decided that X11 is deprecated and we're going
to remove support for X11 in GTK and none of your apps work anymore. That's going to be a huge
transition that we're going to have extreme difficulty with because well the protocol is
a designed around Linux and it has quite a lot of assumptions about Linux's input stack,
baked it, bright into it. By the way does well and run on BSD?
Or on ABSD?
Yes but with lots of like shims and compatibility layers or lots of patching.
Interesting, okay. Because this is becoming more and more of the standard window manager on Linux systems.
So it's implemented by so-called wayling compositors.
Sorry, yes it's protocol rather. Sorry, not a window system. Sorry, yes I do apologize.
I probably should be more specific. It's a window protocol, similar to X11 but without the,
for example, network transparency that X11 brings to the table.
Why I don't think that most people have network transparency disabled on X1s with this in
nearly case. And hence the perceived need by the community for something called wayland because
as you rightly pointed out most people run X11 applications on their desktop so there's no need
for the performance impact or tiny performance impact. Let's put it this way that X11 has by using
a full blown TCP IP stack and in terms of network transparency. So and that's exactly where
kind of wayland comes into play. It's not network transparent. You can only run it locally
and it has quite a few distance around which is in comparison to X11. But more and more
districts are adopting this as their main windowing protocol is put this way plus the compositing
managers surrounding wayland. The wayland of the world and other stuff. Sorry, go ahead.
I'm not quite sure what problems it actually solves. There are sometimes talking about security but
basically most security issues like with graphics card and the DRI graphics driver in a case.
You've got this big blob of an interesting code that runs on your GPU and that has access to
the full memory of your machine in many cases. It bypasses the enemy and everything.
And yeah, sure, well, on this you post that each window can talk to another window unless
this is so but frankly there are security issues. They lie much deeper on that so I'm not quite sure.
And the other opinions on this topic before we move on.
I've worked with wayland quite closely in the process of porting it to netBSD and I kind of
have to agree. It's too loosely defined. There are lots of protocol incompatibility issues still
and it's just not as powerful. It's like kind of just a downgrade in terms of its feature set.
And X-11 is the standard for Unix and I very much hope it doesn't go away.
Interesting perspective. Maybe the Lillian's people should take notes.
One feature in Gennome that I'm aware of that only exists on Weyland at the moment. I think it was
like fractional scaling where not only having the kind of the standard, I don't know if it's
even the standard, but whenever you want to call it 960PI on x.org server you only have that
or two times, three times, four times. But of course many laptops are probably better suited
for like 1.5 times or something like that. And for whatever reason Gennome is able to
scale to that sort of figure on Weyland. But I don't know why it's different like on a technical side
that makes that possible, but I found that the only thing that I'm aware of that's different.
For me, you say it sounds more like the people who are writing the drivers for X-11 haven't
done the work and what's it. I see absolutely no reason why you shouldn't be able to composite
X-11 windows to whatever ratio you want on the graphics card. You have enough memory for it.
It's fast enough. Your GPU is going to do all of the work. They already do that for video all the time
this day. So just implement it and it should work. I mean,
I'll take it. I'll be accepted. Okay, that has been more than interesting. Finally,
question from us because we're rapidly approaching the three hour mark. No, I'm joking,
but I reckon where do you see this whole BSD thing going in terms of open BSD, free BSD,
and FBSD. And we haven't even touched on the, for example, on the security advantage,
so something of something called open BSD, but what we're going to leave it at that.
So find a question to the road ahead, especially in the light of the mounting adoption that's
put it this way over the last five to 10 years of Linux on an enterprise basis, especially if you
take a look at something called other people's computers, also commonly known as the cloud.
BSD is dying, netcraft confirms it. Sweet and short, okay. Maybe the additional opinions or
maybe elaborations of that remark. I think people have been saying that BSD is dying for
the past 30 years. It's not going anywhere anytime soon. We'll be around long into the future
and we'll keep attracting new users and lots of interest into the future because
people like different things. People don't like monocultures.
Like I'd be a mainframe smaller. Now I'm joking, but you know what I mean. Sorry, go ahead.
Mark. Yeah, but there's more or less that specific point, which is that I don't think that
lots of people are going to use open BSD directly in the future. We're more or less an
experimental OS. Everything works for me and I'm fine with it, but I know that we have some
limitations. Like our symmetric multiprocessing is not quite up to pariette and sometimes we support
hardware better than other systems at some point. We were better on Wi-Fi and Linux. Yes,
are you sure? Ten years ago, that was more or less the case. We still do interesting developments
and build pieces of software that you end up using, whatever you are. Like the most famous
instance, of course, is open SSH, but you have some other pieces of open BSD on your system.
It took a lot of time, but a sterile copy is everywhere, this is. Finally, when finally,
a wishtraper left the Linux kernel and the Glimc, it finally invaded Linux as well.
And some over-experiments, which are used elsewhere. On a more systematic basis between BSDs,
even for we are different systems, we do talk to each other and we spy on whatever is going on.
Yeah, we look at commits and it's all on the BSD license. So you just have to put your
proper attribution and you can steal whatever you want and it's just okay. It's how it's supposed
to be to be done. So we are still moving forward and I think that from time to time,
Linux and other systems do steal from us. I seem to remember that at some point in the past,
Windows, or network stack, for instance.
And Mark, I think the word that you're looking for is collaboration, not spying.
But that's just my personal opinion.
Whatever, it's more or less the same. Sometimes you collaborate with, actually,
talking to each other, you just look at the commits and say, hey, that's a good idea. I could
probably reuse that. And when you're nice enough, you send an email to say, thank you. It was a
really, really nice piece of code and we're going to make good users.
I mean, you do have exchanges between the Linux world and the OpenBusy world and OpenSSH,
probably the best example for this. OpenSSH for that matter. Any other takes on this subject?
Kurt Sherring, as mentioned, is really the answer here. And I think in the Linux community,
there's this real fear of forking and this kind of paranoia that as soon as a piece of software
is forked, then the effort is going to be split and everyone's going to suffer as a result.
But I think we kind of, with the amount that the BSD is sharing and getting from each other,
I think that's not really true. Not everyone wants to eat the same flavor of chocolate.
The problem with Linux is somewhat different in my opinion. I think that it has more to do with
binary compatibility and commercial issues. Like some parts of Linux are actually completely
still like this. As far as I know, it's impossible to add a new system code to Linux because it
would break everything in binary ways. And you have enough compromises we've tested interest in
keeping binaries running that some parts of Linux are getting really hard to change.
And we are, we don't have this kind of problem most of the time.
Well, you don't have a benevolent dictator for Liar, right? Sorry, there are, of course,
currently there's not the Linux right, but at the end of the day, Linux is still calling the
shots. This is not the case in the BSD ecosystem, is it? Because you, you all pretty much do your
own thing. Oh, we have a dictator in Open BSD. Sorry. We have a dictator in Open BSD.
You do, okay. Yeah, you're at, come on. You disagree with me. You're usually out of the project.
If you disagree, you're not enough. I think free BSD has the reputation of being
the longest continuously in charge. It's had the most number of teams,
trying to think of the proper word, governance, the government, longest continuously
government, government project, I think. It's long had a core team that was more or less in charge
of everything. It has a very good transition, and that just keeps rolling over.
Just some scarcity. The kernel code base between the different BSDs is the same.
Nope. So you all have your own kernels? Okay. Oh, yes. Yes. We have some shared code,
like you are going to find some drivers, which are mostly the same from when the BSD to the next.
Okay. And we have the same ancestors, like, for instance, our all-file system, UFS and FFS.
It's mostly the same code. Some of us in Open BSD are still scratching our hair, trying to figure out
what Marshall made a sick did a long time ago. Okay. But yeah, we diverge a great deal.
If you look at any BSD code, you will more or less recognize the same things, but there are common parts,
there are differences, different kernels, different user-land, common ancestor.
Just out of scarcity, because Linux has one trade, and this is the reason why
Richard Armstrong still likes to call it new slash Linux, because the user-land, in terms of
at least the command line, is heavily dependent on GNU software. If memory says correct,
you are still using GCC as a standard compiler on BSD, but what about the rest? You're not.
No, okay. No, no. We've been with WinonClin for about five years, I think.
Right. Okay. I know that Apple made that move quite quite some time ago, but I wasn't to
share about the rest of the BSD ecosystem. Okay. That's interesting. Okay. Because of why? Because of
technical superiority, or why? Why did you make that move? Because of the license. Because the
they tried to put the first one when they when we moved to GPL V3 and Open BSD got fact.
We had to stick with GCC 0.2.1 for a very long time, because it was the last
compiler, PCC compiler with GPL V2 license. And finally, we were able to move to C-Lung on
most architectures. We see GCC as a backup compiler. Let's say if you want to debug stuff,
and it works slightly differently, so that you can find some differences, but at least on
Intel processors, everything is compiled with C-Lung Vista. And linked with LLVM linker as well.
Interesting. And we have completely away from GCC. Wow. And what about the rest of the
user lands, like standard utilities, like LS move or whatever? Well, there's a BSD style, of course.
But what about you? At least on Open BSD, most everything is BSD license,
while very spare in our best system. But we are not using it under the GPL license,
since it's dual license. And you've got the artistic license, which is very close to
to the BSD license. I think that from the start, when the goals of Open BSD was to have everything
under an acceptable license. And if not possible, we would resort to GPL V2. And at some point,
the wall running system was BSD with a compiler being GPL and stuff like that. And I think that
these days we have managed to have more or less the best running system is more or less entirely BSD.
I think. And what about the other BSD, same, same, same, same, same user land,
like most like all co-paces, but essentially BSD license? Yes, essentially,
essentially everything, but a few things. We don't have as much of a strict licensing policy
as Open BSD. And we use GCC because some processor architectures we support
are only supported by GCC. Okay. And but apart from the toolchain, yes,
basically everything is the SD MIT under similar licenses. I just checked
free BSC 13 and a free BSC 12.2 host here. And they both are running C-lang version 10 and C-lang
I missed it. C-lang 11, 11.01 respectively.
Yeah, sorry. No, that's a very interesting perspective because, as I said,
Linux is pretty much dominated by the GNU review. By the GNU user land, and of course,
the GNU co-paces are GPL licensed as is the Linux kernel, of course.
It also means that when it comes time to make a kernel decision, you're not worried about
breaking user land because it's your user land. You don't have to worry about all the different
repo, repo's distros breaking because you can fix it right here and now and move on with life.
I mean, there are no such things as open BSD distributions, right? There's not
BSD, there's a free BSD, and there's not BSD, and that's about it.
A little time to time. From time to time, you have people who are trying to make some
derivative distributions. I don't know if PCBSD still exists.
You have some, but here you might have some derivative distributions, but more or less,
one official distribution, but it's something called HelloSystem, which I think is a free BSD base.
And you said PCBSD, I think that's renamed. That's from my existence, isn't it? Didn't they
rename themselves? True OS? I'm not sure. It also reminded me of Frisbee, F-R-E-S-B-I-E. I think
max ran that and it allowed you to create your own bootable ISO of FreeBSD with other things you
wanted in it. Interesting. Okay. The nomenclature of distributions and
for GNU Linux naming dispute, both of them seem to be a symptom of the debate as to whether
Linux itself should actually be called an operating system itself, because I mean,
one could easily make the argument that, you know, Debian is an operating system for doors and
operating system. Ubuntu is an operating system rather than distributions of the name that
just seems to have arisen, because Linux is referred to as an operating, well, at least a family
of operating systems, and just needed to be another term to to differentiate everything that comes
that's, you know, based on it. I mean, that's a very interesting perspective, because
if you take a close look at the history of Linux, I mean, it started out as a terminal emulator,
and then Linux took a close look at many things and didn't like it, so the rest is on use net
and the operating system was on the rest of it. Kitty, it gets the links maybe in the show notes
depending on whether I'm up to it or not, but at some stage, basically, big enterprise moved in,
the redheads and the other people and the canonicals of the world. And not before long, you had
a set of standards like the file system hierarchy, the Linux database, no rest of it, that almost
all distributions adhere to. And of course, you had big money in the shape of redhead and
canonical moving into that market. Mark Shutterworth took a close look at Debian, liked it, and that's
essentially the base for Ubuntu these days. Now, redheads still has this playground called
Fedora. I won't go into the center as debacle, because that in-laws is not a center as show,
but yes, never mind the Linux foundation. If you take a look at the sponsoring page,
who's a member and what money flows into that organization, this is clearly big business moving
in. And I reckon this is, at least from commercial perspective, the main difference between
between the BSEs of the world and Linux, because Linux these days is all about enterprise
deployments, the cloud, containers, all the rest of it, all runs Linux.
I was to say, Android apparently isn't in the next distribution, or at least it doesn't seem to be
like, I don't know, commonly known as one, anyway. It seems to be able to just stand on its own,
even though, I mean, okay, it's kind of a rolling from what I'm aware of, it's kind of a rolling fork
of its version of Linux is kind of a, it's not, it's more different than most other
implementation of the Linux anyway. So apparently it's not generally referred to as a Linux
distro, but then where, where is everyone's supposed to draw the line? Indeed Patrick, I was just
going to touch upon this, because if you take a close look at the system architecture or something
called Android, you still have a full, full-blown Linux kernel underneath it, but the rest of the
user land, and that's exactly your main differentiator here, it's quite different. You have a different
in the system, you have something called Zygo that is actually in charge of spinning up processes,
I'm simplifying things, of course, and then you have this main driver called JVM.
Sorry, it's not called JVM, it's hard, or it's nostalgic, or whatever you want to call it these days,
it depends on your Android version, but at the end of the day, the commonalities is something
called the AOSP, the Android open source project, because that's exactly the code base
that Google couldn't make proprietary or Android for that matter, because it's all GPL licensed,
and if you actually have a phone in front of you, if you managed, if you managed to connect this
phone to a computer, if you turn on, with a USB cable, for example, if you turn on a USB debugging
on this phone, you still have a command line in front of you once you invoke ADB shell,
and of ADB, of course, standing for the Android debugging bridge, so at the very core, it's still
a Linux system, GPL, mostly GPL licensed, and similar to, or I'm always trying to say similar to
the OSX architecture, the rest is proprietary crap, namely the stuff, basically, that Google put
on top in terms of the user interface, the virtual machine that executes Java by coding all the rest of it.
Is it still going to be Linux in the future? It seems like Google is getting sick of Linux,
and then you think moving towards their own thing, future. Yes, future is a different story. Google
has copped on to the fact that AOSPS has one significant disadvantage, it's licensed because it's
Linux at the end of the day, it's licensed under GPL, but as I said, I think it's licensed under BSD
or IMAD license, which is much more permissive, so the smartphone manufacturers who basically take
the OSP and the Google ecosystem run on top of it and do something themselves with it,
like, for example, Samsung has their own user interface, I don't even call it what it's called,
but if you take a close look at quite a few smartphone manufacturers, they all do their own thing,
and I reckon with the dominance of Google in the end of the market,
Tyson, thank you very much, with the dominance of a company called Google in the smartphone market,
this is essentially the driver that made them basically do their own thing in terms of
coming up with a much more permissive license, operating system base going forward,
then basically the smartphone manufacturers could use not to be bound by the GPL under which
the majority of the AOSB called basis license. It's just a matter of tamaracking before you see
that switch happening from the AOSB, which, as I said, is mostly a little space to do something
called FUSHIA. I would like to see Android phones get security updates faster or at all,
there doesn't seem to be a long life for a given Android phone. It's a bit to see a market,
I mean, you're looking at one, maybe here, maybe two years of the shelf life of a smartphone,
because after that is being replaced by something else, so why bother? No, no, no, I disagree.
I still have iPhone 5s and iPhone 7s that are perfectly functional, and they still receive
updates. Yes, but that's not Google. Oh, that's not Samsung, but that's not most of all of
something. This is why I specifically mentioned Android. Did you hear about Pegasus?
I didn't hear you said. Pegasus? Pegasus, yes, I did. Yeah, especially iOS.
Can you, maybe for the two people in the audience who do not know what Pegasus is, maybe you can
elaborate, please Mark. Oh, it's a big news with this. We just found out that some Israeli people
have been using Pegasus to spy on journalists in France in other places, among other things.
And as far as I remember, they have been using zero days on iOS phones.
I think both Android and iOS systems are affected.
Yeah, but both are affected more or less because this is still stuff we've closed for software.
I don't mean that open source is perfectly safe, but if you can't even look at the software,
you have absolutely no reason to think that it's going to be secure, especially when you're
looking at a state spying on each other. I mean, that's a wonderful debate, but maybe some
just point at the show. I don't see how you can trust a phone that's manufactured by the
United States or Korea to be perfectly safe or China forward matter.
Buy your own kit and do your own OS running on top of that kit. Just make sure that you have
the blobs in place for the SSE. This is not something you can do specifically because you
have blobs. How much longer is it going to be possible to install your OS and how long will it take
for them to decide it's too unsafe to allow users that much freedom? Good question.
This is precisely why we should be continuing to be doing what we do and fight for it,
so that this doesn't ever happen, but you can still tinker and do your own OS and do your own
hardware and do your business. That's a reckon precisely the difference between something
called the BSD software world as in these days, not back in the olden days, and something called
Linux, apart maybe from a few corners in the Linux empire that still think along the same lines,
how about that? To answer the question, Pegasus is a spyware that was created by an Israeli cyber
arms firm called NSO Group and then covertly installed on mobile phones and other devices.
Both iOS and the Wikipedia page. Both iOS ads, what is Android's first to do?
And it was first discovered, let me see here, I had this discovered in August 2018.
Okay guys, unfortunately we have to wrap this up because we have been recording now for almost
one and a half hours, no worries. Any final statements before we close off the show?
I have one, but I'll go last.
Any prior takers?
I would just like to say run BSD stop fascism.
Fair enough, fair enough, fair enough. Any other things before the last statement?
I think I've been doing enough trolling for tonight, so just try to be as video and see if you like it.
I really haven't heard any trolling today. None. None whatsoever. Run BSD stop fascism.
Yes, it's all free opinions and all the rest of it.
Yes. Now for the very final remark.
Yeah, I want to correct something in my opening statement.
I started with open source software in 1998, 1995. If you want to have a better overview of the
history of BSD, I suggest you look for a YouTube video called a narrative history of BSD by Dr.
Kirk McEusek. That will get you well into the door. If you want to hear more about a BSD
perspective on System D, look for a YouTube video by Beno Rice, sorry Beno Rice, called the
Tragedy of System D. And if you want to look at how much BSD is evolving, go back 10 years,
look at the size of the dev teams, go now, look at the size of the dev teams. Dev teams don't increase
without interest. People join dev teams because they're interested in the product and they want to
work on the product. And that's how you keep a project self-sustaining is by having a growing
user community and development community. Strong words are softly spoken, I'm tempted to add.
I'd just like to actually be serious for a moment. And I referenced a talk earlier called
the Rise and Fall of Copy Left by Robert Lagley. And if the audiences particularly interested in
history of open source and of copyrights and licenses, I'd recommend listening to it.
Details of all of these projects and pointers, of course, will be in the show notes.
People, first of all, a big thank you to the panel that has been more than interesting,
especially given the fact that this is probably an outsider's take on the whole Linux ecosystem
that has been more than refreshing. And I would like to thank each and every one of you
for participating. And with that, I would like to close the show. Thank you very much for being on
the panel, being part of something called Linux Enloss. And maybe we'll get another show
on the BSD ecosystem, we'll have another show. And thank you for participating.
This is the Linux Enloss. You come for the knowledge. But stay for the madness.
Thank you for listening. This podcast is licensed under the latest version of the creative
commons license. Tap Attribution Share Like. Credits for the entry music go to bluesy roosters
for the song Salut Margot to Twin Flames for their piece called The Flow used for the second
intros. And finally to the lesser ground for the songs we just is used by the dark side.
You find these and other ditties licensed under creative commons at Tremendo. The website
dedicated to liberate the music industry from choking corporate legislation and other crap
concepts.
What is your name? Sorry, my name is Chris. Because your app is Martian McKeezyk.
Yes, that was a joke. Okay. Because when I first saw that, I said, okay, Kirk is here. What's
going on? Yeah, but his name could have been Martian McKeezyk.
So BSD, although I'm not using it on regular basis, has been with me for the last 40 years
easily. I use some unique somewhere in university and I can't really remember much about it.
Yeah, my first Tunics machine was in 1987 and I think the most born free that was
born in 1988 or something like that. Interesting. That was actually in 1987, that was the first
time when I compiled an EMAX version on something called Solaris or Sunways, it was then called.
Sunways. And that was my still a few years in the future. Yeah, Sunways, sorry. And that was
actually my introduction to something called free and open source software back in 1987.
I've been using open source software ever since. The concept is great for GPL is not so great.
You see Richard, I'm storming. May you think differently about this?
I'm not really concerned about what that gentleman thinks.
Gentleman?
Gentleman?
Gentleman might be a bit of a stretch.
Do I know how to troll or what?
Keep trolling, Mark. Don't stop.
No problem.
You've been listening to Hecker Public Radio at HeckerPublicRadio.org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HBR listener like yourself.
If you ever thought of recording a podcast, then click on our contribute link to find out
how easy it really is. Hecker Public Radio was founded by the digital
dog pound and the infonomicant computer club and is part of the binary revolution at binwreff.com.
If you have comments on today's show, please email the host directly, leave a comment on the website
or record a follow-up episode yourself. Unless otherwise stated, today's show is released on
creative comments, attribution, share a like, 3.0 license.