# FreeBSD proliferation



## gofer_touch (Nov 15, 2015)

A question that has had be quite interested for some time, but one that I could never truly find a satisfactory answer for, was why has FreeBSD been so successful in its proliferation compared to the other BSDs? 

I know that OpenBSD code has managed to to get in some pretty important corners of the web, networking infrastructure and so on. I know that NetBSD has in the past been used in scientific computing and if I recall correctly it is the basis for Apple's time capsule. DragonflyBSD has a number of very interesting technologies, but I haven't really seen wider adoption.  

It is only FreeBSD that seems to have been the basis for products that are at the core of some extremely valuable companies. The list is long. What are some reasons for this besides the usual stuff like the BSD license and a relatively large and stable developer base...which other BSD's could be said to also benefit from via the wider BSD community?


----------



## sidetone (Nov 15, 2015)

Something that stopped me from using NetBSD is my network card driver crashed boot up, until I would physically remove the card. FreeBSD has companies investing in making sure theirs, and a few other network cards work.

I read a book on OpenBSD, it said it is for people who know what they're doing, and that their community doesn't assist people who have questions on how to set up their operating system.

I tried Dragonfly, and it's differences in configuration from BSD weren't documented enough. Either I set up my network configuration wrong, or it's network abilities aren't stable. It worked, but it kept disconnecting, but I've had problems like that in FreeBSD too.

There is something I like from other BSD's plus Minix, but none of them have it all together. Eventually they will, and other BSDs and UNIXes can benefit from it too.


----------



## Beastie7 (Nov 15, 2015)

gofer_touch said:


> A question that has had be quite interested for some time, but one that I could never truly find a satisfactory answer for, was why has FreeBSD been so successful in its proliferation compared to the other BSDs?
> 
> I know that OpenBSD code has managed to to get in some pretty important corners of the web, networking infrastructure and so on. I know that NetBSD has in the past been used in scientific computing and if I recall correctly it is the basis for Apple's time capsule. DragonflyBSD has a number of very interesting technologies, but I haven't really seen wider adoption.
> 
> It is only FreeBSD that seems to have been the basis for products that are at the core of some extremely valuable companies. The list is long. What are some reasons for this besides the usual stuff like the BSD license and a relatively large and stable developer base...which other BSD's could be said to also benefit from via the wider BSD community?



You might want to check out George Neville-Neils "not a Linux distro" video. He addresses questions like that and explains why.


----------



## gofer_touch (Nov 15, 2015)

Beastie7 said:


> You might want to check out George Neville-Neils "not a Linux distro" video. He addresses questions like that and explains why.



Quite a nice video! George Neville-Neil seems to be quite a guy. It did answer a lot of questions that had. FreeBSD is pretty awesome.


----------



## Beastie7 (Nov 15, 2015)

Yeah, he's a cool dude. I'm a huge fan of his work on networking.


----------



## NewGuy (Nov 16, 2015)

