Taking a Look at Nexenta's Blend of Solaris and Ubuntu 248
Ahmed Kamal writes "What happens when you take a solid system such as Ubuntu Hardy, unplug its Linux kernel, and plug in a replacement OpenSolaris kernel? Then you marry Debian's apt-get to Solaris' zfs file-system? What you get is Nexenta Core Platform OS. Let's take Nexenta for a quick spin, installing and configuring this young but promising system."
Get me a Redhat/Centos userland (Score:3, Interesting)
I'll look at it when there's a Redhat/CentOS userland to go with it. I'd say I'm pretty familiar with both Redhat Linux and
Solaris and the BSDs but you would have to give me some really compelling reasons I should go through the Debian/Ubuntu
learning curve.
Re:Even if.... (Score:5, Interesting)
Re:Even if.... (Score:3, Interesting)
Well, there is a kfreebsd-port for Debian, but it's not gonna be in the upcoming release of Debian (Lenny) so it seems.
Re:Excellent! (Score:3, Interesting)
Yes: more is better. And it might breathe some life into Solaris. Sun could use some of that right now. Solaris has the benefit of solid code developed at a comparative snail's pace, but with the energy of being hard, and toughened. Any distro mix is a good mix, because you learn from it.
Re:Excellent! (Score:3, Interesting)
Good point, but we already have the whole BSD family. Having a third family of kernels available is probably a lot less important than having a second one. I would think that avoiding monoculture would be a much less important argument in Nexenta's favor than the availability of ZFS, for people who need specific features of ZFS. Hmm...but then, the licensing issue that makes ZFS incompatible with the Linux kernel doesn't apply to BSD, and ZFS is already available on BSD. I suppose if you want specific features of ZFS, and you're used to the GNU toolchain, then Nexenta might be more congenial than BSD. But an awful lot of the user-visible differences between BSD userland and Linux userland have been going away lately. E.g., GNU m4 is now the default on BSD.
Re:Better Proposed Names... (Score:1, Interesting)
"Somnambulent" is a real word, which makes it unusable to pharma companies. Maybe "Somnioxx," or "Somnagra".
Got that backwards, and a misuse of term (Score:1, Interesting)
Something to think about when you use the GPL for your own code - you may be preventing it from being bundled with other Free Software.
I guess the other software wasn't very Free then to start with if it disallows something as simple as linking with a GPL package, was it? After all, any GPL software can link with any other without legal complications...
If the CDDL is the problem then it is not Free.
Re:Even if.... (Score:5, Interesting)
The Debian people believe that distributing GPL'd code that links against a GPL-incompatible libc is a violation of the GPL (and they are probably right).
The FSF themselves distribute GPL'd code that links against GPL-incompatible libcs (including Suns) - and they have done for years (in fact decades), way before CDDL exsited, when Solaris / SunOS libcs were proprietary.
The FSF are right, "the Debian people" are wrong. If there was one thing the system libraries exception clearly covers, it is libc.
Re:Get me a Redhat/Centos userland (Score:2, Interesting)
Naw the way I see it replying to you and the guy calling Redhat 'not as popular'.. I think there's a lot of bias in any OS
discussion and obviously you're going to be batting for the ones you are familiar with. Now the thing is, it's not necessarily
a matter of what I like, it's more take for an example that Redhat/CentOS is probably the most common operating system
you'll find in a datacenter next to Solaris. It is only for my personal home use these fall short so I've used Ubuntu at home
for a few days.. only to find it a learning curve that conveys little benefit outside of what I could already do with Rhel/CentOS
and a little work of my own.. That's why I finally got a Mac. There still is a learning curve here with OSX but I'm willing to
take it because knowing my way around OSX is something I can use at work.
Re:Excellent! (Score:2, Interesting)
For the major kernels I'm counting 7: Linux, BSD/Darwin, Solaris, HP-UX, AIX, QNX, Win..
Probably forgot some, but the point is, that this kind of number is ok, could also be more, but not less. I mean, some also have kind of specialized uses and the larger number of kernels also ensures, that somebody cares about standards (because if that would not be the case, then the whole tool set for every platform wold be need complete reimplementation - and yes, we are doing this for a well known platform and it is cumbersome to work around the problem instead of solving it).
Similar to browsers, the more, the merrier.
Re:Get me a Redhat/Centos userland (Score:5, Interesting)
The reason Ubuntu is so popular is because they took a standardized, stable, flexible, but up-to-date base (Debian) and took care of the desktop-oriented customization that a Debian user would normally have to do manually. Then they started filling in the holes in the UI, which trickled back to Debian of course.
The reason Red Hat is no longer popular (and I don't know why it ever was, since Debian has almost always been this good) is, in my opinion, because the packaging system is way too open and not nearly standardized enough. Although they have been fixing this in the recent years, when you run a Red Hat based system (Fedora, Centos, etc), you seem to end up installing packages from random places.
From Debian, if you stick with the official repositories (which is possible since they are very thorough and extensive), you are pretty much guaranteed that all your packages have passed through a standardized system where they are checked for problems, inter-dependencies, and are all compiled with the same methodology.
Additionally, Debian's seemingly-overbearing policies on legal issues are actually a good thing, as long as they have enough developers (and they do): as long as you have your "gold standard" distribution where every package meets very strict rules, you can always branch out from there by adding other trusted repositories or doing what Ubuntu has done. However, if you start from a "messy" packaging system / distribution where anything goes, its much harder to select the "standardized" subset of those packages.
Finally, Debian's developer base is very large, diverse, and relatively unified in their efforts, and their organization is *very* democratic and user-driven. There is no one central authority that has total and permanent control over the distribution. While this has the possibility for failure, they've done it in a way that seems to have worked out very well. In contrast, Red Hat is a corporation that has a vested interest in getting customers to pay for support contracts, while the Red Hat based distributions are more numerous and don't have nearly as much manpower (note: purely based on speculation). I don't know how much penetration Debian has in the enterprise, but if someone stepped up to provide paid Debian support, I think they could make a lot of money...
Anyways thats just been my view. I honestly don't mean to offend anyone who really likes Red Hat -- I just feel that Debian's packaging system is much more powerful, standardized, up-to-date, and trustworthy (the key being meeting all of these points, and not sacrificing one for another -- say more up-to-date for less standardization, etc).
Please feel free to correct me -- I am interested to hear a Red Hat admin's point-of-view on the issue.
Re:Got that backwards, and a misuse of term (Score:5, Interesting)
I guess the other software wasn't very Free then to start with if it disallows something as simple as linking with a GPL package, was it? After all, any GPL software can link with any other without legal complications...
Nice troll. The CDDL is roughly equivalent to the Mozilla Public License. It makes no demands on code linked to it at all. It is a per-file license, and can be linked with any other code unless the other code's license explicitly prohibits it. You can mix CDDL, Apache licensed, BSD licensed and any other per-file license together into a single program.
It is the GPL which makes this a problem. The GPL states that, if you distribute a GPL'd program, all parts of the program must be covered by licenses which impose the same conditions as the GPL and no others. The CDDL (along with every other Free Software license on this list [fsf.org]) does not fall into this category. This means that you do not have a distribution license for the GPL'd software if you attempt to distribute it along with any software under any of these licenses (and they link together - 'mere aggregation' is allowed).
Apple would have the same problem distributing bash on OS X if their libc were APSL'd (like most of the rest of Darwin), but since it comes from FreeBSD they kept the BSDL, which is GPL-compatible.
Any GPL'd software can link against any other GPL'd software without legal complications, but you can say the same about the CDDL, the APSL, the ASL, and even a load of proprietary licenses. It's only when mixing with the GPL that any of these have problems.
If the CDDL is the problem then it is not Free.
Well, the Free Software Foundation list it as a Free Software License, and the Open Source Initiative class it as an Open Source License, so it certainly seems free.
Re:Get me a Redhat/Centos userland (Score:4, Interesting)
What's so different in Ubuntu vs. Red Hat, on a desktop machine?
The packaging system is very similar AFA what the end user sees, and there's a GUI program installed by default that can handle all that for you anyway. I suppose config files might sometimes be located in different places, but how many of those to you edit on a regular basis, if any? Especially with modern, highly effective automatic hardware detection and configuration, it's unlikely that you'll need to edit a large number of config files on a desktop machine. Just locate the one or two (if any) that you need to work with and you're done.
The GUI is Gnome or KDE in either one, or any of the other WMs that you can install on either. No big learning curve.
Bash and 99.9% of the console tools are the same.
Installing a program that doesn't have a package is going to be the same on either, usually a configure and a make.
Hell, I'm pretty sure the network manager in Ubuntu was originally created for (and, I assume, is still used by) Red Hat.
What's the learning curve? I'm not trying to be a dick, I really just can't figure out what would be so different, and would like to know what gave you trouble. I can understand servers being troublesome, since Red Hat has tons of tools that other distros don't, but the desktop experience ought to be very similar, considering they're largely composed of the same 3rd party apps.
1Tb zfs "user" data for Developer Release = FAIL (Score:1, Interesting)
The free developer release limits the entire zfs used "user" data to 1Tb. You can setup over 1Tb worth of disks, but only 1Tb can ever be be in use by the "user". I hope user data doesn't include the OS install....
Re:Looks interesting (Score:3, Interesting)
Looks fun but I am still waiting for 3ware Solaris drivers.
3ware is redundant on Solaris. There's no reason to be doing hardware RAID if you can do ZFS. Take all your drives on 3ware and put them on commodity controllers.
General purpose hardware today is fast enough that dedicated RAID controllers are getting nearly obsolete.
Re:Get me a Redhat/Centos userland (Score:1, Interesting)
I'll agree that apt is far superior to yum/up2date, but one of RedHat's staying powers is the commercial support it has. We run nearly 2k hosts for research computing (university) and nearly all are redhat strictly because research apps (and thus our customers) support it. To be fair, quite a bit of our backend infrastructure is debian.
As to your comment about installing packages from random sources, RedHat's sources have everything you need for a server. That may hold true for desktops, but that's not our forte. Most of our admins have Macs on the desktop. :o)
I'll also add, kickstart > FAI any day of the week. We've got automated installation setup for every cluster and it's a ton easier with redhat's kickstarts. We did a 500 node install within a few hours with PXE+kickstart+cfengine.
Don't get me started on SuSE, it's got no place in a real linux shop and yast is a curse to anyone that has to use it.
Re:Get me a Redhat/Centos userland (Score:4, Interesting)
The importance of doing an apt-get and having the apps work bugfree is importance as a desktop. I used to be a unix guy from 1999 when I tried Caldera openLinux lite and then tried out the FreeBSD's from 2001 - 2004.
I switched to vista (shudder)because I want something to just work. I just very recently got ubuntu to actually install bugfree on my laptop only to see strange screen artificats on white screens due to some way X is setup.
Anyway the big deal for OpenSolaris is for servers. Solaris can handle many threads concurrent and loads for high end servers and ZFS and Ztrace are very nice for system administrators running server farms.
As a desktop I would run from this as the plague as I assume its untested and buggy. Wifi, 3d, flash, and maybe wine compatibility for those hell bent on win32 apps. I could be wrong. I would not trust a server on this either as its not as well tested as Sun Solaris.
If you want a desktop use MacOSX or Windows. Linux for when you need to learn programming or unix and real solaris from sun for reliability and big iron.
I agree this would be a nice toy for those wanting to learn solaris.
Re:Get me a Redhat/Centos userland (Score:3, Interesting)
Given the history of Mac OS, knowing your way around a particular version can be of very little help once the next major version is out. Remember the OS 9 -> OS X transition...
Re:solaris and.....ubuntu? (Score:3, Interesting)
there is a major difference between binary blobs and firmware images; the blobs are loaded as code into the OS kernel, but the firmware runs directly on the device on crappy embedded micro CPUs.
OpenBSD does contain binary firmware files. But don't take my word for it (or the article's) and check the contents of /etc/firmware/.