Comment Re:FM mode? (Score 1) 128
I have been experimenting with 2400b on UHF for almost a year now. Especially since it allowes mixed voice and data.
I have been experimenting with 2400b on UHF for almost a year now. Especially since it allowes mixed voice and data.
Mail voting is incredibly weak and incredibly stupid.
There is no way to verify that the person voting is the correct person and he is not forced in any way.
Your paper trail is completly useless if you cannot prove it has a proper origin.
Voting in secrecy in a nice voting booth using a simple straightforward ballot is a beautifull system. It is simple enough that you can not only explain it to a ten year old, the ten year old can actually go see for him self and verify proper procedures are followed.
Yet again and again people try to fuck it up with mail or electronic voting schemes.
No, just NO.
Getting inf or -inf out of floating point actually makes sense: It is not just exactly zero but a whole range of very small numbers which give similar results and are treated as 'limits as x approaches 0'.
Integer numbers and arithmetic are exact and although INT_MAX might be large these days it is still not anywhere near infinity and just does not make any sense at all.
And having signed and unsigned behave differently also does not make any sense at all.
Your compile time option might as well be named '-foutput-random-instructions'
50 million? You are not even close! Billions of billions of babies die each year due to masturbation! Even more than the population of earth!
Seriously... read up on some biology, there is a big difference between the various stages of a fetus
I don't know how many panels you need, but your price sounds ridiculous.
I spend less then a tenth of that and have enough panels for about 2/3 of my electriciy consumption. They are also well on their way to pay for themselves in about 6 years. (currently in year 2).
Unless your build environment is really broken (or you have a seriously a-typicall code base) compile time should not matter nearly as much as the resulting code. Don't forget that the resulting code has a big impact on the test phase of your cycle.
Normally during the edit phase you only touch part of a codebase, and proper dependency tracking should result in only a small part of it being rebuild and linked.
Proper dependency handling is not a job of the compiler.
LInking is also not the job of the compiler. (And untill lld is mature enough llvm and gcc use the same one anyway, and even then it still has to prove itself)
I am more interested in what it produces. Is the produced code fast and correct?
Sorry to hear your world is so small.
You should get out more
Are your eyes also used for listening?
Wait, you stopped reading after five words?
Filtering out nmap to places you don't want it to go is EXACTLY what a firewall is for.
And your IPX comparison is also flawed. You don't need to use your MAC address, that is just one way of generating an IPv6 address. And being able to address a packet to any node on the internet directly is exactly how the internet was suposed to work. (Note that a firewall may still prevent such packet from ariving unwanted).
Which overhead do you mean exactly?
The increased address size is not really a problem, route aggregation actually makes routing ipv6 easier than ipv4.
Packet size increases a bit (20 bytes) but calling that 'too much' is simply unfair.
2: Attackers can view your entire IP space. A simple nmap scan, then choosing what zero days to use... instant pwn-ership.
Bullshit. Just use a firewall the proper way and stop using crap.
If your machines are that vulnerable you are already screwed. Hiding behind NAT and thinking you are safe is a joke.
Where and how exactly?
I know llvm integrates better with IDEs, but I couldn't care less.
As far as I have seen they produce comparible code. Last time I checked gcc code outperformed llvm code most of the time, but they were very close.
The two terms are not mutualy exclusive
It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome Klapka Jerome