While I agree FreeBSD is probably the most widely used on the desktop and server, I would like to point out that pieces of other BSDs are perhaps more widely spread. For example, OpenSSH is used virtually everywhere (Linux, OS X, other BSDs and it's even spreading to Windows). OpenSSH grew out of OpenBSD, though it's now more or less independent.  The same applies for technologies like LibreSSL which started in OpenBSD and will probably soon be used by just about every BSD and Linux project.

So while OpenBSD as a whole might see less wide spread use than FreeBSD, I would argue pieces of it grow break off and become more popular than just about any single OS.

As to why FreeBSD is relatively so popular, I think it comes down to its wide focus. FreeBSD is a pretty good general purpose operating system and does well in a lot of areas (file systems, security, portability, documentation). Other BSDs might be better in one specific area (NetBSD is super portable, OpenBSD is very well documented and secure), but on balance I think FreeBSD offers the best combination of features, documentation, security, portability and performance.


----------



## Oko (Nov 16, 2015)

NetBSD hopes for wider adoption have been dished around 2004-2005. Namely it was wildly speculated that NetBSD will be picked up as a based for new Google mobile OS. Unfortunately Google surprised everyone by acquiring Android, Inc. and betting its future on at that time inferior embedded OS (Linux) ridden with copy left license. After that the only serious consumer of NetBSD was  Japanese company  Wasabi Systems which went out of business 2009 but not before doing one great thing for humanity. Namely they released WAPBL Journaling file system (in traditional sense of that word) which is specifically tailored for embedded devices.
These days there are few smaller Japanise printer manufacturers who use NetBSD as the OS for their printer controllers. Other than that NetBSD is practically hobby project typically used for retro hardware. NetBSD annual budget is less than 30K which is far less than what other BSDs spend for electric bills alone.

DragonFly is an interesting story IMHO. Namely they have business friendly license and the most advanced file system in existence which happens to be light weight and ideally suited for desktops. I will speculate that Apple which has serious problem with the file system could port HAMMER1 or HAMMER2 to OS X. As many of you know HFS is not upper/lower case aware + plus that quick dirty hack which enables the file system which is designed for big-endian (PowerPC) to run on little-endian (Intel). HFS also suffers serious penalty performance on multi users environments as it is really designed to read and write one file at the time.  HAMMER which doesn't have ZFS licensing problem could be ideal FS for Apple. Maybe they are waiting to see what happens with HAMMER2. That would be really quantum leap comparing to what other proprietary desktop vendors have to offer.


----------



## fernandel (Nov 16, 2015)

Oko, here is the link for you:
http://www.netbsd.org/gallery/products.html


----------



## Oko (Nov 16, 2015)

fernandel said:


> Oko, here is the link for you:
> http://www.netbsd.org/gallery/products.html


Thanks for the link. I am aware of that link. I am not sure what was the purpose of pointing it out. If you look for example "Sortware products based on NetBSD*" * you will see half of that things are obsolete. It doesn't change my personal assessment of the state of NetBSD project. NetBSD is in sorry state more so than any other BSD


----------



## Oko (Nov 17, 2015)

TeamBlackFox said:


> I think FreeBSD is the best of the BSDs at the minute due to its documentation and hardware support


I am not arguing with people's opinions and what they thing it is the best. However you are wrong about hardware support and documentation. OpenBSD has better documentation (man pages) than FreeBSD and equal or better hardware support with the exception of hardware RAID cards were FreeBSD has the edge. OpenBSD also works on far more architectures (over 20) than FreeBSD which until recently (significant work on ARM platform) was more or less (i386/amd64 OS only). FreeBSD focus on i386/amd64 was the original reason that many of old UNIX people like myself preferred NetBSD which worked on UNIX hardware in early nineteens.



TeamBlackFox said:


> as it stands, no other BSD works on such a wide variety of hardware so well. And while I love OpenBSD, the giant locked kernel inhibits multicore performance necessary for a lot of modern tasks and I think most of its security comes from its shipment in a locked down state.


While you are right that giant lock inhibits performance you are wrong about the role of giant lock in the security. It is true that systems without giant lock are more tricky to secure but that is not the reason that OpenBSD is so secure. There was a wonderful post by a French system admin about a year ago comparing Open and Free security. There has being a significant recent effort on removing Giant lock from OpenBSD kernel, making network truly multi-core aware and also PF. While OpenBSD might never get to the FreeBSD level of performance (FreeBSD was always about optimization) many people myself included think that taking  3% or even 5% performance penalty (I am talking about commodity hardware not high end network storage gear where Free might have significantly better performance) is worth of all that extra security. People who are casual desktop computer users are unlike to notice any serious difference between Free, Open or for that matter any other BSDs (Net, DragonFly). I would argue that from the point of casual desktop computer user lack of advanced file system like HAMMER or ZFS is by the far the most important reason why would one chose not to run OpenBSD. Finally if I need to use empirical method to compare the speed of BSDs, DF wins hands down


----------



## sidetone (Nov 17, 2015)

Oko said:


> Namely they have business friendly license


 Not really, because of DragonFlyBSD's choice of GCC.



TeamBlackFox said:


> I may switch to DFBSD one day, but I'm less inclined to for their willingness to use GCC and other non-BSD-friendly tools in their packaging


I agree with this, but I'd use it anyways if their network drivers and configurations were reliable.



TeamBlackFox said:


> DFBSD continues to be a neat project, but I don't see eye to eye with the developers on their priorities or choices.



There's something I like from other UNIX distributions, (such as NetBSD's clean code, or DragonFLY's or Minix's hybrid kernel) but at the moment, the distributions don't work for me. Those benefits from other distributions aren't a necessity, while FreeBSD simply works better.


----------



## Oko (Nov 17, 2015)

TeamBlackFox said:


> When I say FreeBSD has support for the widest range of hardware, I do assert my stance for x86 at least, I should have properly qualified that statement. While it does not have as many platforms, and the non-x86 ones are subpar at best, it has the widest GPU support and commercial/proprietary driver support. This is because of Nvidia's support for FreeBSD, and the presence of various proprietary drivers, some of which overlap on the other BSDs, but not to the same range. Therefore, it is most accessible to new users and easier for most users to get going and running as they like.


We can go back an forth all you want with this. The best graphics support has DragonFly thanks to hard work of French developer Francois Tigeot






