
FreeBSD: the next 10 years - danieldk
http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years
======
DCKing
The most intriguing part of FreeBSD (any BSD really) from an outsider's
perspective I find the fact that "the FreeBSD project" has a bigger, more
directed scope than "the Linux project" or "the GNU project". It's a kernel
and userland all in one, and they can actually _decide_ to focus more on unity
of configuration files and mobility. I get the impression that you cannot
decide that as efficiently on Linux at all.

People often say "Linux is all about choice" as if it's a good thing [1]. I
think this overwhelming focus on choice really is what's so frustrating about
Linux and its community. If needs aren't being catered to, or if there are
disagreements, the amount of vitriol that gets thrown around is despicable.
The systemd controversy is so terribly shameful, but lo and behold: FreeBSD
now seems to be envious of it (or at least some of its aspects). Gnome 3 is
widely regarded [2] as the best, well-integrated desktop environment Linux has
ever had, and look at the amount of vitriol _that_ got for having a direction
and making choices for the user. I personally think that the level of
integration systemd and Gnome 3 are attempting to pioneer make Linux far more
attractive than ever, but the Linux community really alienates me with its
attitude towards that. With this attitude, desktop Linux mostly remains a
patched together collection of software. The rough edges of this patchwork are
still far more apparent on even the best regarded distros when compared to OS
X or Windows or even Android.

It's a shame FreeBSD doesn't maintain an integrated or official graphical
interface. Since it uses the same not-so-well integrated desktops as Linux
does, it unfortunately means that using FreeBSD is only a minor improvement
over Linux for me in daily use [3]. That means I'll just leave it to Apple to
build me a well-working and well-integrated operating system. If an operating
system project or vendor makes choices for me, I consider that a big advantage
most of the time. If a project can actually take on a proper direction like
this presentation suggests, that is a big selling point to me.

[1]: I know what the good things about choice are, I'm trying to make a point.

[2]: Widely regarded does not mean "universally regarded" or even "regarded as
such by the majority".

[3]: Ignoring the problem that FreeBSD doesn't have the level of driver or
application support that Linux has.

~~~
freehunter
That's why Ubuntu became so popular, and Mint after it. There was a cohesive
vision that a Linux OS can be more than a collection of text processing
utilities. That's also why Ubuntu is so reviled in some Linux circles, because
they dared to make a choice for their users, dared to try something new, dared
to implement something that wasn't a direct continuation of decades-old
software. Once they proved it was possible, others started jumping on board,
giving Linux the freshest coat of paint it had ever seen. It was a serious
contender for the year of the Linux desktop, especially with the rise of
netbooks.

But then politics happened. If it doesn't work the same way it did in 1968,
it's not allowed in the OS that was the child of the 90's. Pulse Audio, Unity,
Gnome 3, systemd (along with anything else Poettering has touched) are evil
because they're new. Unix never did it, so Linux can't.

GNU's Not Unix (yet... we'll get there someday though!).

~~~
nisa
> Pulse Audio, Unity, Gnome 3, systemd (along with anything else Poettering
> has touched) are evil because they're new.

At least for Unity and Gnome 3 (including GTK3) I'd rather say: Great ideas
but they're evil because they are badly designed, full of bugs that don't get
fixed due to complexity, constant API changes, almost no documentation or only
wrong and outdated documentation and a lack of flexibility that annoys even
the casual Desktop user.

Nobody is against progress - most people love to use OS X as a UNIX GUI these
days... it's not perfect but it's not that bug ridden mess GNOME became.

~~~
coldtea
> _Nobody is against progress_

