Obviously he was really asking for something like IPMI enabled by default, that way we can get rid of the legacy serial port, ps/2 ports, and power button...
Even with multicast you still need a Venue Server, but you don't need lots of network bandwidth for that machine. You can simply use an existing venue server, but that makes you reliant on external services.
It's pretty easy to setup these days, although if you're planning on using h264 you're going to need a whole lot of CPU.
Problem is, your advice sounds reasonable even though it's not.
Looking at the hardware spec sheets, I'd agree with you. But when it came to it, and I compared what at the time were the top cards (Quadro 4500 vs 7800GTX) the difference was night and day. If you wanted to play games, but the 7800GTX, it was waaaay faster. Want to do your own OpenGL apps that are quite demanding (high polygon count, multiple clipping planes, lots of transparency) and it's clear that not only is the 4500 faster, but it gives almost twice the bang for buck. That's pretty impressive for a 1500 ukp card, where you're not expecting value for money...
What you need to see are benchmarks of a Quadro 1700 against a similarly priced 8800. I'd be tempted to call in favour of the Quadro for things that matter to me, but short of buying some to test, it's hard to get decent figures.
I'd say it's more complicated than that. Gamer cards push game graphics around fast. This often means high memory bandwidth for texturing, fast full screen anti-aliasing, and these days fast shader performance. Workstation cards often are better at line-antialiasing, much better with high polygon count work, much better working with mutiple windows. Quadros always used to support more clipping planes in hardware for example. How much of this is a real hardware difference, who knows.
We've got a home-grown application rendering a 4 million polygon model. Quadro 4500 is an order of magnitude faster than a 7800 GTX. You wouldn't guess that from the tech specs.
I'm sure you thought you were being clever, but you weren't.
If you knew anything about parallel algorithms you'd know that it's fairly common to have things that scale with more like 75% efficiency, and you're still happy. It's all down to how much communication is required, and how often it's required. With raytracing normally (as in, a decade ago when I knew anything about this) you'd parallelise over multiple frames. With real-time rendering you'd need to parallelise within a frame. Depending on your scene, there will be a static cost (bounding box calculations) in addition to the per-pixel costs.
Helped by the fact that pascal was designed as a teaching language. The thing that annoys me with teaching Java as a first language is that you have to start with teaching classes first (yuk), or by simply saying "all this public class stuff at the top you can just ignore for now". But if you teach it properly then you can work with Java as a first language. I don't think it's the right choice, but it's not the end of the world.
It's not like teaching kids C makes them understand low level issues better...
Depends what the target of the performance measure is. To stick with your camera, if it's 0.5 pictures a second then that's fine, but if it's 0.5 pixels per second...
Well, in fairness, they drew up a constitution and voted on it. People said no. So now they've reworded it, it's no longer a constitution, and so people don't have to vote on it. So no, we do not have a european constitution, and there seems little point in creating one now.
I agree. I was with him up to his closing comment. The whole point of what you *should* be arguing for is a separation of hardware and operating system as far as the purchase goes. Putting two OSs in the box is simply unfair on the third OS maker. The answer is to select your OS at purchase time just like you choose your monitor. And if you don't like the monitor/OS on offer from Dell, you just buy the machine from them and get the OS from somewhere else.
It *still* leaves a minefield of support problems, but then that's where the hardware manufacturers get a chance to differentiate themselves. Personally I'm quite happy with hardware manufacturers supporting the hardware, and OS vendors supporting the OS. That's pretty much what you get if you install RHEL on a Dell.
Then you bought the wrong license. You can get node-locked matlab licenses that don't require any connection. Funnily enough the shared floating-licenses require a connection to the license server...
USB to RS232 converters are cheap, and easily let you have lots of serial ports. Firewire didn't win because it was backed by the wrong people, and USB is good enough. I'm not disagreeing that firewire is in many cases better, but that's not the point.
Slashdot Mirror
If there was an agreed standard, then you'd save on cost, since you wouldn't include one in the box with the device.
nspluginwrapper?
Obviously he was really asking for something like IPMI enabled by default, that way we can get rid of the legacy serial port, ps/2 ports, and power button...
IRIX on an O2 as a pinnacle of stability?
Hahaha. IRIX back then was so buggy I'm amazed that the user experience was as good as it was.
I'm entirely unbothered by what you want; having cars that are taller than average for the purpose of getting a better view is antisocial.
Even with multicast you still need a Venue Server, but you don't need lots of network bandwidth for that machine. You can simply use an existing venue server, but that makes you reliant on external services.
It's pretty easy to setup these days, although if you're planning on using h264 you're going to need a whole lot of CPU.
Only if you're planning on installing a microwave death-ray in your loft...
You don't have to wonder with RedHat. Just look at the SRPMs and see what patches they've applied.
I think you're missing the point. Unused memory is wasted memory, given how quick you can free it, and how slow disk is. I see this on my linux box:
Mem: 8178828k total, 8125980k used, 52848k free, 258096k buffers
Swap: 8388600k total, 312k used, 8388288k free, 7385240k cached
I'm quite happy I've only got 50 Mbytes free.
If you want lots of free memory, take it out and put it on your desk to look at.
That's not true. Quite a few modern engines are factory certified to run at least on E85.
Vital things like a second decoder? There was me thinking I liked the idea of Blu-Ray for the better picture...
Problem is, your advice sounds reasonable even though it's not.
Looking at the hardware spec sheets, I'd agree with you. But when it came to it, and I compared what at the time were the top cards (Quadro 4500 vs 7800GTX) the difference was night and day. If you wanted to play games, but the 7800GTX, it was waaaay faster. Want to do your own OpenGL apps that are quite demanding (high polygon count, multiple clipping planes, lots of transparency) and it's clear that not only is the 4500 faster, but it gives almost twice the bang for buck. That's pretty impressive for a 1500 ukp card, where you're not expecting value for money...
What you need to see are benchmarks of a Quadro 1700 against a similarly priced 8800. I'd be tempted to call in favour of the Quadro for things that matter to me, but short of buying some to test, it's hard to get decent figures.
I'd say it's more complicated than that. Gamer cards push game graphics around fast. This often means high memory bandwidth for texturing, fast full screen anti-aliasing, and these days fast shader performance. Workstation cards often are better at line-antialiasing, much better with high polygon count work, much better working with mutiple windows. Quadros always used to support more clipping planes in hardware for example. How much of this is a real hardware difference, who knows.
We've got a home-grown application rendering a 4 million polygon model. Quadro 4500 is an order of magnitude faster than a 7800 GTX. You wouldn't guess that from the tech specs.
I'm sure you thought you were being clever, but you weren't.
If you knew anything about parallel algorithms you'd know that it's fairly common to have things that scale with more like 75% efficiency, and you're still happy. It's all down to how much communication is required, and how often it's required. With raytracing normally (as in, a decade ago when I knew anything about this) you'd parallelise over multiple frames. With real-time rendering you'd need to parallelise within a frame. Depending on your scene, there will be a static cost (bounding box calculations) in addition to the per-pixel costs.
jh
Helped by the fact that pascal was designed as a teaching language. The thing that annoys me with teaching Java as a first language is that you have to start with teaching classes first (yuk), or by simply saying "all this public class stuff at the top you can just ignore for now". But if you teach it properly then you can work with Java as a first language. I don't think it's the right choice, but it's not the end of the world.
It's not like teaching kids C makes them understand low level issues better...
Two data points, surely? And if they're right, they expect more in the future...
Depends what the target of the performance measure is. To stick with your camera, if it's 0.5 pictures a second then that's fine, but if it's 0.5 pixels per second...
You can call it interpreted if you're trying to win a pub argument, but JIT compiled code very much different.
Well, in fairness, they drew up a constitution and voted on it. People said no. So now they've reworded it, it's no longer a constitution, and so people don't have to vote on it. So no, we do not have a european constitution, and there seems little point in creating one now.
I agree. I was with him up to his closing comment. The whole point of what you *should* be arguing for is a separation of hardware and operating system as far as the purchase goes. Putting two OSs in the box is simply unfair on the third OS maker. The answer is to select your OS at purchase time just like you choose your monitor. And if you don't like the monitor/OS on offer from Dell, you just buy the machine from them and get the OS from somewhere else.
It *still* leaves a minefield of support problems, but then that's where the hardware manufacturers get a chance to differentiate themselves. Personally I'm quite happy with hardware manufacturers supporting the hardware, and OS vendors supporting the OS. That's pretty much what you get if you install RHEL on a Dell.
It's the problem you have to face if you're a monopolist, there's no two ways about it.
In which case you're pretty dim.
Then you bought the wrong license. You can get node-locked matlab licenses that don't require any connection. Funnily enough the shared floating-licenses require a connection to the license server...
Because you can't see all of it, as anything beyond LifeOfTheUniverse light years would yet to have come into view.
And that ignores all the crap between here and there that absorb the emitted radiation.
Two points:
USB to RS232 converters are cheap, and easily let you have lots of serial ports.
Firewire didn't win because it was backed by the wrong people, and USB is good enough. I'm not disagreeing that firewire is in many cases better, but that's not the point.