closely followed by OpenBSD. FreeBSD until recently supported only VESA on modern video hardware (sorry I don't count NVidia binary blob). While I will concede that at work I have to run NVidia binary crap to be able to use Tesla K80 (CUDA on RedHat) I get paid for it. When I don't pay to use computers I would not touch a computer with NVidia binary blob even with a broomstick. FreeBSD has at best limited (an example is LSI Logic's MegaRAID controlling software) at worse non-existing vendor support (no MATLAB, Mathematica, Maple is just non-starter for an academic desktop at work). Other BSDs have zero vendors support.



TeamBlackFox said:


> I may switch to DFBSD one day, but I'm less inclined to for their willingness to use GCC and other non-BSD-friendly tools in their packaging, their outright 'we're not supporting non-x86 stance' whereas the other BSDs at least make an attempt to at some level, and its lack of support for Nvidia dealbreaks it for me, as I have a fanatical hatred for AMD due to shitty R&D and driver support and while Intel is pretty good, I still prefer the flexibility of a dedicated graphics card.


HAMMER is 64bit only file system so there is no point in supporting i386. You might as well use FreeBSD 4.8. DragonFly BSD has no packagings system. They use DPorts which are just FreeBSD adopted port three. There is a non-trivial number of FreeBSD ports which don't compile on DragonFly (collectd was a deal breaker for me). NVidia is close hardware. If you like that hardware you have to chose supported platform. FreeBSD happens to be at the moment one of those supported platforms (up to certain extend since NVIdia doesn't support CUDA programming on FreeBSD). I am not arguing about AMD. What is wrong with Intel graphics?



TeamBlackFox said:


> The performance between Free and OpenBSD on non-multithreaded applications is likely to be very similar, but anytime you need a kernel routine or syscall there's going to be a performance penalty due to giant locking. I'm not saying OpenBSD isn't practical as a desktop, but it isn't ideal for my use case, but for a server or network appliance, its worth a look. For network intensive, i'd probably use FreeBSD though.


Far enough. I will give you another reason to stick with FreeBSD. Diversity is the great enemy of the productivity in the server room. If you are running FreeBSD as a storage OS where Open has nothing to offer at the moment for more serious enterprise deployment  you are more likely to stick with Free for other roles. Personally obsolete PF, lack of IPSec (in the base system), and portable OpenSSH version as oppose to native  is just too much for me to swallow. I could care if FreeBSD/IPFW outperforms Open on 20 gigabit network. I like most other people don't have such network. I have mostly 1 Gigabit slowly migrating to 10 Gigabit network. In such environment Open preforms reasonably well.



TeamBlackFox said:


> DFBSD continues to be a neat project, but I don't see eye to eye with the developers on their priorities or choices.


Fair enough. Personally I am scared how few developer work on DF. If you check their mailing lists you will see far greater community enthusiasm prior to HAMMER and early in the HAMMER life. Their mailing lists are mostly silent now.


----------



## Oko (Nov 17, 2015)

sidetone said:


> Not really, because of DragonFlyBSD's choice of GCC.
> I agree with this, but I'd use it any ways if their network drivers and configurations were reliable.


DF guys tend to be very Linux tolerable  I would cold heartedly agree with  your second argument. I tried to use DragonFly very hard at work but between the lack of developers and "unstable" base it was terrifying experience putting my livelihood on the line. Hopefully once HAMMER(2) is finished they will stabilize the base. Until then it is a cool thing but not worthy a serious risk.


----------



## kpa (Nov 17, 2015)

Oko said:


> DF guys tent to be very Linux tolerable  I would cold heartedly agree with  your second argument. I tried to use DragonFly very hard at work but between the lack of developers and "unstable" base it was terrifying experience putting my livelihood on the line. Hopefully once HAMMER(2) is finished they will stabilize the base. Until then it is a cool thing but not worth serious risk.



I haven't really taken a look at DF recently. Is it that they are stuck with the old 4.2.1 GCC just like OpenBSD is (and FreeBSD before the CLang import) or are actually using a newer GCC as a system compiler?


----------



## Oko (Nov 17, 2015)

kpa said:


> I haven't really taken a look at DF recently. Is it that they are stuck with the old 4.2.1 GCC just like OpenBSD is (and FreeBSD before the CLang import) or are actually using a newer GCC as a system compiler?


DragonFly is already using GCC 5.1. as a system compiler.  Check out the latest snapshots. I use 4.9.2 for developing on OpenBSD but you are right system is compiled with 4.2.1. Interestingly enough I see lots of activity with LLVM on OpenBSD these days. I would not be too surprised to see that thing becoming OpenBSD system compiler on supported platforms. My hope was that PCC will be resurrected but that effort went nowhere.


----------



## gofer_touch (Nov 17, 2015)

Wow, this has spiralled into something quite interesting.

I tend to follow the the FreeBSD and DragonflyBSD projects. Mainly because I use NFS rather extensively and both offer high bandwidth performance and filesystems which make working with large storage systems and backups easier. 

I'll chime in on a few items that I've found to differ from what has been said above.

Dragonfly's web-based documentation is dated, its true but their man pages are very good. What FreeBSD has in its corner is the fact that there are so many more users and those users have blogs, websites and BOOKS(!) which offer far more literature for the beginner up to the advanced user. This is a BIG plus for FreeBSD...its documentation is not only more widespread it is more diverse.

As far as Dragonfly going GCC 5.1, it typically has two compilers in base and the system currently does build using LLVM/Clang. I imagine they will make the switch when they are good and ready. They tend to make design and maintenance choices that are suitable for a small team (which they are). FreeBSD can probably switch to different compilers all day long and deal with the fall out more elegantly because there are far more developers and far more users which report issues (not to mention companies that also report issues and pay developers to fix things).

As far a DF being unstable, LOL!, the DF base is extremely stable. Even the master branch (i.e. current) is stable for day to day use and there are those that even run it in production environments. Any issues that are discovered are reported via the mailing lists by the team and promptly looked into. In particular there have been a lot of changes in the graphics stack, but issues get fixed quickly.

There is also an ARM64 port of Dragonfly in the works. If you have time, hang out over at EFNet #dragonflybsd, a lot of things are discussed among the developers (which all hang out there). They are easily accessible. The mailing lists are in fact usually quiet.

I've done some dabbling in OpenBSD as well. It is a REALLY nice OS, but the lack of a robust filesystem and slow NFS make it not yet ready for my needs. NetBSD has never worked for me on anything that I've tried it on and their installer does weird things.

All in all I do think all of the BSD's benefit by having the diversity that they have as well as having a "flagship BSD" which is likely to mean different things to different people.


----------



## Oko (Nov 17, 2015)

gofer_touch said:


> As far a DF being unstable, LOL!, the DF base is extremely stable. Even the master branch (i.e. current) is stable for day to day use and there are those that even run it in production environments. Any issues that are discovered are reported via the mailing lists by the team and promptly looked into. In particular there have been a lot of changes in the graphics stack, but issues get fixed quickly.


I use word stable as in "stable features". I was not saying that DF code is not stable I was saying that features are so rapidly changing that if I deploy file server now I will not be sure that all features will be there year from now let alone 5-7 years down the line which is typical life of the a server. You can check their mailing list for my post about LDAP. In June of 2014 DragonFly didn't support LDAP authentication and authorization (I am not sure what is the status of Kerberos because I don't use it for authentication). In November feature simply worked and I posted howto. Now guess what? I deployed 4 FreeBSD file server prior to DF having LDAP and primarily because DF didn't have LDAP. Do you think that I will be migrating now to DF just because support was added? Similarly I had trouble monitoring DF with m/monit and more importantly collectd. collectd port fails to compile on DF more than 5 years. Yes I know that they lack the man support and that is probably trivial issue, but guess what? When you run 80 something servers it is no longer trivial issue to me and I don't have time to fix it myself.


