This would be a great harddrive for all sorts of performance sensitive applications. I'm thinking of things like video transcoding or tivo-like situations where you're storing in one place and reading in another.. it would make a huge screaming fast ring buffer too.
But even for regular server-type activities, I think that decoupling read/write on a hdd would make sense.. and besides, if you're not doing any writing you get an immediade 2x performance boost on your random access reads (or better if you're smart about writing the elevator code)
Some DSL modems *cough*alcatel*cough* have been designed to buffer data (1MB or more) when it reaches the maximum allotted bandwidth instead of simply dropping it on the floor like a good device should. Buffering the data seriously confuses the TCP flow control of your OS because it sees huge bandwidth going through one second, followed by no bandwidth the next, and so on.. These modems also throttle the downstream when the upstream is maxed, which is what you're probably seeing.
If you traffic shape your upstream to just under the cap you shouldn't see this sort of stupidity (or you could update the firmware yourself, though your ISP probably wouldn't like that)
linux 2.5 has brought my aging vaio laptop ALSA for its poorly supported ymfpci soundcard, and a frame buffer driver for its meager NeoMagic video chip, and now finally software suspend for its no-hope-in-hell-of-getting-it-to-work-under-anythi ng-but-windows suspend feature.
So when you do find something unexpected during implementation, which always happens, you run back to the whiteboard and read what it says, and send back the appropriate exception. No design changes, no mess, no fuss... unless you screwed up the design in the first place, in which case you probably want to get some lessons so that you know what you are talking about (since its evident that you don't).
By unexpected, I don't mean simply cases that result in exceptions, I'm talking about valid situations that weren't thought of in the first design process. (we're all human, right?)
For example: some method returns 6 different types of widget, 2 of which must be handled differently 7 method calls later, where the Right Way of handling this situation might mean rearranging a class heirarchy and touching many different files.
I agree that with OO, if things are designed well (which becomes difficult very quickly as the complexity of the project increases) there should be minimal changes required in some circumstances, but the resulting code of OOA and OOD tends to be more rigid when it comes to supporting things not included in the original design, than code written in some other languages.
Inflexibility may well be a valid design goal, but I disagree with anyone who would use it as the default when introducing people to programming.
.. like designing GUI libraries or monolithic applications, but most programming is an iterative process better suited to other languages.
Consider: with OO you're told that you should spend 80% of your develompent time in OOA and OOD (making cute little object diagrams on whiteboards before doing any real work). I doubt that anyone except the most experienced programmers can forsee all the problems that they will encounter when writing the code, before actually writing it.
And once you do run into something that you didn't expect, you have to run back to the whiteboard for some more OOA & OOD, then sit down and make little changes over many source files that depended on the way you set things out the first time (at least in Java or other strongly-typed OO languages). Personally, I find that pretty wasteful.
Why not try a language that encourages you to write small amounts of code that can be tested in isolation, and then makes it easy to combine that tested code in different ways with little modification. I've found Python to be very good at this, but I'm sure there are some other good options.
Slashdot Mirror
"actually outrunning XP"? You mean it's possible to make improvements to an OS that *improve* its performance? Shocking.
I use Quasar accounting and point-of-sale (GPL) for a small retail business, and I have no complaints.
http://www.linuxcanada.com/
This would be a great harddrive for all sorts of performance sensitive applications. I'm thinking of things like video transcoding or tivo-like situations where you're storing in one place and reading in another.. it would make a huge screaming fast ring buffer too.
But even for regular server-type activities, I think that decoupling read/write on a hdd would make sense.. and besides, if you're not doing any writing you get an immediade 2x performance boost on your random access reads (or better if you're smart about writing the elevator code)
Some DSL modems *cough*alcatel*cough* have been designed to buffer data (1MB or more) when it reaches the maximum allotted bandwidth instead of simply dropping it on the floor like a good device should. Buffering the data seriously confuses the TCP flow control of your OS because it sees huge bandwidth going through one second, followed by no bandwidth the next, and so on.. These modems also throttle the downstream when the upstream is maxed, which is what you're probably seeing.
If you traffic shape your upstream to just under the cap you shouldn't see this sort of stupidity (or you could update the firmware yourself, though your ISP probably wouldn't like that)
Am I? As a consumer if I'm offered less, why shouldn't I expect to pay less?
Companies can only get away with this sort of thing in an unhealthy market.. I place my vote firmly on "Cash Grab"
Sounds good but in my area noone will be paying less. We currently have 1.1Mbit DSL for $40 CDN/ month, now we have a choice of:
same speed with a brand new 3GB max for $45/month
slightly faster with 10GB max for $60/month
And the price hikes for cable are on their way..
Really? Hmm.. OSS has never worked for my YMF-744B chip, which has been supported for more than a year by the ALSA drivers.
:-/
I had assumed that ALSA is the future for soundcards under Linux, I had no idea people are still working on OSS.
Why bother with OSS when the included ALSA driver works just fine?
linux 2.5 has brought my aging vaio laptop ALSA for its poorly supported ymfpci soundcard, and a frame buffer driver for its meager NeoMagic video chip, and now finally software suspend for its no-hope-in-hell-of-getting-it-to-work-under-anythi ng-but-windows suspend feature.
Gratz to all you fine kernel hackers out there.
The last time I checked, the #1 reason Linux on the desktop is going nowhere is because there is no Linux version of MS Office.
real weapons
realistic maps
thriving user community
Grab Loki's patch to install Unreal Tournament, then hop over to Strike Force Center to try the mod.
So when you do find something unexpected during implementation, which always happens, you run back to the whiteboard and read what it says, and send back the appropriate exception. No design changes, no mess, no fuss ... unless you screwed up the design in the first place, in which case you probably want to get some lessons so that you know what you are talking about (since its evident that you don't).
By unexpected, I don't mean simply cases that result in exceptions, I'm talking about valid situations that weren't thought of in the first design process. (we're all human, right?)
For example: some method returns 6 different types of widget, 2 of which must be handled differently 7 method calls later, where the Right Way of handling this situation might mean rearranging a class heirarchy and touching many different files.
I agree that with OO, if things are designed well (which becomes difficult very quickly as the complexity of the project increases) there should be minimal changes required in some circumstances, but the resulting code of OOA and OOD tends to be more rigid when it comes to supporting things not included in the original design, than code written in some other languages.
Inflexibility may well be a valid design goal, but I disagree with anyone who would use it as the default when introducing people to programming.
Consider: with OO you're told that you should spend 80% of your develompent time in OOA and OOD (making cute little object diagrams on whiteboards before doing any real work). I doubt that anyone except the most experienced programmers can forsee all the problems that they will encounter when writing the code, before actually writing it.
And once you do run into something that you didn't expect, you have to run back to the whiteboard for some more OOA & OOD, then sit down and make little changes over many source files that depended on the way you set things out the first time (at least in Java or other strongly-typed OO languages). Personally, I find that pretty wasteful.
Why not try a language that encourages you to write small amounts of code that can be tested in isolation, and then makes it easy to combine that tested code in different ways with little modification. I've found Python to be very good at this, but I'm sure there are some other good options.