Nope, doesn't work that way. For a good (and entertaining) explanation, read the Illustrated Guide to Criminal, particularly the section about Mens Rea: http://lawcomic.net/guide/?p=1...
If you destroy or dispose of something because you believe it likely that prosecutors will seek that something as part of an criminal investigation, you have destroyed evidence and are obstructing justice. It doesn't matter whether that "something" is a piece of paper, a computer browser history or your baby tooth that fell out when you were six. Your suspicion that prosecutors will want that item makes its destruction a crime.
And like any crime, the prosecutor will have to prove it in court... not just that you wiped the browser history but that the reasonable explanation why you wiped the browser history was to prevent the authorities from gaining access to it. Actus rea -- wiping the browsing history. Mens rea - intending to hide something from police. The prosecutor has to prove BOTH to get a conviction.
Metric is a bad choice for industry and engineering. Because it isn't aligned on a power of 2, it's constantly subject to rounding error when we do any computation. And we do computation. We rarely work with these numbers by hand. Rounding errors bite us again and again.
The Imperial system isn't any better, but at least the funkiness leads us to expect errors and check for them more vigilantly.
I await the politician willing to push the octal system!
C is a good choice where performance is critical for small or large programs. C++ used like C is comparable.
Perl or Python are good choices for short programs where ease of development and programming practices resilient to buffer-overflow style bugs are more important than performance.
Java is a good choice for large, complex programs where safe and secure programming practices are more important than micro-optimized performance.
See what's missing from that picture? Any role where C++ used with the low-performance safe practices abstractions is a better choice than something else.
No, you lose efficient code. For a simple example, the string abstractions in C++ and Java are much, much less computationally efficient than manipulating a C character array.
Once you're willing to take that hit for the sake of the things the abstractions gain you, Java's bytecode machine is a tiny additional hit versus the far superior design of the language itself.
And anyway, in case you didn't know it there are tools (like gcj) for compiling java straight to native code if that's what you really want. Only that usually isn't what you want because object code portability is damn useful.
Except we're not talking about off-grid systems, we're talking about Tesla's grid-tie application where power is stored from both off-peak grid delivery and adjunct DC systems and then supplements household usage during grid peak pricing.
When living completely off grid, you move most of the high-wattage equipment to propane. No electric stove or hot water heater. And you use an ammonia-cycle refrigerator. But that always will be a niche market, even if Tesla's dream comes true.
That's what C is for -- situations where low overhead is important. You retain that feature when you use C++ as if it was C but lose it when you employ Java-like abstractions instead.
Use what makes sense for the application. I'd never try to run my *entire* house on DC. But between my modem, router, access point and VOIP box I have 5 separate 120V -> 12V rectifiers. I would love if I could just plug them into a separate 12V plug.
The common buck converter circuit that reduces 12VDC to 5 VDC is as inefficient if not more inefficient than the common transform/rectify/smooth wall wart that drops 120VAC to 5 VDC. That's another problem with running a low voltage DC circuit through the house: whatever voltage we standardized on, every dang thing you plugged in to it will still need buck/boost circuits that are no better than the AC to DC circuits we're using now.
And it probably would be 12 volts (actually, 13.6). There's too much obvious value in matching what car electronics run on.
Seems premature to me. An awful lot of things have to work out just right for whole-home battery systems to make much sense.
Even then low-voltage DC plants don't make much sense. Your microwave oven consumes 1100+ watts. Know what amperage that is at 5 volts DC? You'd barely be able to wrap your hand around the power cord.
Even at 48 volts DC, the power plant in a telephone company central office is really something to behold.
Also, AC/DC conversion isn't as dire as stated. Sloppy cheap converters do indeed operate at around 75% effeciency with the remaining 25% lost as heat. But look at the "80+" computer power supply standards. The "80+ platinum" standard requires 95% efficiency. Those power cost twice as much but "pure science" does not prevent their operation. They work as promised.
C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java
That's a bit of a problem, because when you program in C++ the same way you'd program in Java, you lose the efficiency and simplicity of C without gaining the clean design of Java. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C but with, you know, a little bit plus.
If all of that sounds wrong to you, congrats, you're a C coder
Then you haven't been to the right kinds of meetings. I've lost count of the number of meetings I've been to where we draw out architectures on a marker board and half a dozen people's different misunderstands about what we're trying to build coalesce into a useful design.
I also disagree with the premise but in the opposite direction.
Risk is the probability of something happening times the damage if it happens.
If Damage = Death of All (functionally infinite), the Probability need only be more than infinitesimal for the Risk to be significant. Is the probability of a mankind-killer asteroid more than infinitesimal? Well, it's happened a couple times before, so while the probability appears quite small it's certainly more than infinitesimal.
Even if you dedicated a core and sat in a busy loop polling the NICs for new packets, you'd still have to wait for the receiving NIC to get the whole packet, you'd still have to set up a DMA transfer to ram, you'd still have to look up the address in an O(log n) trie too large to stay in the L3 cache and you'd still have to set up a DMA transfer from ram to the outbound NIC which would still wait for the entire packet before beginning to transmit it.
"Big Iron" routers don't do this. They wait until they have the whole packet. Then the address is looked up in the O(1) TCAM*, a special tri-state static ram that isn't present in your generic x86 machine. Then the packet is transmitted across the backplane to the outgoing interface without ever touching main memory or the the main processor.
Even then the packet tends to get buffered at least twice with a stochastic probability of waiting in the buffer for other traffic to clear. And that's if you're using a high-quality service provider that avoids running links over 80% of capacity.
* TCAM = Ternary Content Addressable Memory. Bits are organized in rows containing an address or subnet. Each bit can have three states: 1, 0 or "don't care." The address to be looked up is injected at the top of the TCAM and compared against all rows in the TCAM during a single clock. The TCAM outputs the position of the first matching row.
It's not about the number of cores, it's about the expense of the context switches when servicing the interrupt. The x86 architecture doesn't have register banks the way the old Sparc chips did. Every context switch the registers have to be dumped to ram and the new contents loaded from ram. That's an expensive operation.
Get a switch which supports VLANs, 1 vlan on each port and the trunk on your laptop. Then run the mfg's software inside virtual machines, each of which has one of the vlans connected to its virtual ethernet, using the mfg's IP address. Now you can run all the updates in parallel.
The better solution is for the mfg to give you software and a configuration that does not suck. But if you're stuck with it, the above will work just fine.
They mostly don't forward until the entire packet is received. That can't work unless the sending interface is the same or lower speed and the hardware for it (hardware fast path at high data rates) tends to be brittle.
Linux does not do this. The ethernet cards Linux uses do not do this. They work with complete packets. In the case of OSes on PC architectures, the kernel may not even get an interrupt until the card has multiple packets to deliver.
Buffering and switching latency is the main source of delay, not signal latency in the copper and fiber. Microwaves would do exactly nothing to improve the switching and buffering latency. If anything they'd make it worse: light in fiber travels much further than line-of-sight microwave before it has to be regenerated with another delay.
Who peer-reviewed this paper? Did they know the first thing about networking?
Nope. It would scram when the rest of the electric grid collapsed a few days in. The plant has to constantly output power. When the grid fails, the plant automatically goes into safe mode to avoid tearing apart the turbines. Diesel generators then start up to run the plant until grid power returns but they'd only last as long as the fuel.
Nothing associated with the public electric grid would last long without humans present.
Slashdot Mirror
NSA already has your stuff. ;)
Nope, doesn't work that way. For a good (and entertaining) explanation, read the Illustrated Guide to Criminal, particularly the section about Mens Rea: http://lawcomic.net/guide/?p=1...
If you destroy or dispose of something because you believe it likely that prosecutors will seek that something as part of an criminal investigation, you have destroyed evidence and are obstructing justice. It doesn't matter whether that "something" is a piece of paper, a computer browser history or your baby tooth that fell out when you were six. Your suspicion that prosecutors will want that item makes its destruction a crime.
And like any crime, the prosecutor will have to prove it in court... not just that you wiped the browser history but that the reasonable explanation why you wiped the browser history was to prevent the authorities from gaining access to it. Actus rea -- wiping the browsing history. Mens rea - intending to hide something from police. The prosecutor has to prove BOTH to get a conviction.
Metric is a bad choice for industry and engineering. Because it isn't aligned on a power of 2, it's constantly subject to rounding error when we do any computation. And we do computation. We rarely work with these numbers by hand. Rounding errors bite us again and again.
The Imperial system isn't any better, but at least the funkiness leads us to expect errors and check for them more vigilantly.
I await the politician willing to push the octal system!
C is a good choice where performance is critical for small or large programs. C++ used like C is comparable.
Perl or Python are good choices for short programs where ease of development and programming practices resilient to buffer-overflow style bugs are more important than performance.
Java is a good choice for large, complex programs where safe and secure programming practices are more important than micro-optimized performance.
See what's missing from that picture? Any role where C++ used with the low-performance safe practices abstractions is a better choice than something else.
No, you lose efficient code. For a simple example, the string abstractions in C++ and Java are much, much less computationally efficient than manipulating a C character array.
Once you're willing to take that hit for the sake of the things the abstractions gain you, Java's bytecode machine is a tiny additional hit versus the far superior design of the language itself.
And anyway, in case you didn't know it there are tools (like gcj) for compiling java straight to native code if that's what you really want. Only that usually isn't what you want because object code portability is damn useful.
Except we're not talking about off-grid systems, we're talking about Tesla's grid-tie application where power is stored from both off-peak grid delivery and adjunct DC systems and then supplements household usage during grid peak pricing.
When living completely off grid, you move most of the high-wattage equipment to propane. No electric stove or hot water heater. And you use an ammonia-cycle refrigerator. But that always will be a niche market, even if Tesla's dream comes true.
That's what C is for -- situations where low overhead is important. You retain that feature when you use C++ as if it was C but lose it when you employ Java-like abstractions instead.
Use what makes sense for the application. I'd never try to run my *entire* house on DC. But between my modem, router, access point and VOIP box I have 5 separate 120V -> 12V rectifiers. I would love if I could just plug them into a separate 12V plug.
The common buck converter circuit that reduces 12VDC to 5 VDC is as inefficient if not more inefficient than the common transform/rectify/smooth wall wart that drops 120VAC to 5 VDC. That's another problem with running a low voltage DC circuit through the house: whatever voltage we standardized on, every dang thing you plugged in to it will still need buck/boost circuits that are no better than the AC to DC circuits we're using now.
And it probably would be 12 volts (actually, 13.6). There's too much obvious value in matching what car electronics run on.
Seems premature to me. An awful lot of things have to work out just right for whole-home battery systems to make much sense.
Even then low-voltage DC plants don't make much sense. Your microwave oven consumes 1100+ watts. Know what amperage that is at 5 volts DC? You'd barely be able to wrap your hand around the power cord.
Even at 48 volts DC, the power plant in a telephone company central office is really something to behold.
Also, AC/DC conversion isn't as dire as stated. Sloppy cheap converters do indeed operate at around 75% effeciency with the remaining 25% lost as heat. But look at the "80+" computer power supply standards. The "80+ platinum" standard requires 95% efficiency. Those power cost twice as much but "pure science" does not prevent their operation. They work as promised.
C++ is not C. C++ written like C tends to be crap code - just an overly complex and distracting language for that coding style. If C++ is the right tool for the job, you need to be using a coding style very similar to C# and Java
That's a bit of a problem, because when you program in C++ the same way you'd program in Java, you lose the efficiency and simplicity of C without gaining the clean design of Java. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C but with, you know, a little bit plus.
If all of that sounds wrong to you, congrats, you're a C coder
I resemble that remark.
That's certainly better, but I'm looking for a version in some kind of vector format, not just a larger bitmap that will print out "less" pixelated.
Any idea where to find that in its "original" form? The low res scan is funny and all but not very suitable for printing.
Then you haven't been to the right kinds of meetings. I've lost count of the number of meetings I've been to where we draw out architectures on a marker board and half a dozen people's different misunderstands about what we're trying to build coalesce into a useful design.
Wouldn't work. Idiot bosses have been among the first to adopt standing desks, likely due to the alleged health benefits.
I die, it's years times value. Everybody dies, it's the loss of all the future to come. Functionally infinite.
Mitigation is a separate issue. You weigh Mitigation's cost versus Risk to determine whether to Act.
Not the one that made the moon.
http://en.wikipedia.org/wiki/G...
We assume no life was present to be destroyed but for obvious reasons we've no evidence.
I also disagree with the premise but in the opposite direction.
Risk is the probability of something happening times the damage if it happens.
If Damage = Death of All (functionally infinite), the Probability need only be more than infinitesimal for the Risk to be significant. Is the probability of a mankind-killer asteroid more than infinitesimal? Well, it's happened a couple times before, so while the probability appears quite small it's certainly more than infinitesimal.
Even if you dedicated a core and sat in a busy loop polling the NICs for new packets, you'd still have to wait for the receiving NIC to get the whole packet, you'd still have to set up a DMA transfer to ram, you'd still have to look up the address in an O(log n) trie too large to stay in the L3 cache and you'd still have to set up a DMA transfer from ram to the outbound NIC which would still wait for the entire packet before beginning to transmit it.
"Big Iron" routers don't do this. They wait until they have the whole packet. Then the address is looked up in the O(1) TCAM*, a special tri-state static ram that isn't present in your generic x86 machine. Then the packet is transmitted across the backplane to the outgoing interface without ever touching main memory or the the main processor.
Even then the packet tends to get buffered at least twice with a stochastic probability of waiting in the buffer for other traffic to clear. And that's if you're using a high-quality service provider that avoids running links over 80% of capacity.
* TCAM = Ternary Content Addressable Memory. Bits are organized in rows containing an address or subnet. Each bit can have three states: 1, 0 or "don't care." The address to be looked up is injected at the top of the TCAM and compared against all rows in the TCAM during a single clock. The TCAM outputs the position of the first matching row.
Yes, it's a heater.
It's not about the number of cores, it's about the expense of the context switches when servicing the interrupt. The x86 architecture doesn't have register banks the way the old Sparc chips did. Every context switch the registers have to be dumped to ram and the new contents loaded from ram. That's an expensive operation.
Get a switch which supports VLANs, 1 vlan on each port and the trunk on your laptop. Then run the mfg's software inside virtual machines, each of which has one of the vlans connected to its virtual ethernet, using the mfg's IP address. Now you can run all the updates in parallel.
The better solution is for the mfg to give you software and a configuration that does not suck. But if you're stuck with it, the above will work just fine.
Not really. The x86 architecture can't handle the interrupts. That's why modern cards don't interrupt on every packet received.
They mostly don't forward until the entire packet is received. That can't work unless the sending interface is the same or lower speed and the hardware for it (hardware fast path at high data rates) tends to be brittle.
Linux does not do this. The ethernet cards Linux uses do not do this. They work with complete packets. In the case of OSes on PC architectures, the kernel may not even get an interrupt until the card has multiple packets to deliver.
Buffering and switching latency is the main source of delay, not signal latency in the copper and fiber. Microwaves would do exactly nothing to improve the switching and buffering latency. If anything they'd make it worse: light in fiber travels much further than line-of-sight microwave before it has to be regenerated with another delay.
Who peer-reviewed this paper? Did they know the first thing about networking?
Nope. It would scram when the rest of the electric grid collapsed a few days in. The plant has to constantly output power. When the grid fails, the plant automatically goes into safe mode to avoid tearing apart the turbines. Diesel generators then start up to run the plant until grid power returns but they'd only last as long as the fuel.
Nothing associated with the public electric grid would last long without humans present.