| |||||||||||||||||||
The Illumos Project decloaks on August 3
A number of the community leaders from the OpenSolaris community have been working quietly together on a new effort called Illumos, and we're just about ready to fully disclose our work to, and invite the general participation of, the general public. We believe that everyone who is interested in OpenSolaris should be interested in what we have to say, and so we invite the entire OpenSolaris community to join us for a presentation on at 1PM EDT on August 3, 2010. You can find out the full details of how to listen in to our conference, or attend in person (we will be announcing from New York City) by visiting http://www.illumos.org/announce (The final details shall be posted there not later than 1PM EDT Aug 1, 2010.) We look forward to seeing you there! - Garrett D'Amore & the rest of the Illumos Cast -- This message posted from opensolaris.org (Log in to post comments)
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 14:19 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Rather odd for a Free software project to announce the launch in such vague terms. Why wait for a conference instead of just sending the mail with the details to the mailing list and be done with it?
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 14:26 UTC (Mon) by kartik (subscriber, #54526) [Link]
Looking forward to see something new at DebConf10!
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 16:03 UTC (Mon) by clump (subscriber, #27801) [Link]
Indeed. It does seem counterproductive compared to other free/open projects.
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 18:45 UTC (Mon) by lkundrak (subscriber, #43452) [Link]
To get more attention? (not sure if I'm not answering a rhetorical question)
Though I doubt they'll get more attention from potential contributors this way; probably just scare them away the very same way opensolaris did.
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 19:07 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
IMO, this type of attention grabbing tactics has a negative impact and it is better to just announce it when ready instead of setting up a conference which is a rather unusual way to launch it and the secretive nature of the launch rubs potential participants the wrong way. This is not a fatal failure but I don't consider it a good approach either.
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 19:35 UTC (Mon) by jengelh (subscriber, #33263) [Link]
Usuaully because one tends to forget to attend the conference easily, esp. in the virtual world.
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 3:44 UTC (Tue) by drag (subscriber, #31333) [Link]
> Rather odd for a Free software project to announce the launch in such vague terms. Why wait for a conference instead of just sending the mail with the details to the mailing list and be done with it?
Because it allows them to set the agenda the way they see fit rather then get into a bunch of messy discussions in some mailing list.
The message is pretty obvious: 'This is our project we made. If you want to work with us then we have created a conference you can attend and you can discuss it with us.'
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 4:02 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
The "messy discussions in some mailing list" is how projects get participation. If you want just to send a announcement, send it to the announce only mailing list. Record a self video and send a link if you want. How does setting up a conference avoid it anyway? Post announcement, you will have to engage in mailing list discussions at some point. A conference just makes it more inaccessible to a lot more people.
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 4:40 UTC (Tue) by drag (subscriber, #31333) [Link]
> A conference just makes it more inaccessible to a lot more people.
And what if that is what you want?
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 4:46 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Do you assert that this project is trying to deliberately make it inaccessible to more people? I have no reason to believe that. This appears to be just marketing tactics with some unintended consequences. Hardly the first time this has happened. Remember the GNOME Mobile launch discussions?
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 7:04 UTC (Tue) by drag (subscriber, #31333) [Link]
*shrug*
What I am asserting is that the people in charge of the project want to make sure to everybody that they are the ones in charge. There are a few different reasons why somebody would want to start a project like this and apparently they are aiming for recognition, whether entirely couscous or not is not really relevant. Maybe that what happened with the Gnome thing you linked, maybe not.
If they were aiming for a all-inclusive type of approach they would of gone through pains to get as many people interested early on as possible.
That's all. I am not saying they are committing a terrible sin or anything like that. It's their project and they can run it however they please.
The asked earlier as to why they would take this approach and odd secrecy and this is my suggestion. I suppose I was not just clear enough in my original post.
The Illumos Project decloaks on August 3 Posted Aug 4, 2010 13:35 UTC (Wed) by kartik (subscriber, #54526) [Link]
http://lwn.net/Articles/398605/ is the answer..
The Illumos Project decloaks on August 3 Posted Aug 4, 2010 14:22 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
That explains what they were doing but not why they choose the approach they did but I guess Sun's culture is a good explanation as any.
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 7:15 UTC (Tue) by paulj (subscriber, #341) [Link]
Probably cause the people involved are steeped in Sun culture, in which conference calls are a normal and regular work tool.
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 14:41 UTC (Mon) by SEJeff (subscriber, #51588) [Link]
Heres to hoping it isn't another complete dud like "Project Indiana". Whatever happened to Ian Murdoch anyways?
Call me a sceptic, but hopefully they can make solaris relevant again compared to the Linux juggernaut. I doubt it.
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 15:33 UTC (Mon) by nix (subscriber, #2304) [Link]
What do you mean, a complete dud? The Indiana package manager is there, and so are the packages, aren't they?
(And it's 'Murdock'. Murdoch is a media mogul.)
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 16:18 UTC (Mon) by SEJeff (subscriber, #51588) [Link]
I took the idea of Indiana to more or less be, "Project Kill Linux" or "Project make Solaris a bit more GNU so noob admins stop hating on it". Hiring the guy who build Debian is a perfect example of why that perception exists.
Solaris is a great base, but it's popularity with the young crowds is quickly waning. It's a shame too. In massive threading and db style workloads it still is better than Linux.
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 17:12 UTC (Mon) by Nick (guest, #15060) [Link]
By what measures is Solaris better than Linux at database or massive threading workloads?
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 17:41 UTC (Mon) by SEJeff (subscriber, #51588) [Link]
Well in performance, Linux spanks solaris (just about always) across the board. Especially in my own Oracle experience.
The latest generation of sparc processors runs more threads concurrently than just about anything else. The Niagara 3 [1] can run 128 concurrent threads. An x86 cpu simply can not do that. Solaris was built to take advantage of this. Back in the Linux 2.4 days, linux really sucked at threading. With the advent of Linux 2.6 and NTPL, most of those previous gripes went away. Solaris has done threading well the entire time however.
While I'll almost always defend Linux _over_ solaris, my experience with massive Oracle databases and Linux has always been subpar compared to Oracle with the same configuration on Solaris. You'll often run into weird kernel bugs or obscure errors where solaris "just works TM".
[1] http://en.wikipedia.org/wiki/SPARC#SPARC_microprocessor_s...
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 22:05 UTC (Mon) by joib (guest, #8541) [Link] The latest generation of sparc processors runs more threads concurrently than just about anything else. The Niagara 3 [1] can run 128 concurrent threads. An x86 cpu simply can not do that.Well no, but OTOH x86 CPU's have a lot better single threaded performance, are generally significantly cheaper, and, amusingly, at the higher end are used to build bigger monster machines than SPARC ever has, e.g. SGI Altix UV with 4096 hw threads, running Linux. Of course, this doesn't per se prove that Linux scales better than Solaris, generally speaking. The HPC apps that the Altix is designed for don't really stress the kernel to the same extent as maybe some DB workload. So it might be that Solaris is better, say, for some 128-way DB machine. Or then maybe not, unfortunately I haven't seen any relevant benchmarking. Solaris was built to take advantage of this. My guess would be the opposite; just like Linux isn't re-architected every time Intel or AMD spits out a new x86 chip, neither is Solaris when a new SPARC chip is launched. Solaris has done threading well the entire time however. Well, I recall Solaris spent a long time in the wasteland of M:N threading before finally switching to a lightweight and scalable 1:1 model with Solaris 9, similar to Linux NPTL. Of course, one could argue that Solaris threading before 9 was still pretty Ok, Linux pre-NPTL, not so much. But that's all a long time ago now anyways.
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 8:36 UTC (Tue) by TRS-80 (subscriber, #1804) [Link] My guess would be the opposite; just like Linux isn't re-architected every time Intel or AMD spits out a new x86 chip, neither is Solaris when a new SPARC chip is launched.Sun put in a fair amount of engineering work for the UltraSPARC T (Niagara) series. Here's some blog entires describing the work done for the T2 and T2 Plus.
Performance comparison, or [citation needed] Posted Aug 2, 2010 17:20 UTC (Mon) by cesarb (subscriber, #6266) [Link]
> In massive threading and db style workloads it still is better than Linux.
I have been reading for a long time things like "in workload X Solaris is better than Linux" or "in workload Y Linux is better than Solaris". I wonder if it is really true or is just a self-propagating meme from some time last century when it was actually true. After all, both systems are continually improving (at least Linux is; I am not following Solaris development, but I suppose it is too).
Does someone know of benchmarks which compare recent Solaris releases with recent Linux releases (say, less than 1 year old for each) for these sorts of workloads? Preferentially with error bars? This way, we would be sure to have still relevant data.
Performance comparison, or [citation needed] Posted Aug 2, 2010 18:26 UTC (Mon) by avik (guest, #704) [Link]
I'm not sure a fair comparison is possible. Solaris is optimized for SPARC, while Linux is optimized for x86.
If one of the kernels beats the other on its native ground, though, that would be telling.
Performance comparison, or [citation needed] Posted Aug 2, 2010 19:15 UTC (Mon) by cesarb (subscriber, #6266) [Link]
You could do two comparisons then: one on SPARC and one on x86. We could then say "Solaris is X% faster/slower than Linux on SPARC, and Y% slower/faster than Linux on x86, on this workload and on the machines I tested". It would still be better than nothing, and much better than the "common knowledge" of which one is faster, based on experiences from last century, which is what people seem to use.
Performance comparison, or [citation needed] Posted Aug 2, 2010 22:29 UTC (Mon) by joib (guest, #8541) [Link] Solaris is optimized for SPARC, while Linux is optimized for x86.Is that a relevant distinction? I mean, what design decisions would be different if you're optimizing for SPARC vs. x86? Looking at Linux, except for the necessary arch-specific code such as memory barriers, some locking primitives and such, the rest of the kernel seems more or less oblivious to architecture differences. Performance and scalability comes from appropriate data structures and algorithms, and obviously things like the balance between cpu speed vs. memory bw/latency vs. cache-coherency fabric bw/lat vs. disk subsystem vs. network etc. affect the choice of data structures and algorithms. But surely even within an architecture, different systems exhibit bigger differences in the balance between these factors than any inherent difference between the architectures per se? Not to mention how dramatically these balances have changed during the lifetime of the respective kernels.
Performance comparison, or [citation needed] Posted Aug 8, 2010 19:18 UTC (Sun) by nix (subscriber, #2304) [Link]
If you were using a SPARC you could use register windows to improve performance... although as far as I know nobody has ever found a way to make register windows anything but a pain in the neck in multitasking environments, as you have to throw the whole thing out whenever you context-switch. So we could mark this up as a doubly-theoretical speed boost.
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 17:41 UTC (Mon) by ewan (subscriber, #5533) [Link] Solaris is a great base, but it's popularity with the young crowds is quickly waning. It's a shame too. In massive threading and db style workloads it still is better than Linux.Once upon a time, long ago, hardware was expensive, and it made sense for admins to do whatever it took to get the best out of it. Now, hardware is cheap, and it's usually more cost-effective to throw kit at a performance problem than it is to spend the admin effort needed to support a whole different OS for niche workloads.
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 19:07 UTC (Mon) by nicooo (guest, #69134) [Link]
It depends on your definition of "young crowds". They can't hate Solaris because they don't even know it exists. It would have to appeal to high school kids and things like ZFS or being good at running Oracle doesn't. OpenSolaris could have changed that, but its future doesn't look too good. So, noob admins have several years of experience with Linux before they even come into contact with a machine running Solaris.
Whether you're targeting routers and firewalls, big databases, cell phones, supercomputers or even mainframes, your OS needs to be available on regular PCs.
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 0:41 UTC (Tue) by cmccabe (guest, #60281) [Link]
> Solaris is a great base, but it's popularity with the young crowds is
> quickly waning. It's a shame too. In massive threading and db style > workloads it still is better than Linux.
One thing I liked about Solaris is their attitude towards thread-safety in the libC. For example, getenv is thread-safe in Solaris. A lot of nasty and hard-to-spot bugs just evaporate.
I thought I saw a post somewhere that said that every libC function was thread-safe in Solaris. I can't find it now, and I don't know if that is true.
It wouldn't really be that hard to have a threadsafe glibc. It's just that every place where you would normally use a static buffer, you use a thread-local buffer. I think nearly every programmer would link against such a libc if it were available.
I think the only real rationale for not using thread local storage in glibc is that it would involve a dependency on pthreads. Pointing to POSIX is just passing the buck. After all, POSIX gave us the "wonderful" readdir_r:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-N...
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 5:26 UTC (Tue) by jhhaller (subscriber, #56103) [Link]
> I thought I saw a post somewhere that said that every libC function was thread-safe in Solaris. I can't find it now, and I don't know if that is true.
They certainly weren't all thread-safe when I was using Solaris 8. And the APIs which were thread-safe were occasionally so slow that no one in their right mind would use them. Standard I/O was one of the slow ones, where if compiled for threading, every character would take a lock. I had an occasion to implement a TFTP server which implemented the large block size, as Solaris's TFTP did not at the time. Performance was abysmal until I implemented my own I/O using read/write. At the time, the only thread-safe calls were the ones labelled as MT-Safe. Surprisingly, "system" was not labeled as MT-Safe, so for a different project, we had to convert many system(3c) calls to popen/pclose. This remains true through Open Solaris 11.
The good part of Solaris was that its documentation was very explicit about whether a particular API was thread-safe or not. While the glibc manual does list this information, the glibc manual pages do not.
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 19:39 UTC (Tue) by bronson (subscriber, #4806) [Link]
> I think nearly every programmer would link against such a libc if it were available.
I sure wouldn't. Why should every app pay the thread-safety penalty?
The Illumos Project decloaks on August 3 Posted Aug 4, 2010 1:53 UTC (Wed) by cmccabe (guest, #60281) [Link]
Using thread-local data should be as easy as doing a bitmask on the stack pointer (SP) and then adding an offset. I just don't see that causing a major performance regression.
The exponential increase over the next few years will be in the number of cores, not megahertz. In a few years "high performance non-threaded application" will be as incomprehensible as a screen door on a submarine. (I guess there will be a few people who will go the multi-process route, but so far they seem to be in the minority by far.)
The Illumos Project decloaks on August 3 Posted Aug 8, 2010 16:27 UTC (Sun) by bronson (subscriber, #4806) [Link]
"In a few years, every program will have to be threaded!!" I've been hearing that for over ten years now. We'll see...
Once the number of cores is unmanageably high (like, WAY higher than 12), I expect someone will come up with a good solution to concurrency. I doubt it will be threading. Threaded code is moderately painful to write and seriously painful to maintain. We can do better.
The Illumos Project decloaks on August 3 Posted Aug 8, 2010 13:22 UTC (Sun) by nix (subscriber, #2304) [Link]
s/noob admins/anyone who has to do actual software development on a Solaris box/g
The Illumos Project decloaks on August 3 Posted Aug 2, 2010 17:23 UTC (Mon) by jengelh (subscriber, #33263) [Link]
Illumos, ... IllumOS. Sounds like a spoonfork.
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 2:13 UTC (Tue) by jiu (subscriber, #57673) [Link]
LuminOS would have sounded so much better...
The Illumos Project decloaks on August 3 Posted Aug 3, 2010 16:04 UTC (Tue) by captrb (subscriber, #2291) [Link]
Judging by the announcer and their blog, this appears to include participation from Nexenta. That may imply that this is a Solaris+Debian userland project.
Some background (making OpenSolaris really Free Software) Posted Aug 3, 2010 17:36 UTC (Tue) by mjw (subscriber, #16740) [Link]
Simon Phipps describes Illumos is to OpenSolaris, as what IcedTea is to OpenJDK: http://www.computerworlduk.com/community/blogs/index.cfm?...
And they already have some code liberated (like the libc library):
|
|||||||||||||||||||