You'd be surprised. Just listen to the arguments against giving Linux a more
logical directory setup (somewhat like OS X's).

~~~
sesqu
Change is not the same as progress. A lot of people are against change, for
reasons both good and bad. I'm not familiar with the arguments over directory
setup, but I'd almost bet money on them centering around tradition.

Personally, I think the various flavors of directory setup are already so
divergent that tradition no longer holds massive value, but that's not
something to be proud of.

------
fdsary
Choosing a unified format for configurations is an interesting task, because
they all suck a lot (hehe). XML is too verbose to be nice to work with. Plain
text files with config flags delimited by newlines lead to the program in the
end implementing a small scripting language for config files.

JSON is pretty nice, but also a bit clunky. A lot of {:} all the time.

Personally, I think the nicest and most expressive way is S-expressions. I'm
no lisper, but you have to admit sexprs are expressive, easy to read, and can
be run as functions if the program knows lisp.

    
    
        {  
        "configFiles": "in JSON",  
        "wouldLook": {"like":"this"}  
        }  
    
        (while sexpr
          (could look)
          (even nicer))

~~~
barosl
Regarding the configuration formats, I would recommend TOML.

In fact, I hated it because it seemed to be just "another standard" that
unnecessarily adds dependency.

But after using Rust, whose package manager forces me to write the package
configuration in TOML, I found the format is more like "JSON designed for
configuration file." As you said, JSON is full of ':', '{' and '}'. And it is
natural because it started from data interchange format, not for handwriting.
TOML solves this problem very well IMHO.

Also, unlike XML that requires an external structure to validate the types of
the values, TOML values have types, just like JSON.

~~~
klez
Link for the lazy [https://github.com/toml-lang/toml](https://github.com/toml-
lang/toml)

------
tambourine_man
Audio from the talk:

[https://archive.org/download/bsdtalk247/bsdtalk247.ogg](https://archive.org/download/bsdtalk247/bsdtalk247.ogg)

~~~
pmarin
Video from the talk:
[http://youtu.be/Mri66Uz6-8Y](http://youtu.be/Mri66Uz6-8Y)

~~~
mlvljr
3D virtual-something from the talk, anyone? ;)

------
nkuttler
I find it irritating to see cheap jabs at Linux/GNU/GPL in most BSD
presentation I check out. It doesn't prevent me from using it, but it's just
childish. Focus on your strength, not what you perceive as weakness elsewhere.

~~~
byuu
Linux and OS X do the same thing to Windows (xbill, Micro$oft, PC vs Mac
commercials, etc.) It is kind of sad, but it's how underdogs always work.
Selling yourself as an underdog means not only pointing out what you do well,
but how you do things better than others, and that always ruffles feathers.

Just saying what you do well will result in your competitors saying, "we do
that well too", and won't win you any market share. You have to demonstrate
that, "no, they really don't do that well." So it's a real balancing act
between promoting yourself and not being a dick to your competitors. In my own
personal case, I screwed that balance up royally, and it's a problem that has
followed me around for the last decade.

Similarly, look how hostile OpenBSD is toward FreeBSD about security designs
(watch any Theo de Raadt presentation.) I almost never see any FreeBSD users
taking pot shots at OpenBSD like that. Then look at the market share of both,
and it makes more sense.

~~~
vezzy-fnord
_I almost never see any FreeBSD users taking pot shots at OpenBSD like that.
Then look at the market share of both, and it makes more sense._

Then the more logical explanation is that FreeBSD is lagging behind exploit
mitigations.

Keep in mind that Theo actually praises Windows and says that they're second
after OpenBSD. If this was about being envious over market share, then that
wouldn't make much sense.

~~~
not_with_retard
It makes plenty of sense when you consider who OpenBSD's actual competition
is. Hint: They aren't trying to target the desktop market.

------
justincormack
I didnt find this talk very visionary (I saw the similar one at EuroBSDcon).
Power management needs to be better, add something like systemd thats not like
that. Vision in (existing) operating system development in terms of ten year
projects is actually quite rare, mostly there are incremental changes. OSX is
maybe an example, go for usability, and ZFS is another, make a radically
different file system. Windows NT perhaps as well.

------
andrewflnr
This may be a stupid question, but what's wrong with shell scripts as config?
Yeah, they're Turing-complete, but they're necessarily trusted, and a lot of
times you end up wanting that anyway. But in the simplest case, they're almost
the platonic ideal of a config language: name=value, repeat. If your objection
is that shell languages have lots of nasty warts, then I'd agree, but you
should be fixing that separately anyway. I sort of encountered this idea in
FreeBSD init scripts, so I don't see why they don't just run with that.

~~~
thristian
The problem with a Turing-complete configuration format is that pretty much
the only thing you can do with it is preserve it verbatim, or execute it to
see what config it produces. You can't, for example, write a tool to safely
update a config file to work with a new version of the software, or to apply
some specific update across a bunch of machines, or to catalogue the
configurations each machine has.

~~~
andrewflnr
Yeah, but that's more of problem with shell than Turing-completeness in
general. You just need to design a language with a usable T-incomplete subset,
like maybe name assignments and conditionals. The only problem is that it's
tricky to enforce that sort of sunsetting on sh. But I don't see why your
migration script couldn't just say, "sorry, your config is too weird to
automatically migrate" when it sees a loop or external callout.

------
nathell
"All OS and app configuration data in OS X and iOS are XML plist files, even
GNU emacs and X11.org's preferences!"

Naming correctness aside (it's X.org), can this be backed somehow? I remember
using Emacs on OS X and I very much was storing my configuration in
~/.emacs.d/, the way it should be. The idea to have a unified configuration
format for the entire system is glorious in theory, but with a system as
heterogeneous as FreeBSD (and Linux even more so), it seems next to impossible
in practice.

~~~
danieldk
I assume he is speaking of the base system. Though I wonder how good an idea
it is in practice. E.g. I cannot really imagine configuring, say mutt, via
JSON, XML, or whatever. The power of such configuration files is that they are
often domain-specific and allowing a custom format makes them compact.

Of course, for automation or writing user-friendly interfaces, a unified
format is better.

------
coldtea
For those that don't know it (there are some comments here but not very
clear): the writer of this presentation, Jordan Hubbard was a head FreeBSD
developer for many years, who then become a head developer of OS X at Apple.
He left Apple last year, and is back into FreeBSD work.

------
sudioStudio64
I have to admit that I came to this thread to see if anyone accused Jordan
Hubbard of not understanding the "Unix Way" when he mentioned that they need a
subsystem like the one that must go unnamed on this and every other forum.

Gosh, I remember when you could get FreeBSD on floppies. I've always had a
great deal of respect for the work that they do. 10.0 was awesome, but I have
to admit that I don't use *NIX everyday anymore.

~~~
peatmoss
Oh my gosh yes. I can't imagine anyone with JKH's particular type of cred in
the Unix arena, who could more convincingly sell me on such a service. He
cofounded such an iconic traditional *nix environment, and then spent years
presiding over the technical direction of the internals for OSX.

I like to think JKH has already seen the future at Apple in terms of what
worked, and what could have been improved. That JKH is back to working more
closely on FreeBSD is exciting.

------
cwp
Can someone explain bit about "trying really hard not to suggest launchd?"
He's right, it does seem like an obvious fit, but he takes it as obvious
FreeBSD wouldn't use it. What am I missing?

~~~
_jsn
Jordan Hubbard only recently left Apple. I suspect he is trying to avoid
suggesting only Apple solutions for FreeBSD problems.

------
josteink
I must admit I like some of what I see, but I'm not sure the people currently
ditching Debian for FreeBSD is.

Hopefully FreeBSD's _execution_ will better than Debian's, but given their
long standing track record I have little doubt they'll be able to make a
future transition a million times smoother.

I'm still not sure I agree that all configuration has to be stored/processed
in the same format (ref Apple plists).

I know this is the way things are done on some embedded platforms like OpenWRT
and once you get used to it, it's _OK_ , but it always means a feature needs
to be doubly supported: first in the original service and its config-file and
then in the translation layer between the config-file translated by the init-
script into the "real" deal.

And will they be doing this for the 70k+ ports, or just for core services
provided by the base OS?

------
porker
Let's hope they take these pointers to heart, discuss and move forward. It'd
be great to have an even stronger FreeBSD in 10 years' time.

------
teddyh
Regarding “A centralized event notification system”, I predict that D-Bus will
soon have this position in Linux, certainly when kdbus lands.

~~~
teacup50
D-Bus is an amazingly crap implementation of this idea.

~~~
teddyh
Your comment is an amazingly crap comment. Provide _details_ and/or _links to
details_. Also, does your “crap” assessment also apply to kdbus?

------
krick
> My dream laptop has evolved (BSD instead of Windows) (15th slide)

But, wait, isn't it Mac?

~~~
dbbolton
It's a stock photo: [https://www.google.com/search?tbs=sbi:AMhZZivX9JS-
QLEbVyc-hN...](https://www.google.com/search?tbs=sbi:AMhZZivX9JS-QLEbVyc-
hNm9pulGOhgNa0zpQ-eCE-
mTFSlgREXdOD6kgOwxp7H8Xy3Ogb8hahkhki6Y7I-cCc0-9zqi03zdOS8RRAmH0bNLWCYCd89-bLWAFvbXOyujsSHUlk_1OqEuPzFQ6dAgPoCfCyrTj2EjsRuVBEGq2wMVUyW_1vWwB2I7IuebBxeU-43I4NHwfgW6Ait_1h6w6Nri0OiFlsvCYy0sb-Q0gRuGGKUElekx1PIDynjEjpwQfnFOu04CvRxfrOqYKxrRkNWVvAylrSDFGWsW_1b4xN7VkON4-E5EY7u4g1pxHuWzZTRZqVG_1MA9Fwn-
VbaTma0YMQXSDKdmp7JZw1xxYLsNAwUsN_1HjreyzRI0SaEJQ5LDyqlbuGxi66iGmb7dhsqGpmO-
mkH7Hj2nhpdKKqOErV2lHcjZB9HXIEkbaI6MADGqyrl8MXQdWR96BCtVuFUjCc6l29m8_1ELVNh9FbqtbHH5QDKprfT06K68MXYEMW7PLxvVRT7Z9De0H9ARmX9NkNSqYMeyF_18u-8116hZ3zY475gQdhZFBJL_1Fjvz_1cJf0kqjm-
CR58zsvdKuxGjHkt3eLG3bQRig_1PPHFgrOW9CWf2WVHHuQmedCuI2AFhbhMJk4w3g77dvrxaLzuYIBnssNZz0mE0SMqAHYeJsY6eXoLIDAuuHhWi9zMLtRG9PeJTS5vkJQoVLXzWPT908X9_1LBSNB_1gWp1Fdb4eeJPAgFx2Qd_15r-XzGIG9MIi6qPtYDUTp8bKY5cnXsaLBSaNtM-
tvksY_1wAD2Iy4142MK0p_1OZvGg-v78m-lT0UanutaLRtiqO4zl2ZkWZp1sXou-K39jBQVXlJvou1FjSwiY94F7VJ7_1Qyuh6EMrMdClK0Z7ApDhOsWZwgA6XoWqNGnbviuNdRzTKhAAllJKRpgF3bXFrIEYH08F1hist8LpGCkIyOc8NB3e-_10rdBl2QJ4pnbQGdPFYxwDJBG_1fz_1Dlf76VNXe8mFj61YS1LoVq2HBCkC3EjmWgENm4X-7xPnISWDTVtJjvXF0FfxeGJb2JlwSA6G8eh5olWRTmTOVXEkpRba7dAmu_16HrCVDJckoFKhGIOD9Dxtm0y_1llBYO7pbazh61dzTdLyfo_1GqK5QjUbeKQZOqgJLY6SbFSE4vD2Xa9M2XEnpbEzyc1984mnFvOlovmylyTfb3NfYRbKUef0Wx4EwoqJiTxXfSK9o2oLJu3b2eO0ccDboC7yGwiXOPY68fRowdpAMKRGPMpy_1IT0AfDYh-_1A5d3lNUK1qGTQE7Wy3hjZm3KoxtTd_1e0DxMFjazHK5YYinb1n_17hoUze-
os1LUmdiF1vQ5Ge8Kqp8CCf0MtCj9GL7XDkZlNgYvhH747bAvnTq59P78bP_1eMn1ZoCrchajrP55A_1QohUYi0KqhkKcenjr9ESqa5Q&gws_rd=ssl)

~~~
zanny
It still ships with OSX, albeit it is less apparent than how buying a Windows
computer to run Linux (hic, Lenovo fanboys) how antithetical to your cause
buying the machine is.

------
gtirloni
Regarding the centralized configuration data, I don't know how to feel about
it. Sure, it would be good but most recent attempts at it usually involve
going the Registry way.

~~~
threeseed
I didn't see anything about centralized configuration.

Only standardising on a single format e.g. JSON.

------
Spidler
"Even the linux die-hards have essentially grasped the necessity of systemd
(Even though they're going to hate on it for awhile longer)"

~~~
ausjke
the only reason I'm re-interested in bsd is that it does not have systemd, if
BSD wants systemd-alike init I will stop right here...

additionally, for the vast majority linux systems that are actually embedded,
BSD needs a solution for that.

~~~
ghshephard
The one great thing about OpenBSD, is that it provides a consistent, reliable,
cleanly documented, constantly maintained, operating system.

There is such an emphasis on consistency, that a solid OpenBSD administrator,
who last worked on OpenBSD in 2004, and then, 20 versions later, (OpenBSD
releases a new major version, along with a full set of architecture releases
and binary packages every six months, like clockwork) - would have _zero_
problem understanding all of the system concepts. A few things have
changed/updated/evolved, but a couple hours with the man pages would bring
them right up to date.

OpenBSD is about very gradual evolution, not revolution.

My sense is that OpenBSD is not designed for Watches, Tablets, or SmartPhones.
It is a world class Server, Firewall, Router, networking device, networking
appliance operating system, and it's unlikely to ever lose that focus.

I'm pretty confident that we won't see anything like systemd confusing
everyone on OpenBSD as long as Theo continues his steady management at the
helm. Systemd actually serves some pretty important functions on systems that
have a lot of dynamic services going up and down with dependencies,
particularly on low-power devices, and on systems that require rapid parallel
process initiation - so I'm not hating on systemd here, just appreciating the
consistency that we find in OpenBSD.

~~~
clarry
> OpenBSD is about very gradual evolution, not revolution.

To make a concrete example, look at ifconfig and ip (from iproute2 I guess?)
on Linux. ifconfig was used to be the one tool to rule them all, everybody
knew it, everybody used it. At some point somebody decided they need a new
tool, so now there are two, and the other is said to be deprecated. The fun
thing is that ifconfig still mostly works, and you find lots of
documentation/tutorials/wikis telling you to use it. But at some point you
might bump into some really weird issue which turns out to be because the tool
you're using is.. well, deprecated. I did have such a problem myself (related
to IPv6, years ago) and it wasn't much fun, because the tool looked like it's
got support for the thing I was trying to do, but it would just silently and
weirdly fail...

In the OpenBSD land, a network interface is a network interface. You use
ifconfig. IPv6 or not. Wireless or not. The same tool everybody knew has been
evolved to support the new stuff. The developers are _careful_ about
needlessly changing the user facing part of a tool in a way that would require
him to re-learn it or another tool. Of course, sometimes changes are
inevitable, and these changes are usually documented in the upgrade guide (and
the page which documents changes to the -current branch). So there are few
surprises.

Sometimes the underlying tool might change entirely to another implementation,
yet the user facing parts are made for most part finger-compatible with the
old tool. For example, mandoc(1) has replaced historical tools like man(1),
apropos(1), etc. And sendmail has been replaced by smtpd, but smtpd still
provides newaliases and makemap.

So they don't push shiny new poorly tested tools and tell everyone to relearn
everything all the time because _shiny new features (and the old tool was
cranky and nobody wanted to fix it)._

~~~
emmelaich
ifconfig didn't support infiniband and hadn't been maintained for many years.

It was irritating at first but ip is a better, more capable tool.

[http://serverfault.com/questions/458628/should-i-quit-
using-...](http://serverfault.com/questions/458628/should-i-quit-using-
ifconfig)

~~~
ghshephard
I've never used "ip" in a sysadmin setting - the only command I've ever used
on a _nix (bsd, OS X, Solars, Linux) is ifconfig - which may just indicate I
'm using the wrong command, but also demonstrates the issues involved in
switching to a new command.

Re- ifconfig/infiniband - this is ironic - because when I google "configure
infiniband linux" \- every page I come up with only mentions ifconfig, and
never ip.

(though, ifconfig is just used to display the interfaces, and it's usually
other commands like ib_ that seem to be used to configure the infiniband
interfaces)

------
XERQ
I find it alarming that releases are EOL after 1 year, whereas RedHat Linux
releases are supported for 10 years.

~~~
danieldk
That's a point release. Red Hat point releases are also not supported for 10
years (you follow along the point releases on the major version for that
length of support).

It seems to be pretty much the same on FreeBSD. However, the support for major
versions is also shorter. E.g. 8.0 was released in 2009, and 8.x is not
supported anymore.

~~~
crest
FreeBSD 8.4 is supported until 2015-06-30. FreeBSD 8.0 was released on
2009-11-25. Odd numbered minor releases and the last minor releases in a major
release are supported for 2 years.

Migration two newer minor releases of the same major release preserves binary
compatibility. There are ports to preserve binary compatibility with previous
major releases.

Why would want to run 10 year old binaries if a compatible and improved
version exists? Run FreeBSD 8.4 and 10.1 on the same hardware and perform a
bunch of benchmarks. Even if none of the new features are relevant to you it
offers improved performance.

~~~
rsync
Yes, that is what it says on paper, but I would submit that both 5.x and 7x
were essentially EOL the day they came out.

Since 4.x there has been a huge focus on the upcoming releases. By the time
the x.0 release comes out, all of the cool kids are working hard on x+1 and
x+2 - you saw this especially during 8.0 and 8.1 when a lot of mailing list
chatter from core developers revolved around nitty gritty details of 10.x.

By the time 7.1 came out (for instance) all new driver bug fixes, etc.,
stopped being applied to the 7 tree and the answer to every question was "it
will be in (8/9)".

I _do_ appreciate the fact that an 8.4 was created - it's a step in the right
direction and a sign of some real understanding of the problems the end users
are having with an inability to invest in FreeBSD and make long-term plans
with their own platforms.

However, I still would like to see a release ... any release ... get to x.10
or x.11 - like 4 did. I even committed $50k to that end a few years ago
(although I suppose that's small fries these days :)

If people would like to know my specific critiques, there was a long mailing
list discussion in 2012:

[http://lists.freebsd.org/pipermail/freebsd-
hackers/2012-Janu...](http://lists.freebsd.org/pipermail/freebsd-
hackers/2012-January/037294.html)

~~~
kev009
I expect this would be a big deal for the appliance manufacturers (think
Juniper, NetApp, Isilon) that need to support long life cycles . I'd also
expect those type of companies to pony up for long term support (and they do,
at least internally, with staff developers and trees)

But in an ops context, why not simply install compat<version> packages? Or
worst case, run the obsolete apps in a <version> jail? With containers, I
think we're rapidly approaching a point where the software that touches the
hardware can evolve faster than the libraries/support around applications, and
this quite frankly is awesome!

------
mp3geek
In 10 years time will they still be using CVS?

~~~
Freaky
FreeBSD migrated to Subversion in 2008.

