Taking a Look at Nexenta's Blend of Solaris and Ubuntu
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."
Open Solaris is OSI approved Open Source.
Do you even lift?
These aren't the 'roids you're looking for.
But seriously, sounds like a great idea.
Don't blame me, I voted for Baltar.
These are the types of stories I miss on /. No, politics, no civil procedure/court news, no DRM wars. Just plain old news for nerds (even if it doesn't matter all that much).
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.
You must have missed the memo. Sun has been open sourcing projects left and right: OpenSolaris, Java and VirtualBox to name a few high profile examples. Sure OpenSolaris isn't GPL'd, but Java and VirtualBox are.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
Even if the idea behind all this is sound.. Try to consider that Nexenta has been around for 2+ years and still not finished the process to being a Debian port. Is it because the parent company is too busy trying to sell storage appliances or they simply don't have any developers to pull it off? The long term maintenance plans for the project to stay in sync with both upstream OpenSolaris and Debian/Ubuntu is fatally flawed and will cause extraneous effort. Then ask yourself.. why? If you really want ZFS + Ubuntu/debian/linux then please.. start work on that.. smf and a lot of the other useland tools *can* be ported to linux with relative ease if you guys actually knew what you were doing..
The x86 iso includes 64bit kernel. It auto detects on boot.
It's not possible to compile Opensolaris without downloading and using a whole bunch of binary components which are distributed under a proprietary license. (see here for details.
This is in stark contrast to OpenBSD (and to a lesser degree NetBSD and/or FreeBSD -both of which include proprietary binary-only blobs). Their license is OSI approved, but you can't compile a working system using only the parts that are open source.
And this is after three and a half years, guys.
We need to prevent another monoculture in the information sector, even in open source. If everyone uses the same kernel, they will all have the same vulnerabilities. Safety in numbers means having more than one popular kernel.
Let me clarify this before someone gets confused -by "Their" I only meant Opensolaris.
NetBSD and FreeBSD include binary blob device drivers -but you can compile a working system without them.
You can't compile a working system without using the binary-only components of OpenSolaris.
only SPARC 64 is supported, 32 bit SPARC was dropped from any Solaris support with the release of S10.
as for the x86 port, it is both, you don't need a separate distro for 64 bit support because of isaexec and a smart kernel
So come help rewrite them.
Thus is the power of open source. If you don't like something, change it
Perhaps you are just jaded.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
> you... unplug its Linux kernel, and plug in a[n]... OpenSolaris kernel...
What happens?
Neither Linus nor Richard are happy.
I have been working with Solaris for many years. When OpenSolaris was announced, I jumped for joy at what could be accomplished. When it was just a re-release of Solaris major, I said, ok, well, it is a certified Unix(tm) and now open source. But when they started working on Indiana, their replacement for the old Solaris system, I again jumped for joy, a chance to remove the cruft, while keeping ZFS and other Solaris goodies. When Ian jumped on the project, I thought, HOLY cow, we can get Debian GNU/Solaris. Well...... Guess what, they had to re-implement dpkg, why, well, I don't rightly know. Sure, you can install the old packages on the system and you now get a network repository, but darn it, why not just go with the darned proven system. Their current ipkg will break a system if the upgrade doesn't go well. I know dpkg can theoretically do this, but why re-code something that has had YEARS of testing and is used by almost half of the Linux community? I don't get it. Why the heck did they decide to re-implement something that could work so well? Just because it is GPL doesn't taint the core OS, it sits in userland. This must be so that they can sell proprietary Indiana builds to those who don't want to play out in the open. That is the only reason I can see. I really hoped for a good package system, but instead, we get a "me-too" system. It just doesn't make sense. And yes, I have been following OpenSolaris since it was barely usable, about nv 40 or something like that. I really wanted an old school Unix to survive, but at this point, I can't see it happening. They are now, not "Unix" they are "Not Linux" and I don't think they can handle the new market. Their Open Source strategy doesn't make sense. Their new storage line, I cannot see where this has a market. Sure, you get support, but once it is up and running well, there isn't much need for that support. There are much cheaper solutions for the SMB to MB segment, with much better support plans. I hope they survive for MySQL, VirtualBox, Java and NetBeans' sake, but I am not quite sure about it. I cannot find a revenue stream that they are first in class for anymore. Their workstations are a joke. I put together a home made Ultra 24 with the same specs for half of what they are asking. This was when they used the slower Q6600 quad cores. I see they upgraded. For outfitting a small to medium development group, I can't see going with the support premium. I know, support, etc... but hey, I can buy a service plan separately for OpenSolaris and when the H/W fails, just buy a new quad core workstation, which will be faster than the one it is replacing. I can't see the price premium. Apple is another story. Their system is integrated and will only work on their hardware. Sun is trying to compete in the commodity OS market. I just don't see it happening. Comments are welcome.
One Token Ring to Rule them All, One Search Engine to Find Them, One WAN to bring them in, and TCP/IP Bind them...
This isn't the only problem with libc/compilers in Solaris. A few years ago, I was trying to use Solaris 10 to do a project in perl. The project had to do with parsing street addresses, so I was trying to use the CPAN module for that. Turns out that the Sun provided perl binary on Solaris is absolutely borked because it is compiled on the Sun Forte compiler and it won't work with CPAN, which expects to build parts of its modules against GCC and there are some fatal incompatabilities. There are some work-arounds involving shims, but they are serverly non-trivial and I never got them working properly. I was using solaris because all the data was in a berkley-db on the solaris box. I ended up runing the perl part on linux and mounting the berkley-db directory via NFS, which was far easier and reliable than trying to untangle the entire shim business. The other option, I suppose, might have been to compile a completely new perl binary against GCC/glibc and call that whenever I used my project. But still, a major tool like perl should "just work". Perl without CPAN isn't much use. I was completely flabergasted.
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) 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.
I am TheRaven on Soylent News
Hi, I'm one of NCP (Nexenta Core Platform) developers. The Ubuntu part of Nexenta is the userland. So over 5000 apps that you see in our repository are ports of 8.04 counterparts.
Theres some more information for developers in an article I wrote over at OSnews.
http://dilemma.gulecha.org - My philospohical short film.
Let's get this straight, an article about the new version of Nexenta (2.0alpha - you did RTFA, right?) comes out, and you complain that nexenta hasn't been updated ;-) ? The reason for the delay is nexenta tracks ubuntu's long term releases.
I agree with you on Nexenta's irrelevance, though. Nexenta just isn't worth it unless you need untrained monkeys to administer the thing.