The KDE and GNOME guys are competing with Windows on Windows' playing field. If you don't want all that functionality, go with WindowMaker or fluxbox or something.
Actually, England tested armor that allowed a tank to survive direct hits by both armor-piercing and incendiary shells. Saw it on Modern Marvels a few weeks ago.
No, but I imagine you could use software to produce a 3D model from two photographs taken at different angles. So I doubt there's more than one public photo of the beast.
In the US Navy, at least, all crewmembers are trained in fire and damage control, for good reason. One ship's entire damage control crew was wiped out in a blast, and nobody else was trained in damage control. The ship survived the experience, though.
Again, in the US Navy, the standard firefighting gear includes an oxygen mask, so the fumes shouldn't be a problem. Treating crewmembers caught in the fumes before they could get their equipment on will probably require some additional training for the medical personnel, though.
I don't think they'll start to cut their prices until fewer people start signing up.
I mean, it's all about growth...once the market get saturated for the price they're offering, they'll have to cut costs if they want to continue to grow.
I figured the software compiler would handle it. Add some extensions to translate certain common bits of code into FPGA code.
Shared libraries would especially benefit. FFTs and regex engines, for one. SIMD trigonometry functions. A Perl or Java VM. The 3D accelerator's software driver. CRC checking.
Some kernel modules would benefit as well. Framebuffer code, crypto ciphers and digest algorithms. The scheduler (as I mentioned earlier). The IRQ handler.
Even if code doesn't necessarily require superfast algorithmic processing, you could treat FPGA space as another cache. The kernel could provide a secure IPC mechanism that kept all data on-die.
This is truly a case where if you build it, and provide some practical sample code, they will come.
I'm pretty sure Heinlein said it through Lazarus Long, but Heinlein also has a habit of uncredited quotes. Or even partial-references ("Not mine...some ancient Earth bloke.")
Re:You don't have the slightest idea...
on
QNX 6.3 Released
·
· Score: 1
The kernel gets interrupted by events, and calls the process associated with the event.
Any process that process sends a message to gets immediately elevated to the priority level of the process sending the message...i.e. it gets run immediately.
The kernel also can get its temporary priority elevated in this way.
I've been running from an extracted zip file since last fall. The only problem is that your settings don't go with you, even if you pack everything back into the zip file.
The drawbacks: you either need a FPGA that you can reprogram very quickly (on the order of nanoseconds) or you need a task that takes a long time and can more than benefit from having to take the time it takes to reprogram the FPGA,/i>
That's why you'd divide the gate array into sections. Assuming you weren't trying to run too many apps with FPGA code at the same time, you can leave the section of code in there while waiting for that process's next timeslice.
FLOPS won't work; it ignores workloads that use integer math. It also ignores workloads that specialize in vector math. And workloads that depend a great deal on automated decision-making. And random-number generation.
The problem is that no matter what metric you use, it won't fit all cases. Different workloads have different requirements. Personally, I'd like to see programmable hardware...Essentially an FPGA section on CPUs. Programs would provide the OS's scheduler with a circuit layout, and the scheduler would have the layout programmed in when needed.
Each program doesn't necessarily have to have access to the whole grid array, either. The scheduler could divide the array into sections. One section would be for speeding up scheduler operations. The rest would be available to have programs loaded in. You wouldn't even need to erase one program's hardware when another program had something it wanted to implement. With the hardware divided, you could load the new program's code into an empty slot, and leave the old code available for the old program's next timeslice. (To prevent having to reprogram the FPGA section every time the program's turn came about.)
What bugs me is how AMD and Intel kicked up their processor speeds. Both of them made their pipelines deeper.
While that's fine for some workloads, with more instructions being executed at the same time, it harms workloads that depend heavily on the results of current calculations to figure out what to do next.
Intel eased the problem by implementing hyperthreading; I'm surprised we haven't seen the same thing come out of AMD's corner.
That doesn't work for those of us who require medical insurance as a job benefit. I'm on three perscriptions, and paying for them out-of-pocket would rival paying for rent.
Or even X10. The ISP I worked at for years had a box attached to a phone line that controlled the power going to several machines running unstable software.
You dialed the phone number, then the passcode, then the X10 address of the box you wanted to power-cycle.
Slashdot Mirror
The KDE and GNOME guys are competing with Windows on Windows' playing field. If you don't want all that functionality, go with WindowMaker or fluxbox or something.
Actually, England tested armor that allowed a tank to survive direct hits by both armor-piercing and incendiary shells. Saw it on Modern Marvels a few weeks ago.
Wrong on two counts. McCain wasn't the pilot, though he was nearby. Also, it was a missile that was launched from a plane on deck that caused the fire.
It's required viewing for Navy basic training. My brother told me about it.
It's interesting to note that the USS Forrestal later sank, on a different mission. I think it was similar circumstances, but I'm not sure.
It's no more dangerous than sitting in a cafe next to someone else who's got wi-fi enabled. Or at a theater production, or in a stadium.
No, but I imagine you could use software to produce a 3D model from two photographs taken at different angles. So I doubt there's more than one public photo of the beast.
Out of order?! Fuck! Even in the future, nothing works.
Well, after saying it, my monitor had all these multicolored dots on the screen...
In the US Navy, at least, all crewmembers are trained in fire and damage control, for good reason. One ship's entire damage control crew was wiped out in a blast, and nobody else was trained in damage control. The ship survived the experience, though.
Again, in the US Navy, the standard firefighting gear includes an oxygen mask, so the fumes shouldn't be a problem. Treating crewmembers caught in the fumes before they could get their equipment on will probably require some additional training for the medical personnel, though.
I don't think they'll start to cut their prices until fewer people start signing up.
I mean, it's all about growth...once the market get saturated for the price they're offering, they'll have to cut costs if they want to continue to grow.
I figured the software compiler would handle it. Add some extensions to translate certain common bits of code into FPGA code.
Shared libraries would especially benefit. FFTs and regex engines, for one. SIMD trigonometry functions. A Perl or Java VM. The 3D accelerator's software driver. CRC checking.
Some kernel modules would benefit as well. Framebuffer code, crypto ciphers and digest algorithms. The scheduler (as I mentioned earlier). The IRQ handler.
Even if code doesn't necessarily require superfast algorithmic processing, you could treat FPGA space as another cache. The kernel could provide a secure IPC mechanism that kept all data on-die.
This is truly a case where if you build it, and provide some practical sample code, they will come.
I'm pretty sure Heinlein said it through Lazarus Long, but Heinlein also has a habit of uncredited quotes. Or even partial-references ("Not mine...some ancient Earth bloke.")
Thanks...
One extrme method I read about on slashdot the other day was a guy using cvs to pack up everything in his home directory (the url escapes me)
That was a Linux Journal article.
The kernel gets interrupted by events, and calls the process associated with the event.
Any process that process sends a message to gets immediately elevated to the priority level of the process sending the message...i.e. it gets run immediately.
The kernel also can get its temporary priority elevated in this way.
A navy Nuke could tell you, but then he'd have to kill you. :)
I've been running from an extracted zip file since last fall. The only problem is that your settings don't go with you, even if you pack everything back into the zip file.
Sure there is...to some extent. Mostly it's between gecko-based and KHTML-based browsers.
And if your database or wiki software was configured improperly, you'll hear the sound of all the taxi drivers going on strike.
The drawbacks: you either need a FPGA that you can reprogram very quickly (on the order of nanoseconds) or you need a task that takes a long time and can more than benefit from having to take the time it takes to reprogram the FPGA,/i>
That's why you'd divide the gate array into sections. Assuming you weren't trying to run too many apps with FPGA code at the same time, you can leave the section of code in there while waiting for that process's next timeslice.
FLOPS won't work; it ignores workloads that use integer math. It also ignores workloads that specialize in vector math. And workloads that depend a great deal on automated decision-making. And random-number generation.
The problem is that no matter what metric you use, it won't fit all cases. Different workloads have different requirements. Personally, I'd like to see programmable hardware...Essentially an FPGA section on CPUs. Programs would provide the OS's scheduler with a circuit layout, and the scheduler would have the layout programmed in when needed.
Each program doesn't necessarily have to have access to the whole grid array, either. The scheduler could divide the array into sections. One section would be for speeding up scheduler operations. The rest would be available to have programs loaded in. You wouldn't even need to erase one program's hardware when another program had something it wanted to implement. With the hardware divided, you could load the new program's code into an empty slot, and leave the old code available for the old program's next timeslice. (To prevent having to reprogram the FPGA section every time the program's turn came about.)
What bugs me is how AMD and Intel kicked up their processor speeds. Both of them made their pipelines deeper.
While that's fine for some workloads, with more instructions being executed at the same time, it harms workloads that depend heavily on the results of current calculations to figure out what to do next.
Intel eased the problem by implementing hyperthreading; I'm surprised we haven't seen the same thing come out of AMD's corner.
No, it's how people in the know look at it. There's a difference between being stupid and being ignorant. One is curable.
(Odd...I feel like I just quoted someone. But I can't remember who.)
That doesn't work for those of us who require medical insurance as a job benefit. I'm on three perscriptions, and paying for them out-of-pocket would rival paying for rent.
Or even X10. The ISP I worked at for years had a box attached to a phone line that controlled the power going to several machines running unstable software.
You dialed the phone number, then the passcode, then the X10 address of the box you wanted to power-cycle.
Not really...they may just need an intern to follow directions. VNC and ssh can do the rest.
My dad's workplace is looking at outsourcing its entire IT department overseas.