Does openindiana, sco-unix, unixware has features freebsd does not have.

SCO and UnixWare are quite outdated. OpenIndiana is a quite modern SysV UNIX with a quite intriguing init system (SMF) that borrowed a lot from FreeBSD now.
 
SCO and UnixWare are quite outdated. OpenIndiana is a quite modern SysV UNIX with a quite intriguing init system (SMF) that borrowed a lot from FreeBSD now.
SMF borrowed nothing from FreeBSD. SMF was there in Solaris 9 (before Oracle purchased Sun Microsystems). That was long before FreeBSD had rcNG. I was at the dog & pony at one of the local hotels here when Bryan Cantrill came to town to announce SMF, DTrace and ZFS.

FreeBSD's rcNG wasn't a FreeBSD development either. It was imported from NetBSD and improved.

BTW, IMO the Solaris SMF was the correct way to solve the problem. The Linux way, systemd, is horrible compared to the simplicity of SMF. Having worked with SunOS and Solaris in the old days SMF was certainly an improvement. It did not replace init(8) but added some code to init to work closely with its SMF child process. One could still disable SMF and use SYSV init files as the capability was still in init. Whereas systemd not only changed the paradigm but it endeavours to also replace logging and home directory services. It is certainly not in the spirit of the UNIX philosopshy while SMF tries to adhere to the UNIX philosophy.

The Illumos source was forked from OpenSolaris shortly after Oracle purchased Sun Microsystems, closing the OpenSolaris source code. A number of different downstream projects repackaged Illumos for various reasons, such as file server, desktop, and the like. OpenIndiana is desktop packaging of the Illumos source which can be found at illumos-gate.
 
What I meant was that OpenIndiana (illumos) did though. Increasingly more FreeBSD stuff is found in illumos distributions.

And yes, I like SMF a lot. :)
A number of minor FreeBSD features have been imported into Illumos and one major feature, bhyve.

Illumos has expressed interest in me importing ipfilter 5.1.2 with all my fixes and enhancements into their codebase replacing their ipfilter 4.1.8. They wanted their addition to allow ipfilter which allowed it to work with their zones to be included. I recently (this year) added this support to ipfilter for VNET jails (while disallowing non-VNET jails to manipulate the global ruleset). I believe this is what they do. Their zones are akin to our VNET jails. It's probably time to check in with them again.

I was planning on importing SMF into FreeBSD but CDDL is not as open as BSDL. It's easy enough to exclude ZFS and DTrace, both of which are CDDL, from FreeBSD but you cannot do without an init. And maintaining two init systems is a pointless duplication of work.

BTW, it was FreeBSD jails that caused Sun to consider the concept of zones. Though they didn't import FreeBSD jails the concept of jails was what got them thinking about zones in the first place.
 
SCO OpenServer has a versioning filesystem (HTFS), though it's an antique today (as Cthulhux pointed out). Its kernel fit on a single 1.44 MB floppy, and a working root filesystem on another.
 
Raises question , how do freebsd jails & solaris zones compare ?

 
The problem?
Slow boot. Personally, I didn't think it was a problem but others in the industry did.

The problem for Sun and other mainstream UNIX vendors was that Linux was nipping at their heels. They were worried and rightfully so. Look at where they (Sun Solaris, Tru64, DG-UX, HP/UX, Irix...) are and where Linux is.

This probably got Pottering thinking of laptop boot performance which systemd is supposed to address. However systemd IMO is probably not the best solution in an enterprise environment. systemd-homed illustrates that in spades.
 
[citation needed], as “the BSDL” has the same requirements as the CDDL, minus an optional patent clause which would not apply to FreeBSD anyway.
Read the license. This is why cddl sources are not merged directly into src/. Just in case some entity may wish to distribute FreeBSD sans bits and pieces they're not comfortable with.
 
Even though systemd is technically not the best solution, a lot of,many,linux distro's have systemd as default.
Some big players like redhat are pushing it.
About alternative init systems and boot times. I use gentoo-linux with openrc and it has a short boot-time. I use void-linux with runit and it has also a short boot-time.
Normally you can make "flame-sharts" for freebsd booting. But i never managed to get it working.
 
Even though systemd is technically not the best solution, a lot of,many,linux distro's have systemd as default.
Some big players like redhat are pushing it.
"Just because everyone is doing it doesn't mean it's the right thing" ;)

OpenSolaris is the original place that had ZFS, I don't know if Illumos/OpenSolaris/OpenIndiana are moving towards OpenZFS, but if not, that could be considered a huge difference.

Solaris kernel was fully (or almost fully) preemptible a long time ago.

Basic system management is different, not better, not worse, just different.

At the application level, just about all the current *nixes seem to be able to build the same set of applications, so not much difference in firefox on FreeBSD/NetBSD/OpenBSD/DragonFlyBSD/Linux/OpenIndiana.

Has someone like Phoronix done a benchmarking of IllumOS/OpenSolaris vs *BSD/Linux?
 
[citation needed], as “the BSDL” has the same requirements as the CDDL, minus an optional patent clause which would not apply to FreeBSD anyway.
This is why cddl sources are not merged directly into src/. Just in case some entity may wish to distribute FreeBSD sans bits and pieces they're not comfortable with.
So CDDL may be perfect for use with other permissive and weak-copyleft licenses which have patent clauses, like Apache and MPL. That's a compatible opensource ecosystem right there, in addition to with permissive licenses without patent clauses.

Edit: IIRC, CDDL was a variant or was similar to MPL 1.0 or 1.1. There's also opensource Apple and Microsoft licenses which were similar to these.
 
Slow boot. Personally, I didn't think it was a problem but others in the industry did.
(1) The device probing takes most time when booting, this will not be changed with new init/rc.
(2) It does not boot slow, it is hence not "slow boot".
(2) I never heard industry complain, but desktop freaks, the ones that continuously bring the theme desktop ad nauseam here.
 
(1) The device probing takes most time when booting, this will not be changed with new init/rc.
(2) It does not boot slow, it is hence not "slow boot".
(2) I never heard industry complain, but desktop freaks, the ones that continuously bring the theme desktop ad nauseam here.
I never complained, neither did any other Solaris or any other UNIX admin complain. But there was Linux. There was always comparison between Windows and Linux boot times. I wouldn't be surprised if someone told me their marketing droids told their software developers that something needed to be done.

Considering the money angle almost always seems to offer some kind of explanation.
 
I never heard industry complain
As it was said above most of the time boot delays are in fw, mostly on memory checks. So OS independent. Some of our fully loaded HANA boxes take up to 25mins to get to the grub so you can load the OS. Imagine troubleshooting multipath issues when you don't know what's wrong. Every time you changed something and wanted to test it you lose 30+mins. Doing that even on 8hr downtime is a big pain.
While I wouldn't call it complain but many swear a lot and don't care if the time is lost in fw or the actual OS boot. :)
 
Probing for USB devices is however faster in Linux then FreeBSD.
I don't mind FreeBSD booting times a few seconds more than Gentoo-Linux(openrc).
Some time is lost in starting services. Offcourse if you disable that service booting time is faster.
All in all, the stability of the O.S. & Kernel is primordial.
 
Boot times. If a server, with redundancy, average uptimes in 100's of days, boot time is pretty much irrelevant. If failed over, a reboot time can play into the "5 9s" statistics.
Home users? I'd posit it's not "boot time" but "resume from suspend/hibernate". Laptops: one uses them, shuts the lid, drives somewhere, opens the lid. How quickly after opening the lid can I use the system becomes important.

But my experience, based on my usage patterns, is that "correct booting 100% of the time" trumps "how fast do I boot" every single time.
 
Back
Top