Correlation doesn't prove causation, but it most certainly does imply causation.
In this case, our world ecosystem is clearly screwed up in any number of ways because of our actions. Also, amphibians are dying out. It's a pretty good bet we're the cause.
It as my attempt at portal humor... apparently "it was a triumph" and "there's science to do" and "for the good of all of us" and "back to work" should have been in italics or something...
No, it wasn't a lie it was a triumph... no spelling errors, grammar mostly correct (except "Workshop" isn't a proper noun), working links -- almost like it had been edited by some kind of editor. Now, back to work; there's science to do, for the good of all of us.
I like polipo. It's much, much easier to use for personal browsing and you can have it cache your cgi-bin stuff or whatever. You should be able to set it up to cache the youtube videos, even if they are 'Cache-Control: no-cache'.
I tried to install squid, but it brought back sendmail nightmares. Squid is just way overkill for personal browsing proxy/cache.
How about just laying down huge fields of white stuff... like styrofoam only that doesn't get dirty as fast. There's probably some inert-ish byproduct from things we're making anyway that could be used. Seems like that could reflect a couple % back pretty easy, and if something went wrong we could always fix it.
System is at work... I would test except there are not any easy options for doing so there. Also, I realize that you can't be expected to fix hardware problems where you don't have the hardware... in fact I've personally seen code fail on one system and run perfectly on the exact same spec hardware sitting right next to it, with exactly the same software (ghosted).
Mostly I'm just pointing out that there are longstanding problems in linux... the original fanboy post was way over the top.
Re:This is a huge amount of work
on
Linux 2.6.27 Out
·
· Score: 4, Informative
In only 3 months, all of this code has been completed and reviewed by multiple developers. This happens *every* three months.... It is clearly the case that the Linux kernel has hit a new kind of critical mass and is now a form of software development that has never been seen before.
Intel HDA audio still has static noise in the left channel since at least 2.6.20 kernel (probably before). This is a known problem and the solution is 'try random settings of some undocumented (outside the kernel source code) module parameters and hope it maybe works'.
This is on Dell hardware. model=dell3stack, position_fix=1(?). This hardware works perfectly under Windows, with no tweaking whatsoever. It worked under older linux kernels, which means they probably broke something.
The linux kernel is good, but just having a bunch of people look at the code means nothing unless they are actually finding and fixing problems people care about.
This isn't for real security, it's to make simple sniffing harder. As the video puts it, it simply raises the bar for someone who wants to read other people's traffic.
Um, no. It's so that it costs more to index the web, meaning that any competitor to google has to pay more to challenge their dominant position as search engine. Microsoft has to bleed even more money trying to compete. Yahoo might have to abandon search.
The cost of indexing the web has gone down a lot, with cheaper bandwidth and cheaper storage and cheaper computers. So, adding automatic encryption raises the price back to where it was a decade ago.
As an added bonus, if TLAs can't just tap the internet backbones, if they have to do say 10 thousand times the work to eavesdrop then that makes all of the massive databases more valuable to them. For instance, google, with probably the largest user databases on the planet.
Which is why a tax on trades is in order. Make the cost to play to gamble on stock high enough that people don't do it, but the cost to invest longer term still pays. People don't professionally gamble because most of the games are rigged in favor of the house -- over the long term you can't win against the house by gambling. Stock gambling should be the same way.
I believe the democrats suggested this for part of the bailout bill. I think it was shot down though as part of a 'compromise'.
I'm a registered Republican and made the mistake of voting for Bush once.
So in other words, you have really bad judgment.
And anybody that was stupid enough to vote for Bush the first time was still that stupid 4 years later. He was elected again, after all. You seriously expect us to believe you are one of the <1% of the Bush voters that somehow grew a couple of brain cells? Come on.
If you are going to admit to voting for Bush the fist time, you might as well just own up to voting for him a second time. Because voting is anonymous so everybody is 99/100 sure you did anyway.
Re:Meh. It's alright. Not great yet.
on
C# In-Depth
·
· Score: 1
Inlining limitations in.NET have nothing to do with generics at all - they are just thrown in "for good measure", and are often conscious design decisions (because, you know, sometimes inlining decreases performance).
On the contrary, CLR's bytecode is polymorphic. For instance, 'add' can add any type of objects so the VM has to maintain complete knowledge of the types of objects on the stack. That means code can't be interpreted efficiently, and that to get deep inlining the inlined version has to work with ALL types that an object could possibly be. Real generics just add to this problem by making more actual types, and more information to maintain. In other words, CLR has to know whether the object is a "List<int>" or a "List<String>".
Java on the other hand only needs to verify the code on load and then it doesn't need to maintain type state of the stack at all times, so it can write inlined code that works for any object, whereas CLR has to have inlined versions that track types -- that is the reason why CLR can't inline, and it won't ever be fixed, and real generics makes it worse.
Meanwhile, if we're still talking about performance, try comparing the one of java.util.ArrayList vs System.Collections.Generic.List. And then come tell us why.NET generics suck because they are slow...
I just told you. CLR can't inline effectively, and real generics make the problem worse. The vast, vast majority of instructions in any program operate within a loop. The 'slowness' of ArrayList<Integer> is a narrow example and easily, if clumsily, solved with an 'ArrayListInteger', but inlining affects everything. It is harder to see why all of your program is slower rather than one small part being much slower.
And as far as runtimes go,.NET GC has always favored better in my tests than Java GC, by about 15-20%
A) unless you have 'permission' from Microsoft, you are violating their license agreement by posting benchmark results. B) I doubt your tests are representative, but share the code if you think they actually say something.
If anything, value types and methods being non-virtual by default gives it an edge.
Non-virtual methods are the same thing to the VM as final methods. All Java methods are considered 'final' until code is loaded that overrides them. So, no, there is zero benefit from having methods be non-virtual by default. But you are in good company, since even Anders didn't know this (see interview with Bill Venners).
Value types help far less than inlining.
Delegates are significantly faster that anonymous classes when it comes to implementing the Observer pattern (because implementation of delegates works directly with raw function pointers).
There's more opportunity to inline inner classes that delegates. Delegates are a cute features, not a performance advantage.
For instance, Java reflection works by actually loading a class for Method objects. This class can then be inlined, meaning that after the initial creating and loading the reflection is ridiculously fast.
Again, inlining > all those.NET cute things you mention. Inlining in CLR is broken and always will be.
Re:Meh. It's alright. Not great yet.
on
C# In-Depth
·
· Score: 2, Interesting
The fact it feels like he's faking the enthusiasm, as he did for most of this dumb interview, is slightly scary.
Of course Anders Hejlsberg is faking enthusiasm... just like for instance Bjarne Stroustrup about C++ and C++0x.
In both cases the language features they chose to include cause incredible amounts of complexity. At first they are all excited about all these cool features... but then when they get to the gritty, like for instance getting C# to beat Java in performance (it doesn't come close), they start tearing their hair out.
For instance, one big reason Java did not include 'real' generics is because it had never been done before in a major statically-typed virtual machine and the interaction with other parts was not understood or simple. C# just threw it in, and now they have problems like not being able to inline more than one method deep, and only ridiculously simple methods (less than 32 bytecodes, no branches, etc). Another reason was backward compatibility, but see discussions with Bracha for instance about implementation if you think that was the main reason.
Designers of languages like Smalltalk are enthusiastic forever. Designers of languages like Java are workers, they get the job done and done well but aren't crazy excited about it. Designers of languages like C++, C# go mad and in their warped minds 'complexity is simplicity' and they have to feign enthusiasm so they don't have to admit their mistakes.
Generally things that are one atom thick are much more fragile than things that are millions of atoms thick. When they get this working in cars and not 'losing capacity' aka frying you when you go over a speed bump it'll be a pretty good replacement for batteries...
All the coverage of this cowardly act seems to really implicitly glamorize suicide.
Apparent suicide. A writer that questioned the patriotism of those who take away rights in the name of security and criticized McCain found dead. Somehow I think Jonathan Swift would have apparently committed suicide as well, if he were to have lived now.
I'm just saying that it seems like a lot of people are committing apparent suicide these days. This guy, the 'dc madame', the anthrax guy come to mind. Suppose there's a drug that pharmaceutical companies discovered doing normal drug research that makes people very suicidal and was kept secret by the man -- how would you know then even with no evidence of foul play if these people actually committed suicide under their own free will?
Seems to me the only fair thing to do is celebrate the departed's accomplishments regardless of how their death happened.
You've made here the classic mistake of thinking that everyone else uses a piece of technology in the same way that you do. This is not the case. With the advent of tabs, I typically have multiple dozens of them open at any given time. I also often leave programs running for days on end. I surf a LOT of very different sites, most of which I've never been to before, and which often have lots of javascript and/or Flash. This makes for a very different experience than you describe, as I've often had Firefox crash, sometimes without any warning at all, just *poof*, the window is gone without even a warning message
And you've made the classic blunder of starting a land war in Asia... look, when chrome gets plugins and the rest of the 90% features that firefox has which chrome is missing, each process will take a lot more resources. There will be weird kludges where the tabs use protocol buffers to talk to each other and the main process, add-ons that sync between tabs and crash them all when one crashes.
The amount of communication between tabs and main process in order to implement firefox features is probably going to open up lots of security holes also, where you exploit the tab then it's cake to exploit the main process from there. Or 'steal credentials' from other tabs, etc.
The fact is that a crash of a tab is not acceptable even if it is running in a lower security context. Really the only things that should be in a separate process are plugins -- and on linux they already are, via nspluginwrapper. So really, Chrome -- where's the beef?
According to reports, Debian detected one compromise because of a faulty rootkit that, props to the author, but it had many, many flaws. The other compromise was detected by a 'filesystem integrity check' -- if you think that inspires confidence in people then GTFO. Those hackers screwed up... basically Debian only discovered their systems were compromised by dumb luck and simplistic checks.
This is why Debian isn't used by anybody even moderately serious about system security.
Probably it was like the Debian situation. Someone got sloppy and had their password sniffed. Then once on the system a privilege-escalation vulnerability was used.
"Probably" meaning "you hope", because it makes Debian look better by comparison. What you are engaging in is idle speculation, but what's known is that Red Hat are very serious about security.
Did you consider that Red Hat may not have legally been able to give much more information? It probably took serious effort to compromise their system, more than some random hacker.
You're touting Debian, but what I wonder is would they even know they were hacked? Last time their servers were compromised wasn't it like several months before they even discovered it? Seriously, what good is 'oss reporting' of the problem if it has gone undetected for months? IIRC there was at least one ~2003 and one ~2006, but I don't remember how long between hack, discovery, and recovery.
If you believe their comic book that the memory is separate, that means the images and most resources for a page are also separate. So when you have ten tabs of the same site then you have multiple copies of the same images in memory (page header, favicons, etc). That means less memory for disk cache for instance. It also means, unless their security model is fundamentally flawed, that images and such are decompressed multiple times, wasting time.
Google released their browser now because the new betas of firefox and safari will equal or surpass it in performance, and at least firefox has a lot more performance in the pipeline past the betas. Chrome's isolation approach (in contrast to IE8) is like a microkernel... fault tolerant, but with a LOT of resource overhead and programmer overhead (communicating, coordinating settings between main process and tab processes).
So ultimately you're going to be disappointed with Chrome if you're looking for performance. If you want fault tolerance, sure, but in general a failure that crashes the browser can be exploited. Loosing your email is kind of trivial compared to having a bot ruin your system, so the best is just not to crash (iow, write as much of the browser in possible in javascript).
They say that flash drives provide significant performance advantages... and they measure how long a benchmark runs until the batter runs out?! If the drive is faster, the benchmark does more work in a given time. It uses more % of the processor rather than waiting for the drive, which uses more power.
Some of these drives take less power under load than idle hdd's. I may not be a rocket scientist, but how do they think something that draws less power has a shorter battery runtime other than the computer is doing more work?/boggle
If they had seen fit to publish how many runs or iterations the benchmarks performed before the battery ran down, you'd clearly see that flash drives are better in pretty much every way except space and cost -- certainly in power and speed.
Slashdot Mirror
Correlation doesn't prove causation, but it most certainly does imply causation.
In this case, our world ecosystem is clearly screwed up in any number of ways because of our actions. Also, amphibians are dying out. It's a pretty good bet we're the cause.
It as my attempt at portal humor... apparently "it was a triumph" and "there's science to do" and "for the good of all of us" and "back to work" should have been in italics or something...
No, it wasn't a lie it was a triumph... no spelling errors, grammar mostly correct (except "Workshop" isn't a proper noun), working links -- almost like it had been edited by some kind of editor. Now, back to work; there's science to do, for the good of all of us.
I like polipo. It's much, much easier to use for personal browsing and you can have it cache your cgi-bin stuff or whatever. You should be able to set it up to cache the youtube videos, even if they are 'Cache-Control: no-cache'.
I tried to install squid, but it brought back sendmail nightmares. Squid is just way overkill for personal browsing proxy/cache.
More importantly, does the cake run linux. 'Cause that would be ironic...
How about just laying down huge fields of white stuff... like styrofoam only that doesn't get dirty as fast. There's probably some inert-ish byproduct from things we're making anyway that could be used. Seems like that could reflect a couple % back pretty easy, and if something went wrong we could always fix it.
whoopdifriggindo is a tag, not a post.
whoopdifriggindoisatagnotapost is a tag.
That's why it's offtopic.
Do you have this hardware? Any chance you could narrow down the versions it works on and the versions it doesn't?
Same hardware as this guy:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/266927
System is at work... I would test except there are not any easy options for doing so there. Also, I realize that you can't be expected to fix hardware problems where you don't have the hardware... in fact I've personally seen code fail on one system and run perfectly on the exact same spec hardware sitting right next to it, with exactly the same software (ghosted).
Mostly I'm just pointing out that there are longstanding problems in linux... the original fanboy post was way over the top.
In only 3 months, all of this code has been completed and reviewed by multiple developers. This happens *every* three months. ... It is clearly the case that the Linux kernel has hit a new kind of critical mass and is now a form of software development that has never been seen before.
Intel HDA audio still has static noise in the left channel since at least 2.6.20 kernel (probably before). This is a known problem and the solution is 'try random settings of some undocumented (outside the kernel source code) module parameters and hope it maybe works'.
This is on Dell hardware. model=dell3stack, position_fix=1(?). This hardware works perfectly under Windows, with no tweaking whatsoever. It worked under older linux kernels, which means they probably broke something.
The linux kernel is good, but just having a bunch of people look at the code means nothing unless they are actually finding and fixing problems people care about.
He signs posts:
Adam Langley
Google Engineering
... not google's idea?
This isn't for real security, it's to make simple sniffing harder. As the video puts it, it simply raises the bar for someone who wants to read other people's traffic.
Um, no. It's so that it costs more to index the web, meaning that any competitor to google has to pay more to challenge their dominant position as search engine. Microsoft has to bleed even more money trying to compete. Yahoo might have to abandon search.
The cost of indexing the web has gone down a lot, with cheaper bandwidth and cheaper storage and cheaper computers. So, adding automatic encryption raises the price back to where it was a decade ago.
As an added bonus, if TLAs can't just tap the internet backbones, if they have to do say 10 thousand times the work to eavesdrop then that makes all of the massive databases more valuable to them. For instance, google, with probably the largest user databases on the planet.
Right, they're gamblers instead of investors.
Which is why a tax on trades is in order. Make the cost to play to gamble on stock high enough that people don't do it, but the cost to invest longer term still pays. People don't professionally gamble because most of the games are rigged in favor of the house -- over the long term you can't win against the house by gambling. Stock gambling should be the same way.
I believe the democrats suggested this for part of the bailout bill. I think it was shot down though as part of a 'compromise'.
I'm a registered Republican and made the mistake of voting for Bush once.
So in other words, you have really bad judgment.
And anybody that was stupid enough to vote for Bush the first time was still that stupid 4 years later. He was elected again, after all. You seriously expect us to believe you are one of the <1% of the Bush voters that somehow grew a couple of brain cells? Come on.
If you are going to admit to voting for Bush the fist time, you might as well just own up to voting for him a second time. Because voting is anonymous so everybody is 99/100 sure you did anyway.
Inlining limitations in .NET have nothing to do with generics at all - they are just thrown in "for good measure", and are often conscious design decisions (because, you know, sometimes inlining decreases performance).
On the contrary, CLR's bytecode is polymorphic. For instance, 'add' can add any type of objects so the VM has to maintain complete knowledge of the types of objects on the stack. That means code can't be interpreted efficiently, and that to get deep inlining the inlined version has to work with ALL types that an object could possibly be. Real generics just add to this problem by making more actual types, and more information to maintain. In other words, CLR has to know whether the object is a "List<int>" or a "List<String>".
Java on the other hand only needs to verify the code on load and then it doesn't need to maintain type state of the stack at all times, so it can write inlined code that works for any object, whereas CLR has to have inlined versions that track types -- that is the reason why CLR can't inline, and it won't ever be fixed, and real generics makes it worse.
Meanwhile, if we're still talking about performance, try comparing the one of java.util.ArrayList vs System.Collections.Generic.List. And then come tell us why .NET generics suck because they are slow...
I just told you. CLR can't inline effectively, and real generics make the problem worse. The vast, vast majority of instructions in any program operate within a loop. The 'slowness' of ArrayList<Integer> is a narrow example and easily, if clumsily, solved with an 'ArrayListInteger', but inlining affects everything. It is harder to see why all of your program is slower rather than one small part being much slower.
And as far as runtimes go, .NET GC has always favored better in my tests than Java GC, by about 15-20%
A) unless you have 'permission' from Microsoft, you are violating their license agreement by posting benchmark results.
B) I doubt your tests are representative, but share the code if you think they actually say something.
If anything, value types and methods being non-virtual by default gives it an edge.
Non-virtual methods are the same thing to the VM as final methods. All Java methods are considered 'final' until code is loaded that overrides them. So, no, there is zero benefit from having methods be non-virtual by default. But you are in good company, since even Anders didn't know this (see interview with Bill Venners).
Value types help far less than inlining.
Delegates are significantly faster that anonymous classes when it comes to implementing the Observer pattern (because implementation of delegates works directly with raw function pointers).
There's more opportunity to inline inner classes that delegates. Delegates are a cute features, not a performance advantage.
For instance, Java reflection works by actually loading a class for Method objects. This class can then be inlined, meaning that after the initial creating and loading the reflection is ridiculously fast.
Again, inlining > all those .NET cute things you mention. Inlining in CLR is broken and always will be.
The fact it feels like he's faking the enthusiasm, as he did for most of this dumb interview, is slightly scary.
Of course Anders Hejlsberg is faking enthusiasm... just like for instance Bjarne Stroustrup about C++ and C++0x.
In both cases the language features they chose to include cause incredible amounts of complexity. At first they are all excited about all these cool features... but then when they get to the gritty, like for instance getting C# to beat Java in performance (it doesn't come close), they start tearing their hair out.
For instance, one big reason Java did not include 'real' generics is because it had never been done before in a major statically-typed virtual machine and the interaction with other parts was not understood or simple. C# just threw it in, and now they have problems like not being able to inline more than one method deep, and only ridiculously simple methods (less than 32 bytecodes, no branches, etc). Another reason was backward compatibility, but see discussions with Bracha for instance about implementation if you think that was the main reason.
Designers of languages like Smalltalk are enthusiastic forever. Designers of languages like Java are workers, they get the job done and done well but aren't crazy excited about it. Designers of languages like C++, C# go mad and in their warped minds 'complexity is simplicity' and they have to feign enthusiasm so they don't have to admit their mistakes.
If anyone remembers, atomic bombs were originally estimated to have a 15% chance to cause complete atmospheric ignition on a planetary scale.
I believe the phrase you are looking for is "cascading exothermal inversion".
Dance Dance Revolution on PS2 has better sound quality also, using 24 bit samples instead of 16 bit. And that was back in 2000 (or whenever).
Generally things that are one atom thick are much more fragile than things that are millions of atoms thick. When they get this working in cars and not 'losing capacity' aka frying you when you go over a speed bump it'll be a pretty good replacement for batteries...
All the coverage of this cowardly act seems to really implicitly glamorize suicide.
Apparent suicide. A writer that questioned the patriotism of those who take away rights in the name of security and criticized McCain found dead. Somehow I think Jonathan Swift would have apparently committed suicide as well, if he were to have lived now.
I'm just saying that it seems like a lot of people are committing apparent suicide these days. This guy, the 'dc madame', the anthrax guy come to mind. Suppose there's a drug that pharmaceutical companies discovered doing normal drug research that makes people very suicidal and was kept secret by the man -- how would you know then even with no evidence of foul play if these people actually committed suicide under their own free will?
Seems to me the only fair thing to do is celebrate the departed's accomplishments regardless of how their death happened.
You've made here the classic mistake of thinking that everyone else uses a piece of technology in the same way that you do. This is not the case. With the advent of tabs, I typically have multiple dozens of them open at any given time. I also often leave programs running for days on end. I surf a LOT of very different sites, most of which I've never been to before, and which often have lots of javascript and/or Flash. This makes for a very different experience than you describe, as I've often had Firefox crash, sometimes without any warning at all, just *poof*, the window is gone without even a warning message
And you've made the classic blunder of starting a land war in Asia... look, when chrome gets plugins and the rest of the 90% features that firefox has which chrome is missing, each process will take a lot more resources. There will be weird kludges where the tabs use protocol buffers to talk to each other and the main process, add-ons that sync between tabs and crash them all when one crashes.
The amount of communication between tabs and main process in order to implement firefox features is probably going to open up lots of security holes also, where you exploit the tab then it's cake to exploit the main process from there. Or 'steal credentials' from other tabs, etc.
The fact is that a crash of a tab is not acceptable even if it is running in a lower security context. Really the only things that should be in a separate process are plugins -- and on linux they already are, via nspluginwrapper. So really, Chrome -- where's the beef?
Debian uses a hardware cryptography devices so that hackers can't get the key even if the systems are compromised?
Debian has trusted servers not connected to the internet?
Debian has systems with one function (hg, db, etc)?
Debian has IDS software monitoring the network?
Afaik those are all 'no' for debian and 'yes' for Red Hat. Tell me where I'm wrong...
According to reports, Debian detected one compromise because of a faulty rootkit that, props to the author, but it had many, many flaws. The other compromise was detected by a 'filesystem integrity check' -- if you think that inspires confidence in people then GTFO. Those hackers screwed up... basically Debian only discovered their systems were compromised by dumb luck and simplistic checks.
This is why Debian isn't used by anybody even moderately serious about system security.
Probably it was like the Debian situation. Someone got sloppy and had their password sniffed. Then once on the system a privilege-escalation vulnerability was used.
"Probably" meaning "you hope", because it makes Debian look better by comparison. What you are engaging in is idle speculation, but what's known is that Red Hat are very serious about security.
Did you consider that Red Hat may not have legally been able to give much more information? It probably took serious effort to compromise their system, more than some random hacker.
You're touting Debian, but what I wonder is would they even know they were hacked? Last time their servers were compromised wasn't it like several months before they even discovered it? Seriously, what good is 'oss reporting' of the problem if it has gone undetected for months? IIRC there was at least one ~2003 and one ~2006, but I don't remember how long between hack, discovery, and recovery.
If you believe their comic book that the memory is separate, that means the images and most resources for a page are also separate. So when you have ten tabs of the same site then you have multiple copies of the same images in memory (page header, favicons, etc). That means less memory for disk cache for instance. It also means, unless their security model is fundamentally flawed, that images and such are decompressed multiple times, wasting time.
Google released their browser now because the new betas of firefox and safari will equal or surpass it in performance, and at least firefox has a lot more performance in the pipeline past the betas. Chrome's isolation approach (in contrast to IE8) is like a microkernel... fault tolerant, but with a LOT of resource overhead and programmer overhead (communicating, coordinating settings between main process and tab processes).
So ultimately you're going to be disappointed with Chrome if you're looking for performance. If you want fault tolerance, sure, but in general a failure that crashes the browser can be exploited. Loosing your email is kind of trivial compared to having a bot ruin your system, so the best is just not to crash (iow, write as much of the browser in possible in javascript).
They say that flash drives provide significant performance advantages... and they measure how long a benchmark runs until the batter runs out?! If the drive is faster, the benchmark does more work in a given time. It uses more % of the processor rather than waiting for the drive, which uses more power.
Some of these drives take less power under load than idle hdd's. I may not be a rocket scientist, but how do they think something that draws less power has a shorter battery runtime other than the computer is doing more work? /boggle
If they had seen fit to publish how many runs or iterations the benchmarks performed before the battery ran down, you'd clearly see that flash drives are better in pretty much every way except space and cost -- certainly in power and speed.