----------



## gofer_touch (Nov 17, 2015)

TeamBlackFox said:


> It is good to see ARM64 being worked on by DFBSD, but I'd still like to see some things in the project change. That is why, if the Apple shills (iXSystems, Jordan Hubbard etc) get their way with FreeBSD and it becomes a little brother to OS X, I'm gonna setup a fork of the last version without all of that versus jumping ship to another camp.



I'd swim the length of the Nile if you gave us FreeBSD with a version of the HAMMER filesystem!


----------



## Maelstorm (Nov 25, 2015)

I don't think that Hammer will be in FreeBSD anytime soon.  As I understand it, DFBSD was forked off FreeBSD due to differences of opinion between developers which eventually resulted in one developer's write access to the repository getting revoked.  That developer then forked the FreeBSD tree into DFBSD.  They still use GCC as their system compiler.


----------



## Beastie7 (Nov 25, 2015)

TeamBlackFox said:


> That is why, if the Apple shills (iXSystems, Jordan Hubbard etc) get their way with FreeBSD and it becomes a little brother to OS X



Care to elaborate on this? Shills? Any proof of such entity having power over the project? I'd really like to hear your thinking behind this sentiment.



TeamBlackFox said:


> If I did, it would be in lieu of ZFS. I like ZFS, but the CDDL encumbrance and its massive memory consumption among other things is just, too much. HAMMER would be the preferred FS for multidisk systems, but I would probably improve UFS and soft updates further as well as I have a fondness for how fast UFS is, and set it to default for single disks.



Just how is ZFS "too much" exactly? Re-inventing everything that's been well designed, useful, and battle tested for over a decade would be a complete anti-pattern.

As far as licensing is concerned, it hasn't had any detrimental effects on the project; so I'm sure all is fine.


----------



## beastDemian (Nov 28, 2015)

TeamBlackFox said:


> I don't have proof but there's a few developers on the project and some people who pop up constantly about launchd and other Apple-derived parts that are in the open and integrating them into FreeBSD. Just google launchd FreeBSD and if you go back a bunch there's a ton of info on it. iXSystems is using launchd in FreeBSD derived projects, for what reason, I dunno because rc init still serves well enough. We don't need a full featured systemd suite or anything close to that.



