There's a lot of little things you'll notice over the years about Solaris / OpenSolaris that are unique, cool, neat, or useful -- too many to list in an article like this, of course. One example I was reminded of by the "differences" table -- the authors note that the Solaris equivalent of Linux's "/tmp" is "/var/tmp" -- but they failed to point out that Solaris also has a/tmp, and that, by default/tmp is actually partially backed by RAM, which is extremely convenient and useful from time to time, when you want a little piece of lightning-fast filesystem space, or want to eliminate disk as a variable in some sort of timing test. Of course, linux also has ramdisks, but this is generally far more convenient.
$ time dd if=/dev/zero of=/var/tmp/foo bs=1024k count=128 128+0 records in 128+0 records out dd if=/dev/zero of=/var/tmp/foo bs=1024k count=128 0.00s user 0.71s system 24% cpu 2.910 total
$ time dd if=/dev/zero of=/tmp/foo bs=1024k count=128 128+0 records in 128+0 records out dd if=/dev/zero of=/tmp/foo bs=1024k count=128 0.00s user 0.43s system 98% cpu 0.438 total
While we're talking about drivers, you touched on something. Yes, Linux is way out ahead of Solaris x86 in terms of hardware support, however one major pain with Linux is binary driver dependence on minor kernel versions. This is a serious problem for the 'enterprise' server crowd, where to patch my kernel, I must wait on the slowest ISV who happens to have a binary-only module in my kernel. Even if I have source, as the AC pointed out, whipping out a compiler because you want your HBA driver to continue to work after applying a kernel update is pretty LOL for an 'enterprise' OS.
I think we're all agreed that using kernel modules from third parties is something to avoid where possible on any platform, but it's a reality that many in the corporate world have to live with. Compare to Solaris, where it is unheard of for a particular build of a particular driver that works with any minor revision of a given kernel to not work with any other minor revision of that same major. Put another way, if driver xyz works with any Solaris 9 kernel, I can bet my job that it's going to work with any other Solaris 9 kernel, and heck, it'll probably even work with any Solaris 7, 8, or 10 kernel, too.
Even outside of drivers and kernel modules, Solaris' binary compatibility is something you seriously start to appreciate, believe me.
"Supercomputer" is an odd term to use these days. I assume you're referring to large clusters as opposed to large single-image machines? The former isn't nearly as difficult a job, kernel-wise. Linux on large (i.e. >8 CPU) single-image machines still seems pretty fringe to me. I understand many of the relevant patches weren't rolled in until as recently as 2.6.9, and while I've of course, not done any testing yet myself, an HP presentation I just read on "BigTux" was mysteriously vague on speedup results for some of their benchmarks, and offered no comparisons to HP/UX running the same benchmarks on the same hardware. To be fair, it wouldn't be scientific to blame all vertical scalability problems on Linux alone, since we're also talking about IA64, in this example.
The other problem outside of raw performance is the other 'enterprise' features (usually) become absolute nececessities on large single-image boxes. Namely, I'm talking about a modern resource management facility, very good and very safe visibility tools, and the ability to fully leverage all of the dynamic hardware reconfiguration features the machine's vendor provides.
I think a relevant question to ask is how advantageous it is to each specific market to have that wide focus you mention. You gave one example, of exposing bugs - I won't argue with that, but I do wonder at the exact quantity of its utility, compared to possible disadvantages of the same wide focus. It seems to me that compromise is inevitable, and no doubt there are decisions made (either of inclusion or omission) that benefit one market at the expense of another. There is an argument to made for specialization, and Solaris has (with brief, embarassing exceptions) never purpoted itself as anything but laser-focused on being the best server OS. Alright, it's also been billed as an engineer/workstation OS, but by the time I became heavily involved with Solaris, it was already a better bet in most cases to use Linux on x86 workstations for that. [In a research lab I worked at in the late 90s, my boss got 'that look on his face' when I showed him how the Pentium III we used for burning CDs was outperforming the Ultra 60 he'd just bought (for a pretty penny, of course) to run MATLAB.]
'BigTux' also gets me thinking about a phenomenon I've noticed. Here we see an example of HP throwing a lot of resources and money at helping Linux get better. However, no one is really kidding themselves (I hope) that this is an altruistic move on their part. They have an obvious incentive to help Linux perform well on Superdome, in that they are abandoning HP/UX, and will be left without a Unix-like OS for their big boxes, unless Linux can improved enough to do the job. All of the x86 hardware vendors are flexing considerable money and marketing muscle to either improving Linux technologically, or pushing adoption. However, all of this is happening in just one market - the server, and they are all doing it for reasons that should be obvious to anyone who wants to stop and think about the business strategies of each of these companies. Dell being the best example of this, consider their position. They are pushing Linux adoption extremely hard, using their excellent marketing and FUD machines to their fullest extent, but they are only pushing Linux in one role - replacement of UNIX servers. Turning one installed Solaris machine into four Dell machines is obviously a good idea for them. Turning four Dell servers running Windows into four Dell servers running Linux - well, what does Dell get out of that, aside from Microsoft's wrath? Turning a Dell desktop running Windows into a Dell desktop running Linux, what does that get them? Nothing but MS wrath. So, my beef here is that we already had an embarrassment of riches in the server space - several very good, very well accepted, very understood, and very open-standard friendly server OSs. Not to mention a few that were already open source and free. This, to my mind, is where Linux was
You'll get zero argument from me, as far as the laptop/desktop/embedded stuff. Solaris has never been well-suited (or even an option) for those tasks, and I don't see it catching up to Linux in the near future, either. Solaris isn't even "second" to Linux in that space, as far I'm concerned. It's way, way back, behind Windows, MacOS, Linux, BSD, and who knows what all else.
As to servers though, I completely disagree. If Linux's development is so far outpacing Solaris's, why has it been consistently behind in 'enterprise' features for over a decade? Don't get me wrong, please - I'm a huge Linux fan and have been a heavy Linux user for years longer than I've been a heavy Solaris user (Slackware 1 vs. Solaris 2.6, as far as when I got majorly involved with each), but I do not see Linux significantly closing the gap on Solaris in server features. 2.6 was a huge step, but then, predictably, Solaris 10 shipped, and it was at least equally as huge, to my mind.
Re:Before you comment ...
on
Debian GNU/Solaris
·
· Score: 3, Insightful
What is your criteria for calling the Solaris kernel a "far second" to Linux? OSS community involvement? x86 hardware support? ISV support on x86? I'll give you those three, but if you've got something else in mind, you'll probably get an argument from me and others who have used both kernels for a long time.
I also don't see Solaris' lead diminishing, let alone rapidly. If anything, it appears to me that Sun further widened the gap with Solaris 10. Sun is regularly releasing very advanced and important OS features, in fully-baked and rock-solid form, and the FOSS community is doing its best to keep up, but even though Solaris 10 shipped nearly a year ago, look at the current state of SystemTap, for example - a project spawned in direct response to Solaris 10 dtrace, that is still nowhere near ready to primetime. Where (for example) also is the modern full-fledged resource management? This is a critical feature for an 'enterprise' kernel, and it's still nowhere in sight, though everyone's known it's been necessary for Linux to achieve for several years.
It's one thing to reimplement BitKeeper in a month - advanced kernel features are something else entirely, and we have a decade to look back on and see Sun's record of innovating and Linux following. What happens when Linux has cannibalized the last true innovator, and there's no one left to follow? Lest you think I'm trolling, I have a serious question: what major kernel innovations in the last decade appeared in Linux *first*? I can think of one, maybe two, but put up against the parade of inventions and innovations that have come from Solaris in the last decade, I don't know.
Re:Where are the differences?
on
Debian GNU/Solaris
·
· Score: 4, Informative
A few corrections / notes:
There is no provision for running multiple kernels on the same hardware, aside from 'domaining', which is more like IBM's LPARing (prior to P5 and 5.3, that is - splitting a single server into two or more hardware partitions). But, when you do this, each partition really is its own machine, with distinct and non-shared CPUs, memory, and IO buses. You can move hardware from one domain to another (even without shutting down applications), but a given kernel is only ever running on one machine at a time.
More recently, is the concept of 'Zones'. Here, you can install seperate copies of userland onto the same box, and when you are 'inside' of any one zone, you appear to have your very own box, complete with your own/etc and everything else (or you can opt to share parts of the install with the 'global' zone), however there is still a single kernel running all of the zones on a given server. Applying a kernel patch, for example, still requires a reboot of the whole enchilada to take effect.
Actually, I believe 'Slowaris' was coined in 93 or 94 or so, when admins started switching from SunOS 4.1.3/4.1.4 to Solaris on SMP boxes, and ran into bug where no matter how many CPUs, every thread was being scheduled on the same CPU. I forget what version this was - maybe 2.3? I remember logging onto my University's student shell machine (back then, SLIP and PPP were still not being used by home users - you'd dial up to terminal into a UNIX machine to check email, usenet, or IRC). Anyway, I remember logging in and seeing a load in the thousands, just after the upgrade.
You can "upgrade on the fly", in a way. The concept is you mirror your root disk, split the mirror, perform the upgrade against the inactive mirror, and finally reboot, this time off the upgraded side. It more or less works, but you do need to use your brain. Really what it gets you is the ability to immediately revert back to the pre-upgrade image with just a single reboot, and also shortens the outage window to one reboot. They've had this since Solaris 8, I believe, and you could use it to upgrade from say 2.6 to 8.
Over time, 'Slowaris' did come to refer to the performance disparity between Linux and Solaris on x86. Until Solaris 10, Linux pretty clearly outperformed Solaris on like-hardware (x86). I think in part, as you say, due to Sun's lack of effort in optimizing for x86 and small servers, but also because x86-based benchmarks tended to focus on things like web-serving, and Sun's networking stack was long overdue for an overhaul (the first phase of which was completed for Solaris 10, and returned enormous improvements).
I'm not sure why this comment is getting -2 redundant, since as far as I know it's nowhere else in the article or the comments that I wrote reflscan and that I'm honored that Fyodor is conscientious enough to continue to mention it in interviews like these (as well as the other scanners he liked and wanted to improve upon). If the mods are detecting sarcasm in my post, they do so incorrectly.
Hey Fyodor,
I wrote reflscan, and I think it's pretty cool that you still mention it, especially since the version that got out was so crappy, and your scanner doesn't owe anything to it. Cheers.
As far as I know, there is not a single "Sun Fire" system ever made that didn't use bone-standard SCSI disks manufactured by IBM, Seagate, Fujitsu, or Hitatchi, etc (with 'proprietary' drive rails). That being said, the Sun-branded disks on their website are ridiculously overpriced, but there has never been anything technological to stop you from using whatever disks you please.
I really hate this "proprietary" phrase getting thrown around with regard to Sun. Forget that they're using AMD CPUs now (the whole point of TFA), and please go ahead and tell me how SPARC is proprietary and Intel isn't. I'd love to hear this. Not to mention that Sun has probably done more for open standards and protocols over the years than any other single company that comes readily to mind. Open source is not necessary for open standards, which really, is what matters far more to me. But, even so, Solaris is now open source as well. But please don't let over 20 years of history and assorted facts stop/. folks from crying "proprietary!" every time Sun is mentioned in the news.
Well, you're probably aware that they sell their Office tools for Mac OS. The only other instance in this vein that I'm aware (and it may surprise you) is that they made Internet Explorer available for Solaris/SPARC, for free. It didn't work incredibly well, but it worked.
Sure - sorry for the vaguely snarky tone - I was leaning toward "troll" myself, but I believe you're genuinely frustrated now.
I agree about not running 'catman -w' at install time. You'll find lots of things like this in Solaris. There seems to be a general philosophy of not making decisions for you, which you can get to appreciate, with time. I think they kind of assume that if you want to use apropos, you'll slap a 'catman -w' into one of your jumpstart scripts. Rememeber that it's really an OS geared for bigger corporate environments with dedicated staffs of sysadmins, not desktop users or casual passers-by. But, I do agree that it'd be nice for it to take care of that automatically. If that bugs you, you'll also be bugged trying to use sar, and a few other things that they except you to go explicitly enable. My big gripe is that they abandon that philosophy when it comes to which network services they'll enable - they enable pretty much all of them and expect you to go explicitly turn off the ones you don't want - in stark contrast with the general philosophy of asking you to explicitly turn on the stuff you do want. But, again, really, this is all very superficial stuff. It's not nearly enough to condemn an OS by. You just turn on the stuff you want and turn off the stuff you don't, and if you're in Sun's historical customer demographic, then you're a corporate sysadmin just adding stuff to your jumpstart scripts.
Sorry too that I didn't understand what your beef with ifconfig was. Yes, ifconfig won't show you any interfaces that haven't been "plumbed." The concept of plumbing an interface doesn't exist in Linux, of course. I don't have a Solaris machine handy to play with this second, so I can't tell you a sure-fire and elegant way to get a list of all valid-but-unplumbed interfaces, but I know it can be done. In fact, one of the Solaris install scripts does it (I believe that if you bomb out of an install or toss yourself out of a begin/finish script at the right place, and do an 'ifconfig -a', you'll see all the interfaces on the box plumbed up). I'm not suggesting that's a valid way to do it, just pointing out that it must be possible, because Solaris itself does it. Here's a hack I came up with that should do it:
By the way, comp.unix.solaris is a great resource, full of very smart and helpful people (many of whom work for Sun, including several kernel engineers) who have always spent a lot of time answering all sorts of questions, from newbie to insanely technical and complex. Some people also like BigAdmin, and of course SunSolve and docs.sun.com are invaluable. Make sure especially to check out the System Administration Guide on docs.sun.com.
Keep an open mind and be patient - it's definitely an acquired taste, especially for someone coming from Linux, but I personally think it's a truly great and unique OS that's totally worth the effort.
apropos: From the manpage you besmirch for not having been updated in 10 years:
(first paragraph):
This information is contained in the/usr/share/man/windex database created by catman(1M). If catman(1M) was not run, or was run with the -n option, apropos fails.
(footer):
SEE ALSO man(1), whatis(1), catman(1M), attributes(5)
DIAGNOSTICS /usr/share/man/windex: No such file or directory This database does not exist. catman(1M) must be run to create it.
Maybe it hasn't been updated because it hasn't needed to be?
dhcpconfig: I don't know, it worked fine for me. Our two anecdotes cancel each other out, it seems.
interface names: Yes, Solaris names the interfaces by the drivers providing them, which are in turn named for the hardware chipset (which a few exceptiosn like qfe, which stands for "quad fast ethernet" and refers to the number of chips on the cards, as opposed to the chipset). Since you seem to already know apropos, why didn't you do:
% man -k ethernet |grep driver bge bge (7d) - SUNW,bge Gigabit Ethernet driver for Broadcom BCM57xx ce ce (7d) - Cassini Gigabit-Ethernet device driver ...snip... spwr spwr (7d) - SMC EtherPower II 10/100 (9432) Ethernet device driver xge xge (7d) - S2IO Xframe 10Gigabit Ethernet Network Adapter driver
Also, I have no idea how you managed to bungle 'ifconfig -a', but it doesn't require any specific interface argument. It works almost exactly the same as on Linux ("almost", because it doesn't show you some of the interface statistics like Linux does - use kstat for that). If I were spanking-new to Solaris, I think I'd do 'ifconfig -a', and then when I saw a bge0, I'd probably try 'man bge' and what do you know?
I've found Solaris to have really pretty excellent manpages, and docs.sun.com is very, very good. I honestly wish Red Hat for example would have documentation even a fraction as complete and good as the stuff all over docs.sun.com. There's plenty of valid things to fault Solaris for, but you've hit on none of it.
This is one of my biggest pet peeves in IT journalism. How Intel CPUs are always "industry standard," and everything else is "proprietary." Tell me again how x86 isn't proprietary? SPARC is actually somewhat open, as described here. Now, I'm not saying it's open like GPL software is open, but there's an IEEE standard for the SPARC instruction set, and anyone can license the SPARC specification. There have always been two distinct vendors (Sun and Fujitsu) selling different but compatible SPARC implementations. Even after the APL goes into effect, I believe each vendor will still have SPARC chips not covered by that agreement (each vendor's low-end line).
Now, x86 has both Intel and AMD making compatible chips, but they actually have a license agreement. AMD pays Intel royalties, and it's even rumored that Intel has the right under that agreement to cap AMD's production volume. To me, it starts looking like AMD is a pet Intel keeps around to be able to say, "but we're not a monopoly, look at AMD!" You only need to look at Microsoft's legal history to see why that'd be a smart move.
"Commodity" is the other term consistently abused in discussions like this. When people say Intel CPUs are "commodity" and "industry-standard", what they mean to say is that they are "cheap" and that there are "lots of them."
If you have enough CPUs, DIMMs, and OS instances from any of those vendors, you'll see plenty of kernel panics. They all have hardware and OS related panics, you just have to have a large enough sample size to notice it.
Putting a signal on an antenna will obviously result in radiation, yes. What's not obvious though, is how much, and how quickly it falls off with distance. It's not clear to me if the entire line radiates and therefore it drops off as 1/R, or if (as some claim), it will instead fall off with 1/R^2 or 1/R^4. Add to the fact that they're notching the public frequencies, and I don't think we can necessarily trust the article's author at his (clearly biased) word that "there will be interference."
I don't know enough about this to say if anyone is right or wrong, but I do suggest reading the author's disclosure at the end of his article, and considering that the ARRL has an established position on this issue, and one that may be more emotional than rational, in the final analysis. It's also not clear from my quick read of the article if interference has been demonstrated from BPL lines complying with the new FCC rules for BPL
Within the OOo Project, Sun Microsystems, which released the project's code in 2000 and still provides most of its developers, is regarded, with some exceptions, as a community benefactor. By contrast, free software advocates view Sun -- and, by extension, OpenOffice.org -- with suspicion, largely because Sun has a history of alternately supporting and damning free and open source software (FOSS). For instance, while CEO Scott McNealy has called Sun a "heavy contributor" to open source and claimed that Sun invented it, president Jonathan Schwartz has heavily criticized the GNU General Public Licence. Although this inconsistency could be interpreted as an effort to steer a middle path between proprietary and FOSS software, or as an internal difference of opinion at Sun, more often the community has seen it as evidence of duplicity and untrustworthiness.
I think this paragraph helps explain why some people are viewing this as a somewhat anti-Sun article or conversation. I definitely wouldn't say Sun has ever "damned" FOSS. Criticizing the GPL isn't damning FOSS. If you think that, you are someone who believes that the only FOSS is GPL software, and that is simply not true. Also, Schwartz didn't really rip into the GPL - I've read all his blog comments and his speech that generated all the excitement, and his point was simply that the GPL poses problems for some of his customers, and he felt the CDDL with its MPL model was a better fit for them and for Sun. What's wrong with that? He's not even really criticizing the GPL, he's just saying it's not the right FOSS license for his company's needs. When do we stop pretending that the GPL is the only FOSS license out there and that the FSF's agenda has to be embraced for a project to be beneficial to "the community?"
It's pretty ridiculous to see the article's author claim it's an "inconsistency" or "duplicity" to embrace FOSS but criticize the GPL, even if Schwartz had been really tearing the GPL a new one, which he totally wasn't.
Finally, as to the original issue, I agree that OOo should be written at least to public interfaces, and the debate should end there. If "the community" hasn't yet produced a viable FOSS implementation of Java, that is not Sun's fault, not Schwartz's fault, not McNealy's fault, and not OOo's fault.
P.S. The paranoid and cynical (certainly not me) could see this as a backhanded attempt to further pressure Sun to open Java entirely, and if you were especially paranoid (again, not me by any means), you could further note that this is exactly what IBM is dying for, and finally, wonder why Stallman's missives always seem pretty lined up with IBM's agenda and and why they (one of the biggest patent aggressors in the industry) always seem exempt from his diatribes.
While it might not be obvious to Dell's home customers, as an architect at a very large company that does a very large amount of server business with Dell, I can tell you that they have been pushing Red Hat extremely aggressively for the last year or two. I see the pitches, roadmaps, and political jockeying from all the major 'enterprise' vendors, and I do not see anyone pitching anything as hard as Dell is now pitching Red hat.
It's an obvious and core component of their enterprise strategy to make the 'UNIX migrations to Red Hat' pitch. As you look at the typical Fortune 500 datacenter, and see the huge percentage of installed hardware occupied by Sun and IBM gear running UNIX, it doesn't take a genius to figure out what Dell's angle with Red Hat is. Dell has nothing to gain by marketing Windows migrations to Linux (on either the desktop or the server) - you're buying roughly the same number of units either way, and so that'd only piss off MS for no return. But, there is obvious value in making a huge, concerted, brilliantly-executed marketing push for switching from Solaris and AIX to Red Hat (and believe me, they are).
As to everyone above relating their Red Hat warm fuzzies - don't believe it for a microsecond. If you heard just five minutes of their current pitch to Fortune 100 brass, you'd choke on your bile. I don't believe I can go into specifics, but I'll just say that I've never even heard Microsoft spout anything so evil, rawly mercenary, or misguided, and I've heard it all. Red Hat is not your friend,/.ers, and don't except any love from them, even if you're getting it now (even as I type this on a machine running FC3). I see them making lots of the same mistakes Sun and Microsoft have each made over the years (it basically boils down to arrogance and disregard for the customers / community, respectively), and it's really a shame.
It seems sometimes we get so swept up in evangelizing Linux and cheering the success of Linux-based companies like Red Hat that we miss the fact that there is nothing to prevent Red Hat from becoming as negative a force in the industry as Microsoft has become, and it looks to me like they have every intention of doing exactly that.
I am a huge fan of Linux adoption, but you have to consider what's being displaced. The vast majority of enterprise adoption is being driven by the big x86 server hardware vendors (again, gee, I wonder why), at the expensive of a very excellent operating system in Solaris, which also happen to be a hotbed of OS innovation. People without in-depth and long-standing experience with both Linux and Solaris / SunOS might be very surprised to see how many 'Linux' features can be ultimately traced back to Sun. To me, that's just not worth it, this type of robbing Peter to pay Paul, outside of pure and unjustifiable fanboyism. It's not good for the industry, and not good for the community, ultimately.
Linux (not Red Hat) should succeed because it's fundamentally better (if and when it is) than its competition, not because it's Dell, HP, and IBM's ticket to increased x86 server sales revenue, and their marketing machines severely outclass Sun's (believe me, they do).
Linux (not Red Hat) should be something we evangelize because it represents a shift to open standards and interfaces, and the companies that should feel the sting of that shift should be the ones who have failed us on this front (gee, guess who I'm talking about, and no, it sure isn't Sun).
Oh come on, mods. This is 13.636% off-topic, by my math. The point is that here is an awesome tool, an opensource project being realistically compared to a cornerstone of Microsoft's desktop empire, and we have Sun to thank for that, in large part. My comment was clearly ironic, pointing out that OO.o is significant, praising Sun for helping to make it a reality, and getting a zing in on/.ers for being so rabidly anti-Sun so much of the time.
What has Sun every done for the community, anyway? I have zero reason to trust them, and you can be sure they're only looking for a way to line their pockets. I will breathe a sigh of relief when they finally die and we can say there is one less evil corporation in the world. Thank goodness there are corporations on the other hand like IBM that Love Linux and promise not to enforce their patents for preventing unauthorized access to a rotating shaft against us.
Slashdot Mirror
Pronounced "PSSSSH!" of course.
While we're talking about drivers, you touched on something. Yes, Linux is way out ahead of Solaris x86 in terms of hardware support, however one major pain with Linux is binary driver dependence on minor kernel versions. This is a serious problem for the 'enterprise' server crowd, where to patch my kernel, I must wait on the slowest ISV who happens to have a binary-only module in my kernel. Even if I have source, as the AC pointed out, whipping out a compiler because you want your HBA driver to continue to work after applying a kernel update is pretty LOL for an 'enterprise' OS.
I think we're all agreed that using kernel modules from third parties is something to avoid where possible on any platform, but it's a reality that many in the corporate world have to live with. Compare to Solaris, where it is unheard of for a particular build of a particular driver that works with any minor revision of a given kernel to not work with any other minor revision of that same major. Put another way, if driver xyz works with any Solaris 9 kernel, I can bet my job that it's going to work with any other Solaris 9 kernel, and heck, it'll probably even work with any Solaris 7, 8, or 10 kernel, too. Even outside of drivers and kernel modules, Solaris' binary compatibility is something you seriously start to appreciate, believe me.
"Supercomputer" is an odd term to use these days. I assume you're referring to large clusters as opposed to large single-image machines? The former isn't nearly as difficult a job, kernel-wise. Linux on large (i.e. >8 CPU) single-image machines still seems pretty fringe to me. I understand many of the relevant patches weren't rolled in until as recently as 2.6.9, and while I've of course, not done any testing yet myself, an HP presentation I just read on "BigTux" was mysteriously vague on speedup results for some of their benchmarks, and offered no comparisons to HP/UX running the same benchmarks on the same hardware. To be fair, it wouldn't be scientific to blame all vertical scalability problems on Linux alone, since we're also talking about IA64, in this example.
The other problem outside of raw performance is the other 'enterprise' features (usually) become absolute nececessities on large single-image boxes. Namely, I'm talking about a modern resource management facility, very good and very safe visibility tools, and the ability to fully leverage all of the dynamic hardware reconfiguration features the machine's vendor provides.
I think a relevant question to ask is how advantageous it is to each specific market to have that wide focus you mention. You gave one example, of exposing bugs - I won't argue with that, but I do wonder at the exact quantity of its utility, compared to possible disadvantages of the same wide focus. It seems to me that compromise is inevitable, and no doubt there are decisions made (either of inclusion or omission) that benefit one market at the expense of another. There is an argument to made for specialization, and Solaris has (with brief, embarassing exceptions) never purpoted itself as anything but laser-focused on being the best server OS. Alright, it's also been billed as an engineer/workstation OS, but by the time I became heavily involved with Solaris, it was already a better bet in most cases to use Linux on x86 workstations for that. [In a research lab I worked at in the late 90s, my boss got 'that look on his face' when I showed him how the Pentium III we used for burning CDs was outperforming the Ultra 60 he'd just bought (for a pretty penny, of course) to run MATLAB.]
'BigTux' also gets me thinking about a phenomenon I've noticed. Here we see an example of HP throwing a lot of resources and money at helping Linux get better. However, no one is really kidding themselves (I hope) that this is an altruistic move on their part. They have an obvious incentive to help Linux perform well on Superdome, in that they are abandoning HP/UX, and will be left without a Unix-like OS for their big boxes, unless Linux can improved enough to do the job. All of the x86 hardware vendors are flexing considerable money and marketing muscle to either improving Linux technologically, or pushing adoption. However, all of this is happening in just one market - the server, and they are all doing it for reasons that should be obvious to anyone who wants to stop and think about the business strategies of each of these companies. Dell being the best example of this, consider their position. They are pushing Linux adoption extremely hard, using their excellent marketing and FUD machines to their fullest extent, but they are only pushing Linux in one role - replacement of UNIX servers. Turning one installed Solaris machine into four Dell machines is obviously a good idea for them. Turning four Dell servers running Windows into four Dell servers running Linux - well, what does Dell get out of that, aside from Microsoft's wrath? Turning a Dell desktop running Windows into a Dell desktop running Linux, what does that get them? Nothing but MS wrath. So, my beef here is that we already had an embarrassment of riches in the server space - several very good, very well accepted, very understood, and very open-standard friendly server OSs. Not to mention a few that were already open source and free. This, to my mind, is where Linux was
You'll get zero argument from me, as far as the laptop/desktop/embedded stuff. Solaris has never been well-suited (or even an option) for those tasks, and I don't see it catching up to Linux in the near future, either. Solaris isn't even "second" to Linux in that space, as far I'm concerned. It's way, way back, behind Windows, MacOS, Linux, BSD, and who knows what all else.
As to servers though, I completely disagree. If Linux's development is so far outpacing Solaris's, why has it been consistently behind in 'enterprise' features for over a decade? Don't get me wrong, please - I'm a huge Linux fan and have been a heavy Linux user for years longer than I've been a heavy Solaris user (Slackware 1 vs. Solaris 2.6, as far as when I got majorly involved with each), but I do not see Linux significantly closing the gap on Solaris in server features. 2.6 was a huge step, but then, predictably, Solaris 10 shipped, and it was at least equally as huge, to my mind.
What is your criteria for calling the Solaris kernel a "far second" to Linux? OSS community involvement? x86 hardware support? ISV support on x86? I'll give you those three, but if you've got something else in mind, you'll probably get an argument from me and others who have used both kernels for a long time.
I also don't see Solaris' lead diminishing, let alone rapidly. If anything, it appears to me that Sun further widened the gap with Solaris 10. Sun is regularly releasing very advanced and important OS features, in fully-baked and rock-solid form, and the FOSS community is doing its best to keep up, but even though Solaris 10 shipped nearly a year ago, look at the current state of SystemTap, for example - a project spawned in direct response to Solaris 10 dtrace, that is still nowhere near ready to primetime. Where (for example) also is the modern full-fledged resource management? This is a critical feature for an 'enterprise' kernel, and it's still nowhere in sight, though everyone's known it's been necessary for Linux to achieve for several years.
It's one thing to reimplement BitKeeper in a month - advanced kernel features are something else entirely, and we have a decade to look back on and see Sun's record of innovating and Linux following. What happens when Linux has cannibalized the last true innovator, and there's no one left to follow? Lest you think I'm trolling, I have a serious question: what major kernel innovations in the last decade appeared in Linux *first*? I can think of one, maybe two, but put up against the parade of inventions and innovations that have come from Solaris in the last decade, I don't know.
A few corrections / notes:
/etc and everything else (or you can opt to share parts of the install with the 'global' zone), however there is still a single kernel running all of the zones on a given server. Applying a kernel patch, for example, still requires a reboot of the whole enchilada to take effect.
There is no provision for running multiple kernels on the same hardware, aside from 'domaining', which is more like IBM's LPARing (prior to P5 and 5.3, that is - splitting a single server into two or more hardware partitions). But, when you do this, each partition really is its own machine, with distinct and non-shared CPUs, memory, and IO buses. You can move hardware from one domain to another (even without shutting down applications), but a given kernel is only ever running on one machine at a time.
More recently, is the concept of 'Zones'. Here, you can install seperate copies of userland onto the same box, and when you are 'inside' of any one zone, you appear to have your very own box, complete with your own
Actually, I believe 'Slowaris' was coined in 93 or 94 or so, when admins started switching from SunOS 4.1.3/4.1.4 to Solaris on SMP boxes, and ran into bug where no matter how many CPUs, every thread was being scheduled on the same CPU. I forget what version this was - maybe 2.3? I remember logging onto my University's student shell machine (back then, SLIP and PPP were still not being used by home users - you'd dial up to terminal into a UNIX machine to check email, usenet, or IRC). Anyway, I remember logging in and seeing a load in the thousands, just after the upgrade.
You can "upgrade on the fly", in a way. The concept is you mirror your root disk, split the mirror, perform the upgrade against the inactive mirror, and finally reboot, this time off the upgraded side. It more or less works, but you do need to use your brain. Really what it gets you is the ability to immediately revert back to the pre-upgrade image with just a single reboot, and also shortens the outage window to one reboot. They've had this since Solaris 8, I believe, and you could use it to upgrade from say 2.6 to 8.
Over time, 'Slowaris' did come to refer to the performance disparity between Linux and Solaris on x86. Until Solaris 10, Linux pretty clearly outperformed Solaris on like-hardware (x86). I think in part, as you say, due to Sun's lack of effort in optimizing for x86 and small servers, but also because x86-based benchmarks tended to focus on things like web-serving, and Sun's networking stack was long overdue for an overhaul (the first phase of which was completed for Solaris 10, and returned enormous improvements).
I'm not sure why this comment is getting -2 redundant, since as far as I know it's nowhere else in the article or the comments that I wrote reflscan and that I'm honored that Fyodor is conscientious enough to continue to mention it in interviews like these (as well as the other scanners he liked and wanted to improve upon). If the mods are detecting sarcasm in my post, they do so incorrectly.
Off-topic I could maybe see, but redundant? What?
Hey Fyodor, I wrote reflscan, and I think it's pretty cool that you still mention it, especially since the version that got out was so crappy, and your scanner doesn't owe anything to it. Cheers.
As far as I know, there is not a single "Sun Fire" system ever made that didn't use bone-standard SCSI disks manufactured by IBM, Seagate, Fujitsu, or Hitatchi, etc (with 'proprietary' drive rails). That being said, the Sun-branded disks on their website are ridiculously overpriced, but there has never been anything technological to stop you from using whatever disks you please.
/. folks from crying "proprietary!" every time Sun is mentioned in the news.
I really hate this "proprietary" phrase getting thrown around with regard to Sun. Forget that they're using AMD CPUs now (the whole point of TFA), and please go ahead and tell me how SPARC is proprietary and Intel isn't. I'd love to hear this. Not to mention that Sun has probably done more for open standards and protocols over the years than any other single company that comes readily to mind. Open source is not necessary for open standards, which really, is what matters far more to me. But, even so, Solaris is now open source as well. But please don't let over 20 years of history and assorted facts stop
Well, you're probably aware that they sell their Office tools for Mac OS. The only other instance in this vein that I'm aware (and it may surprise you) is that they made Internet Explorer available for Solaris/SPARC, for free. It didn't work incredibly well, but it worked.
I agree about not running 'catman -w' at install time. You'll find lots of things like this in Solaris. There seems to be a general philosophy of not making decisions for you, which you can get to appreciate, with time. I think they kind of assume that if you want to use apropos, you'll slap a 'catman -w' into one of your jumpstart scripts. Rememeber that it's really an OS geared for bigger corporate environments with dedicated staffs of sysadmins, not desktop users or casual passers-by. But, I do agree that it'd be nice for it to take care of that automatically. If that bugs you, you'll also be bugged trying to use sar, and a few other things that they except you to go explicitly enable. My big gripe is that they abandon that philosophy when it comes to which network services they'll enable - they enable pretty much all of them and expect you to go explicitly turn off the ones you don't want - in stark contrast with the general philosophy of asking you to explicitly turn on the stuff you do want. But, again, really, this is all very superficial stuff. It's not nearly enough to condemn an OS by. You just turn on the stuff you want and turn off the stuff you don't, and if you're in Sun's historical customer demographic, then you're a corporate sysadmin just adding stuff to your jumpstart scripts.
Sorry too that I didn't understand what your beef with ifconfig was. Yes, ifconfig won't show you any interfaces that haven't been "plumbed." The concept of plumbing an interface doesn't exist in Linux, of course. I don't have a Solaris machine handy to play with this second, so I can't tell you a sure-fire and elegant way to get a list of all valid-but-unplumbed interfaces, but I know it can be done. In fact, one of the Solaris install scripts does it (I believe that if you bomb out of an install or toss yourself out of a begin/finish script at the right place, and do an 'ifconfig -a', you'll see all the interfaces on the box plumbed up). I'm not suggesting that's a valid way to do it, just pointing out that it must be possible, because Solaris itself does it. Here's a hack I came up with that should do it:By the way, comp.unix.solaris is a great resource, full of very smart and helpful people (many of whom work for Sun, including several kernel engineers) who have always spent a lot of time answering all sorts of questions, from newbie to insanely technical and complex. Some people also like BigAdmin, and of course SunSolve and docs.sun.com are invaluable. Make sure especially to check out the System Administration Guide on docs.sun.com.
Keep an open mind and be patient - it's definitely an acquired taste, especially for someone coming from Linux, but I personally think it's a truly great and unique OS that's totally worth the effort.
apropos: From the manpage you besmirch for not having been updated in 10 years:
(first paragraph):
(footer):Maybe it hasn't been updated because it hasn't needed to be?
dhcpconfig: I don't know, it worked fine for me. Our two anecdotes cancel each other out, it seems.
interface names: Yes, Solaris names the interfaces by the drivers providing them, which are in turn named for the hardware chipset (which a few exceptiosn like qfe, which stands for "quad fast ethernet" and refers to the number of chips on the cards, as opposed to the chipset). Since you seem to already know apropos, why didn't you do:Also, I have no idea how you managed to bungle 'ifconfig -a', but it doesn't require any specific interface argument. It works almost exactly the same as on Linux ("almost", because it doesn't show you some of the interface statistics like Linux does - use kstat for that). If I were spanking-new to Solaris, I think I'd do 'ifconfig -a', and then when I saw a bge0, I'd probably try 'man bge' and what do you know?
I've found Solaris to have really pretty excellent manpages, and docs.sun.com is very, very good. I honestly wish Red Hat for example would have documentation even a fraction as complete and good as the stuff all over docs.sun.com. There's plenty of valid things to fault Solaris for, but you've hit on none of it.
This is one of my biggest pet peeves in IT journalism. How Intel CPUs are always "industry standard," and everything else is "proprietary." Tell me again how x86 isn't proprietary? SPARC is actually somewhat open, as described here. Now, I'm not saying it's open like GPL software is open, but there's an IEEE standard for the SPARC instruction set, and anyone can license the SPARC specification. There have always been two distinct vendors (Sun and Fujitsu) selling different but compatible SPARC implementations. Even after the APL goes into effect, I believe each vendor will still have SPARC chips not covered by that agreement (each vendor's low-end line).
Now, x86 has both Intel and AMD making compatible chips, but they actually have a license agreement. AMD pays Intel royalties, and it's even rumored that Intel has the right under that agreement to cap AMD's production volume. To me, it starts looking like AMD is a pet Intel keeps around to be able to say, "but we're not a monopoly, look at AMD!" You only need to look at Microsoft's legal history to see why that'd be a smart move.
"Commodity" is the other term consistently abused in discussions like this. When people say Intel CPUs are "commodity" and "industry-standard", what they mean to say is that they are "cheap" and that there are "lots of them."
If you have enough CPUs, DIMMs, and OS instances from any of those vendors, you'll see plenty of kernel panics. They all have hardware and OS related panics, you just have to have a large enough sample size to notice it.
Putting a signal on an antenna will obviously result in radiation, yes. What's not obvious though, is how much, and how quickly it falls off with distance. It's not clear to me if the entire line radiates and therefore it drops off as 1/R, or if (as some claim), it will instead fall off with 1/R^2 or 1/R^4. Add to the fact that they're notching the public frequencies, and I don't think we can necessarily trust the article's author at his (clearly biased) word that "there will be interference."
I don't know enough about this to say if anyone is right or wrong, but I do suggest reading the author's disclosure at the end of his article, and considering that the ARRL has an established position on this issue, and one that may be more emotional than rational, in the final analysis. It's also not clear from my quick read of the article if interference has been demonstrated from BPL lines complying with the new FCC rules for BPL
Within the OOo Project, Sun Microsystems, which released the project's code in 2000 and still provides most of its developers, is regarded, with some exceptions, as a community benefactor. By contrast, free software advocates view Sun -- and, by extension, OpenOffice.org -- with suspicion, largely because Sun has a history of alternately supporting and damning free and open source software (FOSS). For instance, while CEO Scott McNealy has called Sun a "heavy contributor" to open source and claimed that Sun invented it, president Jonathan Schwartz has heavily criticized the GNU General Public Licence. Although this inconsistency could be interpreted as an effort to steer a middle path between proprietary and FOSS software, or as an internal difference of opinion at Sun, more often the community has seen it as evidence of duplicity and untrustworthiness.
I think this paragraph helps explain why some people are viewing this as a somewhat anti-Sun article or conversation. I definitely wouldn't say Sun has ever "damned" FOSS. Criticizing the GPL isn't damning FOSS. If you think that, you are someone who believes that the only FOSS is GPL software, and that is simply not true. Also, Schwartz didn't really rip into the GPL - I've read all his blog comments and his speech that generated all the excitement, and his point was simply that the GPL poses problems for some of his customers, and he felt the CDDL with its MPL model was a better fit for them and for Sun. What's wrong with that? He's not even really criticizing the GPL, he's just saying it's not the right FOSS license for his company's needs. When do we stop pretending that the GPL is the only FOSS license out there and that the FSF's agenda has to be embraced for a project to be beneficial to "the community?"
It's pretty ridiculous to see the article's author claim it's an "inconsistency" or "duplicity" to embrace FOSS but criticize the GPL, even if Schwartz had been really tearing the GPL a new one, which he totally wasn't.
Finally, as to the original issue, I agree that OOo should be written at least to public interfaces, and the debate should end there. If "the community" hasn't yet produced a viable FOSS implementation of Java, that is not Sun's fault, not Schwartz's fault, not McNealy's fault, and not OOo's fault.
P.S. The paranoid and cynical (certainly not me) could see this as a backhanded attempt to further pressure Sun to open Java entirely, and if you were especially paranoid (again, not me by any means), you could further note that this is exactly what IBM is dying for, and finally, wonder why Stallman's missives always seem pretty lined up with IBM's agenda and and why they (one of the biggest patent aggressors in the industry) always seem exempt from his diatribes.
While it might not be obvious to Dell's home customers, as an architect at a very large company that does a very large amount of server business with Dell, I can tell you that they have been pushing Red Hat extremely aggressively for the last year or two. I see the pitches, roadmaps, and political jockeying from all the major 'enterprise' vendors, and I do not see anyone pitching anything as hard as Dell is now pitching Red hat.
/.ers, and don't except any love from them, even if you're getting it now (even as I type this on a machine running FC3). I see them making lots of the same mistakes Sun and Microsoft have each made over the years (it basically boils down to arrogance and disregard for the customers / community, respectively), and it's really a shame.
/soapbox
It's an obvious and core component of their enterprise strategy to make the 'UNIX migrations to Red Hat' pitch. As you look at the typical Fortune 500 datacenter, and see the huge percentage of installed hardware occupied by Sun and IBM gear running UNIX, it doesn't take a genius to figure out what Dell's angle with Red Hat is. Dell has nothing to gain by marketing Windows migrations to Linux (on either the desktop or the server) - you're buying roughly the same number of units either way, and so that'd only piss off MS for no return. But, there is obvious value in making a huge, concerted, brilliantly-executed marketing push for switching from Solaris and AIX to Red Hat (and believe me, they are).
As to everyone above relating their Red Hat warm fuzzies - don't believe it for a microsecond. If you heard just five minutes of their current pitch to Fortune 100 brass, you'd choke on your bile. I don't believe I can go into specifics, but I'll just say that I've never even heard Microsoft spout anything so evil, rawly mercenary, or misguided, and I've heard it all. Red Hat is not your friend,
It seems sometimes we get so swept up in evangelizing Linux and cheering the success of Linux-based companies like Red Hat that we miss the fact that there is nothing to prevent Red Hat from becoming as negative a force in the industry as Microsoft has become, and it looks to me like they have every intention of doing exactly that.
I am a huge fan of Linux adoption, but you have to consider what's being displaced. The vast majority of enterprise adoption is being driven by the big x86 server hardware vendors (again, gee, I wonder why), at the expensive of a very excellent operating system in Solaris, which also happen to be a hotbed of OS innovation. People without in-depth and long-standing experience with both Linux and Solaris / SunOS might be very surprised to see how many 'Linux' features can be ultimately traced back to Sun. To me, that's just not worth it, this type of robbing Peter to pay Paul, outside of pure and unjustifiable fanboyism. It's not good for the industry, and not good for the community, ultimately.
Linux (not Red Hat) should succeed because it's fundamentally better (if and when it is) than its competition, not because it's Dell, HP, and IBM's ticket to increased x86 server sales revenue, and their marketing machines severely outclass Sun's (believe me, they do).
Linux (not Red Hat) should be something we evangelize because it represents a shift to open standards and interfaces, and the companies that should feel the sting of that shift should be the ones who have failed us on this front (gee, guess who I'm talking about, and no, it sure isn't Sun).
Oh come on, mods. This is 13.636% off-topic, by my math. The point is that here is an awesome tool, an opensource project being realistically compared to a cornerstone of Microsoft's desktop empire, and we have Sun to thank for that, in large part. My comment was clearly ironic, pointing out that OO.o is significant, praising Sun for helping to make it a reality, and getting a zing in on /.ers for being so rabidly anti-Sun so much of the time.
What has Sun every done for the community, anyway? I have zero reason to trust them, and you can be sure they're only looking for a way to line their pockets. I will breathe a sigh of relief when they finally die and we can say there is one less evil corporation in the world. Thank goodness there are corporations on the other hand like IBM that Love Linux and promise not to enforce their patents for preventing unauthorized access to a rotating shaft against us.