For one thing, airliners don't carry IFF. For another, IFF is not infallible; if I remember correctly, the Tornado(s) the US ground missile batteries shot down in the Gulf had IFF, but it wasn't configured the way the US crews expected, so they decided it was an Iraqi plane even though they hadn't been flying for days.
Not being allowed to shoot at the range the aircraft was designed to engage at because they can't positively ID the bad guy is a common complaint in the pilot memoirs I've read from recent wars.
WTF?! When was the last time you've ever heard of a dogfight?
That's what they said when they built the Phantom with no cannon. That's why they had to hurriedly retrofit cannon for Vietnam, when Phantoms started getting into dogfights.
As for long-range missiles, they've been the panacea for decades, but then the military impose rules of engagement requiring positive ID of the bad guy before you shoot, and suddenly you're not at long range any more.
Like I said, AMD fanboy claptrap. Memory bandwidth has never had much impact on the majority of computing tasks, which are typically limited by CPU performance and memory latency.
It's not crap. The Athlons crushed the Pentium 4's. I remember that very clearly. Slashdot people should know this unless you were born yesterday.
1. Comparably priced 32-bit Athlons only beat the P4 on floating-point-intensive tasks that didn't use SSE. Which typically meant games, but not pro-level 3D applications like the ones I was running. 2. The performance difference was nothing to do with the FSB.
Indeed. AMD make good graphics chips, and mediocre CPUs. They should sell off the CPU side and start a new company that just makes graphics. They could call it... I don't know... ATI?
Yes. Back when I had the misfortune to work on Windows, I was one of the people in the company who were continually running benchmarks, so I was one of the few people in the company allowed to not have anti-virus software on my PC, because it turned the computer from one of the fastest then available to a complete slug that spent most of the time hammering its hard drive.
for a brief period of time they totally outshone intel which was still culturally crippled by the concept of a parallel 'front end bus'
Um, that's utter crap.
AMD beat Intel when it was crippled by the concept of 'long pipelines with high clock frequencies' and 'pushing 64-bit users onto Itanium'. The early Core chips took back the crown from AMD, and they had an FSB.
'AMD rulez because no FSB' was just AMD fanboy claptrap, like 'AMD rulez because Intel put two chips in one package for a quad-core, but AMD puts four on one chip.' None of those things made any significant difference to performance in that era.
That just makes it even more of a 'rich man's subsidy'. I can only wonder why you support a program that takes tax money from the poor and gives it to the rich.
so much for "no matter what the underpinnings might be"
Chevrolet Spark: MSRP $13k to $17k, according to Chevrolet's web site. Chevrolet Bolt: MSRP $37,500 minus $7,500 of taxpayer subsidies, according to these articles.
This appears to be a similar size to, or smaller than, a Honda Civic, and costs twice as much without the thousands of dollars of taxpayers' money being thrown at subsidies. So, yes, it's a damn expensive car.
It's also a damn stupid name, since my first web search found numerous page on Chevrolet wheel bolt patterns before it actually found anything about the car.
I'm pretty sure that was CD-Rs and not pressed discs.
Some of my oldest CDs have curly tracks leading from the edge of the disk toward the music tracks, where the metal layer has oxidized. None are unplayable yet, but some won't last much longer.
It's lucky they're mostly 1980s music, when albums only took up half the disk.
Perhaps I'm blissfully ignorant, but I don't understand why almost any software would need to be time synchronized down to the second.
Yes, you are. Fart apps don't care about the time. The systems that let you sell your fart app to mobile users do.
Assuming there are applications where synchronized time is mission critical..... in those cases, relying on a 3rd party to provide time in a way you have no control over is PURE LUNACY.
Most of the world syncs to GPS, either directly using the time, or by using a frequency output that's synced to GPS. If you don't sync to GPS, you'll be out of sync with most of the world.
1. The code I wrote worked fine. But we have to interoperate with other people's code that doesn't. 2. Any solution requiring programmers to write software properly is doomed to fail. 3. No-one, at the last leap second, thought that Linux servers would crash when they printed out a message indicating that a leap second would soon happen. 4. No-one, at the last leap second, thought their Java server software would go insane after a leap second because the internal timers stopped working.
The world is full of code that will break when a leap second happens.
How about software developers stop relying on the notion of time being continuous? They could stop being lazy and actually implement algorithms that can handle discontinuous time.
A tug in orbit can use a much more efficient engine than a satellite launched directly from Earth. The big problem is likely to be damage from passing through the Van Allen Belts if you use ion drive or some other slow but fuel-efficient mechanism.
Agreed. Slew is acceptable in using NTP. Slew is often more than 1 second.
If I remember correctly, NTP has a leap-second flag which indicates that the time should jump by a second at midnight. It doesn't slew, at least on Linux... otherwise different machines would be reporting different times until they'd all slewed back to what they should be.
People working on near-RT systems already know -or should know, how to cope with leap seconds.
Hey, guess what, those guys they outsourced the software development to in the third world... don't. And they know they'll have moved on to a new job by the time the next leap second happens.
The rest of us have to deal with their hardware not doing what it's supposed to when the leap second hits.
Linux (at least the kernel we run) handles a leap second as 23:58, 23:59, 23:59, 00:00. Code that has to do something specific at 23:59 then ends up doing it twice, unless you detect that and deal with it.
I find it strange than a possible 1 second different could cause so much issues.
It's not the time difference that causes problems per se, it's time going backwards. You presumably missed the fact that many Java servers crashed over the last leap second because of a kernel bug that screwed up their internal timers?
We had problems last time due to faults reported by external hardware when it saw the time jump backwards. I'll be at my desk when it happens this time to deal with any problems that come up this time.
And, given the chaos every leap second causes, hopefully we can finally convince the 'experts' to stop fiddling with time.
Before piracy, we had Trent Reznors, Joe Satriani, and many other good artists promoted.
Uh, dude, you do realize that Nine Inch Nails have been uploading their new albums to torrent sites, right? Because they figured that exposure through those sites sold more copies of their music than trying to stop piracy?
And that piracy has been the norm since the invention of the cassette tape? What do you think those dual-tape cassette decks my generation grew up with were for?
Slashdot Mirror
For one thing, airliners don't carry IFF. For another, IFF is not infallible; if I remember correctly, the Tornado(s) the US ground missile batteries shot down in the Gulf had IFF, but it wasn't configured the way the US crews expected, so they decided it was an Iraqi plane even though they hadn't been flying for days.
Not being allowed to shoot at the range the aircraft was designed to engage at because they can't positively ID the bad guy is a common complaint in the pilot memoirs I've read from recent wars.
WTF?! When was the last time you've ever heard of a dogfight?
That's what they said when they built the Phantom with no cannon. That's why they had to hurriedly retrofit cannon for Vietnam, when Phantoms started getting into dogfights.
As for long-range missiles, they've been the panacea for decades, but then the military impose rules of engagement requiring positive ID of the bad guy before you shoot, and suddenly you're not at long range any more.
why can't it be used to fix bugs in user interfaces?
True. It could inject a completely new UI into Window 8.
All these companies have almost no other valuable assets than your data to begin with!
Bingo. These companies make money collecting your data. It's their biggest asset, and that asset will be sold if the company is sold.
Like I said, AMD fanboy claptrap. Memory bandwidth has never had much impact on the majority of computing tasks, which are typically limited by CPU performance and memory latency.
It's not crap. The Athlons crushed the Pentium 4's. I remember that very clearly. Slashdot people should know this unless you were born yesterday.
1. Comparably priced 32-bit Athlons only beat the P4 on floating-point-intensive tasks that didn't use SSE. Which typically meant games, but not pro-level 3D applications like the ones I was running.
2. The performance difference was nothing to do with the FSB.
Indeed. AMD make good graphics chips, and mediocre CPUs. They should sell off the CPU side and start a new company that just makes graphics. They could call it... I don't know... ATI?
Yes. Back when I had the misfortune to work on Windows, I was one of the people in the company who were continually running benchmarks, so I was one of the few people in the company allowed to not have anti-virus software on my PC, because it turned the computer from one of the fastest then available to a complete slug that spent most of the time hammering its hard drive.
So AMD goes away and intel prices the new CPUs even higher in the sky? Are you a retard? Besides, i'm buying AMD any day.
CPU prices were higher back when AMD was competitive with Intel.
Their competition in most markets today is ARM, not AMD.
for a brief period of time they totally outshone intel which was still culturally crippled by the concept of
a parallel 'front end bus'
Um, that's utter crap.
AMD beat Intel when it was crippled by the concept of 'long pipelines with high clock frequencies' and 'pushing 64-bit users onto Itanium'. The early Core chips took back the crown from AMD, and they had an FSB.
'AMD rulez because no FSB' was just AMD fanboy claptrap, like 'AMD rulez because Intel put two chips in one package for a quad-core, but AMD puts four on one chip.' None of those things made any significant difference to performance in that era.
That just makes it even more of a 'rich man's subsidy'. I can only wonder why you support a program that takes tax money from the poor and gives it to the rich.
so much for "no matter what the underpinnings might be"
Chevrolet Spark: MSRP $13k to $17k, according to Chevrolet's web site.
Chevrolet Bolt: MSRP $37,500 minus $7,500 of taxpayer subsidies, according to these articles.
That extra $13k-17k buys a lot of gas.
Stop bitching about "expensive" electric cars.
This appears to be a similar size to, or smaller than, a Honda Civic, and costs twice as much without the thousands of dollars of taxpayers' money being thrown at subsidies. So, yes, it's a damn expensive car.
It's also a damn stupid name, since my first web search found numerous page on Chevrolet wheel bolt patterns before it actually found anything about the car.
Given the EV1s apparently cost over $100k each, everyone who leased one for a fraction of its value sure should have loved it.
This looks like just another sucky electric car that costs more than a Civic and all the fuel the Civic will ever burn.
I'm pretty sure that was CD-Rs and not pressed discs.
Some of my oldest CDs have curly tracks leading from the edge of the disk toward the music tracks, where the metal layer has oxidized. None are unplayable yet, but some won't last much longer.
It's lucky they're mostly 1980s music, when albums only took up half the disk.
Perhaps I'm blissfully ignorant, but I don't understand why almost any software would need to be time synchronized down to the second.
Yes, you are. Fart apps don't care about the time. The systems that let you sell your fart app to mobile users do.
Assuming there are applications where synchronized time is mission critical..... in those cases, relying on a 3rd party to provide time in a way you have no control over is PURE LUNACY.
Most of the world syncs to GPS, either directly using the time, or by using a frequency output that's synced to GPS. If you don't sync to GPS, you'll be out of sync with most of the world.
1. The code I wrote worked fine. But we have to interoperate with other people's code that doesn't.
2. Any solution requiring programmers to write software properly is doomed to fail.
3. No-one, at the last leap second, thought that Linux servers would crash when they printed out a message indicating that a leap second would soon happen.
4. No-one, at the last leap second, thought their Java server software would go insane after a leap second because the internal timers stopped working.
The world is full of code that will break when a leap second happens.
How about software developers stop relying on the notion of time being continuous? They could stop being lazy and actually implement algorithms that can handle discontinuous time.
Yeah, because that'll work.
A tug in orbit can use a much more efficient engine than a satellite launched directly from Earth. The big problem is likely to be damage from passing through the Van Allen Belts if you use ion drive or some other slow but fuel-efficient mechanism.
Agreed. Slew is acceptable in using NTP. Slew is often more than 1 second.
If I remember correctly, NTP has a leap-second flag which indicates that the time should jump by a second at midnight. It doesn't slew, at least on Linux... otherwise different machines would be reporting different times until they'd all slewed back to what they should be.
People working on near-RT systems already know -or should know, how to cope with leap seconds.
Hey, guess what, those guys they outsourced the software development to in the third world... don't. And they know they'll have moved on to a new job by the time the next leap second happens.
The rest of us have to deal with their hardware not doing what it's supposed to when the leap second hits.
Linux (at least the kernel we run) handles a leap second as 23:58, 23:59, 23:59, 00:00. Code that has to do something specific at 23:59 then ends up doing it twice, unless you detect that and deal with it.
I find it strange than a possible 1 second different could cause so much issues.
It's not the time difference that causes problems per se, it's time going backwards. You presumably missed the fact that many Java servers crashed over the last leap second because of a kernel bug that screwed up their internal timers?
We had problems last time due to faults reported by external hardware when it saw the time jump backwards. I'll be at my desk when it happens this time to deal with any problems that come up this time.
And, given the chaos every leap second causes, hopefully we can finally convince the 'experts' to stop fiddling with time.
Before piracy, we had Trent Reznors, Joe Satriani, and many other good artists promoted.
Uh, dude, you do realize that Nine Inch Nails have been uploading their new albums to torrent sites, right? Because they figured that exposure through those sites sold more copies of their music than trying to stop piracy?
And that piracy has been the norm since the invention of the cassette tape? What do you think those dual-tape cassette decks my generation grew up with were for?
Can you explain how the FEDERAL Aviation Administration has any Constitutional power to regulate a drone with a range of a couple of hundred feet?