7 ms·

Solaris, and why

20 points by ableal 18y ago

tptacek 18y ago
This guy uses "security" as a value prop for SPARC and Solaris 3 times in this article. But there is no such value prop for either technology. Solaris is not more secure than FreeBSD or even many Linux distributions. And despite the mocking jab, the Itanium processor has a far more powerful and flexible security model than the SPARC does.
- ableal 18y ago
  Murphy is an unabashed Solaris/Sparc partisan, but he usually makes good points (in past posts, not much data on this one). I appreciate his dissenting from the majority viewpoint - thundering herds are prone to occasionally going off cliffs, as recently demonstrated. I also believe he's right in thinking Sun is getting a raw deal from 'the street'. Of course, it would help if Sun could sell its way out of a wet paper bag ...
  - bensummers 18y ago
    It does seem that many of the problems are down to short-term views from the "investors" forcing certain courses of action. The evidence does not show that bankers are any better running a computer company than they are running a bank. (disclosure of bias: my startup runs on Sun + Solaris)
  - rbanffy 18y ago
    "Of course, it would help if Sun could sell its way out of a wet paper bag ..." Oh boy... They sure make selling good hardware look hard. Any decent marketing team would make them fly off the shelves.
- rbanffy 18y ago
  I remember Theo De Raadt pointing out several design errors in x86 chips that could be used as attack vectors. I am not sure how many of those SPARCs or Itaniums have.
  - tptacek 18y ago
    Different x86 microarchitectures have had errata (such as TLB consistency) that, if you're a kernel VM developer, can bite you in the ass. That's annoying, but it's not an intrinsic flaw in the x86 architecture, and it is not as if there are latent x86 vulnerabilities lying around waiting to be exploited. On the other hand, at least two times now, Sun managed to screw up floating point in a way that compromised security. For instance: http://www.matasano.com/log/222/this-old-vulnerability-umuludiv/ http://www.matasano.com/log/222/this-old-vulnerability-umulu...
erlanger 18y ago
Wow, not a single mention of DTrace or ZFS. I believe that these are the best reasons for keeping these projects going.
- tptacek 18y ago
  I'm really kind of mystified by how DTrace has captured people's imaginations. How could something like DTrace justify an entire server platform? I have it on my Mac, I'm a professional reverser, and it's never the first thing I reach for. I'm serious, what's the huge win here? You never, ever hear people say that Detours is a reason to switch to Win32. But Detours seems, if anything, more useful than DTrace.
  - patrickg-zill 18y ago
    Dtrace is useful because you can run it without having to interrupt any processes on the machine, and it is safe (won't cause kernel panics) and lightweight (won't slow the machine down too much) enough to use on a production site. DTrace lets you instrument either 1 process, a collection of processes, or all processes at the syscall level. Want to know which processes are usinng disk IO; then what the size of the IO writes is? You can do that. For instance, you might want to tune your RAID controller stripe size to your IO-intensive application. Etc. etc.
    - tptacek 18y ago
      I'm pretty sure syscall-level instrumentation isn't the win with DTrace, since every modern Unix provides a safe, lightweight method for collecting that info. In fact, if you know how DTrace actually works, what Sun is doing is actually scarier than, say, truss. I'm not saying there isn't a DTrace win; just that you haven't shown it.
      - bayareaguy 18y ago
        DTrace's innovation is that it provides an easy to use interface which allows people to get results they want in a way that would otherwise require significant low-level expertise and engineering time. That people like it should come as no suprise to the entrepreneurial crowd here - it's just another twist on Make Something People Want. One thing I particularly like about DTrace is its awk-like language makes it easy to borrow snippets of useful code from existing DTrace scripts. When I needed the equivalent of linux's Paco [1] tool on my OSX box I found I could easily build it from the code of /usr/bin/dtruss[2] and /usr/bin/pathopens.d[3] DTrace is also what apparently powers Sun's Storage Analytics[4] [1] - http://paco.sourceforge.net http://paco.sourceforge.net [2] - http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-48/DTTk/dtruss http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-4... [3] - http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-48/DTTk/Proc/pathopens.d http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-4... [4] - http://ctistrategy.com/2008/12/17/sun-storage-7000-analytics-overview http://ctistrategy.com/2008/12/17/sun-storage-7000-analytics...
