FreeBSD: the next 10 years(slideshare.net)
slideshare.net
FreeBSD: the next 10 years
http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years
178 comments
> It's a shame FreeBSD doesn't maintain an integrated or official graphical interface.
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
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
> hey - it's the only OS in the world allowing you run Xorg as an unprivileged user
Wait, what?
https://imgur.com/ZrdgN1H
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.
Wait, what?
https://imgur.com/ZrdgN1H
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.
I could be wrong, but I was under the impression that that wasn't the case?
https://wiki.archlinux.org/index.php/Systemd/User#Xorg_as_a_...
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.Thats in the context of using xorg as a systemd user service. You can run startx as a normal user and have the server run unprivileged just fine.
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!).
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!).
> 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.
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.
>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).
You'd be surprised. Just listen to the arguments against giving Linux a more logical directory setup (somewhat like OS X's).
How is OSX's directory setup more logical than the traditional Unix one? Be careful not to confuse your familiarity with one system with it's inherent qualities.
I have switched between BSD an Linux as my main desktop OS a few times and had this "damn, this is so much clearer in x" feeling in both directions.
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.
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.
> Great ideas but ...
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.
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.
> The trick was that when Gtk/Gnome came out there was no existing solution. So, even a bad one was okay.
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.
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.
Mogrief was a non-starter due to license. Lesstif was a pile of fail forever. Athena widgets? Are you trolling me? See Xfig for an example of how bad those are.
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.
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.
"That's also why Ubuntu is so reviled in some Linux circles..."
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 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?
In my opinion, parcelling out software development in a modular way doesn't work that great neither if you don't have guidelines, api definitions – community enforced styles of doing things.
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...
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...
I would suggest it is democratic - there is and always has been a tension between our elected officials bein our representatives and our delegates.
The same goes for any democratically appointed UX team.
The same goes for any democratically appointed UX team.
Yes your right. But i'm swiss, so a lot of countries dont really feel democratic to me:) Not enough power for the people – too much for those elected.
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.
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.
I thought the UK was the only one insane enough to think human rights were a pick and mix. I recommend Conor Gearty on why the Uk should not pull out (LSE podcasts on iTunes)
We're not directly voting against it. The referendum is carefully titled "Swiss law before foreign law" which would include the human right convention among every international law. The Advocates emotionally argue that the swiss should never be dictated by foreign judges, we can perfectly handle everything ourselves. Unfortunately a lot of people in Switzerland live on ivory towers, thinking their better than everybody else on the planet and agree with that statement.
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.
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.
The modern marketing machine has indeed done a number on democracy. And with marketing being related to money, and money invariably congregating on the right, well...
Perhaps the reason pulse and gnome were disliked has something to do with distros that don't support the old versions after a new one comes out and foisted unfinished buggy releases on their users before either was ready for prime time?
You need to take a few steps back to fully understand the so called systemd controversy.
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.
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.
There are already several alternatives to systemd, starting with the systems that systemd is replacing that have worked well for years.
That comment sounds like you either don't know what systemd does or are just trolling. If you want to have a constructive conversation, talk about how something which is tedious in e.g. SysV init is better solved by OpenRC/Upstart/launchd/SMF/etc. rather than systemd. (Repeat for any other aspect of interest)
How can he possibly be trolling? He's pointing out that the existing systems work fine and have for years, and that's the full extent of his post. This is why people hate systemd: the hordes of people who do personal attacks on anyone who even disagrees with them. You're doing it right here: anyone who disagrees with you is a troll.
> He's pointing out that the existing systems work fine and have for years, and that's the full extent of his post
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?
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?
The unresolved problems of SysV don't automatically make the systemd approach right either.
Just because those are the stated reasons for developing systemd, that doesn't mean that those are the actual reasons, nor does it mean that other init systems don't work (even though they could be improved - into, say, OpenRC).
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?
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?
We must remember that the BSDs in particular exist in a reality where you can issue a single source control checkout command and you have the whole tree literally to do anything you want with, most of it even with a license amenable to anything.
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.
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.
As an additional point: in the spectrum between centralization and decentralization, there's a clear difference between Linux and FreeBSD. This is what I highlighted in my post: FreeBSD's greater degree of centralization seems to me to be more efficient and leading to a better integration. That much is a correct observation.
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.
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.
That's a fair point. When I wrote "centralization" I mainly meant components rather than development model. Systemd is very "centralized" in that a single package does a lot, but Linux as a whole is very decentralized in development model. BSDs are "centralized" in the sense that they have a single tree in source control, but the main result is a rather small, very configurable base system. (Then you deal with ports and packages on top, which feels more like a Linux distro: scripts that pull distfiles from lots of different sites and apply patches; not unlike the experience of building a .deb from source.)
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.
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))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.
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.
Link for the lazy https://github.com/toml-lang/toml
There's also http://p3rl.org/JSONY which is explicitly "JSON re-imagined for configuration files" by myself and ingy (the creator of YAML).
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.
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.
Can you give some examples of TOML-based Rust package configurations that you think are good? My experience using TOML for config files has been very different.
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.
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.
Is there some reason for the commas in lists? I'm starting to like s-exprs more and more for configs and am starting to think it might be because of a lack of love for commas.
It just seems that TOML (and similar formats) would be more of an interface rather than the configuration itself.
NixOS got this right.
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.
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.
Could you give an example of a NixOS config file that contains as much complexity as the CloudFront JSON config file, but does so in a more readable way?
Take a look at GUIX (GNU Guile ~wrapper~ around Nix) http://www.gnu.org/software/guix/manual/guix.html#Programmin...
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)
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)
I've (purposely) ignored the config files and systemd wars.
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 ...
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 ...
There are two things which I've heard a lot:
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.
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.
"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)"
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.
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.
>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.
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.
> plain old unix-style config files
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.
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.
And yet elsewhere, domain specific languages are preferred.
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.
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.
> And yet elsewhere, domain specific languages are preferred.
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.
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.
Best i can tell, they don't play well with GUI config tools...
The YAML format mentioned in the slides actually has the least syntactic clutter, however the parsing is quite difficult
Well, that's why you use a library.
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.
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.
Because it simply is too complex for a format that emphasizes easy readability. Some easy-to-grasp subset of YAML might be a good choice.
I came up with such a format (called BML) and for the same reasons. Here's an example that shows the entirety of the syntax:
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.
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.
quite similar to plan9's config style
http://akaros.cs.berkeley.edu/lxr/#akaros/kern/kfs/lib/ndb/l...
http://akaros.cs.berkeley.edu/lxr/#akaros/kern/kfs/lib/ndb/l...
Haven't seen that before; indeed it is similar. I quite like that.
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.
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.
hmm, I can't remember about spaces and you would need them for txt records. I cand find anything in the documentation, i'd have to do some tests
I really like this. Wish it would be widely adopted in place of YAML.
Have you written a spec and promoted it at all?
Have you written a spec and promoted it at all?
Thanks! I did write up a spec (currently not online after a host move), but I'm very bad at expressing grammars with eg EBNF, so it was a fairly verbose read.
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.)
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.)
You can bypass the issue by using the amazing Augeas project; a universal configuration API. http://augeas.net/
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.)
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.)
JSON is clunky, it's true, but it has advantages. It's very, very widely supported. There is no format versioning, there are no dialects, there is only One True JSON. It's incredibly minimal and supports no more, and no less, than it needs to.
It's not perfect, but it's a very good choice.
It's not perfect, but it's a very good choice.
But JSON doesn't support comments which are pretty nice in a config file. You can do the ugly comment as property stuff, or strip them out, but you're getting away from the One True Format.
That's true. You could standardise on JSON with comments removed by JSMin... The underlying data would still be standard.
Consider Sendmail as a cautionary tale. One more than one occasion I have seen a busy sysadmin manually edit a .cf file and forget to backport the edit to the .mc file. The next time someone regenerates the .cf from the .mc you have a vanishing edit.
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.
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.
> 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.
Er, only if the application doesn't run the preprocessor itself.
Er, only if the application doesn't run the preprocessor itself.
OpenBSD solution has been to use "pf format" config files for as much as possible. They're all different, but immediately intelligible to anyone who's seen any of them before.
Would be even cooler if "Python-ized" (i.e. if spacing mattered):
that is
they could look
like thisSignificant whitespace in configuration files... what could possibly go wrong.
Didn't we learn something from Makefiles here? Does that 'tab' look like 8 or 4 spaces to you?
Didn't we learn something from Makefiles here? Does that 'tab' look like 8 or 4 spaces to you?
Same that goes wrong in Python: Nothing. As long as tabs are outlawed, anyway.
I see many people continuing holy wars between tabs and spaces, even to a point to dismiss specific technology because of it.
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.
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.
It doesn't really matter which it is, as long as it's one of them. Spaces are more copy-paste friendly though.
> As long as tabs are outlawed, anyway.
When did that happen?
When did that happen?
Tabs look like a light grey arrow in any editor I care to use.
This is mentioned a lot by Python newcomers but rarely turns out to be a problem in practice because, unlike GNU Make, Python simply requires you to be consistent throughout the same file.
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.
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.
> Python simply requires you to be consistent throughout the same file.
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.
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.
If your team can't pick a single style and stick with, it is exceedingly unlikely that whitespace will be your biggest source of problems.
So your argument is that because you should be doing $X anyway, let's make the entire OS's configuration system needlessly brittle, just because you're a python dev and like python's style.
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 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.
My point is that I've rarely found "predictable and reliable" to hinge on whitespace convention. The Python mention was simply that the same category of complaint comes up frequently in reference to the language but is so rarely an issue in practice that it's not worth discussing.
> > Python simply requires you to be consistent throughout the same file.
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!
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!
That’s basically YAML (that they mentioned as a possibility). http://yaml.org/
They were suggesting an api for it as well. Who cares what the format is if you access it programmatically?
As much as people make fun of Java for putting abstractions over implementations this is a situation where I would love to see something like this. We can always switch to the hot new data format with something like this.
[deleted]
> Personally, I think the nicest and most expressive way is S-expressions.
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.
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.
> 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.)
It's not a devil, it's a Daemon. Like, Unix daemons (httpd, ftpd etc.)
An evil daemon is worse than the devil (sarcasm)
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
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
You "BSD devil" trolls are really not putting in much effort.
why, the goal and purpose of the FreeBSD Unix is to agitate 1600s-style cavemen of course.
Audio from the talk:
https://archive.org/download/bsdtalk247/bsdtalk247.ogg
https://archive.org/download/bsdtalk247/bsdtalk247.ogg
Video from the talk:
http://youtu.be/Mri66Uz6-8Y
3D virtual-something from the talk, anyone? ;)
Thanks, I went through the slides and then found this. Contrary to some of the other posters I actually found it kind of interesting.
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.
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.
Likely, as Jolla is using systemd on their Sailfish powered phone.
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.
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.
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.
Yeah, when the Linux phenomenon was new, they used to make just as bad (or even worse) jokes at Windows’ expense. But they don’t anymore. Why is that? Maybe they gained enough acceptance that they don’t feel they have to, anymore. In that case, the fact that FreeBSD still does this is a symptom that FreeBSD does not view itself as having gained common acceptance.
EDIT: Toned down possibly inflammatory language
EDIT: Toned down possibly inflammatory language
Have you ever read some comment sections on Phoronix and /r/linux (or even LWN) when BSD is brought up? The lighthearted licensing jabs we see here are nothing compared to the vitriolic disinformation that is regularly seen when uninformed Linux users try to talk about other operating systems.
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.
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.
I think it's worth noting here that mezcalero is Lennart Poettering. His attitude is a seriously bad one if he's supposed to be one developing Free Desktop software.
Funny how LWN.net seems to be the one place where he is willing to stick his neck into discussions he don't control.
Portability is clearly important to him in the sense that it's brought up as a reason for him not have this or that feature in his software.
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?
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?
Why do you call his attitude seriously bad? I agree with him, portability leads to complexity and therefore isn't worth it when you are trying to move fast. You may disagree that OSS should move fast, of course, but why should you want to slow down others?
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.
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.
Because he's a developer for more than Linux services, he's also a developer for software like PulseAudio, which is supposedly meant to be kernel-agnostic. That is why I said Free Desktop software, not Free software. If he wants to restrict his viewpoint to the Linux kernel, that's his problem, but if he does, then he needs to stop pretending that he cares about Free Desktop environments and state that he's a Linux Desktop developer.
> PulseAudio, which is supposedly meant to be kernel-agnostic
Was this agnosticism part of the design?
And even if it was -- I suspect his experience has altered his view on it.
Was this agnosticism part of the design?
And even if it was -- I suspect his experience has altered his view on it.
It's not so much his opposition to portability that bothers me personally, which I personally disagree with and think that it should be strived for to a reasonable degree.
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.
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.
> You may disagree that OSS should move fast, of course, but why should you want to slow down others?
This is a nonsense false dichotomy.
This is a nonsense false dichotomy.
A herd is only as fast as their slowest member.
I saw a joke about the GPL and comment on systemd? GPL joke was unnecessary, though it does comment on why companies may prefer *BSD; the systemd bit - well threads passim here on HN say Linux users are tearing themselves apart enough without help. And I read it as that Linux is onto something good here and FreeBSD should follow.
Slides 21 to around 30 seemed like an argument for something like systemd - a 'stack' in the middle between the kernel and the applications. I saw it as a back-handed compliment. One has to remember that the slides supported a talk and talks need a little humour sometimes.
> argument for something _like_ systemd
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.
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.
At this point there are at least three fairly major "post-sysV" integrated launch/supervision/config systems that I would guess the FreeBSD devs will take away some lessons from (especially because I know there are FreeBSD devs with experience using each of them): Linux's systemd, Solaris's SMF, and OSX's launchd.
Perhaps I should have said 'something like' and qualified the differences.
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.
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.
Seeing as he explicitly referenced launchd, I'd say it was an argument for something like launchd, NOT systemd.
This was my take on it as well.
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.
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.
> 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.
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.
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.
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.
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.
It makes plenty of sense when you consider who OpenBSD's actual competition is. Hint: They aren't trying to target the desktop market.
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.
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.
I agree - kind of. You have to have a standard - make.conf for example is just systemd for the 90s.
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.
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.
You can't, for example, write a tool to safely update a config file to work with a new version of the software
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).
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).
"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.
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.
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.
Of course, for automation or writing user-friendly interfaces, a unified format is better.
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.
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.
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.
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.
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.
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?
Jordan Hubbard only recently left Apple. I suspect he is trying to avoid suggesting only Apple solutions for FreeBSD problems.
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?
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?
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.
Regarding “A centralized event notification system”, I predict that D-Bus will soon have this position in Linux, certainly when kdbus lands.
I honestly thought that was already the case. In fact, much of what the speaker wants are things that play catch-up.
- 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.
- 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.
> My dream laptop has evolved (BSD instead of Windows) (15th slide)
But, wait, isn't it Mac?
But, wait, isn't it Mac?
It's a stock photo: https://www.google.com/search?tbs=sbi:AMhZZivX9JS-QLEbVyc-hN...
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.
He is, throughout the talk, presenting the case that iOS and OS X are really BSDs, and somehow nearly FreeBSD, so somehow relevant.
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.
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.
He said UNIX machines, not FreeBSD specifically. He was talking about Android and iOS.
"Even the linux die-hards have essentially grasped the necessity of systemd (Even though they're going to hate on it for awhile longer)"
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.
additionally, for the vast majority linux systems that are actually embedded, BSD needs a solution for that.
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.
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.
There's been a bit of revolution in OpenBSD as well, just smaller ones. OpenSSH, PF, and now LibreSSL were all fairly rapidly developed at inception due to issues with the original projects they replaced. They made it into the base system within 1 or 2 releases (every 6 months in OpenBSD), so there's no reticence to change or rapid development. However, they did take care to limit the projects to a well understood, readily achievable scope thus allowing them to ship on time (what a novel concept in software development!). OpenBSD also pioneered some major concepts in modern OS design such as privilege separation which has since been adopted by most other comparable operating systems. Yes, they do an excellent job of maintaining consistency, but a lot of that has to do with good design and careful choices, and not because they've avoided change.
OpenBSD has a remarkable history of identifying key and crucial elements and providing replacements on its own where necessary.
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
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
> 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).
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).
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-...
It was irritating at first but ip is a better, more capable tool.
http://serverfault.com/questions/458628/should-i-quit-using-...
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)
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)
NetBSD is your traditional BSD for embedding. With nothing like systemd... give it a try.
OpenBSD does not seem to have any interest in systemd-lookalikes.
For me at least the problem is not the basic "trigger A on event B", but the whole jungle of systemd-*d's that have sprouted and their tight coupling to systemd-as-pid1.
Linux (and yes, FreeBSD) really needs something that provides that kind of functionality. It needs this so much that distros are wiling to put up even with systemd to get it.
The only problem is that systemd is a bad piece ("piece"? Or rater "lot"?) of software.
The only problem is that systemd is a bad piece ("piece"? Or rater "lot"?) of software.
I can't comment on whether or not it is bad, it is badly designed and re-invents wheels that did not need re-inventing whilst re-introducing bugs from the past. The role of systemd may be a good one, the design and implementation have nothing to do with the role. But with systemds role being defined as 'anything we can grab' there is no end to what will be sucked up into the black hole and re-implemented in a half-baked manner.
The architecture he describes, that of an event broker, sounds a lot more like Upstart than it does like systemd, though.
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.
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.
> The architecture he describes, that of an event broker, sounds a lot more like Upstart than it does like systemd, though.
Not dbus? Because that + the notify api sounds... a lot like dbus.
Not dbus? Because that + the notify api sounds... a lot like dbus.
As much as I don't like how an entire monolithic tightly-coupled complex systemd infrastructure is being crammed down the Linux pipe, and as much as I've argued against it in the past few days here on HN, there are some useful things out of systemd.
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.
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.
It's quite likely that you and the other "systemd truthers" will forget all about this in a year or two and systemd will continue just as it has.
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).
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).
Are the slurs really necessary?
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.
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.
The problem is really that there are so many FUD-filled talking points and conspiracy theories about systemd going round in circles that it's hard (at least for me) to tell whether somebody makes a genuine argument in good faith, if they also happen to mention what sounds like one or more of those talking points.
And that's why I make a very strong point of attacking points and, in cases, ideologies, rather than individuals.
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.
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.
I find it alarming that releases are EOL after 1 year, whereas RedHat Linux releases are supported for 10 years.
[deleted]
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.
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.
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.
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.
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...
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...
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!
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!
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.
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.
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.
I don't think that's entirely true. I've been told you can get support for older RedHat point releases but you have to pay RedHat an obscene amount of money.
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.