8 ms·

I wouldn't call illumos "thriving". Commit activity[1] is low for a project of this size (compared to e.g. BSDs) and its hardware support is poor. Probably the

I wouldn't call illumos "thriving". Commit activity[1] is low for a project of this size (compared to e.g. BSDs) and its hardware support is poor. Probably the biggest problem is the fact that all existing distributions are undermaintained and unpolished. SmartOS is the only exception, but it's not a replacement for Solaris which was a general-purpose server OS. SmartOS is merely a bare-metal hypervisor. I really hope that some of the laid-off developers will start contributing to the project. It really needs them. [1] - https://github.com/illumos/illumos-gate/commits/master https://github.com/illumos/illumos-gate/commits/master

Philipp__ 9y ago
I can relate to your statement to some extent. Why illumos is not "thriving" is _maybe_ because it does not have solid general purpose distribution. Tribblix is kinda trying to get there, but I haven't used it for more than few sessions inside VM. Dream OS for me would be something ala OpenBSD, but built on top of illumos and with all the goods that would come with it.
- paulmd 9y ago
  Wouldn't that be OpenIndiana?
foxhop 9y ago
SmartOS is better then Solaris for servers. It's truly badass. I have an HP DL160 G6 running SmartOS in my basement. If you learn to use zones (which you should) it can run any workload that Solaris can. On top of that it also runs native Linux containers and KVM for virtualizing everything else. It's hands down my favorite operating system.
- Vivtek 9y ago
  Well, and as of Friday, of course, SmartOS is infinitely better than Solaris.
bcantrill 9y ago
While I'm obviously biased, I think you are succumbing to a kind of cargo culting with respect to both commit activity and hardware support. On commit activity, we in illumos don't necessarily have the same values as other projects: we really want to get it correct the first time -- a trait inherited from Solaris that we call "FCS quality all the time."[1] As such, commits have to be tested, thoroughly reviewed (four or more reviewers is not uncommon), and (as a practical matter) are more often than not shipping in a downstream repo for an extended period of time before they integrate upstream into illumos. In short, we value quality much, much more than quantity -- and what you perceive to be "low" activity I perceive to be quality activity (and as someone who very much relies on the ability to stay current and deploy into production, high commit activity would leave me nervous). In terms of hardware support, you need to be specific. Yes, there is esoteric hardware we don't support -- but we in illumos are really focused on the server-side, where there is less hardware variation than you might realize. At the moment, the biggest hardware limitations aren't in the traditional domain of CPU/NIC/HBA/flash/spindle (where we have broad support), but rather in the emerging domain of the GPGPU. And anyone who is interested in engaging in the substantial kernel work in this domain (both to make NVIDIA-based GPGPUs to work in hardware virtualized guests and to allow AMD-based GPGPUs to work natively) should consider reaching out -- Joyent is very much hiring![2] [1] http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-fetid-and-grimy/ http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-f... [2] https://www.joyent.com/about/careers https://www.joyent.com/about/careers
- sintaxi 9y ago
  This is worth pointing out. To me high commit activity is much more an indicator of poorly designed software than a quality project especially when a project has been focused on solving a particular problem for some time. This Solaris news is disappointing. I feel bad for those of you who have worked on this project for a significant portion of your career. Hope those who have been working on it find a good home somewhere. Bryan, do you expect this will affect the direction of SmartOS in any significant way?
  - bcantrill 9y ago
    For us, with the exception of the human toil on former colleagues (which shouldn't be minimized), this is a total positive: it eliminates the Solaris confusion (which we've seen recently in Go[1]), and it gives us a new talent pool to draw into illumos. While I don't know how many will matriculate, I can say with confidence that it will be significant in terms of magnitude if not in terms of numbers. So yes, I expect it to affect the direction of SmartOS -- and very much for the better! [1] https://github.com/golang/go/issues/20603 https://github.com/golang/go/issues/20603
Sir_Cmpwn 9y ago
Hardware support is by far the stupidest complaint that prevails when people talk about operating systems. Choose your hardware for your software, not the other way around. There are so many better things operating system authors have to do than to implement thousands of competing proprietary hardware interfaces. Mature support for even 50% of consumer hardware would take a massive team of full time engineers years to pull off, and would be wasted when that team could have been making huge strides and innovations in the parts of the OS that actually matter. If your hardware isn't supported and you don't like it, get your ass into the code and build support for it.
- helper 9y ago
  Illumos has a lot of nice features I'd like to use. But my product is a small low power ARM device and I'd run out of money long before I'd finish adding minimal ARM support to illumos. Things are not as simple as you suggest.
  - Sir_Cmpwn 9y ago
    Minimal ARM support would probably be pretty easy. 3 or 4 weekends tops.
