Thats why once, in.NET, I coded some tool, it took let say 50000 lines of code, then learned about some obscure feature that could have reduced it to 500. Yes, 500.
So if one of those red-light-cameras snaps a picture of my car running down a pedestrian, it should be a really great defense for me to say, "Oh yeah, I have a policy of leaving my car doors unlocked the keys in the ignition. Everyone around the neighborhood knows that."
Which completely ignores that pretty much nobody does that with their cars (since having your car stolen results in a definite loss that can cost lots of money and a major inconvenience), but a large percentage of people do that with their wi-fi (since most of the time they don't even notice, and it doesn't cost them anything).
WRONG. Often, you don't even know something went wrong (see buffer overflows).
not the compiler, not some class or wrapper or interface you have never seen, not the VM, or some bug or leak or god knows what.
What? You're saying the Java libraries and runtime are full of bugs, as opposed to C's perfect libraries? Or the OS is perfect when running C programs?
If something is messed up, I KNOW I did it, and I shouldn't google around for workaround, a bug fix or some undocumented feature.
This makes no fucking sense. How does using Java prevent you from determining where the problem is? What are all these bugfixes and undocumented features you need? The rest of your post makes just as little sense. If anything, Java is far more predictable and documented than C is. No, it's not good for embedded apps like PIC or AVR, but who fucking said it was?
Your post is full of straw men stuffed with bullshit.
If you don't expect a strong money bias on a PC Mag article, you haven't been paying attention. There are a lot of whores out there, and PC Mag is one of the worst.
++ to this. I've actually been playing it the past few days. Somewhat similar character and sense of humor, ridiculous battles (in some places, there are literally HUNDREDS of creatures attacking), and it plays damn smooth on old hardware.
If you like Duke Nukem, definitely play Serious Sam.
Your post is so vague, that it is pointless. You might want to be more specific because otherwise I could easily just say "no you can't" and I'd be just as right.
Grandparent post was specific: shared cache
You don't have to be an ass if you want specifics, you could just ask. In this case, I think GPP is referring to the upfront cost of memory access. Once one core pays that price (think of it as a fixed cost), the other cores will be able to access the memory from the shared cache without having to pay that cost. Thus, theoretically resulting in a speedup greater than the number of cores.
Probably the same people who think vaccination is eeevil. But then, if you get your health information from youtube, you deserve the darwin award. So I see no problem.
Where this gets interesting is when you have idiot adults making decisions for their children.
So your solution is that all devices and operating system support all dam code-page in the world while Unicode cover 99.99% of all symbols used in a single simple solution!
BTW my mother language is not English...
I can tell: I'm arguing for UTF-8, not against it. As a developer, I dislike having to deal with a bunch of character encodings.
I looked at the Wikipedia article on GB 18030, and it says there's no straightforward way of translating a byte stream into a set of unicode code points. Contrast this with UTF-8/16/32, which are trivial to translate to code points, and I really don't see the point of using alternative systems. You can argue over what the code points mean, but UTF-8/16/32 works well for encoding the code points. I fail to see how it's English-centric; Windows-1250 or ISO 8859 would be English-centric, and they should be discriminated against equally.
Yes, it can encode all unicode characters. The only drawback is that some languages are better suited for UTF-16, which may make UTF-8 encoding longer than needed.
Compared to other seemingly ad articles, this isn't bad. Most take the form "Product X is awesome, discuss". This is more like "Product X is awesome; what other products are awesome?", which can include direct competitors and replacements for X. Provided enough good comments get in, I think this is a useful question. To be fair, the EyeClops shouldn't have been in the summary, but it probably provides a good starting point for discussion.
DC has become feasible and possibly advantageous for long-distance transmission lines now, thanks to better technology. The trouble was that there wasn't a good way to alter DC voltage, something trivial with AC using transformers. Now that DC can be pumped up to high voltages like AC, it's easier to transmit due to fewer losses and less stress on the lines.
It still may not be economical beyond transmission lines though.
This is only a problem if your syscall wrapper didn't take this into consideration. If you're writing a syscall wrapper for security reasons, you don't pass parameters that the original caller still has write access to.
I love installing FoxIt Reader after installing Acrobat for years. Acrobat downloads some huge bloated reader that takes forever to even begin thinking about installing, let alone the actual installation. FoxIt is far smaller and installs pretty much instantly, and starts up about as fast too.
Has there ever been a case of someone suing an ad-blocker company for tortious interference? I hate to give anyone ideas, but that seems to be what this guy's rant is implying.
That's not what the paper talks about. The vulnerability is that the scheduler gathers statistics (used to make scheduling decisions) by checking who is running at every clock tick. By running only between clock ticks and never running at the time of a clock tick, your process can use a lot of CPU without the scheduler knowing.
Slashdot Mirror
I kid, I kid!
Your post is full of straw men stuffed with bullshit.
If you like Duke Nukem, definitely play Serious Sam.
You don't have to be an ass if you want specifics, you could just ask. In this case, I think GPP is referring to the upfront cost of memory access. Once one core pays that price (think of it as a fixed cost), the other cores will be able to access the memory from the shared cache without having to pay that cost. Thus, theoretically resulting in a speedup greater than the number of cores.
Turn in your geek card!
I looked at the Wikipedia article on GB 18030, and it says there's no straightforward way of translating a byte stream into a set of unicode code points. Contrast this with UTF-8/16/32, which are trivial to translate to code points, and I really don't see the point of using alternative systems. You can argue over what the code points mean, but UTF-8/16/32 works well for encoding the code points. I fail to see how it's English-centric; Windows-1250 or ISO 8859 would be English-centric, and they should be discriminated against equally.
Compared to other seemingly ad articles, this isn't bad. Most take the form "Product X is awesome, discuss". This is more like "Product X is awesome; what other products are awesome?", which can include direct competitors and replacements for X. Provided enough good comments get in, I think this is a useful question. To be fair, the EyeClops shouldn't have been in the summary, but it probably provides a good starting point for discussion.
DC has become feasible and possibly advantageous for long-distance transmission lines now, thanks to better technology. The trouble was that there wasn't a good way to alter DC voltage, something trivial with AC using transformers. Now that DC can be pumped up to high voltages like AC, it's easier to transmit due to fewer losses and less stress on the lines.
It still may not be economical beyond transmission lines though.
It'll silently drop all your bad memories of Microsoft products. BSODs, Explorer crashes... gone!
Or, stop playing WoW. More people should consider this option.
Exposing it through TCP/IP is separation enough (exposure to the intranet). There's nothing to be gained by exposing it to the internet at large.
Mod parent up.
This is only a problem if your syscall wrapper didn't take this into consideration. If you're writing a syscall wrapper for security reasons, you don't pass parameters that the original caller still has write access to.
Could this be used to make a tattoo printer? Maybe they could release a laser tattoo remover as well.
I love installing FoxIt Reader after installing Acrobat for years. Acrobat downloads some huge bloated reader that takes forever to even begin thinking about installing, let alone the actual installation. FoxIt is far smaller and installs pretty much instantly, and starts up about as fast too.
10,000 packets/second ought to be enough for anyone.
Has there ever been a case of someone suing an ad-blocker company for tortious interference? I hate to give anyone ideas, but that seems to be what this guy's rant is implying.
That's not what the paper talks about. The vulnerability is that the scheduler gathers statistics (used to make scheduling decisions) by checking who is running at every clock tick. By running only between clock ticks and never running at the time of a clock tick, your process can use a lot of CPU without the scheduler knowing.