"Liberi" are freemen - either born free (ingenui), or having been freed from slavery (libertini).
So the four things would be books, free men, freedom/liberty, and generosity/social virtue. Well, that's six things, but chalk it up to my liberalitas.
I agree with most of your sentiments - as you say in your point 4, the truth is that this announcement doesn't change much. So Microsoft doesn't want to push any more Win2K Pro into the channel, for obvious reasons. But this doesn't really affect anyone's strategy, unless they were asleep at the switch.
I've already provided my clients with a response to this latest news, which amounts to "continue upgrades to Win2K as already planned, avoid XP and.NET until further notice, continue working towards open solutions (e.g. Java application servers), and don't panic or get excited."
I don't have to twist any arms, and nothing really changes. No-one's rushing to upgrade to XP, but similarly, no-one's rushing to move to non-Windows desktops, nor are they likely to in the forseeable future.
I'm not sure whether you're talking about using aggregated FCAL connections as the communications medium, or actually writing to and reading from disk/cache (which is what the original poster seemed to be suggesting.)
Even with a big cache (and the 8GB you mentioned isn't much, for this sort of application), if the communications go through such a cache, then the caching box would need 20Gbps total bandwidth to support reading and writing the 10Gbps simultaneously. Even if a bundle of FCAL connections (e.g. 5 x 2Gbps to each host) is capable of that bandwidth in theory, you're going to need a pretty good box in the middle. I've seen SANs that can sustain 5Gbps, but not 10Gbps or 20Gbps. I don't doubt that some might exist, but most real SANs can't do this.
If you're simply talking about bundling FCAL connections to reach the desired bandwidth between two machines or clusters, well duh. But Ethernet has a bunch of advantages over FCAL - in fact, the SAN industry is licking its lips waiting for this tech.
no single peice of commodity hardware would fill that with usefull data.
On the one hand you're talking about what you call "real" SANs that can sustain 20Gbps bandwidth, and on the other hand you're worrying about whether "commodity" hardware can saturate it? Give me a break.
The bottom line is that communicating through a SAN doesn't really make sense today if your goal is 10Gbps point-to-point streaming communication.
Um, what speed do you think SAN's are accessed at?? They would still need the 10Gbit Ethernet to connect to the SAN, otherwise they'd be limited to a lower speed. Anyway, disks are a huge bottleneck in this sort of thing - a fancy fiber channel RAID array will do 1.6Gbps, which would have seriously slowed down this test.
I can't think of a practical situation, but if somebody could explain why you would need to send a gigabyte of data in one second vs. 8 second I'd be more impressed.
You're thinking point-to-point, but that's not what networks are for. Imagine the backbone at a hospital with CAT scanners, MRIs, xrays all generating digital images, and doctors around the hospital accessing a database of those images. 10Gbps isn't enough for applications like this. My local dentist's office uses digital xrays, and they complain about the 1Gbps on their little LAN - and they probably don't have more than about 15 workstations.
And as someone else mentioned, rendering and editing of digital video uses up even more bandwidth. You don't have to be Pixar to need to do stuff like this - many companies in the media business can use this.
Places that deal with a lot of multimedia can use this bandwidth - easily. Medical applications, such as high-resolution digital xrays and CAT scans, can generate enormous volumes of data which can take ages to push around - sneakernet is still sometimes the easiest/quickest way. Then there's video - anyone doing rendering and editing of video can use this.
The throughput from a single hard disk is not that important: in these environments, RAID arrays (typically fiber channel) optimized for read performance allow overall disk performance at e.g. 1.6Gbps. If you have multiple such servers on your network, with many workstations trying to get at the data, 1Gbps Ethernet starts looking a little slow, especially for the backbones.
FWIW, i agree with you, but then again, "Ask Slashdot" is a little like "Jeopardy" - you have to phrase your question so that it's relevant to geeks/nerds. Which results in questions like this one...
Just be thankful no-one's yet asked CmdrTaco for advice on marriage proposals!
It could be done pretty easily with a small hardware mod, which could be installed inside the keyboard. For example, a microcontroller like the PIC or 68HC11 could be connected to the keyboard cable output, to read it and translate each value, and send the desired value on to the PC. This would mainly be a programming project, it doesn't require much electronics knowledge since the circuits are very simple and can be copied from similar devices. Here's some info about keyboard interfacing - there's plenty more if you search.
I had the same thought about the feedback between the Dvorak layout and the final layout, but to me that invalidates your statement that "his final layout's resemblance to dvorak testifies to the advantage of dvorak." It may testify much more to the power of skewing a test, and how easy it is to get the results you expect, regardless of their validity. I'm not saying Dvorak isn't good, but rather that this guy's test wouldn't qualify as good science (not that it's meant to be, I guess).
Not sure if you're trolling, but this is a fallacy. The more a country tries to do, the better they'll do. If they just do nothing but react to the disasters, they'll never improve.
Thousands of companies have used those for many, many years without meeting with this sure disaster you predict.
Thousands of companies have met with disaster in various forms - products that have been abandoned underneath them - Visual J++ being a fairly recent, relevant example. J# is too late to help those companies. VB developers have been similarly screwed.
Also, the hidden costs of using MS platforms are high: Microsoft generally forces upgrades whether you want them or not, for reasons that are not technical. They unnecessarily interrelate products and generally bring the antitrust concept of "tying" to new heights. Just because the average business isn't aware of these costs, doesn't mean they don't exist. However, open platforms will continue to succeed in opposition to Microsoft, exactly because of issues like this.
Thousands of developers have made a very comfortable living with the "lock-in" of Windows developpment
I'm not saying that developers can't make a living developing for Windows - clearly, they can, although in the past, for smart developers, it's been a frustrating business because of lack of openness. It'll be interesting to see how much that really changes under.NET. Anyway, my point is that.NET is a big risk for businesses to take, since they become completely dependent on a single vendor in a way that goes beyond what was the case before - e.g. Microsoft didn't own the X86 instruction set.
The lock-in play is to get businesses more dependent on MS intellectual property than ever before, and in less of a position to choose alternatives. Ah well, I look forward to the next round of anti-trust litigation, which is bound to begin in the next few years, possibly depending on whether Dubya gets re-elected.
You don't understand. All Trek episodes are vetted for Prime Directive violations before being sent back in time for our viewing pleasure. They couldn't reveal that Fermat's theorem was going to be solved in our near future, without disrupting the timeline. So "The Royale" had to be censored, of course.
If you were a true Trekkie, you would know that and would have copies of the original, uncut episodes...
Presumably the moderator in question didn't follow the link, or do we really have such extreme fundamentalists on/. as to be offended by a movie like Pi?
Technically it can do 1600x1200 resolution, but the screen itself gets so unreadable from the large pixels that the screen itself is only useable at 640x480 or 800x600
You've been misled. 800x600 is the highest native resolution the Gateway Destination (31") supports - and some only supported 640x480. However, it's possible to scale down higher resolution images to display them, but obviously you're going to lose an enormous amount of detail scaling down from 1600x1200, which is quadruple the resolution.
The reason the Destination sucks is the low native resolution combined with the large physical size of the screen, making for relatively few, large pixels which need to be viewed from some distance.
If the screen truly had a 1600x1200 resolution and a 31" size, it would be quite usable. However, it still wouldn't be nearly as good as a smaller 1600x1200 monitor viewed from a closer distance.
But hey, guess what OOP is? It's a way of organizing your procedural code, with some assistance from the language/compiler to help enforce access policies.
Although that characterization does describe a valid benefit of OOP, it completely misses possibly the most important aspect of OOP, which is the introduction of type-based polymorphism.
In fact, the "organizing procedural code" benefit of OOP is simply a side effect of designing systems based on interacting types, something which procedural systems didn't directly support. Saying that OOP is a way of organizing your procedural code completely misses the point.
Modern texts on refactoring focus on factoring issues in these systems of interacting types, and as such are revelant to current systems in a way that it's difficult for e.g. Plauger to be. Certainly, normalizing/factoring/compressing systems has been and always will be a basic goal of software development, but just because the concept is old doesn't mean that there aren't new insights into it. Suggesting otherwise is a little like saying that using Jupiter's gravity to give a spaceprobe an energy boost is nothing new, since Newton discovered gravity. I suspect NASA scientists get most of their information somewhere other than Principia Mathematica.
data structures the things that tie the chicks [sic] together
When you find yourself subconsciously writing about "tying chicks together" in a discussion of source code organization, it's time to take a break from the keyboard and go get laid, if you can...
I agree with you about the correlation between database normalization and code factoring [which is the correct and long-established term, no matter how much you might dislike the term "refactoring"]. However, to get a database into Nth normal form can be done by following some fairly simple rules. Code isn't quite so easy. Books like Fowler's refactoring book cover details, subtleties, and rationales that even above-average developers may miss.
Also, refactoring is a name for something that programmers have always done anyway. An agreed-on name is better than no name at all, or many non-standard names.
But from a purely technical perspective,.NET is pretty great.
That may be true, but from a business perspective, trusting Microsoft to act in your best interests is a proven losing strategy. The business risk of using.NET is enormous, it's the biggest lock-in play that's ever existed in the technical world.
You're confusing different theoretical limits. The theoretical limit of current Firewire is 400Mbps. The idea is that the Firewire spec allows for future versions of Firewire to reach 1600Mbps, but current Firewire buses aren't even theoretically capable of that. In practice, 400Mbps Firewire doesn't get much above 315Mbps of actual data throughput - consistently slower even than ATA/66, which has been demonstrated in real-world tests.
OTOH, ATA/100 is theoretically capable of 100MB/s, i.e. 800Mbps, in its current incarnation today. You probably won't hit that in practice, not only because of bus limitations, but because 50MB/s is about the max any IDE drive can pump out, so you'd need two drives running continuously at their absolute peak speed in order to saturate the ATA/100 bus.
You're right. Ignoring the quantum stuff, just the fact that he's complaining about I/O bottlenecks on a bus that's designed to support multiple devices is silly. The whole point is that a single device shouldn't be able to saturate the bus.
Current Firewire is half the bandwidth of ATA/100. Theoretically, Firewire can be saturated by a single fast disk, so for internal Firewire you'd want a separate Firewire channel on the motherboard for each disk - but Firewire was really intended to be a serial bus which supports multiple devices. That's why in its current form, Firewire is more appropriate for connecting devices like video recorders, or hooking up a single external drive for data portability, than for internal drives.
Slashdot Mirror
- "Liberalitas" is "the Roman goddess/personification of, variously, generosity, largesse, and social virtue".
- "Liberi" are freemen - either born free (ingenui), or having been freed from slavery (libertini).
So the four things would be books, free men, freedom/liberty, and generosity/social virtue. Well, that's six things, but chalk it up to my liberalitas.Microsoft?
I've already provided my clients with a response to this latest news, which amounts to "continue upgrades to Win2K as already planned, avoid XP and .NET until further notice, continue working towards open solutions (e.g. Java application servers), and don't panic or get excited."
I don't have to twist any arms, and nothing really changes. No-one's rushing to upgrade to XP, but similarly, no-one's rushing to move to non-Windows desktops, nor are they likely to in the forseeable future.
Even with a big cache (and the 8GB you mentioned isn't much, for this sort of application), if the communications go through such a cache, then the caching box would need 20Gbps total bandwidth to support reading and writing the 10Gbps simultaneously. Even if a bundle of FCAL connections (e.g. 5 x 2Gbps to each host) is capable of that bandwidth in theory, you're going to need a pretty good box in the middle. I've seen SANs that can sustain 5Gbps, but not 10Gbps or 20Gbps. I don't doubt that some might exist, but most real SANs can't do this.
If you're simply talking about bundling FCAL connections to reach the desired bandwidth between two machines or clusters, well duh. But Ethernet has a bunch of advantages over FCAL - in fact, the SAN industry is licking its lips waiting for this tech.
no single peice of commodity hardware would fill that with usefull data.
On the one hand you're talking about what you call "real" SANs that can sustain 20Gbps bandwidth, and on the other hand you're worrying about whether "commodity" hardware can saturate it? Give me a break.
The bottom line is that communicating through a SAN doesn't really make sense today if your goal is 10Gbps point-to-point streaming communication.
First relevant beowulf cluster post, ever!!!
Um, what speed do you think SAN's are accessed at?? They would still need the 10Gbit Ethernet to connect to the SAN, otherwise they'd be limited to a lower speed. Anyway, disks are a huge bottleneck in this sort of thing - a fancy fiber channel RAID array will do 1.6Gbps, which would have seriously slowed down this test.
You're thinking point-to-point, but that's not what networks are for. Imagine the backbone at a hospital with CAT scanners, MRIs, xrays all generating digital images, and doctors around the hospital accessing a database of those images. 10Gbps isn't enough for applications like this. My local dentist's office uses digital xrays, and they complain about the 1Gbps on their little LAN - and they probably don't have more than about 15 workstations.
And as someone else mentioned, rendering and editing of digital video uses up even more bandwidth. You don't have to be Pixar to need to do stuff like this - many companies in the media business can use this.
The throughput from a single hard disk is not that important: in these environments, RAID arrays (typically fiber channel) optimized for read performance allow overall disk performance at e.g. 1.6Gbps. If you have multiple such servers on your network, with many workstations trying to get at the data, 1Gbps Ethernet starts looking a little slow, especially for the backbones.
Just be thankful no-one's yet asked CmdrTaco for advice on marriage proposals!
It could be done pretty easily with a small hardware mod, which could be installed inside the keyboard. For example, a microcontroller like the PIC or 68HC11 could be connected to the keyboard cable output, to read it and translate each value, and send the desired value on to the PC. This would mainly be a programming project, it doesn't require much electronics knowledge since the circuits are very simple and can be copied from similar devices. Here's some info about keyboard interfacing - there's plenty more if you search.
Yeah, they were worried about that cuz they didn't have kleenex back then...
Not sure if you're trolling, but this is a fallacy. The more a country tries to do, the better they'll do. If they just do nothing but react to the disasters, they'll never improve.
Thousands of companies have met with disaster in various forms - products that have been abandoned underneath them - Visual J++ being a fairly recent, relevant example. J# is too late to help those companies. VB developers have been similarly screwed.
Also, the hidden costs of using MS platforms are high: Microsoft generally forces upgrades whether you want them or not, for reasons that are not technical. They unnecessarily interrelate products and generally bring the antitrust concept of "tying" to new heights. Just because the average business isn't aware of these costs, doesn't mean they don't exist. However, open platforms will continue to succeed in opposition to Microsoft, exactly because of issues like this.
Thousands of developers have made a very comfortable living with the "lock-in" of Windows developpment
I'm not saying that developers can't make a living developing for Windows - clearly, they can, although in the past, for smart developers, it's been a frustrating business because of lack of openness. It'll be interesting to see how much that really changes under .NET. Anyway, my point is that .NET is a big risk for businesses to take, since they become completely dependent on a single vendor in a way that goes beyond what was the case before - e.g. Microsoft didn't own the X86 instruction set.
The lock-in play is to get businesses more dependent on MS intellectual property than ever before, and in less of a position to choose alternatives. Ah well, I look forward to the next round of anti-trust litigation, which is bound to begin in the next few years, possibly depending on whether Dubya gets re-elected.
If you were a true Trekkie, you would know that and would have copies of the original, uncut episodes...
Presumably the moderator in question didn't follow the link, or do we really have such extreme fundamentalists on /. as to be offended by a movie like Pi?
You've been misled. 800x600 is the highest native resolution the Gateway Destination (31") supports - and some only supported 640x480. However, it's possible to scale down higher resolution images to display them, but obviously you're going to lose an enormous amount of detail scaling down from 1600x1200, which is quadruple the resolution.
The reason the Destination sucks is the low native resolution combined with the large physical size of the screen, making for relatively few, large pixels which need to be viewed from some distance.
If the screen truly had a 1600x1200 resolution and a 31" size, it would be quite usable. However, it still wouldn't be nearly as good as a smaller 1600x1200 monitor viewed from a closer distance.
I also read that initial drives were supposed to be comparably priced from the start. I just didn't believe it. :)
Although that characterization does describe a valid benefit of OOP, it completely misses possibly the most important aspect of OOP, which is the introduction of type-based polymorphism.
In fact, the "organizing procedural code" benefit of OOP is simply a side effect of designing systems based on interacting types, something which procedural systems didn't directly support. Saying that OOP is a way of organizing your procedural code completely misses the point.
Modern texts on refactoring focus on factoring issues in these systems of interacting types, and as such are revelant to current systems in a way that it's difficult for e.g. Plauger to be. Certainly, normalizing/factoring/compressing systems has been and always will be a basic goal of software development, but just because the concept is old doesn't mean that there aren't new insights into it. Suggesting otherwise is a little like saying that using Jupiter's gravity to give a spaceprobe an energy boost is nothing new, since Newton discovered gravity. I suspect NASA scientists get most of their information somewhere other than Principia Mathematica.
When you find yourself subconsciously writing about "tying chicks together" in a discussion of source code organization, it's time to take a break from the keyboard and go get laid, if you can...
I agree with you about the correlation between database normalization and code factoring [which is the correct and long-established term, no matter how much you might dislike the term "refactoring"]. However, to get a database into Nth normal form can be done by following some fairly simple rules. Code isn't quite so easy. Books like Fowler's refactoring book cover details, subtleties, and rationales that even above-average developers may miss.
Also, refactoring is a name for something that programmers have always done anyway. An agreed-on name is better than no name at all, or many non-standard names.
That may be true, but from a business perspective, trusting Microsoft to act in your best interests is a proven losing strategy. The business risk of using .NET is enormous, it's the biggest lock-in play that's ever existed in the technical world.
OTOH, ATA/100 is theoretically capable of 100MB/s, i.e. 800Mbps, in its current incarnation today. You probably won't hit that in practice, not only because of bus limitations, but because 50MB/s is about the max any IDE drive can pump out, so you'd need two drives running continuously at their absolute peak speed in order to saturate the ATA/100 bus.
You're right. Ignoring the quantum stuff, just the fact that he's complaining about I/O bottlenecks on a bus that's designed to support multiple devices is silly. The whole point is that a single device shouldn't be able to saturate the bus.
Current Firewire is half the bandwidth of ATA/100. Theoretically, Firewire can be saturated by a single fast disk, so for internal Firewire you'd want a separate Firewire channel on the motherboard for each disk - but Firewire was really intended to be a serial bus which supports multiple devices. That's why in its current form, Firewire is more appropriate for connecting devices like video recorders, or hooking up a single external drive for data portability, than for internal drives.
You can bet the first SATA drives are going to be quite a bit more expensive than an equivalent capacity ATA100, too.
Time to start shopping for converted drives?