iigs 18y ago
Witness, for example, Intel’s “new” Nehalem line - it’s great right? By Wintel standards, it is - but if Sun hadn’t lent AMD some people to design x64 and then supported the company by building its own motherboards to demonstrate what x86 multi-core could do, you’d be paying HP’s prices for Itanium desktops - Itanium performance, and Itanium security. I call [whatever the highest HN-agreeable word that substitutes for "bullshit"]. The Itanium was never positioned for the desktop, and even if it was, it never had the performance to get the job done. It's slow, hot, and is a compromised design for desktop use. AMD did to Intel what Toyota, Honda and Nissan did to GM in the 70s-90s: surprise and delight at the bottom end, and move upmarket slowly while the incumbent sleeps. Intel made the mistake that Joel Spolsky famously warns us about -- don't rebuild things you don't have to; AMD bet on the opposite color and won big time. most of the market, and many among Sun’s own staff, have no idea how the SPARC products line up against x86; no appreciation for the differences between Solaris and Linux; and no interest in learning how unloved products from Sun Ray to the CMT cryptology processors can produce huge savings and/or productivity improvements for customers. Honestly, the more you know about "how the SPARC products line up against x86" the less palatable it is. Sun has too many irons in the fire. On one hand you have the few-core UltraSPARC processors that power the big iron. The servers are big, hot, and not clockspeed competitive with tier-1 x86 hardware costing 1/10th the price. On the other end you have the T1/2/2+ many-core processors that are woefully anemic price:performers except possibly in trivially parallelized tasks. My experience (as an engineer in a multi-billion dollar company building from the ground-up over the last couple years) is that there's no compelling reason whatsoever to go with SPARC hardware unless you have to. We've purchased a few products with a legacy on SPARC, and these systems have been treated like appliances by the vendors -- they don't want us using Zones or ZFS, and they don't support us analyzing the applications using DTrace. Linux is doing to Sun what Sun did to IBM. The difference is IBM had the benefit of more entrenchment and vastly deeper reserves. They managed to evolve away from "pushing iron as an end" to "pushing iron as a means to an end" -- where that end is consulting dollars.
- rbanffy 18y ago
  "Sun has too many irons in the fire. On one hand you have the few-core UltraSPARC processors that power the big iron. The servers are big, hot, and not clockspeed competitive with tier-1 x86 hardware costing 1/10th the price." I find it interesting to see comparisons based on clock speed becoming common again. Different architectures behave differently and SPARC performs differenty (read "better most of the time") than x86 at the same clock. I thought people learned that from the PowerPC Macs. I find this supremely ironic coming from a person nicknamed "iigs". Any half competent programmer could make a 6502 run rings around a Z80 with four times its clock in the Apple II days. "On the other end you have the T1/2/2+ many-core processors that are woefully anemic price:performers except possibly in trivially parallelized tasks." Like... Oh! web-serving! And virtualization. And database workloads. You must be right: those T1/T2 have no useful purpose. While Linux and x86 killed Sun on some workloads (it was Windows who killed the Unix workstation, BTW) being able to properly cast hardware to a given problem is a skill far too few people possess these days. Perhaps you should look more closely into your "legacy" Sun stuff and learn about the good parts.

20 points by ableal 18y ago

This guy uses "security" as a value prop for SPARC and Solaris 3 times in this article. But there is no such value prop for either technology. Solaris is not more secure than FreeBSD or even many Linux distributions. And despite the mocking jab, the Itanium processor has a far more powerful and flexible security model than the SPARC does.

ableal 18y ago
Murphy is an unabashed Solaris/Sparc partisan, but he usually makes good points (in past posts, not much data on this one). I appreciate his dissenting from the majority viewpoint - thundering herds are prone to occasionally going off cliffs, as recently demonstrated. I also believe he's right in thinking Sun is getting a raw deal from 'the street'. Of course, it would help if Sun could sell its way out of a wet paper bag ...
- bensummers 18y ago
  It does seem that many of the problems are down to short-term views from the "investors" forcing certain courses of action. The evidence does not show that bankers are any better running a computer company than they are running a bank. (disclosure of bias: my startup runs on Sun + Solaris)
- rbanffy 18y ago
  "Of course, it would help if Sun could sell its way out of a wet paper bag ..." Oh boy... They sure make selling good hardware look hard. Any decent marketing team would make them fly off the shelves.
rbanffy 18y ago
I remember Theo De Raadt pointing out several design errors in x86 chips that could be used as attack vectors. I am not sure how many of those SPARCs or Itaniums have.
- tptacek 18y ago
  Different x86 microarchitectures have had errata (such as TLB consistency) that, if you're a kernel VM developer, can bite you in the ass. That's annoying, but it's not an intrinsic flaw in the x86 architecture, and it is not as if there are latent x86 vulnerabilities lying around waiting to be exploited. On the other hand, at least two times now, Sun managed to screw up floating point in a way that compromised security. For instance: http://www.matasano.com/log/222/this-old-vulnerability-umuludiv/ http://www.matasano.com/log/222/this-old-vulnerability-umulu...

erlanger 18y ago

Wow, not a single mention of DTrace or ZFS. I believe that these are the best reasons for keeping these projects going.