You are probably talking about NextBSD ( http://www.nextbsd.org/ ). Right now it's a hobby project and a semi-fork of FreeBSD. There are so many Apple technologies that they could easily rename it "Free-OSX". Anyway, for now, most of that work is staying in that branch (heck, most of it is not even stable). I hope they keep most of their stuff in that branch and just pull the changes from FreeBSD current since the amount of shoehorning they have to do is


----------



## sidetone (Nov 28, 2015)

FreeBSD can get influenced by any project. I'd rather that FreeBSD stay true to being BSD, and fork anything that wants to go it's own way.

At least I can say of Apple is that they released LLVM, Clang and will release Swift later this year. This actually helps FreeBSD be it's own. Some companies donate to FreeBSD and ensure their drivers work. I believe a lot of developers worked for Apple or were a former Unix system developer. It's just my opinion.


----------



## beastDemian (Nov 28, 2015)

They have the most up-to-date port of launchd and they are the ones who (in the past) considered integrating some of their work into the main branch. What is certain is that launchd won't go into FreeBSD right now because its not stable enough (AFAIK its not even working and panics every now and then). I'm fine with launchd staying in their semi-forked FreeBSD distro.

I'm sure there will be a discussion about it in the mailing lists in due time. The problems those utilities solve are still there. Until someone comes up with another solution (better or not) FreeBSD can still "be targetted".


----------



## sidetone (Nov 28, 2015)

FreeBSD is always influenced. FreeBSD's startup is better than Linuxism types. Why people want that over what FreeBSD has, I don't understand.

Here's what I find on Apple's Launchd https://wiki.freebsd.org/launchd . Despite worries of that being too much influence, once it works could that be better? It has a clear argument for start up times, but if it's not clearer than what FreeBSD has, I rather keep what FreeBSD has.


----------



## beastDemian (Nov 29, 2015)

sidetone said:


> Despite worries of that being too much influence, once it works could that be better? It has a clear argument for start up times, but if it's not clearer than what FreeBSD has, I rather keep what FreeBSD has.



Depends on your definition of "better". It introduces centralized dependency managment (basically you only start programs once their dependencies are fully satisfied instead of polling all the time) it saves you procesing power (and battery life) but it brings a lot of complexity to PID1...which is supposed to be simple and easy to understand. IMO it's still better than systemd, but the problems it brings to the table are very similar.


----------



## Beastie7 (Nov 29, 2015)

I think you should watch Jordan Hubbards' video on launchd (and many other things related) from BAFUG 2015, or his recent interview on BSDNow. Your post couldn't be further from the truth. Pure FUD non-sense fueled by irrational hate.


----------



## sidetone (Nov 29, 2015)

Launchd would have to change it's license to a BSD compatible one in order to find it's way into FreeBSD. I don't like systemd, and people who want that should go to Linux instead of asking FreeBSD to change their startup. Init works better than anything else, and there is no clear reason to replace it. It's better to leave init alone, or improve it. I can only see init replaced if everyone agrees there's a better replacement, and _if_ there's hardly any expression of strong opposition to the replacement. It would have to be somewhat better by a lot of people's opinion. Any system startup that needs a wrapper doesn't belong in a BSD base, IMO.


----------



## neogeo (Nov 30, 2015)

gofer_touch said:


> A question that has had be quite interested for some time, but one that I could never truly find a satisfactory answer for, was why has FreeBSD been so successful in its proliferation compared to the other BSDs?



My own impression is that FreeBSD is remarkably well architected, throughout the FreeBSD operating system component model -- as in regards to the OS kernel, the FreeBSD base system components, the popular baseline userspace tools, and the broader FreeBSD ports tree. Not as if to flatter, I believe this assertion is well backed of an analysis of the operating system source code, itself.

In a manner of an informal, if not social view: In my own experience, proceeding from an albeit informal experience with Debian GNU/Linux, I think Debian itself has honestly done a lot with regards to end-user support and Debian developer support -- perhaps more to an effect of an emergent popularity, if not ultimately to the ongoing "Variable-Gain Feedback Loops," so to speak, of the Linux developer ecosystem. I do believe Debian is, as an operating system, is more monolithically architected than FreeBSD, but it retains an open access model for contributions -- such as most free/open source software may, certainly, whatever the exacting terms of any single software license may be. As Debian being a popular Linux OS distribution, I believe Debian itself has weathered its popularity very well, over the years.

Perhaps Debian -- in its baseline OS -- might seem to be evolving more than FreeBSD, as in a simple estimate of discussions and subsequent source code changes over time, but FreeBSD is not without analogous changes -- such as in reference to the SystemD adoption in Debian. Assuming "Change is good" -- if one may assume it thus-- I would not want to cast any manner of shadow on the Debian doorstep, so to speak. Across so many effective committee discussions and subsequent changes in the Debian baseline OS, as Debian develops over time, but Debian remains Debian -- formally, a project sponsored by the GNU Foundation and Software in the Public Interest, Inc (SPI).

Contrasted to the Debian revisions and the evolution of the Linux kernel, to my opinion, FreeBSD seems to adopt -- and I think, usefully so -- a philosophy that might seem to be hinted towards as of the idiomatic phrase,  "If it ain't broke don't fix it," or some manner of a practical philosophy as with regards to the design of the kernel, itself, and the "User space" features of the FreeBSD operating system. Not only is FreeBSD well architected, I think -- and I have not as yet looked at OpenBSD or NetBSD, candidly -- it's also well documented in its source code -- even in so much as the makefiles of the whole OS toolchain. Also, there's a lot of meaningful documentation in the manual pages, in books published of the FreeBSD Project, and in broader academia -- all the further technical documentation -- veritably as FreeBSD being a "Work of the state of the art."

Not to try to make a till out of any single relative estimates of popularity, or support, or OS-architectural qualities, juxtaposed to Debian, I understand that Debian itself had managed to have picked up some more of a social if not commercial interest with Canonical's projects -- Ubuntu Linux deriving originally as a fork of Debian, with subsequent forks being developed of Ubuntu. Personally, I could wish that FreeBSD would be picked up by Samsung's Tizen developers -- candidly, I think a FreeBSD fork of Tizen could be easily done, as the Tizen projects are quite squarely managed under the Samsung IRIS system -- but I would certainly not want to "Rock the mobile boat," so to speak, neither as if to figuratively or literally remove any jetwash from Linus Torvalds' projects. Myself, I stick to low-flying things.

Though there are certainly a number of forks of FreeBSD, too -- not to be tedious of a manner of a logical assertion that a _fork of a fork_, in its source code, is transitively a _fork of the original baseline_, however a social identity of a software project may evolve along with the development of the software, and however the original baseline software may be changed in subsequent _direct forks_ -- thus, that there are quite a few forks deriving originally of FreeBSD if not furthermore influenced of designs, broadly, designs in "Other" BSD operating systems, in the whole BSD development ecosystem -- I don't believe anyone has tried to too radically change the OS.  FreeBSD certainly retains a stable design, in its computing architecture.

Although there may be a critique about some of the component models applied in FreeBSD, but software such as the Forth bootloader does not necessarily have a "Shelf life." Though perhaps the Forth language itself might not seem to be one the hippest ones on the Headhunters' "To Go" lists, today -- juxtaposed to HTTP dot CLI and so on -- and perhaps a simple concept of a stack machine may ever seem to go _out of vogue_, but theoretically, that doesn't change its component-wise functionality, in applications.

Trends may come and go, enterprises acquired and acquired again, social parties and all the confetti and so on, but so far as the nuts and bolts of it remain essentially unchanged, the OS persists across all the advertising.

Perhaps FreeBSD was designed in such a way as that it is naturally extensible for new applications in new "State of the Art" developments, without any wide-sweeping changes required in its source code. Personally, I haven't been closely following the discussions about microkernel designs in Linux -- I'm certain that there must be someting of an academic ecosystem about it, also, though I can only make a broad estimate of such. I myself am not even informally familiar with the academia about Linux itself  -- as much as I am well not a formal part of the Linux developer ecosystem, not in any formal or direct regards.

Personally, though Debian has so much more of packaging support, I think FreeBSD is much more accessible in its essential OS design. I feel that I should be wary of trying to convey too much of a "New sports car" vibe about it, though, candidly -- figuratively, to keep all wheels on the road....


----------



## Oko (Nov 30, 2015)

neogeo said:


> Although there may be criticisms of some of the component models applied in FreeBSD, but software such as the Forth bootloader does not necessarily have a "Shelf life."


Wow!!! So all of us who were using Sum Microsystem UNIX workstations which use Prom written in Forth since mid 80s of the last century should switch to machines that use BIOS, UFI or some other Microsoft garbage which has a longer "Shelf life".


----------



## sidetone (Nov 30, 2015)

teamblackfox
What's your idea of improving or replacing BSD's init? I see no problem with improving it with ideas from something modern (even ideas from launchd), provided it's simplicity in configuration is kept.

neogeo
Linux is successful due to advertising, and it's focus on the desktop. BSD's license is more business friendly than GPL, which is still very good for other purposes. It is because BSDs put less investment in advertisements, while FreeBSD put in more than other BSDs. Different BSDs have different strengths. NetBSD has a cleaner system and ports system, but it's peripheral hardware support is lacking, due to lack of investment support compared to FreeBSD.


----------



## neogeo (Nov 30, 2015)

sidetone said:


> Linux is successful due to advertising, and it's focus on the desktop.



With reference to support for Linux in desktop environments, such as with Debian and Canonical, as well as the popularity of the KDE and GNOME desktop environments -- with KDE's support certainly sponsored in part by Trolltech, as Trolltech being an institution in regards to Qt -- as well as any manner of formal commercial advertising about Linux, perhaps there's been a certain uptake in the developer ecosystem -- a sort of informal if not social advertising, to an emergent adoption of Linux as an operating system platform.

In a personal comment, I regret that I am apparently not designed to market well for that kind of marketing. I believe I'm fairly good at sketching up logical models, but it may seem that there's not much of an immediate use for such. If one may indulge, however....

As well as in desktop platforms -- not as though to do all of the Linux's Foundation's own marketing, so to speak -- the Linux kernel might also be found as applied in supercomputer architectures. Personally, I've read a discussion at one point, with regards to Linux having support for parallel processing, in that context. My not being too well familiar with details of microcontroller design, I had not wanted to argue about the adaptability of the FreeBSD kernel, in the discussion -- have read a little more, lately about the ULE scheduler but I'm badly distracted of some ideas about FPGA design. If there may be a belief that Linux may be simply more well suited for applications in supercomputing, perhaps that could be just as well to me -- personally, I'm not a big fan of OS advocacy any more. Candidly, I've not either studied a topic, "Parallel Computing," to any great depth as yet. I've read a little about I2C though.

There's a networking domain, too. In regards to Linux operating systems and ostensible markets, perhaps Red Hat and SuSE have each been somehow favoring towards Enterprise adoption about Linux, as in a context of enterprise servers at least -- respectively in the US and the EU, as each of Red Hat and SuSE having a manner of a market in each respective geographical area. I'm certain that Red Hat and SuSE have made some formal advertising campaigns. Personally, I'd first learned about either, via Freenode.

Contemporarily, there's also the Xen hypervisor and Xen's placement in the Open Stack architecture -- in a sense, Xen's dom0 and dom1 frameworks perhaps having evolved out of the Linux kernel itself. Xen might be categorized towards a manner of a networking domain, perhaps, but furthermore in regards to any number of singular concepts about software defined networking -- _viz a viz _Digital Ocean, Amazon Web Services, IBM BlueMix, and other commercial institutions having adopted the Open Stack framework, in its primarily Xen-based applications.

Not as if to dodge about the networking applications of BSD operating systems, personally I've been studying a little about mobile and embedded computing platforms. I understand that there are some filesystem drivers in the Linux kernel, such that might be said to be ideal for storage onto solid state devices. Perhaps that might be relevant not only in regards to mobile computing, but that is the context in which I had begun reading of the topic.

Of course there's Android, sponsored by Google, and sponsored by every single OEM applying an Android OS. Android has its Dalvik and ART VMs -- something about Java licensing. Comparatively, Tizen -- as a mobile/embedded computing platform applying Linux -- Tizen notably, has evolved partly out of Samsung's sponsorship of the development of the Enlightenment Foundation Libraries (EFL). Tizen itself runs on a Linux kernel, too.  Maybe I've just wanted to reinvent the Enlightenment desktop environment -- something, I think, can be done other than how Windows 8 approached the matter of making an "Apps" framework for desktop PCs. Perhaps that could be approached as well with EFL, independent of the exact features of the Enlightenment desktop environment, in sort of mirroring if not directly forking Tizen's userspace features for PC applications.

Not to remove the "Who's who of computer science" from the matter, I believe that there's a manner of monolithic commercial Enterprise that has taken up quite something of a presence in Linux OS development, over the years. Personally, I think there's something of a nuanced quality of broader social adoption at work, in Linux operating system popularity -- perhaps so much of simple "OS advocacy" could be categorized as advertising, even though not _per se _commercially so.

Personally, I'm more favoring of software for small/medium enterprise (SME) networking environments. Though I don't believe there's been as much online networking for B2B in an SME context, not as much as B2B in -- for instance -- a J2EE context -- or that it's not written large down on Madison Ave, if there has been more of SME B2B online -- I think there's a potential for SME applications of FreeBSD, as in a manner, "Close to the ground," so to speak. In a commercial sense, if it might not seem to be on Cisco's veritable radar, and I for one would not speak harshly about Juniper's hardware and OS platforms, I think they're both kind of going for larger networking environments. Personally, I think there's just as much use in small LAN development, albeit not comparatively "At scale" in hardware applications -- and by in large, absent of very large offices.

If it may be to a domain model in a sense, of applications in desktop, networking, SDN, mobile, and supercomputing environments -- personally, I'm not in any rush to catch up to the GNU.

If there may be a domain defined about content management systems and a domain of knowledge management, perhaps both domains -- in their applications, how far beyond or beside so many academic theses -- it might seem to derive primarily of web architectures at OS layer 7, so to speak. In so much as for applications at OSI layer 7, it being by in large agnostic to any single OS, there, but of course it needs more than tin cans and twine to run a web server and have it communicate with another computer over something more high-voltage than jute fiber, per se.  If there could be a niche market about it, I'm afraid it's not an easy niche to develop, however, least of all for someone completely lacking in social marketing skillz.


----------



## sidetone (Nov 30, 2015)

neogeo
It's not your burden. I was speaking of FreeBSD's foundation marketing. Any user can contribute what work they want.


----------



## sidetone (Nov 30, 2015)

teamblackfox
Those seem better than other Linux start ups. Run levels annoyed me before, but at least one of them has 3 run levels. With FreeBSD, it proved so many run levels weren't needed. BSD only has two, single user mode, and regular user mode. If they have GPL licenses, FreeBSD won't port it. It could only rewrite code from any ideas from it.

If Apple wants a little brother, it should bring back Darwin. Other than that, I'm happy for some of it's influence such as Clang, LLVM, and later Swift. Without Clang and LLVM, FreeBSD could have been left stranded, and dependent on GPL.

On a personal thought, I wish GNU would fork their distribution from FreeBSD, to lessen it's influence in the ports tree, and because GNU needs kernel parts they can tie in with Hurd as their own.  (There's also Pac/ArchBSD for it). It seems FreeBSD people are scared of that, because they think they'll lose programs. I like GNU, but I want to see a truly BSD dependency and desktop solution for basics, and let GPL programs run on top of that if wanted. It's gtk's being gimp that I hate. It's the logo, or what the name rhymes with that's offense, and I think that was intentional.