- jimktrains2 9y ago
  > . Choose your hardware for your software, not the other way around. Oh, look at Mr "I don't need to use what's laying around" over here.
  - Annatar 9y ago
    It's a lesson one learned fairly quickly in the late 1980's and early-to-mid 1990's on the Commodore Amiga. Since then, I've always chosen my hardware for my software, because software is infinitely more important than the hardware: even the most powerful hardware is utterly useless without the software to enable one to get work done. Always choose your hardware for your software, never the other way around.
tgtweak 9y ago
I believe most effort moved to OpenIndiana.

Philipp__ 9y ago

I can relate to your statement to some extent. Why illumos is not "thriving" is _maybe_ because it does not have solid general purpose distribution. Tribblix is kinda trying to get there, but I haven't used it for more than few sessions inside VM. Dream OS for me would be something ala OpenBSD, but built on top of illumos and with all the goods that would come with it.

paulmd 9y ago
Wouldn't that be OpenIndiana?

foxhop 9y ago

SmartOS is better then Solaris for servers. It's truly badass. I have an HP DL160 G6 running SmartOS in my basement. If you learn to use zones (which you should) it can run any workload that Solaris can. On top of that it also runs native Linux containers and KVM for virtualizing everything else. It's hands down my favorite operating system.

Vivtek 9y ago
Well, and as of Friday, of course, SmartOS is infinitely better than Solaris.

bcantrill 9y ago

While I'm obviously biased, I think you are succumbing to a kind of cargo culting with respect to both commit activity and hardware support. On commit activity, we in illumos don't necessarily have the same values as other projects: we really want to get it correct the first time -- a trait inherited from Solaris that we call "FCS quality all the time."[1] As such, commits have to be tested, thoroughly reviewed (four or more reviewers is not uncommon), and (as a practical matter) are more often than not shipping in a downstream repo for an extended period of time before they integrate upstream into illumos. In short, we value quality much, much more than quantity -- and what you perceive to be "low" activity I perceive to be quality activity (and as someone who very much relies on the ability to stay current and deploy into production, high commit activity would leave me nervous). In terms of hardware support, you need to be specific. Yes, there is esoteric hardware we don't support -- but we in illumos are really focused on the server-side, where there is less hardware variation than you might realize. At the moment, the biggest hardware limitations aren't in the traditional domain of CPU/NIC/HBA/flash/spindle (where we have broad support), but rather in the emerging domain of the GPGPU. And anyone who is interested in engaging in the substantial kernel work in this domain (both to make NVIDIA-based GPGPUs to work in hardware virtualized guests and to allow AMD-based GPGPUs to work natively) should consider reaching out -- Joyent is very much hiring![2] [1] http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-fetid-and-grimy/ http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-f... [2] https://www.joyent.com/about/careers https://www.joyent.com/about/careers

sintaxi 9y ago
This is worth pointing out. To me high commit activity is much more an indicator of poorly designed software than a quality project especially when a project has been focused on solving a particular problem for some time. This Solaris news is disappointing. I feel bad for those of you who have worked on this project for a significant portion of your career. Hope those who have been working on it find a good home somewhere. Bryan, do you expect this will affect the direction of SmartOS in any significant way?
- bcantrill 9y ago
  For us, with the exception of the human toil on former colleagues (which shouldn't be minimized), this is a total positive: it eliminates the Solaris confusion (which we've seen recently in Go[1]), and it gives us a new talent pool to draw into illumos. While I don't know how many will matriculate, I can say with confidence that it will be significant in terms of magnitude if not in terms of numbers. So yes, I expect it to affect the direction of SmartOS -- and very much for the better! [1] https://github.com/golang/go/issues/20603 https://github.com/golang/go/issues/20603

Sir_Cmpwn 9y ago

Hardware support is by far the stupidest complaint that prevails when people talk about operating systems. Choose your hardware for your software, not the other way around. There are so many better things operating system authors have to do than to implement thousands of competing proprietary hardware interfaces. Mature support for even 50% of consumer hardware would take a massive team of full time engineers years to pull off, and would be wasted when that team could have been making huge strides and innovations in the parts of the OS that actually matter. If your hardware isn't supported and you don't like it, get your ass into the code and build support for it.

helper 9y ago
Illumos has a lot of nice features I'd like to use. But my product is a small low power ARM device and I'd run out of money long before I'd finish adding minimal ARM support to illumos. Things are not as simple as you suggest.
- Sir_Cmpwn 9y ago
  Minimal ARM support would probably be pretty easy. 3 or 4 weekends tops.
jimktrains2 9y ago
> . Choose your hardware for your software, not the other way around. Oh, look at Mr "I don't need to use what's laying around" over here.
- Annatar 9y ago
  It's a lesson one learned fairly quickly in the late 1980's and early-to-mid 1990's on the Commodore Amiga. Since then, I've always chosen my hardware for my software, because software is infinitely more important than the hardware: even the most powerful hardware is utterly useless without the software to enable one to get work done. Always choose your hardware for your software, never the other way around.

tgtweak 9y ago

I believe most effort moved to OpenIndiana.