Re:This idea is genius.
on
MIT Everyware
·
· Score: 2, Insightful
The basic facts taught in an MIT class are generally the same basic facts taught in any reasonably competant university; perhaps you'll get more stuff crammed in you per unit time because they assume the students are sharper than average, perhaps you'll get slightly fresher basic facts when (for example) you take an algorithms course from Ron Rivest, but on balance the material you'll find in the course notes is the same.
The real reason people want to go to MIT is what you do in between classes, and the stuff which isn't in the course notes. You study with some of the brightest students on the planet, you do grunt labwork for some of the most cutting-edge researchers on the planet, and the idle musings (when a lecture runs a bit short) of someone like Rivest are priceless.
Go ahead and learn all you can from all the courses MIT puts on the web, please! Don't worry about MIT; the more knowledge they put out, the more valuable they'll become. (Now if only they had the notes for the Systems Engineering subject, what was its number.....)
can a sarcastic remark made with the deliberate intent to ridicule (when the remark can clearly be seen by anyone as being such) be considered injurous enough to a reputation to successfully sue for slander?
When SCO tries to use these sales as evidence in their next round of lawsuits (should they stay in business that long, which is doubtful), it will presumably come out who bought those licenses. If it is Microsoft, not only is the credibility of SCO's figures immediately called into question (due to the likelihood it wasn't really an arm's-length transaction), but Microsoft's trustworthiness as a company which can be trusted with the largely voluntary sanctions they got from the anti-trust suit also comes into question.
Instead, I'll lay odds it's either a big customer of Microsoft (which will get a break on a few hundred copies of Windows $LATEST if they spring for a half dozen SCO Linux licenses), or a big software developer which is dependant on Microsoft's largesse (who'll get one free MSDN subscription for each Linux license they buy, up to six -- any more and the rug gets yanked RIGHT out from under them...).
Alternatively, it could be a company whose board of directors contains one of the SCO board, and they negotiated a sweetheart deal whereby company X would buy N SCO licenses in exchange for SCO buying Nx$699 worth of pens or something like that.
Having worked in companies sized from 15 to 150,000:
There is a lot more opportunity for "office politics" in large companies, but it can be present in small companies, too. Pathological office politics can be much more obvious in a small company due to there being less background noise to mask it.
A brand-new startup frequently doesn't have any serious competition for resources, which removes a fertile source of office politics, but once money gets tight things can go sour quite easily. Large companies always have lots of inter-group rivalries, either because of a desire to be cost-efficient, or simply because VP Smith thinks his empire isn't as large as VP Jones'.
Steering closer to the topic of the book under review, the main disadvantage of (most) small companies is a tendancy to stint the design phase; slapping something together for an aggressive demo schedule is all-too-often not simply more important than crafting a workable, implementable, and maintainable design, but is crucial to obtaining the funding needed for the next round of aggressive demos which will be more important than doing real design work... Not that large companies never substitute demoware for design, of course, but in general large companies are big on Formal Process, and Formal Processes usually begrudge at least a little time for design. (Of course, once you've completed the ritual design phase, you often are then told that the completion date was already set by the salesman who had no concept of how much time the project would require...)
a moving head in the HDD causes current transients
Indeed, I was disappointed that their testing regime didn't include any disk seek stress tests; a test which forced two disks (or more) to simultaneously seek from track 0 to track N would would exercise the PSUs' transient capacity really well.
Many years ago, a development system I was using had a cabinet with four disks in it. Every once in a while, during parallel makes, all four disks would spin down simultaneously. Eventually, we discovered that if all four drives were told to seek simultaneously (easy to do on a SCSI bus), the resultant load on the 12V line would pull it out of spec, the power supply would shut down, and the disks would spin down (releasing the overload and allowing the power supply to come back up, hiding the evidence). Since this box was a kludge, we "solved" it with a big, fat capacitor on the 12V line (next to the drives) to handle transients. (Which probably reduced the power supply's lifetime due to power up transients, but who powers down development systems?)
Modern disks do draw less transient current during seeks, so this isn't quite the issue it used to be, but it is still a source of stress they ought to have checked.
Maybe, just like you guys criticize Microsoft for, the Third-Party software company doesnt feel like competing with a component provided inside the OS. Especially given the fact that Apple is only a niche market anyway, and their products have been just as good (if not better) on the PC for a long time.
A very good point. After all, Microsoft would never add a feature to their operating system in order to destroy a competitor.
Hmm. Back when I did Windows networking software, we had a test lab with just about 150 PCs, mostly Microns and a few Dells and Gateways thrown in for good measure (i.e. all machines with warranties). We generally had about one failure a month or two, plus we had an employee whose full time job was maintaining the lab. I'll bet dollars to donut holes that cheap homebrew PCs will have at least as high a failure rate. So, that 150 node cluster of cheap PCs is going to cost you at LEAST $3000 a month in salary for the lab monkey and repair costs, to say nothing of electricity and air conditioning. Ten G5s aren't likely to have a single failure, can be administered in the spare time of whoever decided they needed a $30,000 compute farm, and need far less electricity and cooling.
Those are *real costs*. You pay people and the power company *real money*. "Oh, but it's not fair to add those costs when making a cost comparison, because this is just a thought experiment!"
Hell, if you don't have to pay for the *machines*, think of how much faster 150 G5s would be than 10 cheap homebrew PCs! (And they'd probably *still* need less maintenance...)
Safari appears to have a serious memory leak. I've seen it take up over a gigabyte of VM according to "top", and one of my Macs, which appeared to be frozen, after some very careful investigation turned out to be paging itself to death (ah, when disk drives were the size of washing machines, you knew when a machine was thrashing!), and killing Safari (which took twenty minutes to actually send the signal) unwedged the system immediately.
I've used the Safari bug button to chide them about that; I hope they fix it before the final release. Until then, remember to quit out of Safari every once in a while...
Re:Don't download it!
on
Myth II Updated
·
· Score: 2, Informative
Myth and Myth 2 were done by Bungie Software Products (not BioWare), who are now the Bungie Studios division of Microsoft.
However, as of the sale of Bungie to Microsoft, Myth and Myth 2 became the property of Take 2, along with the game Oni (as part of unwinding Take 2's minority stake in Bungie, and as a consolation prize).
Now if only Take 2 would let Bungie fans muck around with the Oni source code...
Slashdot Mirror
Go ahead and learn all you can from all the courses MIT puts on the web, please! Don't worry about MIT; the more knowledge they put out, the more valuable they'll become. (Now if only they had the notes for the Systems Engineering subject, what was its number.....)
MIT '82 (8 and 6-3)
Ask Apple about "butt-headed astronomers".
(Summary: no.)
When SCO tries to use these sales as evidence in their next round of lawsuits (should they stay in business that long, which is doubtful), it will presumably come out who bought those licenses. If it is Microsoft, not only is the credibility of SCO's figures immediately called into question (due to the likelihood it wasn't really an arm's-length transaction), but Microsoft's trustworthiness as a company which can be trusted with the largely voluntary sanctions they got from the anti-trust suit also comes into question. Instead, I'll lay odds it's either a big customer of Microsoft (which will get a break on a few hundred copies of Windows $LATEST if they spring for a half dozen SCO Linux licenses), or a big software developer which is dependant on Microsoft's largesse (who'll get one free MSDN subscription for each Linux license they buy, up to six -- any more and the rug gets yanked RIGHT out from under them...). Alternatively, it could be a company whose board of directors contains one of the SCO board, and they negotiated a sweetheart deal whereby company X would buy N SCO licenses in exchange for SCO buying Nx$699 worth of pens or something like that.
A brand-new startup frequently doesn't have any serious competition for resources, which removes a fertile source of office politics, but once money gets tight things can go sour quite easily. Large companies always have lots of inter-group rivalries, either because of a desire to be cost-efficient, or simply because VP Smith thinks his empire isn't as large as VP Jones'.
Steering closer to the topic of the book under review, the main disadvantage of (most) small companies is a tendancy to stint the design phase; slapping something together for an aggressive demo schedule is all-too-often not simply more important than crafting a workable, implementable, and maintainable design, but is crucial to obtaining the funding needed for the next round of aggressive demos which will be more important than doing real design work... Not that large companies never substitute demoware for design, of course, but in general large companies are big on Formal Process, and Formal Processes usually begrudge at least a little time for design. (Of course, once you've completed the ritual design phase, you often are then told that the completion date was already set by the salesman who had no concept of how much time the project would require...)
Indeed, I was disappointed that their testing regime didn't include any disk seek stress tests; a test which forced two disks (or more) to simultaneously seek from track 0 to track N would would exercise the PSUs' transient capacity really well.
Many years ago, a development system I was using had a cabinet with four disks in it. Every once in a while, during parallel makes, all four disks would spin down simultaneously. Eventually, we discovered that if all four drives were told to seek simultaneously (easy to do on a SCSI bus), the resultant load on the 12V line would pull it out of spec, the power supply would shut down, and the disks would spin down (releasing the overload and allowing the power supply to come back up, hiding the evidence). Since this box was a kludge, we "solved" it with a big, fat capacitor on the 12V line (next to the drives) to handle transients. (Which probably reduced the power supply's lifetime due to power up transients, but who powers down development systems?)
Modern disks do draw less transient current during seeks, so this isn't quite the issue it used to be, but it is still a source of stress they ought to have checked.
A very good point. After all, Microsoft would never add a feature to their operating system in order to destroy a competitor.
Hmm. Back when I did Windows networking software, we had a test lab with just about 150 PCs, mostly Microns and a few Dells and Gateways thrown in for good measure (i.e. all machines with warranties). We generally had about one failure a month or two, plus we had an employee whose full time job was maintaining the lab. I'll bet dollars to donut holes that cheap homebrew PCs will have at least as high a failure rate. So, that 150 node cluster of cheap PCs is going to cost you at LEAST $3000 a month in salary for the lab monkey and repair costs, to say nothing of electricity and air conditioning. Ten G5s aren't likely to have a single failure, can be administered in the spare time of whoever decided they needed a $30,000 compute farm, and need far less electricity and cooling. Those are *real costs*. You pay people and the power company *real money*. "Oh, but it's not fair to add those costs when making a cost comparison, because this is just a thought experiment!" Hell, if you don't have to pay for the *machines*, think of how much faster 150 G5s would be than 10 cheap homebrew PCs! (And they'd probably *still* need less maintenance...)
Safari appears to have a serious memory leak. I've seen it take up over a gigabyte of VM according to "top", and one of my Macs, which appeared to be frozen, after some very careful investigation turned out to be paging itself to death (ah, when disk drives were the size of washing machines, you knew when a machine was thrashing!), and killing Safari (which took twenty minutes to actually send the signal) unwedged the system immediately. I've used the Safari bug button to chide them about that; I hope they fix it before the final release. Until then, remember to quit out of Safari every once in a while...
Myth and Myth 2 were done by Bungie Software Products (not BioWare), who are now the Bungie Studios division of Microsoft.
However, as of the sale of Bungie to Microsoft, Myth and Myth 2 became the property of Take 2, along with the game Oni (as part of unwinding Take 2's minority stake in Bungie, and as a consolation prize).
Now if only Take 2 would let Bungie fans muck around with the Oni source code...