----------



## ANOKNUSA (Nov 30, 2015)

TeamBlackFox said:


> Also suggest reading this instead of something by a former Apple employee. He's a biased source. Here, read a post by *[insert reference to yet another critic hawking their own alternative init system]*.



I couldn't resist.


----------



## Beastie7 (Nov 30, 2015)

ANOKNUSA said:


> I couldn't resist.



The irony. Gotta love it.


----------



## sidetone (Dec 1, 2015)

Everyone has their own vision of what FreeBSD should be. I also have an idea of what an ideal operating system should be. I'll pick the closet one to my idea and work on that as a side-project that doesn't interfere too much. The one I don't understand is when people say FreeBSD shouldn't be a desktop.

That aside, I rather keep BSD's init, because I haven't seen anything that fits and is all around better.


----------



## ANOKNUSA (Dec 2, 2015)

TeamBlackFox, it's clear that you have some strong concerns, but you can't seem to communicate them without using very specific, irrelevant qualifiers in a derogatory way. It's confusing, because it makes it unclear exactly what you're granting importance, so it leaves me wondering what your actual point is. If uselessd is a non-entity--and therefore irrelevant to any discussion on init systems--then why introduce a blog post critical of an init system as being written "by the author of uselessd"? Clearly having worked on uselessd doesn't validate his opinion, since he apparently thought the project was bad enough to abandoned it. It's irrelevant. Likewise, if you have a problem with "Apple nonsense" and are concerned with FreeBSD "becoming OS X's little brother," then what makes Apple-developed tech like Clang and GCD alright? It's apparent that a project being used in or developed for OS X, or developed by Apple, isn't what you dislike. So why put focus on that?


