They talk about magnetic fields, but I think what they're proposing is actually based on fluctuations on the gravitational field. You can build a precise map of local gravitational fields and combine it with dead reckoning and/or other rough positioning mechanisms to determine a precise position. And there's no plausible way to tamper with the local gravitational field.
If it's doing an ultraprecise measurement of the magnetic field too, that's a possibility, although I can't picture a system that works only based on the magnetic field because you could just be moving along field lines and show no change, and the weak magnetic field of Earth is easy to tamper with. Drift is the least of your worries; I'm sure they could come up with some compensation system for that.
As mentioned elsewhere, if you're keeping supercooled particles in your home GPS, that means a source of power. However, it doesn't sound like it needs to be an always-on source of power, you could just re-cool the particles as needed. If it's just a miniscule quantity of particles requiring cooling, it could conceivably be fast and low power to cool them - then you take your field measurement(s), then let them thermalize again until you want your next reading. Assumedly the cooling lasers would be diode lasers, as they're very efficient and you can make them very small. I can easily picture something like that mounted on a chip. The system could even conceivably be much lower power than GPS - if you only need it on for a fraction of a millisecond, for example, that'd be a huge advantage over GPS where you have to leave it on for long periods while it tries to receive and download the low-gain data from GPS satellites.
Only a tiny percent of US shale production is on the Monterrey Shale. And the very reason for this downgrade was that they were using recovery figures determined from the other shale plays, when the actual recovery rate from the Monterrey Shale is much lower than them due to its highly faulted geology and will take new technology to be recoverable at current prices.
Which you'd have known had you actually read the articles.
I found Todd Rider's work interesting, as it touches on what a lot of these smaller scale fusion approaches try to do - to in some way or another create areas full of just high energy ions, rather than having their bulk plasma be at a Maxwellian distribution wherein only the rare "peaks" will fuse. The problem is that any such plasma will automatically rapidly trend toward a Maxwellian distribution, and any bulk approach toward accelerating ions is not going to overcome that without taking in more energy than the system yield. Rider shows out that if you want to fuse in a non-Maxwellian environment in a manner that will give a net energy yield, you need to have an acceleration mechanism that is highly selective as to what ions it accelerates. You've got to leave that bulk mass of low energy ions alone and focus only on the energetic stuff. The only other option** is to accept that your plasma is going to be maxwellian, which means either go really big (ITER and variants thereof) or really fast (NIF and variants thereof).
** - Okay, there's some more exotic possibilities like muon-catalyzed fusion and the like, but let's leave that out for now;)
I expected to see Slashdot drooling and rushing to catch a ride on the latest "ITER = Bad; everyone without much funding = good but repressed" bandwagon. Good to see the discourse is higher than that.
That doesn't mean that ITER (or NIF, or any of the other major names) is going to be the best solution. Honestly, while there's little doubt in even most critics mind that ITER *could* lead to (via DEMO) a viable way to produce power, I seriously doubt it'll lead to an *economical* way to produce power. But the concept that none of the world's energy companies had an interest in a $200k power source that will change the world... sorry, but no. They looked at it, checked the science, and all decided it was a big "pass".
Personally, I have the most hope for HiPER leading to an economical fusion source. It's like NIF (ICF fusion), but uses far weaker (and thus dramatically cheaper) compression pulse, and makes up for the difference with a heating pulse. Basically, the capital costs are far lower and it gives more than an order of magnitude better gain than standard ICF. It piggybacks on the data from existing ICF fusion research, adding only a few new requirements of its own (such as research on how the heating pulse will interact with the high-energy state resulting from the compression pulse). And there's the standard challenges of any such pulsed fusion system, mainly about achieving a sufficient repeat rate. But it looks doable.
Why? Pretty much everywhere we look on Earth, life has colonized, even boiling springs and groundwater in mines many kilometers underground. The whole point of life is that anywhere that the most basic fundamentals can be met, it eventually finds a way there.
Meh. At least they'll probably find some neat rocks;) I happen to own land comprise of basalt (and a bit of rhyolite) modified by a hydrothermal system. You find the neatest rocks on such land - opal, quartz, chalcedony (jasper, chrysoprase, etc), zeolites, calcite amygdules, etc. My favorite samples I've found are botryoidal chalcedony and a zeolite covered in mesolite "hair".:) The key is finding a place where nature has cut a gash in the ground for you, as recently as possible; the neat stuff doesn't persist forever when expose to the elements (especially calcite and zeolites)
I wonder if Mars will have some minerals that simply don't exist on Earth?:)
. Then, you come to my evil lair, connect via my computer to Teh Interwebz, and type in your secret code. The system verifies you voted for my Master, and I give you your well-earned money.
And how do you know it's *actually* my secret code, and not a dummy code showing a vote registered for someone else or not registered at all?
But any system where you can prove *to yourself* you voted a certain way opens the door to vote selling or coercion.
This is simply false. You can prove things to yourself without being able to prove them to others. It's amazing that you'd think otherwise, people do this every day.
Like I just said, it should be able to prove it to *you*, but not in a manner you should be able to prove to *others*. Why did you ignore what I wrote and go on and on about a system wherein it would be possible to prove to others?
You have a brain. Information can reside in your brain. You cannot (reasonably) prove to others what information exists in your brain, but you can use that information to validate what you see to yourself. Thus, if there is any piece of information in your brain that you cannot confirm to others, you have the above system. Example: when you register at the registrar's office, you register (in private) a code, or are given a code (not written down), or something of that nature. In a well-designed system (of dozens of possible varieties), your vote is associated with that code but in a manner where you can lie and convince others that your vote is associated with a different code, leaving others with no way to know whether that's *actually* your code or not.
I can go into more specific details for an example system if you'd like.
Again: please don't ignore what people write when you respond to them. Respond to what they're *actually* saying, and if you don't understand it, ask for clarification.
A voter should be able to prove to *themselves * that they voted in a particular way and it was registered and counted, but not be able to prove it to *others*.
Seriously, A+. People act as if non-internet voting isn't already plagued with huge problems, many of which a secure net voting system can eliminate. I mean, come on, in the last presidential election Chechnya had 99.59% turnout with 99.82% voting for the "Butcher of Grozny", with one precinct in Grozny with turnout over 107%. Think that's legit? Vote corruption in places like Russia is often done at the precinct/district level, levels which are entirely eliminated by net voting. You also reduce the threat of violence by not having to show up in person.
Nothing is perfect. But a lot of the stuff against net voting seems to me knee-jerk and based on implementations with half-arsed security audits or no security audit at all, with a complete ignoring of how easy conventional elections often are to manipulate.
That's easy. Let the user register as many accounts as they want with the electoral commission, with only one actually tied to their voter ID and actually tallied (note: registration should be *not* over the net! Should ideally be in person, with photo ID presented). A second party can thus sit right behind you during the election, watch you log in and cast a vote... and they have no idea if they were watching you actually vote or just register a fake vote on an account not connected with anything.
On the other hand, with paper voting, the person can (usually) just take a photo of their ballot with their cell phone to prove who they voted for.
There's a lot of opposition to internet voting. I get it; it's VERY easy to do wrong. But that doesn't mean it's *inherently* flawed. All types of voting systems have flaws. Most conventional voting systems have literally hundreds of ways they could be rigged, from the pathetically simple to the so-elaborate-only-the-CIA-could-pull-it-off. You'll never get 100% impossible to mess with from any system, internet or not. Internet voting adds its own new potential attack vectors and eliminates a number of ones from conventional voting.
The problem you mentioned, gl4ss, is one of the four main new vectors. The other three are DoS, compromised computers, and compromised software.
Actually, "compromised computers" isn't entirely new, compromised polling machines are a common fear that has on occasion proven true, and more concerningly, it's often impossible to prove whether they were compromised or not. The main solution to this for internet voting is actually every geek's favorite boogieman - Trusted Computing (you know, that set of hardware capabilities that was supposedly going to make it so that PCs can only run Windows and you won't be able to copy MP3s any more;) ). Basically with TC, you have a chain of trust. Your bios is profiled before it starts up. Your bootloader can be assured that it's running a "safe" unmodified BIOS, your OS can be assured that both the bios and bootloader are safe, and apps can be assured that the bios, and os are safe. And if they're not they can refuse to even decrypt themselves. Your voting software can come on a CD or read-only flash drive with both an app and a Live CD, for people who don't have a TC-compliant OS but do have a TC-compliant bios.
TC isn't perfect, of course. Support isn't universal. It's vulnerable to cold boot attacks - although that requires physical access and there's countermeasures. And defining "safe" or "unmodified" is always going to be a balance between being as expansive as possible but not letting potentially vulnerable systems through the safety net. For people who don't have a valid TC system, the electoral commission could provide a Raspberry Pi or similar for $25-50, setup specifically for voting.
Compromised software is fairly easy to deal with (man in the middle attacks); banks already do this (banks are a good analogy, BTW - why are people so willing to deal with their life savings on the net but terrified of net voting? It all comes down to secure implementations). When the user registers (to reiterate, not over the net), you let them pick confirmation text and/or a confirmation image. When the software starts and you log in, it downloads this info from the electoral commission and prominently displays it before you continue on to actually vote.
With DoS (or non-malicious net failure), there's a lot of things you can do. The simplest is simply to redirect the user to any other form of voting - phone, mail, polling place, at the registrar's office, or whatnot. This can be casting a normal vote there as the non-internet-voters do, or a streamlined version - your computer could print out a pre-filled-out ballot, for example, or supply you with a alphanumeric hashed version of your ballot, optionally timestamped and with your voter ID. In some implementations, a TC-assured timestamp can be made available and the user's vote securely timestamped, allowing
Isn't the main performance benefit that Fortran has always claimed over C/C++ the fact that an array is guaranteed to only be used from one thread at a time, and thus you don't have to re-read from memory to registers each time you want to do something with the data in the array? A capability that was formally added to C in C99 (and pretty much universally informally added to C++) with the restrict keyword?
Correct me if I'm wrong here, as I'm not a Fortran programmer.
Exactly. That's like saying a 1.3hp compressor can't run a nail gun, operating on the assumption that you're constantly shooting nails out of it. Most hand work involves periods of activity mixed with periods of rest in-between.Depending on the task, a few seconds to a few minutes of buffer is usually enough. Even if we assume 10 minutes buffer, at an average of 4.5W that's 0.75Wh. If we assume a low li-ion energy density of 100Wh/kg (laptop cells are more like 200Wh/kg), that's a 7.6 gram battery. Is that really unrealistic?
Still, I don't know why someone would design a gun like that which relies on heat and cooling. Why not UV-hardened epoxy?
That's pushing a popular misconception, though. Yes, the US did rely heavily on German scientists for its rocket program. Most Americans think that Russia did too, but this simply isn't true. The US got almost all of the high-level German rocket scientists under Operation Paperclip, plus most of the rockets. The Soviets only got a handful of scientists and lower-level line workers. Various research and manufacturing facilities were studied by both sides. While the US incorporated the Germans deeply into their programs, the Soviet side didn't. Most were merely debriefed over the course of a few months. Even the highest-level German scientists that they did get were completely shut out of the program by 1951.
The Soviet rocket program was by and large domestic. German technology and data helped, no question, but it wasn't at all like in the US.
It's easy to think about it that way, but try to put yourself in the average American situation at the beginning of the space race: Russia was shooting up satellites full of god-knows what capabilities flying straight over American cities half a dozen times a day and could launch weapons at the US from the other side of the world in under an hour, and the US had no response. Can you imagine how helpless many people felt about that and how strongly they wanted to change the situation? The obvious US responses - playing down Soviet capabilities (including the truth... the early sputniks were rather pathetic) simply made each new report out of Russia of greatly improved launch capabilities all the more concerning and drove the need even more for a US response.
Of course, eventually the tables evened out, the addition of newer capabilities stopped being as big of an issue, etc. The moon race was sort of the jumping the shark moment. I mean, it's not like people were going to start shooting Saturn Vs or N1s at each other.
Reminds me of a translation of a sign I saw in Ukraine: "If you become part of Russia, you won't be speaking Russian - you'll be silent in Russian."
A large portion of the problem is Putin's crackdown on the press. As bad as the state of a free press often seems in the west, it's nothing compared to Russia where pretty much all opposition to Putin has been eliminated. They're now ranked 148th in world press freedom, worse than half of Africa.
Whatever is the current propaganda message, it gets echoed relentlessly. Just the other day they had the same Ukranian guy (Andrey Petkov) on three different stations, but they didn't even bother to give him the same story on each. On NTV, he was a German spy smuggling money to support the anti-Russian protesters. On Rossiya 1, he was a repentent pro-Ukraine extremest who converted to the pro-Russian side after having been savagely beaten by fellow protesters. In yet another segment he was a neo-Nazi surgeon supporting the new Ukranian government.
Probably the funniest bit of propaganda was after an attack on a pro-Russian checkpoint. They all broadcast images of the two totally burned-out cars which they said that members of Right Sector drove up in to attack it. They then presented piles of American money, satellite images, and a business card with the name of the leader of Right Sector on it, among a bunch of other stuff. Just ignoring the absurdity of right-wing assault groups roaming around carrying business cards of their leader (with a fake phone number on them), the funny part was that everything that they presented was pristine - not only unburned, but altogether undamaged. Whatever material Right Sector makes their leaders' business cards out of that can survive a car-gutting fire, please, disclose it immediately so we can use it for fireproofing! It's gotten lots of coverage; the card now has its own Know Your Meme entry;)
As funny as it is, a large portion of the Russian public just takes this sort of stuff at face value. The media keeps repeating the same mantra: "Ukranian neo-nazi extremists overthrew the government and are assaulting innocent Russians". So when international reporters first-hand witness the "little green men" throwing molotov cocktails at a peace rally full of children, it doesn't matter, it gets reported in Russia as "rival protest groups clashed" or even "pro-Russian protesters repel an attack", and there's nobody on the airwaves to say otherwise.
People like you are the reason that there's so many bugs in software these days and code is so hard to maintain.
From a less tongue-in-cheek standpoint, optimization (beyond choosing the proper data structures/algorithms and the like and thinking about where bottlenecks might occur as you go) should only be done in the following manner:
1) Run the program and assess the need. If there is no need, STOP. 2) Instrument the code and find out what is *actually* using up your CPU time. 3) Improve the code in the sections that yield the most benefit; go back to #1.
People who try to optimize everything as they go along spend most of their time "optimizing" things that have no perceptible benefit and are far more likely to simply obfuscate the code and introduce bugs. You need to assess need and find out where it matters first. Is it really worth it, for example, to optimize some string comparison that runs maybe five times in your typical program execution? NO. Is such an "optimization" a likely place to find bugs, including potentially serious ones? You betcha.
As a side note, I find most people who obsess over optimization without profiling spend most of their time doing "optimizations" that don't help at all or are often even counterproductive, such as macro bitswap tricks, math-approximation functions, manual loop unrolling, etc, just assuming that they help, rather than things that actually help, found via testing.
Why on earth would a person *want* to have to go through all that mess just to launch a thread? *boggle* And what on earth is wrong with defining a queue on its own and passing by reference (or using it as global / namespace global if you'd rather)? Why should a queue be part of a thread object? It's not a thread, it's a queue.
Let the user put objects wherever they want, don't force them to extend a bloody class every time they want to thread something. : THAT feels old-school. If a person has to go through that much work every time they want to thread everything, you're inherently discouraging threading, which is a huge problem on today's architectures where increased computing power is increasingly achieved by increasing the number of cores.
BlockingQueue aBlockingQueue;// Put this in whatever scope you want thread([&](){ while (true) aBlockingQueue.take().doSomething(); }).detach();// Insert newlines as per your style perferences. aBlockingQueue.addAThingToQueue(someThingToProcess);// Do this whenever you want
Which version do you think is more conductive to people using threading more often? Be honest with yourself. Heck, it's so simple in C++11 that if would be hardly harder to do:
BlockingQueue aBlockingQueue;// Put this in whatever scope you want thread([&](){ while (true) { auto thing = aBlockingQueue.take(); thread([&](){ thing.doSomething(); } } }).detach();// Insert newlines as per your style perferences. aBlockingQueue.addAThingToQueue(someThingToProcess);// Do this whenever you want
Assuming Thing is some sort of smart pointer, that further sets the processing of each doSomething() into its own thread, and then when it's done, thing gets deleted. In Java as per your example you'd have to create a whole new bloody class to do that - talk about backwards!
C: "Here's a gun. Don't shoot yourself in the foot." C++: "I see you've been shooting yourself in the foot! Well, here's a different gun, rather like your old one, only we've added a safety and a trigger guard and oh by the way it now shoots 40 caliber shells containing fission-warheads." Python: "Have a wiffle bat."
First rule of optimization: Don't. Second rule of optimization (pros only!): Don't yet.
The thing about STL is that it's generally quite fast on its own, and if you ever need more speed doing a particular operation, you can just extend it to access its underlying datastructures. As a general rule, though, the only way you're going to get better performance is doing operations that are "dangerous in general". Which may be fine in your specific case, because you may know enough about your data to know that you don't need, for example, bounds checks or whatnot. But it should only be done where there's a known need for it.
It should also be noted that STL algorithms are generally pretty optimized, and that a lot of programmers aren't really all that good at optimization on their own, so it can actually increase performance sometimes. Example: if I grep in the g++ headers I see __restrict__ used 65 times. How many programmers do you know that make regular use of __restrict__ where they really should? I'd bet it's in the 10% ballpark. But it has a huge impact on array performance in many circumstances.
It should further be pointed out that a lot of the evolution of the language is focused on making there be no penalty from using containers vs. rolling your own implementation with pointers. For example, move constructors.
Lastly, the obvious: STL code Just Works(TM). Rolling your own is a great way to introduce unexpected bugs. Doubly so if you rely on a raw pointer-based implementation.
You're forgetting that C++11 also introduces lambdas, which basically means you can inline-thread any command with thread([](){/*your code here*/}).detach(); All too easy. If you'd rather, you can keep the return value to join it later. Or you can use a future to make it even easier.
Why are you complaining about Make as if that's part of the language and the only way to build C++? (*boggle*)
Funny, that's precisely how I feel when I have to use Java - "Where's capability X? Oh, dang, you don't have it. Wait, where's capability Y? Ugh, you don't have that either? Wait, I need to go through all this mess to do Z? Seriously?". Feels like pulling teeth.
I guess it's whatever you're used to.
I really love C++11. It's not perfect, mind you. The last standards-problem I ran into was that you can't template a class over a constant floating point value, only integer/boolean values... it was designed because a programmer might accidentally compile huge numbers of classes via template metaprogramming or the like when they only wanted one due to the imprecision of floating point values, but 1) how often are people seriously going to template metaprogram over a floating point value like that, and 2) who knows template metaprogramming but is unaware of the imprecision of floating point values?
That said, there's tons of great new stuff in the standard that I just love. Just to pick one: I love how the combination of lambdas and the new threading utilities makes it trivial to inline-thread any task, no matter how mundane. My favorite example is a single-line asynchronous packet handler (assuming you have a packet-handling factory class and a data read routine onhand) - repeatedly reads data, generates a smart pointer to a handler and runs it in its own thread, wherein it deletes itself when the thread expires. Okay, two lines if you want the code cleaner and you put the while loop on its own line, but still...
Slashdot Mirror
They talk about magnetic fields, but I think what they're proposing is actually based on fluctuations on the gravitational field. You can build a precise map of local gravitational fields and combine it with dead reckoning and/or other rough positioning mechanisms to determine a precise position. And there's no plausible way to tamper with the local gravitational field.
If it's doing an ultraprecise measurement of the magnetic field too, that's a possibility, although I can't picture a system that works only based on the magnetic field because you could just be moving along field lines and show no change, and the weak magnetic field of Earth is easy to tamper with. Drift is the least of your worries; I'm sure they could come up with some compensation system for that.
As mentioned elsewhere, if you're keeping supercooled particles in your home GPS, that means a source of power. However, it doesn't sound like it needs to be an always-on source of power, you could just re-cool the particles as needed. If it's just a miniscule quantity of particles requiring cooling, it could conceivably be fast and low power to cool them - then you take your field measurement(s), then let them thermalize again until you want your next reading. Assumedly the cooling lasers would be diode lasers, as they're very efficient and you can make them very small. I can easily picture something like that mounted on a chip. The system could even conceivably be much lower power than GPS - if you only need it on for a fraction of a millisecond, for example, that'd be a huge advantage over GPS where you have to leave it on for long periods while it tries to receive and download the low-gain data from GPS satellites.
Only a tiny percent of US shale production is on the Monterrey Shale. And the very reason for this downgrade was that they were using recovery figures determined from the other shale plays, when the actual recovery rate from the Monterrey Shale is much lower than them due to its highly faulted geology and will take new technology to be recoverable at current prices.
Which you'd have known had you actually read the articles.
I found Todd Rider's work interesting, as it touches on what a lot of these smaller scale fusion approaches try to do - to in some way or another create areas full of just high energy ions, rather than having their bulk plasma be at a Maxwellian distribution wherein only the rare "peaks" will fuse. The problem is that any such plasma will automatically rapidly trend toward a Maxwellian distribution, and any bulk approach toward accelerating ions is not going to overcome that without taking in more energy than the system yield. Rider shows out that if you want to fuse in a non-Maxwellian environment in a manner that will give a net energy yield, you need to have an acceleration mechanism that is highly selective as to what ions it accelerates. You've got to leave that bulk mass of low energy ions alone and focus only on the energetic stuff. The only other option** is to accept that your plasma is going to be maxwellian, which means either go really big (ITER and variants thereof) or really fast (NIF and variants thereof).
** - Okay, there's some more exotic possibilities like muon-catalyzed fusion and the like, but let's leave that out for now ;)
I expected to see Slashdot drooling and rushing to catch a ride on the latest "ITER = Bad; everyone without much funding = good but repressed" bandwagon. Good to see the discourse is higher than that.
That doesn't mean that ITER (or NIF, or any of the other major names) is going to be the best solution. Honestly, while there's little doubt in even most critics mind that ITER *could* lead to (via DEMO) a viable way to produce power, I seriously doubt it'll lead to an *economical* way to produce power. But the concept that none of the world's energy companies had an interest in a $200k power source that will change the world... sorry, but no. They looked at it, checked the science, and all decided it was a big "pass".
Personally, I have the most hope for HiPER leading to an economical fusion source. It's like NIF (ICF fusion), but uses far weaker (and thus dramatically cheaper) compression pulse, and makes up for the difference with a heating pulse. Basically, the capital costs are far lower and it gives more than an order of magnitude better gain than standard ICF. It piggybacks on the data from existing ICF fusion research, adding only a few new requirements of its own (such as research on how the heating pulse will interact with the high-energy state resulting from the compression pulse). And there's the standard challenges of any such pulsed fusion system, mainly about achieving a sufficient repeat rate. But it looks doable.
Why? Pretty much everywhere we look on Earth, life has colonized, even boiling springs and groundwater in mines many kilometers underground. The whole point of life is that anywhere that the most basic fundamentals can be met, it eventually finds a way there.
Meh. At least they'll probably find some neat rocks ;) I happen to own land comprise of basalt (and a bit of rhyolite) modified by a hydrothermal system. You find the neatest rocks on such land - opal, quartz, chalcedony (jasper, chrysoprase, etc), zeolites, calcite amygdules, etc. My favorite samples I've found are botryoidal chalcedony and a zeolite covered in mesolite "hair". :) The key is finding a place where nature has cut a gash in the ground for you, as recently as possible; the neat stuff doesn't persist forever when expose to the elements (especially calcite and zeolites)
I wonder if Mars will have some minerals that simply don't exist on Earth? :)
(Sorry for being a rock geek!)
And how do you know it's *actually* my secret code, and not a dummy code showing a vote registered for someone else or not registered at all?
This is simply false. You can prove things to yourself without being able to prove them to others. It's amazing that you'd think otherwise, people do this every day.
Like I just said, it should be able to prove it to *you*, but not in a manner you should be able to prove to *others*. Why did you ignore what I wrote and go on and on about a system wherein it would be possible to prove to others?
You have a brain. Information can reside in your brain. You cannot (reasonably) prove to others what information exists in your brain, but you can use that information to validate what you see to yourself. Thus, if there is any piece of information in your brain that you cannot confirm to others, you have the above system. Example: when you register at the registrar's office, you register (in private) a code, or are given a code (not written down), or something of that nature. In a well-designed system (of dozens of possible varieties), your vote is associated with that code but in a manner where you can lie and convince others that your vote is associated with a different code, leaving others with no way to know whether that's *actually* your code or not.
I can go into more specific details for an example system if you'd like.
Again: please don't ignore what people write when you respond to them. Respond to what they're *actually* saying, and if you don't understand it, ask for clarification.
A voter should be able to prove to *themselves * that they voted in a particular way and it was registered and counted, but not be able to prove it to *others*.
That doesn't even remotely resemble what I wrote.
Seriously, A+. People act as if non-internet voting isn't already plagued with huge problems, many of which a secure net voting system can eliminate. I mean, come on, in the last presidential election Chechnya had 99.59% turnout with 99.82% voting for the "Butcher of Grozny", with one precinct in Grozny with turnout over 107%. Think that's legit? Vote corruption in places like Russia is often done at the precinct/district level, levels which are entirely eliminated by net voting. You also reduce the threat of violence by not having to show up in person.
Nothing is perfect. But a lot of the stuff against net voting seems to me knee-jerk and based on implementations with half-arsed security audits or no security audit at all, with a complete ignoring of how easy conventional elections often are to manipulate.
That's easy. Let the user register as many accounts as they want with the electoral commission, with only one actually tied to their voter ID and actually tallied (note: registration should be *not* over the net! Should ideally be in person, with photo ID presented). A second party can thus sit right behind you during the election, watch you log in and cast a vote... and they have no idea if they were watching you actually vote or just register a fake vote on an account not connected with anything.
On the other hand, with paper voting, the person can (usually) just take a photo of their ballot with their cell phone to prove who they voted for.
There's a lot of opposition to internet voting. I get it; it's VERY easy to do wrong. But that doesn't mean it's *inherently* flawed. All types of voting systems have flaws. Most conventional voting systems have literally hundreds of ways they could be rigged, from the pathetically simple to the so-elaborate-only-the-CIA-could-pull-it-off. You'll never get 100% impossible to mess with from any system, internet or not. Internet voting adds its own new potential attack vectors and eliminates a number of ones from conventional voting.
The problem you mentioned, gl4ss, is one of the four main new vectors. The other three are DoS, compromised computers, and compromised software.
Actually, "compromised computers" isn't entirely new, compromised polling machines are a common fear that has on occasion proven true, and more concerningly, it's often impossible to prove whether they were compromised or not. The main solution to this for internet voting is actually every geek's favorite boogieman - Trusted Computing (you know, that set of hardware capabilities that was supposedly going to make it so that PCs can only run Windows and you won't be able to copy MP3s any more ;) ). Basically with TC, you have a chain of trust. Your bios is profiled before it starts up. Your bootloader can be assured that it's running a "safe" unmodified BIOS, your OS can be assured that both the bios and bootloader are safe, and apps can be assured that the bios, and os are safe. And if they're not they can refuse to even decrypt themselves. Your voting software can come on a CD or read-only flash drive with both an app and a Live CD, for people who don't have a TC-compliant OS but do have a TC-compliant bios.
TC isn't perfect, of course. Support isn't universal. It's vulnerable to cold boot attacks - although that requires physical access and there's countermeasures. And defining "safe" or "unmodified" is always going to be a balance between being as expansive as possible but not letting potentially vulnerable systems through the safety net. For people who don't have a valid TC system, the electoral commission could provide a Raspberry Pi or similar for $25-50, setup specifically for voting.
Compromised software is fairly easy to deal with (man in the middle attacks); banks already do this (banks are a good analogy, BTW - why are people so willing to deal with their life savings on the net but terrified of net voting? It all comes down to secure implementations). When the user registers (to reiterate, not over the net), you let them pick confirmation text and/or a confirmation image. When the software starts and you log in, it downloads this info from the electoral commission and prominently displays it before you continue on to actually vote.
With DoS (or non-malicious net failure), there's a lot of things you can do. The simplest is simply to redirect the user to any other form of voting - phone, mail, polling place, at the registrar's office, or whatnot. This can be casting a normal vote there as the non-internet-voters do, or a streamlined version - your computer could print out a pre-filled-out ballot, for example, or supply you with a alphanumeric hashed version of your ballot, optionally timestamped and with your voter ID. In some implementations, a TC-assured timestamp can be made available and the user's vote securely timestamped, allowing
Can you inline an instruction as easily as:
thread([&](){ /* Your code here */ }).detach();
?
The easier is is to thread little things, the more people will do it.
Isn't the main performance benefit that Fortran has always claimed over C/C++ the fact that an array is guaranteed to only be used from one thread at a time, and thus you don't have to re-read from memory to registers each time you want to do something with the data in the array? A capability that was formally added to C in C99 (and pretty much universally informally added to C++) with the restrict keyword?
Correct me if I'm wrong here, as I'm not a Fortran programmer.
Exactly. That's like saying a 1.3hp compressor can't run a nail gun, operating on the assumption that you're constantly shooting nails out of it. Most hand work involves periods of activity mixed with periods of rest in-between.Depending on the task, a few seconds to a few minutes of buffer is usually enough. Even if we assume 10 minutes buffer, at an average of 4.5W that's 0.75Wh. If we assume a low li-ion energy density of 100Wh/kg (laptop cells are more like 200Wh/kg), that's a 7.6 gram battery. Is that really unrealistic?
Still, I don't know why someone would design a gun like that which relies on heat and cooling. Why not UV-hardened epoxy?
That's pushing a popular misconception, though. Yes, the US did rely heavily on German scientists for its rocket program. Most Americans think that Russia did too, but this simply isn't true. The US got almost all of the high-level German rocket scientists under Operation Paperclip, plus most of the rockets. The Soviets only got a handful of scientists and lower-level line workers. Various research and manufacturing facilities were studied by both sides. While the US incorporated the Germans deeply into their programs, the Soviet side didn't. Most were merely debriefed over the course of a few months. Even the highest-level German scientists that they did get were completely shut out of the program by 1951.
The Soviet rocket program was by and large domestic. German technology and data helped, no question, but it wasn't at all like in the US.
It's easy to think about it that way, but try to put yourself in the average American situation at the beginning of the space race: Russia was shooting up satellites full of god-knows what capabilities flying straight over American cities half a dozen times a day and could launch weapons at the US from the other side of the world in under an hour, and the US had no response. Can you imagine how helpless many people felt about that and how strongly they wanted to change the situation? The obvious US responses - playing down Soviet capabilities (including the truth... the early sputniks were rather pathetic) simply made each new report out of Russia of greatly improved launch capabilities all the more concerning and drove the need even more for a US response.
Of course, eventually the tables evened out, the addition of newer capabilities stopped being as big of an issue, etc. The moon race was sort of the jumping the shark moment. I mean, it's not like people were going to start shooting Saturn Vs or N1s at each other.
Reminds me of a translation of a sign I saw in Ukraine: "If you become part of Russia, you won't be speaking Russian - you'll be silent in Russian."
A large portion of the problem is Putin's crackdown on the press. As bad as the state of a free press often seems in the west, it's nothing compared to Russia where pretty much all opposition to Putin has been eliminated. They're now ranked 148th in world press freedom, worse than half of Africa.
Whatever is the current propaganda message, it gets echoed relentlessly. Just the other day they had the same Ukranian guy (Andrey Petkov) on three different stations, but they didn't even bother to give him the same story on each. On NTV, he was a German spy smuggling money to support the anti-Russian protesters. On Rossiya 1, he was a repentent pro-Ukraine extremest who converted to the pro-Russian side after having been savagely beaten by fellow protesters. In yet another segment he was a neo-Nazi surgeon supporting the new Ukranian government.
Probably the funniest bit of propaganda was after an attack on a pro-Russian checkpoint. They all broadcast images of the two totally burned-out cars which they said that members of Right Sector drove up in to attack it. They then presented piles of American money, satellite images, and a business card with the name of the leader of Right Sector on it, among a bunch of other stuff. Just ignoring the absurdity of right-wing assault groups roaming around carrying business cards of their leader (with a fake phone number on them), the funny part was that everything that they presented was pristine - not only unburned, but altogether undamaged. Whatever material Right Sector makes their leaders' business cards out of that can survive a car-gutting fire, please, disclose it immediately so we can use it for fireproofing! It's gotten lots of coverage; the card now has its own Know Your Meme entry ;)
As funny as it is, a large portion of the Russian public just takes this sort of stuff at face value. The media keeps repeating the same mantra: "Ukranian neo-nazi extremists overthrew the government and are assaulting innocent Russians". So when international reporters first-hand witness the "little green men" throwing molotov cocktails at a peace rally full of children, it doesn't matter, it gets reported in Russia as "rival protest groups clashed" or even "pro-Russian protesters repel an attack", and there's nobody on the airwaves to say otherwise.
People like you are the reason that there's so many bugs in software these days and code is so hard to maintain.
From a less tongue-in-cheek standpoint, optimization (beyond choosing the proper data structures/algorithms and the like and thinking about where bottlenecks might occur as you go) should only be done in the following manner:
1) Run the program and assess the need. If there is no need, STOP.
2) Instrument the code and find out what is *actually* using up your CPU time.
3) Improve the code in the sections that yield the most benefit; go back to #1.
People who try to optimize everything as they go along spend most of their time "optimizing" things that have no perceptible benefit and are far more likely to simply obfuscate the code and introduce bugs. You need to assess need and find out where it matters first. Is it really worth it, for example, to optimize some string comparison that runs maybe five times in your typical program execution? NO. Is such an "optimization" a likely place to find bugs, including potentially serious ones? You betcha.
As a side note, I find most people who obsess over optimization without profiling spend most of their time doing "optimizations" that don't help at all or are often even counterproductive, such as macro bitswap tricks, math-approximation functions, manual loop unrolling, etc, just assuming that they help, rather than things that actually help, found via testing.
Why on earth would a person *want* to have to go through all that mess just to launch a thread? *boggle* And what on earth is wrong with defining a queue on its own and passing by reference (or using it as global / namespace global if you'd rather)? Why should a queue be part of a thread object? It's not a thread, it's a queue.
Let the user put objects wherever they want, don't force them to extend a bloody class every time they want to thread something. : THAT feels old-school. If a person has to go through that much work every time they want to thread everything, you're inherently discouraging threading, which is a huge problem on today's architectures where increased computing power is increasingly achieved by increasing the number of cores.
BlockingQueue aBlockingQueue;
thread([&](){ while (true) aBlockingQueue.take().doSomething(); }).detach();
aBlockingQueue.addAThingToQueue(someThingToProcess);
Which version do you think is more conductive to people using threading more often? Be honest with yourself. Heck, it's so simple in C++11 that if would be hardly harder to do:
BlockingQueue aBlockingQueue;
thread([&](){ while (true) { auto thing = aBlockingQueue.take(); thread([&](){ thing.doSomething(); } } }).detach();
aBlockingQueue.addAThingToQueue(someThingToProcess);
Assuming Thing is some sort of smart pointer, that further sets the processing of each doSomething() into its own thread, and then when it's done, thing gets deleted. In Java as per your example you'd have to create a whole new bloody class to do that - talk about backwards!
What do you mean? Are you talking about "[&](){ /* your code here */ }"? (& = capture all variables by reference)
#define if(x) if ((x) && (rand() < RAND_MAX * 0.9999))
#define true ((__LINE__&131)!=131)
#define InterlockedAdd(x,y) (*x+=y)
Yeah, C does give you the tools to turn debugging your program into a living hell. ;) With great power comes great responsibility.
C: "Here's a gun. Don't shoot yourself in the foot."
C++: "I see you've been shooting yourself in the foot! Well, here's a different gun, rather like your old one, only we've added a safety and a trigger guard and oh by the way it now shoots 40 caliber shells containing fission-warheads."
Python: "Have a wiffle bat."
First rule of optimization: Don't.
Second rule of optimization (pros only!): Don't yet.
The thing about STL is that it's generally quite fast on its own, and if you ever need more speed doing a particular operation, you can just extend it to access its underlying datastructures. As a general rule, though, the only way you're going to get better performance is doing operations that are "dangerous in general". Which may be fine in your specific case, because you may know enough about your data to know that you don't need, for example, bounds checks or whatnot. But it should only be done where there's a known need for it.
It should also be noted that STL algorithms are generally pretty optimized, and that a lot of programmers aren't really all that good at optimization on their own, so it can actually increase performance sometimes. Example: if I grep in the g++ headers I see __restrict__ used 65 times. How many programmers do you know that make regular use of __restrict__ where they really should? I'd bet it's in the 10% ballpark. But it has a huge impact on array performance in many circumstances.
It should further be pointed out that a lot of the evolution of the language is focused on making there be no penalty from using containers vs. rolling your own implementation with pointers. For example, move constructors.
Lastly, the obvious: STL code Just Works(TM). Rolling your own is a great way to introduce unexpected bugs. Doubly so if you rely on a raw pointer-based implementation.
You're forgetting that C++11 also introduces lambdas, which basically means you can inline-thread any command with thread([](){/*your code here*/}).detach(); All too easy. If you'd rather, you can keep the return value to join it later. Or you can use a future to make it even easier.
Why are you complaining about Make as if that's part of the language and the only way to build C++? (*boggle*)
Funny, that's precisely how I feel when I have to use Java - "Where's capability X? Oh, dang, you don't have it. Wait, where's capability Y? Ugh, you don't have that either? Wait, I need to go through all this mess to do Z? Seriously?". Feels like pulling teeth.
I guess it's whatever you're used to.
I really love C++11. It's not perfect, mind you. The last standards-problem I ran into was that you can't template a class over a constant floating point value, only integer/boolean values... it was designed because a programmer might accidentally compile huge numbers of classes via template metaprogramming or the like when they only wanted one due to the imprecision of floating point values, but 1) how often are people seriously going to template metaprogram over a floating point value like that, and 2) who knows template metaprogramming but is unaware of the imprecision of floating point values?
That said, there's tons of great new stuff in the standard that I just love. Just to pick one: I love how the combination of lambdas and the new threading utilities makes it trivial to inline-thread any task, no matter how mundane. My favorite example is a single-line asynchronous packet handler (assuming you have a packet-handling factory class and a data read routine onhand) - repeatedly reads data, generates a smart pointer to a handler and runs it in its own thread, wherein it deletes itself when the thread expires. Okay, two lines if you want the code cleaner and you put the while loop on its own line, but still...