Yeah, that's the sort of conclusion people jump to. All our x64 manufacturing (and most of our SPARC) is outsourced, usually to companies that are well known for PC motherboards they sell under their own names. This makes people think that we're just churning out white boxes. But the designs are ours, not theirs.
Hmm, just poked at an ILOM that's in a lab downstairs from my office, using the Cygwin version of IPMItool from my PC. Definitely not on the same subnet. Was able to dump all the sensor readings this way.
With the ILOM card you need to have your controller on the same subnet.
I'm going to double-check, but I'm pretty sure that's not the case. If true, it's a very silly limitation!
Can you point me at any official documentation that makes this statement? If we're incorrectly stating or implying misinformation, it needs to get fixed.
Thanks for the encouragement. I hope you're right about that Oracle-on-x86 strategy. I was thinking the same way until I heard Ellison shoring up the HP partnership. HP can't be happy about Oracle becoming a systems company — and Sun's x64 systems are more of a threat to HP's core business (commodity computers) than any SPARC system could be.
I'm not an expert, and I certainly don't speak for Sun on this, but I should think that any remote management solution that works with white boxes will work with our x64 systems. But why would you want to spent a lot of money, effort, and rack space for features that we give you for free?
Detail: Sun ILOM hardware is not a PCI card. Depending on the system, it's either built into the motherboard or on a small daughterboard.
Yeah, my post was pure assholedom. And why? Because I refused to engage properly with the conversation you were trying to have with me. That's all there is to being an online asshole, whatever hairs you choose to split.
What, you think that Rob said, "Oh, juicy Sun story, let's place a Sun ad!"? Get real. Web ads mostly get placed based on keywords in the page. Guess which keyword generated this ad?
the T2 seems to be designed almost entirely for applications like Oracle's database with lots of concurrent queries
Well, yeah, but Oracle's database server is hardly unique in that respect. Any server application has to be really good at heavy-duty concurrency. A classic example: the web server you and I are using to communicate.
What's more to the point, Oracle has always had a heavy commitment to the SPARC/Solaris stack, even as most ISVs were abandoning it. They talk about it being more cost effective for their purposes, but I suspect their engineers just think it's more fun to develop for!
Right, they're going to just refuse to support 90% of the server systems out there, and hope that everybody doesn't switch to DB2 or SQL Server. Moving your applications to a new database stack is a pain, but not that much of a pain.
It does. But even before that announcement, it seemed obvious to me that Oracle wasn't going to spent that much money for a company they intended to mostly fold up.
I work for the part of Sun that makes the blades you're talking about. Two important details: they also run Linux, Solaris and ESX Hyperviser. And although I'm certainly glad you think they're great (as I do), remember that x64 systems (blades, rack mount systems, and one lonely workstation) are still a relatively small part of our business.
The future of which is my biggest concern. I'm encouraged that Ellison has seen fit to debunk the assumption that Oracle wasn't interested in Sun's hardware operations. But frustrated that he hasn't said anything about the x64 systems. He did talk about his partnership with HP. One hopes that preserving that relationship doesn't come at a cost of shutting down Sun's x64 products. If it does, I'm out of a job.
Yeah, Obama's really turning into a disappointment on the outrage front, Dijongate notwithstanding. If only McCain had won! He would have croaked under the strain in the first week, and we would have had four solid years of Palinisms to make fun of!
By normal standards, we are. But these things are relative. Around here, you take a certain about of O&C as normal and don't interpret it as assholeness.
But there are people who are so obnoxious and closeminded that they rate as assholes even by the restricted standards of the geek community. I've since become convinced that Drepper fits that definition. But not because he's O&C and says things like "embedded crap". He's an asshole because he's treating glibc as his private property, not a community effort he's just coordinating.
Online communities can be O&C and still be a community. (Most are!) But Drepper doesn't want glibc to be a community at all.
Pretty much any sane person agrees that if you are programming it would be beter to write:
Add 5 to the variable a, please.
or
Add 5 to a.
Rather than
a+=5 or a=a+5
Lord God, help us. Do you really believe that? Sorry, you're wrong. The most common way to express an idea is not always the clearest. Indeed, I think it usually isn't. It's easy to overlook this because humans have a remarkable ability to deal with complexity and ambiguity. But if you make the most basic attempt to express technical concepts in "plain" language, you'll soon find that your listener gets so bogged down parsing complicated expressions that they have no hope of understanding what you're trying to say.
If you don't believe me, take a chapter from an algebra textbook, and try rewriting it without any mathematical notation.
I write technical documentation for a living. One reason I'm good at this is that I work hard to prune out the noise that ordinary language is full of. People might still understand what I'm saying if I didn't do this, but they'd have to work harder. To me, the Holy Writ for clear communication is this famous advice from William Strunk:
Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.
Now, what's more concise, "h = sqrt(x^2 * y^2) or "h equals the square root of x squared times the square root of y squared"? Not to mention that the English version is ambiguous! The "technical" version simplifies and eliminates ambiguity. That's why it was invented. The designers of COBOL were really dumb to overlook this.
you needed people with Engineering level education to understand ALGOL.
Is Algol 68 still in use? That one was so arcane even computer scientists ran away from it in terror. But now that I think about it, a full compiler was never written (too hard!) so you must be talking about some other dialect of Algol.
In which case, you're full of it. Algol is not that hard to follow. You do need to learn some abstract concepts, but you need to concepts in order to write real software. Somebody that understands "add a to b" but not "a:= a+b;" is not a "novice programmer". They're not a programmer at all, since they've obviously don't have any of the mental skills programmers need.
A group of people that do have these skills are people who write spreadsheet macros. It's possible that more people write this kind of code than any other. These are not "engineers" — they're ordinary business users who have mostly learned this art by doing it. They usually don't even think of themselves as programmers, but by any meaningful definition, they are writing code.
And guess what? Spreadsheet macros uses algebraic notation, not COBOL pseudo-English. So much for "needing to be an engineer".
the last few years seem to have been solely dedicated to 'tarting up' glibc with thread-safety and locale-awareness (and UTF)
"Tarting up"? Thread safety and g11n are considered basic requirements of development platforms these days.
Which is not to disagree with your main point about conditionals. Though I wonder whether the "tartiness" has as much impact on performance as you think it does.
There's a book called "Up the Organization" which the CEO of Avis wrote about his subversive approach to corporate management. A lot of it is dated now, but even back in 1970 the author endorsed your advice about programmers actually working the jobs they're trying to help automate. He says that when his chief programmer was assigned to a reservation desk, the very first customer to approach him caused him to run away in terror!
Consider that most people would regard an argument that's really just a contradiction as pretty assholish, especially when 2 other posts have already made the same point.
Eh. The misuse of "Flamebait" and "Troll" is a systemic problem. I don't TIP, and you shouldn't waste your mod point rescuing my posts. Save them for somebody who makes a really good point and deserves to be modded up. Or a serious flammer who needs to be told to fuck off.
This needs to be fixed in the way moderation is documented, organized, and meta-moderated. I used to throw the odd suggestion to Rob, but not only did he ignore them, recent changes actually go the other way, with a painfully oversimplified metamoderation system.
Can't be fixed without Slashdot management admitting that they have a problem, and they're obviously not going to do that. Time to forget about it and get on with life.
I've never done any serious programming in COBOL, though I did study it in college. You're right, this language does have features that are really important for writing business code: report generation, currency data types, etc. It's interesting that these features never migrated into most mainstream block-structured languages. (Notable exception: PL/1. If you use this language, raise your hand. Anyone?) You could argue that people who design languages don't try to understand the needs of business programmers.
But whatever COBOL's advantages, it's still a pretty ugly language.
Yeah, that's the sort of conclusion people jump to. All our x64 manufacturing (and most of our SPARC) is outsourced, usually to companies that are well known for PC motherboards they sell under their own names. This makes people think that we're just churning out white boxes. But the designs are ours, not theirs.
Hmm, just poked at an ILOM that's in a lab downstairs from my office, using the Cygwin version of IPMItool from my PC. Definitely not on the same subnet. Was able to dump all the sensor readings this way.
So why the Oracle icon on the story's headline?
Because the editor stuck it in the Oracle category. Don't question Slashdot Editor Logic. That way lies madness!
With the ILOM card you need to have your controller on the same subnet.
I'm going to double-check, but I'm pretty sure that's not the case. If true, it's a very silly limitation!
Can you point me at any official documentation that makes this statement? If we're incorrectly stating or implying misinformation, it needs to get fixed.
Thanks for the encouragement. I hope you're right about that Oracle-on-x86 strategy. I was thinking the same way until I heard Ellison shoring up the HP partnership. HP can't be happy about Oracle becoming a systems company — and Sun's x64 systems are more of a threat to HP's core business (commodity computers) than any SPARC system could be.
I'm not an expert, and I certainly don't speak for Sun on this, but I should think that any remote management solution that works with white boxes will work with our x64 systems. But why would you want to spent a lot of money, effort, and rack space for features that we give you for free?
Detail: Sun ILOM hardware is not a PCI card. Depending on the system, it's either built into the motherboard or on a small daughterboard.
Yeah, my post was pure assholedom. And why? Because I refused to engage properly with the conversation you were trying to have with me. That's all there is to being an online asshole, whatever hairs you choose to split.
What, you think that Rob said, "Oh, juicy Sun story, let's place a Sun ad!"? Get real. Web ads mostly get placed based on keywords in the page. Guess which keyword generated this ad?
the T2 seems to be designed almost entirely for applications like Oracle's database with lots of concurrent queries
Well, yeah, but Oracle's database server is hardly unique in that respect. Any server application has to be really good at heavy-duty concurrency. A classic example: the web server you and I are using to communicate.
What's more to the point, Oracle has always had a heavy commitment to the SPARC/Solaris stack, even as most ISVs were abandoning it. They talk about it being more cost effective for their purposes, but I suspect their engineers just think it's more fun to develop for!
Right, they're going to just refuse to support 90% of the server systems out there, and hope that everybody doesn't switch to DB2 or SQL Server. Moving your applications to a new database stack is a pain, but not that much of a pain.
It does. But even before that announcement, it seemed obvious to me that Oracle wasn't going to spent that much money for a company they intended to mostly fold up.
I work for the part of Sun that makes the blades you're talking about. Two important details: they also run Linux, Solaris and ESX Hyperviser. And although I'm certainly glad you think they're great (as I do), remember that x64 systems (blades, rack mount systems, and one lonely workstation) are still a relatively small part of our business.
The future of which is my biggest concern. I'm encouraged that Ellison has seen fit to debunk the assumption that Oracle wasn't interested in Sun's hardware operations. But frustrated that he hasn't said anything about the x64 systems. He did talk about his partnership with HP. One hopes that preserving that relationship doesn't come at a cost of shutting down Sun's x64 products. If it does, I'm out of a job.
So explain, then, why he's willing to spend $6 billion for Sun if he plans to shut most of the company down?
You're wrong!
Yeah, Obama's really turning into a disappointment on the outrage front, Dijongate notwithstanding. If only McCain had won! He would have croaked under the strain in the first week, and we would have had four solid years of Palinisms to make fun of!
It's just not fair.
By normal standards, we are. But these things are relative. Around here, you take a certain about of O&C as normal and don't interpret it as assholeness.
But there are people who are so obnoxious and closeminded that they rate as assholes even by the restricted standards of the geek community. I've since become convinced that Drepper fits that definition. But not because he's O&C and says things like "embedded crap". He's an asshole because he's treating glibc as his private property, not a community effort he's just coordinating.
Online communities can be O&C and still be a community. (Most are!) But Drepper doesn't want glibc to be a community at all.
Discussion and argument means explaining yourself. You didn't do that. You just contradicted me.
Pretty much any sane person agrees that if you are programming it would be beter to write:
Add 5 to the variable a, please.
or
Add 5 to a.
Rather than
a+=5 or a=a+5
Lord God, help us. Do you really believe that? Sorry, you're wrong. The most common way to express an idea is not always the clearest. Indeed, I think it usually isn't. It's easy to overlook this because humans have a remarkable ability to deal with complexity and ambiguity. But if you make the most basic attempt to express technical concepts in "plain" language, you'll soon find that your listener gets so bogged down parsing complicated expressions that they have no hope of understanding what you're trying to say.
If you don't believe me, take a chapter from an algebra textbook, and try rewriting it without any mathematical notation.
I write technical documentation for a living. One reason I'm good at this is that I work hard to prune out the noise that ordinary language is full of. People might still understand what I'm saying if I didn't do this, but they'd have to work harder. To me, the Holy Writ for clear communication is this famous advice from William Strunk:
Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.
Now, what's more concise, "h = sqrt(x^2 * y^2) or "h equals the square root of x squared times the square root of y squared"? Not to mention that the English version is ambiguous! The "technical" version simplifies and eliminates ambiguity. That's why it was invented. The designers of COBOL were really dumb to overlook this.
you needed people with Engineering level education to understand ALGOL.
Is Algol 68 still in use? That one was so arcane even computer scientists ran away from it in terror. But now that I think about it, a full compiler was never written (too hard!) so you must be talking about some other dialect of Algol.
In which case, you're full of it. Algol is not that hard to follow. You do need to learn some abstract concepts, but you need to concepts in order to write real software. Somebody that understands "add a to b" but not "a := a+b;" is not a "novice programmer". They're not a programmer at all, since they've obviously don't have any of the mental skills programmers need.
A group of people that do have these skills are people who write spreadsheet macros. It's possible that more people write this kind of code than any other. These are not "engineers" — they're ordinary business users who have mostly learned this art by doing it. They usually don't even think of themselves as programmers, but by any meaningful definition, they are writing code.
And guess what? Spreadsheet macros uses algebraic notation, not COBOL pseudo-English. So much for "needing to be an engineer".
the last few years seem to have been solely dedicated to 'tarting up' glibc with thread-safety and locale-awareness (and UTF)
"Tarting up"? Thread safety and g11n are considered basic requirements of development platforms these days.
Which is not to disagree with your main point about conditionals. Though I wonder whether the "tartiness" has as much impact on performance as you think it does.
Uh, dude, you do realize that you just contradicted me without explaining why I'm wrong. Exactly how is that less assholish than what Drepper does?
Does too. The Terminator franchise has earned millions so far.
There's a book called "Up the Organization" which the CEO of Avis wrote about his subversive approach to corporate management. A lot of it is dated now, but even back in 1970 the author endorsed your advice about programmers actually working the jobs they're trying to help automate. He says that when his chief programmer was assigned to a reservation desk, the very first customer to approach him caused him to run away in terror!
Consider that most people would regard an argument that's really just a contradiction as pretty assholish, especially when 2 other posts have already made the same point.
Eh. The misuse of "Flamebait" and "Troll" is a systemic problem. I don't TIP, and you shouldn't waste your mod point rescuing my posts. Save them for somebody who makes a really good point and deserves to be modded up. Or a serious flammer who needs to be told to fuck off.
This needs to be fixed in the way moderation is documented, organized, and meta-moderated. I used to throw the odd suggestion to Rob, but not only did he ignore them, recent changes actually go the other way, with a painfully oversimplified metamoderation system.
Can't be fixed without Slashdot management admitting that they have a problem, and they're obviously not going to do that. Time to forget about it and get on with life.
Please. All geeks are unnecessarily offensive and combative. Most non-geeks would use those words to describe the discussion you and I are now having.
That said, I'm now forced to admit that Drepper has an attitude that does indeed go beyond geekiness and into pure assholedom.
I've never done any serious programming in COBOL, though I did study it in college. You're right, this language does have features that are really important for writing business code: report generation, currency data types, etc. It's interesting that these features never migrated into most mainstream block-structured languages. (Notable exception: PL/1. If you use this language, raise your hand. Anyone?) You could argue that people who design languages don't try to understand the needs of business programmers.
But whatever COBOL's advantages, it's still a pretty ugly language.