FreeBSD: the next 10 years
slideshare.net
slideshare.net
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.
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!).
I sometimes wonder if good visual and interaction design can succeed in the open source model. In software development, tasks can be parcelled out in a modular way to many developers. But this model doesn't work well for visual and interaction design. If you want all the parts of an Operating System or piece of software to feel consistent and cohesive, you need a more focused approach. And that means handing design tasks to a designated design team and entrusting them to make the UX decisions. But with open source projects, we all want a say in the UX (me included); thus the endless (and often bitter) discussions about how a piece of software should behave.
The model of open source code has influenced and inspired countless companies. But who can point to examples of visual and interaction design from open source software that has had a similar effect? I see the influence going much more the other way i.e. open source software often follows ideas or conventions from commercial companies. I'd love to see this change. But how?
I think, the same thing works with visual and interaction design. But you'd need a small group of people to make the basic UX decisions and write concise guidelines others can follow. Like Apples «Human Interface Guidelines»[0].
This isn't really purely democratic, but I think it's almost impossible to find the "one way of doing things" if everyone has their say in every micro decision.
For me its much more important to have consistent user experience than the details of it. Its like tab vs spaces in programming or semicolon vs no semicolon in Javascript. I have my personal preferences, but i'm fine with either one as long as it is consistent at least within the project.
[0] https://developer.apple.com/library/mac/Documentation/UserEx...
The same goes for any democratically appointed UX team.
On the other hand, we, the people are soon to vote whether Switzerland should terminate european human rights contracts. It's insanely democratic and it scares the shit out of me because it might actually get a majority.
You can shoot yourself in the foot with too much democracy.
The right wing fear machinery fed with millions of donation money has really poisoned the political climate over the last decade. Whether you agree with their points, a system like ours, where basically every citizen can trigger a nation wide vote about almost anything (e.g. reintroduction of death penalty) only works if the debates are driven by reason, not populism. The other parties recently jumped on the same train, saying it's the only way to defend against those scare mongers … sigh
I still love our system, it gives the people not only power but also a sense of responsibility. It's not the government that fucked things up – you did. But it doesn't make a country completely immune to dedicated actors with enough influence and money like many believe.
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.
You'd be surprised. Just listen to the arguments against giving Linux a more logical directory setup (somewhat like OS X's).
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.
The problem is the comparison point.
When original Gtk/Gnome came out, it was a WAY worse BPOS than Unity or Gnome 3 are today.
The trick was that when Gtk/Gnome came out there was no existing solution. So, even a bad one was okay.
The problem is that the new solution is competing against an existing solution that has more than a decade of development behind it.
It would take a Herculean effort to win that comparison.
There were existing solutions, e.g. Motif or Athena widgets if you wanted a GUI library, or FVWM if you wanted a desktop environment. Of course, GTK/GNOME was a significant improvement.
Qt and Gtk were a breath of fresh air. And Qt got everybody's dander up due to 1) license and 2) C++ requirement.
So, Gtk basically stepped into a vacuum.
1) A number major commercial UNIX vendors have moved in the direction dumping the old startup scripts in favor of something more explicit and declarative. This isn't just engineering for engineering's sake, major corporations have customers with needs. Redhat and company are no different.
2) It's incredibly easy to be vocal. What's really lacking is a compelling alternative. The most vocal opposition have made anonymous web sites, have made tons of noise but done very very little in the way of actually solving the problem, many even refuse to acknowledge them.
It's really easy to think it's a civil war of sorts but the reality is it's mostly just a very vocal group that are against it, and FWIW, they don't seem to contribute that much. The BSD world has had it's share of these too, it's just a more dramatic fork when you startup OpenBSD project or NetBSD or DragonFly or one of the more minor forks.
Openness means you get to see the bad as well as the good, the decision. A very vocal group of folks were crapping on GNOME 3 when it came out, now it's good. If you think systemd was contentious, while I love the idea of unifying configurations, just wait until that debate starts... It's probably not possible to represent all of the different things that the "tower of bable" has without a nightmarish XML schema, if it can be done. I welcome the ideas though, especially if FreeBSD get's serious about mobile and power, there will certainly be some interesting stuff.
That was my point: there are well-known limitations to those systems which are the stated reasons for developing systemd in the first place. It's reasonable to disagree about the priorities or the approach which systemd uses but instead pekk instead just pretended that there aren't any unsolved problems.
> You're doing it right here: anyone who disagrees with you is a troll
Here, try filling in the blanks: “[ ] is hard to do with SysV init. I don't like the way systemd does [ ] because [] and prefer the way [] does [] instead"
See the difference?
And that definitely doesn't imply that the poster was a troll. You didn't even address that. That is a personal attack, and is typical of how systemd supporters shout down the opposition.
> Here, try filling in the blanks: “[ ] is hard to do with SysV init. I don't like the way systemd does [ ] because [] and prefer the way [] does [] instead"
> See the difference?
So anyone who criticizes systemd and doesn't fill in those blanks is a troll?
Linux isn't quite in this world in such a dramatic way as the BSDs, but it exists very close to it.
So "choice" isn't some abstract concept that comes later as an afterthought, it's kind of the whole point in a very concrete and literal sense, in a way that other systems do not offer. Naturally you will see people with their workflows based on that, or some indirect form of that. And these people have working systems, no matter how much people wax philosophical and longingly on forums for "missing" features that are irrelevant to people with already working systems.
So from a certain perspective it's a bit weird to see something like a slide here say that such a system needs to address 99% of people. Who says? It's working fine in its niche.
I think there is also a very simple difference of opinion and difference in personality types here, in a way that I don't often see people acknowledge. On one side you have people who crave authority, order, centralization. One component to manage boot and hardware. One UI toolkit. Choice is bad, freedom is slavery. (OK, just joking on that last one.) Then there are people who just happen to like it the other way. I'm glad that some systems don't bring up a GUI until I ask for one, and even then, it can be whatever I say it is. I find it pleasingly simple that the OpenBSD upgrade instructions basically tell you to run tar and patch. These things are an anathema to those whose personality types are more aligned with, say, OS X, but they work well for me.
But I did not want to imply that "decentralization equals less choice". As an example: Android is as centralized as you can get for an open source project. That does not stop people from customizing it to bits, so much that it's barely recognizable as Android anymore. The beauty however is that people can do that without influencing the direction of the original project (although that happens to a limited and uncredited degree), or bitching and moaning about it.
Coming from an OpenBSD background (hey - it's the only OS in the world allowing you run Xorg as an unprivileged user [1]) -- what I'd like to see is an intra-BSD desktop environment based on Google's Material Design guidelines:
http://google.com/design/spec/material-design/introduction.h...
And for ol' times sake, the IRIX® Interactive Desktop User Interface Guidelines:
http://menehune.opt.wfu.edu/Kokua/Irix_6.5.21_doc_cd/usr/sha...
Similar to Quantum OS (Linux):
https://news.ycombinator.com/item?id=8645504
--
[1] http://undeadly.org/cgi?action=article&sid=20140223112426
Wait, what?
This isn't some custom repo or anything, I'm just running stock Arch and have startx in my bash profile. It runs in user mode, and has for about the last half year.
https://wiki.archlinux.org/index.php/Systemd/User#Xorg_as_a_...
Unfortunately, to be able to run xorg in unprivileged mode, it needs to run inside a session. So, right now the handicap of running xorg as user service is that it must be run with root privileges [...snip...] It seems likely that xorg could be modified [...snip...], and then it could run unprivileged from a user service outside a session.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)) that is
they could look
like thisDidn't we learn something from Makefiles here? Does that 'tab' look like 8 or 4 spaces to you?
When did that happen?
If you simply enable option in your editor to make white spaces visible (i . e. you can tell the difference between tab and space), the problem becomes silly.
I personally like to use tabs for indentation, because of huge flexibility being able to change tab size (which changes indentation) as needed, but that just me.
That strikes me as an even more valuable property for configuration, which is more often accessed by multiple people and tools and more often as a distraction from other work rather than the primary focus.
You or the other team of developers/maintainers/sys-admins looking over or patching this particular file. Using whatever default editor they prefer with whatever config an tabifying/untabifying behaviour that has.
Or maybe they are applying a patch produced on a different system with different tabulation? Or the other 2000 common ways for accuracy to go out the window.
> That strikes me as an even more valuable property for configuration
So you'd like to deliberately make the configuration system more brittle for absolutely no gain?
Yeah. Count me up for anything else. I personally prefer s-expressions, but I would be willing to go the full mile with pretty much any format NOT based on whitespace. Whitespace is bullshit and depending on it even more so.
I don't think you understand the philosophy behind FreeBSD: it's about creating a predictable and reliable OS. This goes against those goals. Simple as that.
I like Python but this is not actually true. you only need to be consistent within a block, or be more deeply indented than the outer.
You can have different indentations for the if and else clauses!
server
path: /core/www/
host: example.com
port: 80
service: true
proxy
host: proxy.example.com
port: 8080
authentication: plain
description
:Primary web-facing server
:Provides commerce-related functionality
server
...
proxy host="proxy.example.com" port="8080"
authentication: plain
Once parsed, element-style (first proxy node) or attribute-style (second proxy node) become identical nodes and are treated the same (but with a flag in case you want to write out a modified file): they are fully interchangeable, so no attribute vs element debates, just use what works best for readability. (This really is critical. Some document types would be ten times as long without attribute-style nodes.)
The syntax has no entities. foo="data" can capture any data that doesn't need quotes or newlines. foo: can capture any data that doesn't need a newline. foo\n:data\n:data can capture any data that doesn't need binary. foo\n:base64\n:base64 can capture absolutely anything.
Node names must be [A-Za-z0-9-.]{1,}, and are case-sensitive. The same node name can appear multiple times at any level, even at the root level. Ambiguity is resolved by the order of appearance for each node.
The data values of nodes are completely unparsed by the markup. The syntax knows no difference between strings, integers, floats, booleans, binary data, arrays, etc. The application parses the text however it wants. The library adds some convenience functions (.text() to strip surrounding whitespace, .integer() to get a number, .boolean() to decode true/yes/on vs false/no/off, etc.)
File format is mandatory UTF-8 (no BOM.) Preferred line feeds are '\n', but '\r\n' is also permitted because Microsoft.
The implementation in C is about 8KB. Since everything has a marker, allocations are not necessary for the node names/values (but you will need to allocate the tree structure, obviously.) There's an accompanying path query syntax (ala XPath) that's another 6KB of code or so.
(All the edge cases are well-defined (mismatched indentation, mixing multi-line and child nodes, etc), but the post is getting a bit long.)
This was the best I could do at minimalism. Removing any functionality it has results in ruling out many use cases.
http://akaros.cs.berkeley.edu/lxr/#akaros/kern/kfs/lib/ndb/l...
The limitation I see is, how do you store data values with spaces in them? If it allows quoted values, then how do you store values with quotes in them? And how do you store line feeds? Not having those rules out a lot of use cases.
Have you written a spec and promoted it at all?
I haven't really promoted it, I don't know how to promote my work tactfully (I tried promoting a few things on r/programming and the mods buried them right off the bat.)
I'd be very happy for any help in this regard, as well as for any suggestions on simplifying the parsing (the edge cases really are annoying to deal with.)
What's important is that it's easy to read and write. And that's yet another reason to standardize you language, so that you don't need to trade legibility over parseability, because you'll only need to write the parser once.
The only problem I see with that is that some programs use turing-complete configuration languages, while for most of them that'd be a bug, not a feature. One just can not standardize all *nix tools in one configuration language... maybe two, but not one.
Not only that. S-expr could be created automatically and run on the fly at runtime, new configurations could be added without restart of services, and Lisp has a well known powerful macro system. That way also "Python-ized" configs could be translated into s-expr easily. Such Lisp based configs could be run in a C embedded Lisp interpreter.
However, the FreeBSD team should at least seriously consider a new neutral logo. I wonder what BSD Unix has to do with the devil.
It's not a devil, it's a Daemon. Like, Unix daemons (httpd, ftpd etc.)
edit: paren'd
edit 2: been using bsd and linux for servers for the past 10 years, love both of them for different reasons.
This is the first time I've seen anyone comment on the FreeBSD logo like that. I thought it was hilarious
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.
IMO, using YAML for the config format is still the best option for most use-cases at this point. (Easy to support both json and YAML.) But I do think that it would be great to have a YAML successor that standardizes some of the cool things people are doing with custom YAML parses, and also removes outdated and unnecessarily complex parts of the original standard.
The key win for us is that all JSON is valid JSONY, so you can use the human friendly syntax for hand editing but still just dump out a JSON object into the file if you're generating the entire thing from code.
That said s-exp can be cryptic depending on how you design your DSL, but overall it's a 80% great to read and easy to process, plus chopping s-exp in s-exp aware editors (not pointing at some very old very large one here)
But that means I am truly ignorant - what, in fact, is the big problem with plain old unix-style config files ?
Note that I am not asking about what is wrong with how they are scheduled and run - I get that controversy. But what is wrong with the files themselves ?
I know I have absolutely hated every single interaction I have had with plists and launchd and whatever else on OSX ...
Like what? /etc/X11/xorg.conf is a different format from /etc/openldap/ldap.conf is a different format from /etc/crontab is a different format from /etc/nsswitch.conf.
Unifying configuration files under a single common format would allow for less complexity in configuration management tools - you could just create a data structure and serialise it to a file, rather than dealing with text-based templates with countless edge cases.
I'd love to see the One Config File Format To End Config File Formats that supports xorg, ldap, crontab, nsswitch, apache, and anything else. Sure, use something like JSON, XML, INI, or YAML for this, for which the format is regular and parsable with an off-the-shelf parser, but then the domain specific stuff just moves into, for example, the key names. You've gained nothing in terms of maintenance or automatic editablity, but you have gained consistent use of whitespace and punctuation characters.
"Creating a data structure and serializing it to a file" is doable text-based formats. Admittedly, templates are troublesome, but that's because you shouldn't be using templates anyway. Templates are an attempt to avoid understanding the domain specific language but still maintain the power of the domain specific language. I've never had good luck with this, which is why I mainly use configuration management tools, like puppet, to keep a fleet of machines in a consistent state by putting fully formed files in place. Templating takes significant care.
Yes, but that's because the DSLs actually provide something of value. Having umpteen different ways to store a list of values under a key, for example, doesn't solve anything.
> the domain specific stuff just moves into, for example, the key names
Anything that wants to manage the system already needs to know the key names, etc - implementing a single config file format is significantly reducing complexity because they no longer have to implement config file parsers/serialisers.
> I mainly use configuration management tools, like puppet, to keep a fleet of machines in a consistent state by putting fully formed files in place
These tools are currently primarily based on templating. If you ever have reason to write your own resources for them (if you have to edit a config file for something obscure or in-house), you're going to have to write a text-based template to convert from your nice Puppet data structure to the config file format - and probably get it wrong on edge cases.
1. Every program rolls their own format, so you end up with a bunch of custom rules for configuring each application on the system. This makes life tedious for anyone automating system management and, on a practical level, increases the chance of human error when someone forgets the precise ways in which their experience with something else isn't quite portable.
2. There are a wide range of supported features – e.g. interaction with environmental variables or external defines / defaults, ability to reference other config values, ability to either include a file or merge config parsed from a different location – and this leads to more tooling to paper over the gaps.
3. Hierarchy and discovery: in Windows or OS X, the preference system has the concept of user, system and domain config so you can set sane defaults at the domain level but a user can still override one of them just for their account. (There's another interesting tangent here where it's useful to have config supplied with a package which can be selectively overridden by a sysadmin without forking the entire file)
This works, at least for certain values of "works", because there's a single standardized API for working with the registry or plist files.
I generally dislike the details of plists but the fact that I can e.g. run "defaults read [scope] key value" and get the same effective config value which an application will use without knowing at which level it was last set or even whether the file was the older XML plist format or the newer binary one is really handy.
The fact that a config tool can simply run "defaults write [scope] key value" and not have to worry about those same mechanics is even nicer for sparing me time worrying about e.g. editing a text file safely, knowing whether I can just dump a new value at the end or must purge old values first (oops, FooD stops at first value while BarD uses the last and BazD does either depending on quirky rules you'll just have to learn…), etc.
Similarly, launchd has a regrettable config syntax but I've forgiven it at lot because it's a relief to use the same tool everywhere rather than needing the accumulation of different hacks and kludges which sysv init/cron or, absurdly, upstart still require in practice.
What would be really nice would be someone building a library with plenty of language which supported configuration based on the classic Unix config files but with a defined syntax and well-documented strategies for error handling and hierarchy and started working to help popular programs migrate over on the next backwards-incompatible release. There's certainly no technical reason why any of the good parts should require Apple's XML cruft or the accumulated bad culture around the Windows registry.
On *nix, system-wide config files are usually under /etc, and they can be often be overridden by dotfiles in a user's home directory.
One example of a way a user can override global/system configs without forking the entire file is using ~/.Xdefaults.
I hear you about there being no common standard, however. It would be nice if there was one good config file format to rule them all, that could please everyone.
But, since you can't please everyone, it's better to have choice than to have someone's (Microsoft's/Apple's/Ubuntu's) idea of "good" forced down everyone's throat.
Sometimes it's more about not wanting to spend another 5h on config files for some deamon on every new system you have. Using Ubuntu's or Apple's defaults is nice when you want something that works and let's you start getting shit done now.
It's not perfect, but it's a very good choice.
Yes, the sysadmin was clearly at fault. No, this is not a deal breaker, as seen by the longevity of Sendmail. But a config file that gets pushed through a preprocessor has a more complicated life cycle than a "static" equivalent.
If your organization has comprehensively embraced ansible/chef/puppet/etc this may be a non-issue, because all of your configs might be generated. Just food for thought.
Er, only if the application doesn't run the preprocessor itself.
Declarative configuration is great in theory but it doesn't scale well. See Amazon's CloudFront configuration files for what configuration in JSON looks like. (For example, https://s3-us-west-2.amazonaws.com/cloudformation-templates-...) It quickly gets hard to manage the syntax and balance all the quotes, parentheses, braces and brackets, with careful use of whitespace being critical for even a hope of understanding it. When you add in semantics, it gets even worse. Take the "Ref" construct in CloudFront to work around the fact that JSON doesn't have a way to name something and refer to it elsewhere.
As the amount of configuration grows, you have to introduce abstractions to encapsulate common patterns, break out of deep nesting, name things etc. I guess it's possible to do that declaratively, but that leads to things like XSLT. (Or, open the CloudFormation JSON linked above and search for "Fn::". It makes me shudder).
S-expressions would indeed be better than JSON, but they still wouldn't scale without macros. So either all programs would have to know lisp, or you need a dedicated program for executing the configuration.
That's what NixOS has. It does all configuration via "nix expresssions" which are written in a lazy, functional language. The functional bit allows for the abstraction necessary to make large amounts of configuration readable and maintainable. The lazy bit makes executing large configurations efficient, given that you're usually only interested in certain parts of it at any one time.
The result is that you can write a configuration that describes a cluster of machines from top to bottom: from how many app servers to put behind the load-balancer to which version of zlib to link node.js against.
It takes a bit of effort to learn nix, and for many, the functional paradigm will be strange and scary. But's so worth it.
At the least a universal API provides a midpoint to moving to a universal format.
It really deserves more attention and use!
(One possible reason that it's not is that people might find it a little user-hostile at first.)
It sounds like this guy, at least, is thinking of a lot of the problems and questions me and my coworkers have been facing re: system startup/service config, which is cool.
I didn't know who he was before, but I do now: http://en.wikipedia.org/wiki/Jordan_Hubbard
Co-founder of BSD, BSD Technology Manager/Director of Unix Technology for 12 years. Sounds like he has some relevant experience, I gather he was talking about the iPhone when he was discussing mobile devices, the IPC mechanism, remote debugging, etc.
Btw, that is likely both the source of the RTC alarm support. And also the source of the infamous bitcoin hitman hire quote. The latter came from the chat log of a community IRC channel related to Maemo/Meego/Mer/Sailfish.
EDIT: Toned down possibly inflammatory language
This is an infamous example: http://lwn.net/Articles/430598/ [gets particularly heated at mezcalero's top level comment]
Linux users make jokes at Windows' expense all the time. It's usually not higher profile developers doing it, but nor have they ever, really.
Free software doesn't need to even support free operating systems, for that matter. I'm sure that there are Windows-only apps that are F/OSS, though I don't know of any off-hand. Of course the systemd developers don't need to support any other OS to write "Free Desktop" software, any more then the FreeBSD developers shouldn't feel compelled to port their filesystems, init-system, or anything else to Linux.
Was this agnosticism part of the design?
And even if it was -- I suspect his experience has altered his view on it.
Rather, it's his patently false and almost obnoxiously smug view of the BSDs as these slow-moving operating systems that simply follow Linux's trail, and his deeper implications of forking being negative and that Linux should play a game of catching up against OS X and Windows instead of doing its own thing.
Then his reasoning against portability seems self-defeating. He says that "i need to reach customers using windows" is a good reason, in which case you can substitute "windows" with any OS and have a purportedly valid reason for portability.
Not living in an arrogant monoculture that seriously believes you're leading the pack and everyone else is biting your dust sounds like another good reason.
This is a nonsense false dichotomy.
And he clearly has a point; at its worst it is a giant ball of YAGNI.
Do you think that Thompson and Ritchie gave a !%^$@ about Multics compatibility? Or OS/360?
Correct. Unfortunately systemd is not a well separated 'stack' in the middle between kernel and applications but an interweaved network which tightly connects all three parts.
I hope that the community has learned from the SystemV/systemd discussion and will go a new way which avoids the weaknesses of both systems towards a cleanly separated layer.
I'm sure the BSD community can learn and can improve on the idea. Perhaps their result could be ported back to Linux as an alternative.
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.
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.
Well, watch the interview with Shawn Webb on BSD Now #52 http://www.bsdnow.tv/episodes/2014_08_27-reverse_takeover and think about his comments on OpenBSD. A lot of NIH in that interview. I don't think it is isolated to one side as you think.
You never can tell the future. This is a straw man.
apply some specific update across a bunch of machines
This is a bad idea anyway: the immutable server model seems to have been recognized as the way forward. See https://news.ycombinator.com/item?id=6705269 for reasoning.
or to catalogue the configurations each machine has
Again, immutable servers make this pointless.
I think, overall, given your examples you are clearly looking at the wrong tool (ssh or whatever plus systemd; a host-centric combined init system, process manager, log manager, and whatever else) for the job (managing multiple machines in disparate states).
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.
Of course, for automation or writing user-friendly interfaces, a unified format is better.
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.
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.
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?
- An automated dependency-driven and parallel init system → launchd, systemd
- An event notification system → notify, DBus
- Virtualization: VMWare for Mac, I guess, docker (LXC) for Linux
- Battery / ARM: a painful change for MacOS X first, then for Linux (when Android fought to improve it)
- Configuration: Mac is stuck with plist/xml (which, at this stage, is both a pro (single system) and a con (awkward system)), Linux is sadly behind. Having a configuration system is hard because many programs that want configuration wish to have a Turing complete one.
- GPLv3… well, MacOS X is actually behind on this one.
But, wait, isn't it Mac?
I don't buy it, which means many of his earlier points don't make any sense. e.g. Majority of FreeBSD machines running on battery.
Only standardising on a single format e.g. JSON.
additionally, for the vast majority linux systems that are actually embedded, BSD needs a solution for that.
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.
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).
It was irritating at first but ip is a better, more capable tool.
http://serverfault.com/questions/458628/should-i-quit-using-...
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)
It's also working on a set of Systemd shims as a replacement for systemd: http://www.phoronix.com/scan.php?page=news_item&px=MTc4MjQ
The only problem is that systemd is a bad piece ("piece"? Or rater "lot"?) of software.
That said, the proposed idea doesn't sound like something that is trivial at all, but rather pretty bug-prone. There already are de facto event engines for certain areas like device hotplugging (formerly HAL and now udev on Linux, devd on FreeBSD), whereas for a lot of other events in Linux software a typical way is to subscribe on an application's D-Bus interface and wait for signals.
Indeed, OS X's notify API looks precisely like a message queue from my brief observations.
But then there's certain events and classes of events (such as "network is up/network is down") that could have literally over a dozen meanings. I'm not sure how a practical centralized event broker could be anything more than a glorified message bus? Otherwise, encapsulating highly multi-faceted and non-deterministic system states into generic events sounds like bugs galore.
Not dbus? Because that + the notify api sounds... a lot like dbus.
The questions are:
* How much of that needs to go in PID 1?
* How much is required to go together? To what extent can the system be made more modular and separable?
* What allowances are going to be made for legacy operation modes?
The concerns I've got are too much being put into highly critical process space while issues are shouted down and/or disparaged. My sense is that the systemd ship is going to encounter the rest-of-linux ship and both are going to be significantly changed. It's quite likely that some key personnel on both sides will get ejected in the process. I'm not happy with the present course and state of affairs.
I've been using it in my Linux distro for at least a year. It works fine-- quicker startup, handles hotplug correctly, rational management of services, and easy to add new ones.
I'm sorry, there is no nice way to say this, but the systemd truther crowd is a lot like the Obama birth certificate crowd, or the anti-vaxxer crowd. Repeating the same discredited arguments over and over. And for the most part, composed of people who have no experience in what they're talking about, so why should their opinion even matter?
Lennart's only mistake was to be bad at public relations and rather blunt about what he said in public. (I, on the other hand, can afford to be blunt because I'm just an anonymous guy, not a project manager).
The "it works for me" fails to address those for whom it hasn't worked. Which includes, I'll note, any number of people who might generally be considered somewhat past beginner status with Linux: Alan Cox, Ted T'so, Bruce Perens, John Goerzen, among many others: http://www.reddit.com/r/linux/comments/2dgy45/if_systemd_is_...
Equating them to Donald Trump and a mob of Koch-backed disinformation shills isn't simply wrong, but trolling, of the level of Donald Trump and a mob of Koch-backed disinformation shills.
I'll note once again that the focus on insults and lack of addressing specific points and issues really cheapens the case for systemd, and its proponents.
If I've established that someone isn't exercising good faith, I'll change course. Particularly if they spout disproved statements on exceptionally well-established points (scientific or similar topics, generally). There's enough genuine grounds for disagreement on the systemd debate (though yes, there's FUD as well) that blanket dismissals strike me as inappropriate.
That said, yes, refuting frequently-raised points gets tedious.
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.
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.
Sorry, I misread the release table. Then, that is pretty impressive, 6 years for a major release!
Why would want to run 10 year old binaries if a compatible and improved version exists?
Personally, I don't but in many enterprises a new stable release is often only introduced after a 1-3 years. Then it is to expensive if support runs out quickly.
When I was involved with CentOS (ca. CentOS 4 & 5) era, there were still many companies running 2.1 and 3.
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...
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!