----------



## beastDemian (Dec 2, 2015)

ANOKNUSA said:


> Likewise, if you have a problem with "Apple nonsense" and are concerned with FreeBSD "becoming OS X's little brother," then what makes Apple-developed tech like Clang and GCD alright?



He was speaking about the shoehorning of Apple technologies in the base system the NextBSD project is doing. It's almost like adding another kernel on top of the FreeBSD kernel. It's not just about LaunchD it's about LaunchD and ASL and the Mach IPC and socket activation....

Using Clang as a system compiler doesn't require drastic changes to the kernel. And the necessary changes don't really affect the way FreeBSD operates. Bringin in LaunchD will afect the system much more. Replacing the system compiler and replacing PID1 are very different things. Launchd might integrate well with OS X, but it doesn't necessarily do so with FreeBSD.


----------



## sidetone (Dec 2, 2015)

That's NextBSD, not FreeBSD. At least they're doing it there.


----------



## beastDemian (Dec 3, 2015)

TeamBlackFox said:


> I'm not talking about NeXTBSD. Please do not put words in my mouth.



Sory, I bring up the project because they seem to be the ones trying to merge launchD into FreeBSD. I know your comments are a more general "launchd is bad" and not "<project Y> is bad".


There were other efforts made in the past...but none came to fruition. I'm partially scared because there are people with commit access on that project (though they say if they commit this now, they will get their commit bits revoked). I'm guessing some sort of consensus with the wider community is needed before integrating something like this though.