tptacek 18y ago
I'm really kind of mystified by how DTrace has captured people's imaginations. How could something like DTrace justify an entire server platform? I have it on my Mac, I'm a professional reverser, and it's never the first thing I reach for. I'm serious, what's the huge win here? You never, ever hear people say that Detours is a reason to switch to Win32. But Detours seems, if anything, more useful than DTrace.
- patrickg-zill 18y ago
  Dtrace is useful because you can run it without having to interrupt any processes on the machine, and it is safe (won't cause kernel panics) and lightweight (won't slow the machine down too much) enough to use on a production site. DTrace lets you instrument either 1 process, a collection of processes, or all processes at the syscall level. Want to know which processes are usinng disk IO; then what the size of the IO writes is? You can do that. For instance, you might want to tune your RAID controller stripe size to your IO-intensive application. Etc. etc.
  - tptacek 18y ago
    I'm pretty sure syscall-level instrumentation isn't the win with DTrace, since every modern Unix provides a safe, lightweight method for collecting that info. In fact, if you know how DTrace actually works, what Sun is doing is actually scarier than, say, truss. I'm not saying there isn't a DTrace win; just that you haven't shown it.
    - bayareaguy 18y ago
      DTrace's innovation is that it provides an easy to use interface which allows people to get results they want in a way that would otherwise require significant low-level expertise and engineering time. That people like it should come as no suprise to the entrepreneurial crowd here - it's just another twist on Make Something People Want. One thing I particularly like about DTrace is its awk-like language makes it easy to borrow snippets of useful code from existing DTrace scripts. When I needed the equivalent of linux's Paco [1] tool on my OSX box I found I could easily build it from the code of /usr/bin/dtruss[2] and /usr/bin/pathopens.d[3] DTrace is also what apparently powers Sun's Storage Analytics[4] [1] - http://paco.sourceforge.net http://paco.sourceforge.net [2] - http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-48/DTTk/dtruss http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-4... [3] - http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-48/DTTk/Proc/pathopens.d http://www.opensource.apple.com/darwinsource/10.5.5/dtrace-4... [4] - http://ctistrategy.com/2008/12/17/sun-storage-7000-analytics-overview http://ctistrategy.com/2008/12/17/sun-storage-7000-analytics...

iigs 18y ago

Witness, for example, Intel’s “new” Nehalem line - it’s great right? By Wintel standards, it is - but if Sun hadn’t lent AMD some people to design x64 and then supported the company by building its own motherboards to demonstrate what x86 multi-core could do, you’d be paying HP’s prices for Itanium desktops - Itanium performance, and Itanium security. I call [whatever the highest HN-agreeable word that substitutes for "bullshit"]. The Itanium was never positioned for the desktop, and even if it was, it never had the performance to get the job done. It's slow, hot, and is a compromised design for desktop use. AMD did to Intel what Toyota, Honda and Nissan did to GM in the 70s-90s: surprise and delight at the bottom end, and move upmarket slowly while the incumbent sleeps. Intel made the mistake that Joel Spolsky famously warns us about -- don't rebuild things you don't have to; AMD bet on the opposite color and won big time. most of the market, and many among Sun’s own staff, have no idea how the SPARC products line up against x86; no appreciation for the differences between Solaris and Linux; and no interest in learning how unloved products from Sun Ray to the CMT cryptology processors can produce huge savings and/or productivity improvements for customers. Honestly, the more you know about "how the SPARC products line up against x86" the less palatable it is. Sun has too many irons in the fire. On one hand you have the few-core UltraSPARC processors that power the big iron. The servers are big, hot, and not clockspeed competitive with tier-1 x86 hardware costing 1/10th the price. On the other end you have the T1/2/2+ many-core processors that are woefully anemic price:performers except possibly in trivially parallelized tasks. My experience (as an engineer in a multi-billion dollar company building from the ground-up over the last couple years) is that there's no compelling reason whatsoever to go with SPARC hardware unless you have to. We've purchased a few products with a legacy on SPARC, and these systems have been treated like appliances by the vendors -- they don't want us using Zones or ZFS, and they don't support us analyzing the applications using DTrace. Linux is doing to Sun what Sun did to IBM. The difference is IBM had the benefit of more entrenchment and vastly deeper reserves. They managed to evolve away from "pushing iron as an end" to "pushing iron as a means to an end" -- where that end is consulting dollars.

rbanffy 18y ago
"Sun has too many irons in the fire. On one hand you have the few-core UltraSPARC processors that power the big iron. The servers are big, hot, and not clockspeed competitive with tier-1 x86 hardware costing 1/10th the price." I find it interesting to see comparisons based on clock speed becoming common again. Different architectures behave differently and SPARC performs differenty (read "better most of the time") than x86 at the same clock. I thought people learned that from the PowerPC Macs. I find this supremely ironic coming from a person nicknamed "iigs". Any half competent programmer could make a 6502 run rings around a Z80 with four times its clock in the Apple II days. "On the other end you have the T1/2/2+ many-core processors that are woefully anemic price:performers except possibly in trivially parallelized tasks." Like... Oh! web-serving! And virtualization. And database workloads. You must be right: those T1/T2 have no useful purpose. While Linux and x86 killed Sun on some workloads (it was Windows who killed the Unix workstation, BTW) being able to properly cast hardware to a given problem is a skill far too few people possess these days. Perhaps you should look more closely into your "legacy" Sun stuff and learn about the good parts.