FreeBSD proliferation

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.
 
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.
 
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....
 
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".
 
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.
 
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.
 
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.
 
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.
 
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?
 
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.
 
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.
 
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.
 
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 :P.
 
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.
 
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."
 
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.
 
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.

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

Hehehe. The cardinal rule of software developers everywhere.
 
Back
Top