----------



## aht0 (Dec 3, 2015)

sidetone said:


> teamblackfox
> Those seem better than other Linux start ups. Run levels annoyed me before, but at least one of them has 3 run levels. With FreeBSD, it proved so many run levels weren't needed. BSD only has two, single user mode, and regular user mode. If they have GPL licenses, FreeBSD won't port it. It could only rewrite code from any ideas from it.


OpenRC has 2-clause BSD license according to its Wikipedia entry. And it seems to be in active development, last stable release came out in the middle of October.

If you want to see it working then minimalistic Alpine Linux is also using it.


----------



## Atsuri (Dec 3, 2015)

aht0 said:


> OpenRC has 2-clause BSD license according to its Wikipedia entry. And it seems to be in active development, last stable release came out in the middle of October.
> 
> If you want to see it working then minimalistic Alpine Linux is also using it.



Manjaro Linux (based on Arch Linux) also runs an OpenRC version for people who dislike systemd. From personal experience I know that setting up Arch Linux with OpenRC is possible as well and everything relevant is on GitHub .

I might be a bit new here and for sure green behind the ears, but I hold the axiom 'if it's not broken, don't fix it' very dear to me. I noticed that the way FreeBSD handles services, processes and boot sequence might not be the most modern, but it works and is quite flexible.

I would be OK with a new init system or another feature, be it from Apple or from anywhere else, as long as there is a considerable gain in comparison to the resources required to port it .


----------



## sidetone (Dec 3, 2015)

If a version of Openrc comes in that has simplified run levels, and has functional configuration like BSD's has, then it might be ok.

Maybe something like a single mode run-level, multi-user run-level, /usr/local/ mode and a network run-level. Except for single user mode, the rest wouldn't be named sequentially, but instead by name. Linux's run-levels ask, which applications do you want to run in modes 1, 2, 3, 4, 5, that doesn't matter and it's useless. I just want it to run like in FreeBSD.


----------



## Maelstorm (Dec 23, 2015)

I'm just stepping into the conversation but from what I have read thus far, it seems that LaunchD is radically different than init(8).  If that is in fact the case, then my concern is that the entire system startup (starting with init) will have to be rewritten or replaced.  Such a project will introduce bugs into the system which will require several debugging cycles to resolve.  Not to mention the learning curve that system admins will be subjected to when such a major component of the system is radically changed.  Right now, it is working pretty good.  So remember the old saying: "If it ain't broke, don't fix it."


----------



## Beastie7 (Dec 23, 2015)

Maelstorm said:


> I'm just stepping into the conversation but from what I have read thus far, it seems that LaunchD is radically different than init(8).  If that is in fact the case, then my concern is that the entire system startup (starting with init) will have to be rewritten or replaced.  Such a project will introduce bugs into the system which will require several debugging cycles to resolve.  Not to mention the learning curve that system admins will be subjected to when such a major component of the system is radically changed.  Right now, it is working pretty good.  So remember the old saying: "If it ain't broke, don't fix it."



That's exactly what NextBSD is for. It's a downstream experiential project to test, and showcase it's implementation. Once completed, it is up to FreeBSD to pull the changes upstream. Will it? Who knows.

However, I haven't seen much opposition to the change from people who know what the hell it is, why it's valuable for FreeBSD and isn't just spouting knee-jerk reaction BS (ie. the developer community). 



> "If it ain't broke, don't fix it."



Just because it isn't broken, it doesn't mean it can't be improved.


----------



## Maelstorm (Dec 23, 2015)

Beastie7 said:


> That's exactly what NextBSD is for. It's a downstream experiential project to test, and showcase it's implementation. Once completed, it is up to FreeBSD to pull the changes upstream. Will it? Who knows.
> 
> However, I haven't seen much opposition to the change from people who know what the hell it is, why it's valuable for FreeBSD and isn't just spouting knee-jerk reaction BS (ie. the developer community).



I find that interesting to say the least.  Who knows, maybe it is an improvement.  I simply don't know.  What I do know, however, is that Apple was one of the first companies to offer a computer with a GUI system, even though they did rip it off from Xerox.



Beastie7 said:


> Just because it isn't broken, it doesn't mean it can't be improved.



Hehehe.  The cardinal rule of software developers everywhere.


----------



## sidetone (Dec 23, 2015)

Maelstorm said:


> "If it ain't broke, don't fix it."





Beastie7 said:


> Just because it isn't broken, it doesn't mean it can't be improved.



It depends. A lot of times something works very well, and messing with it breaks it. Other times, things need to be improved. In the software world, there is a lot to be improved.


----------

