I have two 3ware setups at home, the 8506-4lp, and the new 9000 range (the 85xx range is now no longer available, but you might get some old stock).
Each one is configured identically, 4x160Gb SATA using seagate barracuda sata drives. 3 for RAID 5 and one as "hot spare", which is automatically brought into play should a drive fail.
I had multiple failures using Maxtor drives, and so far, the seagate have been very reliable.
The 3ware stuff can be accessed from the boot-up screen, or they have a little shell program ("tw_cli") where you can see the status of the drives.
To be honest im 100% satisfied. The CPU load is low, the product has been rock solid. The drivers came as part of the kernel. (For the 8506, which i have on linux). For the windows box, again it installed no problem.
The sata cabling makes life much easier.
I also use hot swap caddies, using the 2-to-3 converters. I have two different ones, one from 3ware, and one from chenbro?, which I prefer, as its flush with the case. They both work inthe same way. The hot spare i mount internally, as in theory it should never be used, and when it is, only until i hot swap the failed drive out.
I thought it was written in C++, and simply used a DirectX API.
Dont suppose it would be too much to rip out the DirectX and pop in some OpenGL.
It would be completely possible that they had abstracted away the directX API anyhow, meaning they just need to implement the AbtractionLayer->OpenGL bit.
I wonder what percentage of the code is devoted to the rendering anyhow, 5%?
In the last few years i've worked for 4-12 months at a time in the UK, Norway, Greece, Germany, and NYC.
Basically, it really helps if you have a can-do attitude, and don't come across as one of those irritating America-is-best types. (Nothing annoys a European more than 'Gee, isn't this a cute little town|car|historic building' )
Language skills, to be honest, are not that important ( as long as your English is good ). My Greek is non-existant, and my Norwegian limited to ordering food & beer. What's much more important is you willingness to embrace the various cultural and working practices of your host nation.
(BTW: If you work more than 183 days in Germany, you become liable for German taxes, which are a punitive 60%+, so make sure you factor this into any pay settlement, should you work there. Norway (and other Scandinavian countries) taxes are as high is not higher. Also dont forget the much higher rates of indirect taxation over in Europe (petrol|gas duty, VAT etc)
If you are good at what you do (and remember that there are _many_ people around that think they are good, but really aren't...), and can present yourself professionally, you should not have a problem working in Europe.
Is there really any need now to concentrate on optimising each instruction? As somebody who learnt to program using 68k, i remember doing this well, reducing mulu #40,d0 to a number of shifts and adds. ( moveq #0,d0 is quicker than clr.l d0 etc etc )
Times have moved on however, and that "count-the-raster-lines" performance is something thats just not required nowadays, at least not in the programming domain we are talking about.
That kind of "instruction optimisation" is really the last resort, after the much more important algorithm optimisation, which generally tends to produce far greater benefit.
Even if you hand code your bubble sort in the best assembler ever, its still not going to be quicker for large datasets than a moderately badly written quicksort.
Having never had to use an object in a program ever, I wonder if Mr. Rosler unnecessarily limits himself. Although relatively new to the concept, and long time assembler / C programmer, I am beginning to see that the OO approach has many benefits, not least ease of reuse.
I agree that for pure speed, OO can lack somewhat, as the cost of object instantiation / method execution is not immediately apparent, and for that reason you can write code that works much more slowly than you think it might, but its a balance.
Slashdot Mirror
spfilter
Brings in all these, updated daily.
I have two 3ware setups at home, the 8506-4lp, and the new 9000 range (the 85xx range is now no longer available, but you might get some old stock).
Each one is configured identically, 4x160Gb SATA using seagate barracuda sata drives. 3 for RAID 5 and one as "hot spare", which is automatically brought into play should a drive fail.
I had multiple failures using Maxtor drives, and so far, the seagate have been very reliable.
The 3ware stuff can be accessed from the boot-up screen, or they have a little shell program ("tw_cli") where you can see the status of the drives.
To be honest im 100% satisfied. The CPU load is low, the product has been rock solid. The drivers came as part of the kernel. (For the 8506, which i have on linux). For the windows box, again it installed no problem.
The sata cabling makes life much easier.
I also use hot swap caddies, using the 2-to-3 converters. I have two different ones, one from 3ware, and one from chenbro?, which I prefer, as its flush with the case. They both work inthe same way. The hot spare i mount internally, as in theory it should never be used, and when it is, only until i hot swap the failed drive out.
I thought it was written in C++, and simply used a DirectX API.
Dont suppose it would be too much to rip out the DirectX and pop in some OpenGL.
It would be completely possible that they had abstracted away the directX API anyhow, meaning they just need to implement the AbtractionLayer->OpenGL bit.
I wonder what percentage of the code is devoted to the rendering anyhow, 5%?
What kind of apps are you writing that need c++ anyway?
% ant
Builds anywhere.
If dell cannot supply you with the product you want ( = one with no microsoft ), then go buy somewhere else.
This is surely the way that business works. Supplier can't supply? Find another one....
Or make your own. PCs are only expensive LEGO(tm), but as all the connectors are different, you cant plug them in wrong!
You just have to have the right skills....
In the last few years i've worked for 4-12 months at a time in the UK, Norway, Greece, Germany, and NYC.
Basically, it really helps if you have a can-do attitude, and don't come across as one of those irritating America-is-best types. (Nothing annoys a European more than 'Gee, isn't this a cute little town|car|historic building' )
Language skills, to be honest, are not that important ( as long as your English is good ). My Greek is non-existant, and my Norwegian limited to ordering food & beer. What's much more important is you willingness to embrace the various cultural and working practices of your host nation.
(BTW: If you work more than 183 days in Germany, you become liable for German taxes, which are a punitive 60%+, so make sure you factor this into any pay settlement, should you work there. Norway (and other Scandinavian countries) taxes are as high is not higher. Also dont forget the much higher rates of indirect taxation over in Europe (petrol|gas duty, VAT etc)
If you are good at what you do (and remember that there are _many_ people around that think they are good, but really aren't...), and can present yourself professionally, you should not have a problem working in Europe.
Best of luck.....
I thought this rather strange to be honest.
Is there really any need now to concentrate on optimising each instruction? As somebody who learnt to program using 68k, i remember doing this well, reducing mulu #40,d0 to a number of shifts and adds. ( moveq #0,d0 is quicker than clr.l d0 etc etc )
Times have moved on however, and that "count-the-raster-lines" performance is something thats just not required nowadays, at least not in the programming domain we are talking about.
That kind of "instruction optimisation" is really the last resort, after the much more important algorithm optimisation, which generally tends to produce far greater benefit.
Even if you hand code your bubble sort in the best assembler ever, its still not going to be quicker for large datasets than a moderately badly written quicksort.
Having never had to use an object in a program ever, I wonder if Mr. Rosler unnecessarily limits himself. Although relatively new to the concept, and long time assembler / C programmer, I am beginning to see that the OO approach has many benefits, not least ease of reuse.
I agree that for pure speed, OO can lack somewhat, as the cost of object instantiation / method execution is not immediately apparent, and for that reason you can write code that works much more slowly than you think it might, but its a balance.