It's kind of sad to see that despite all the progressive politics that Obama and Biden embody, that they're following Hollywood's line to the letter.
The fact is, there's just nobody in Washington who doesn't follow Hollywood's will, or they wouldn't be in Washington in the first place. To be a politician these days, you have to side with some companies in order to get money and votes, and it just so happens that Hollywood has deep pockets and sides with anyone who's Pro-IP.
We all know going into this presidency that whoever wound up in office would be a strong on IP. Let's not act like this is some kind of surprise. Sure, it'd be great if the Obama administration really could align with everyone, but that would be fantasy-land, not America.
Europe (+/-50 states): 10,180,000 km^2
US (50 states) (minus Alaska; shit-ton of area, mostly uninhabited): 9,826,630 km^2 - 1,717,854 km^2
No, not really as clear now, huh? Europe is more dense and even in its distribution, but America has less total land mass, and even in the highly concentrated areas, almost no inter-city or intra-region rail.
Yet, we have an interstate highway system that connects the entire United States. Interesting, huh?
That's funny, didn't we build the interstate system for precisely the same reason we're suggesting building a high-speed rail system? To quickly and efficiently move people from one city to another?
Futhermore, it's part of what dug us out of the last depression, creating thousands of jobs and enabling car companies to really thrive in America, creating billions of dollars worth of industry.
Even if the rail systems only connected major metropolitan areas, it'd be a hell of a lot better than what we can do now. Imagine being able to get from NYC to Chicago, or Seattle to San Fransisco without driving for at least 12 hours across some of the world's most traffic dense roads.
Yes. You said it yourself: x86-64 is a superset of x86; the architecture is reliant on instructions from the legacy set. No license to the legacy set, no dice on building the superset.
But that's okay, because there's no way Intel would ever pull the trigger. This is just corporate posturing to get a better crosslicensing agreement and a slice of the Foundry's pie. They'll fight it out for a couple more weeks and then a "settlement" will be reached behind some closed doors, probably with the Foundry agreeing not to mint over N non-x86 chips and some cash changing hands in whichever direction.
PyBank is similar. It also uses GObject-Introspection to automatically bind GObject libraries.
In fact, the Javascript side of this article is completely overlooking the technology that is GObject introspection; adding run-time dynamic introspection to C applications (and soon, reflection too).
And the last Pentium 4s are, as I said, two generations, three years. I guess you like to forget that there are still computers being built with Pentium 4s. Intel's plans to replace it, not replacing it, and your mom's Athlon XP machine are completely irrelevant to the fact that the computer was built in December 2005, and that the chip is, as I said, 3 years old.
And your comparison is as silly as mine; the point is that the chip is not old, unless, of course, you think of "modern" in terms of what came out 5 minutes ago and can't possibly imagine the possibility of using a one month old computer. And for the record, I do have 4 year old bulbs in my house (probably much, much older than 4 years in my basement and attic).
I hate to tell you but a P4 isn't modern any more. Not even "relatively" modern.
Relative to my car and house, the Pentium 4 is brand spanking new. It is relatively modern, in that it's only a couple of CPU generations old (literally; two generations, three years). Unless, of course, you think of "modern" in terms of what came out 5 minutes ago and can't possibly imagine the possibility of using a one month old computer.
The worst, most inefficient computer in my house uses roughly 250Wh in continuous draw (less if the monitor is off, which it usually is). Relatively modern machine too (Pentium 4, lots of disks, etc).
Unless you have some seriously fucked up computer with hairdryers instead of heatsinks or a g'damned Cray as your desktop I can't see how you'd use that cell up in a 'couple of days'.
You may or may not be surprised by this, but not all of the magic happens in hardware, which is why you don't see open sourced drivers for a lot of stuff.
That was true in the mid-90s, when drivers meant the difference between 10fps and 30fps. We're in the late 00s now, where drivers are as thin as possible, so that APIs are sitting right on top of hardware commands, and compiling shaders is the about the only thing left to do with software alone.
Any such optimizations or color corrections are typically done in baked-in firmware, if they are done at all. With GPGPU, there's just zero reason not to give programming languages and APIs full access to the hardware in the same way that Linux has full access to your CPU (minus a few notable exceptions, most of which are meaningless to most of us).
This is why AMD has opened up the floodgates on documentation of their hardware, and the open drivers have been improving ever since.
Older Linuxes are built on GCC 3.x or GCC 4.1.x. Since 4.2.x, GCC has produced absolute garbage code when the Gentoo flags are not enabled.
Since most distros don't ship with --funroll-loops -O19 --ZOMG-MAKE-CODE-FAST, almost everyone has experienced a huge code speed drop. Meanwhile, Apple, knowing that all of their x86 machines support SSE2 or better has no qualms doing said incantations and benefiting from the speedups in autovectorization and other areas where the GCC hackers and Apple have been spending time.
This leads us to the conclusion that a) Older Linuxes were better optimized (by the compiler, not the coder), b) Newer Linuxes are able to benefit but... c) Newer Linuxes are not benefiting because of their one-size-fits-all nature.
One of the saddest parts here is that some of the newer routers that Linksys et. al are shipping do WPA2 so slowly when you've got any number of wireless clients over two that TKIP is generally a godsend. Now that it's broken, it's time to upgrade, yet again... Probably a good excuse to get people to spend the extra buck for WirelessN.
Slashdot is more of a general forum for discussion, whereas blogs typically are not. Slashdot has a better set of regular contributors and more even opinions on topics than most blogs do (due to intellectual and geographic and other biases). There are a lot of advantages to discussing things on Slashdot, like having comments prefiltered and screened for content worth reading and adjustable filters to keep the noise floor low.
No, his point was in its entirety: "Threefish is the name of the block cipher part of Skein."
Which is pretty much what I got from reading the introduction to said paper. My question was posited to discover why there was no information on it, which was more completely answered by later replies, which stated it was just published as a part of this paper; nobody has had time to run any independent cryptanalysis on it.
Certainly it's related to Blowfish and Twofish, but I cannot find a word one on Threefish outside of this document. Anyone care to explain for some good karma?
But since anyone can manufacture files that match known MD5s, the minute said "Child-porn hash database" gets published (which, if you look hard enough, they already have been), all bets are off.
In this case, Ubuntu is the sum of the software it packages. But if one piece of software is slower, then Ubuntu's not slower, that piece of software is slower. 1 + 1 + 1 = 3, 3 != 1.
This would remain true if Ubuntu were replaced with $DISTRO.
First, Canonical chooses to pay some of the developers that work on Ubuntu, but they don't draw any lines with respect to what Ubuntu packages.
Secondly, Ubuntu is made up of packages that are their own, and packages that are Debian's. Ubuntu picks the important stuff (Linux, GCC, Xorg, GNOME versions), but the rest (50+%) of the software is simply imported from Debian.
Testing the performance between Debian builds and Ubuntu builds would be an interesting thing to do here, since it would point us in the correct direction as to whether it is GCC's fault for poorly optimizing code, as to whether it's the kernel's fault for being more aggressive about power management and/or I/O performance latency, whether the graphic slowdowns are due to commercial closed source drivers (which we can do nothing about) or due to Xorg changes, etc. etc.
Namely, graphics hardware. ATi graphics hardware and the FGLRX driver. FGLRX is known to have crappy 2D performance relative to its very strong 3D performance and the 2d performance that the open source driver excels at.
Meanwhile, 2D performance on Intel's hardware is smoking everyone else's pipe.
In this case, anyways. The benchmarks had everything to do with X, GCC and Kernel performance numbers, which all slid over the intervals measured.
In other words, Ubuntus' not getting slower. The software that Ubuntu bundles is getting slower.
It's likely due to GCC's epic failure to better optimize code as 4.x progresses, but I'm not putting my money on anything until they've tested at least one other distro which builds with a different GCC version.
Because of the time required to charge vehicles, we'd need a cord station at pretty much every parking space everywhere for widespread use of pure electrics to be tenable.
Surprise, that's exactly why they're starting the buildout now. You build it once, and you're done, you don't keep building it again and again, as you do with cars.
I'm not saying that we have to immediately switch over to everyone on electric either. I'm not even saying that petrol should go the way of the dinosaur (in this case, literally). But for most drivers, electric is more than enough for every day life. And even "slow" charging batteries are just fine, because most of us spend most of our days inside, whilst our cars sit outside doing nothing but collecting heat.
Yeah, but as has been said a billion times by now, the electrical grid is cheaper and cleaner than a half billion cars driving around burning hydrocarbons. Power plants make it a point to be as efficient as possible, whereas cars make almost the inverse point with IC engines.
Looking forward, the grid is a lot easier to update to cleaner technologies as they come available. It is extremely tough to get anyone to put a new engine in their car because it might improve their gas mileage.
1) Who the heck uses Git? I know a lot of important companies do, but most people do not.
Yeah, but all of the important infrastructural pieces on Linux are moving to Git, including Linux itself, Xorg and the surrounding lowlevel daemons (bluez, etc). If you're going to be pulling from a dozen git servers to build your stack, it's often easier just to manage your stack using git anyways.
2) Who the heck is going to download 2.1GB just to look at 1-2 files in the source-code? That's just insane.
Then you're clearly not the kind of person Google wants looking at the code anyways. Anybody who's really interested has no problem with downloading all of it, because they will eventually want all of it anyways, so they can build the environment and work on it.
Slashdot Mirror
It's kind of sad to see that despite all the progressive politics that Obama and Biden embody, that they're following Hollywood's line to the letter.
The fact is, there's just nobody in Washington who doesn't follow Hollywood's will, or they wouldn't be in Washington in the first place. To be a politician these days, you have to side with some companies in order to get money and votes, and it just so happens that Hollywood has deep pockets and sides with anyone who's Pro-IP.
We all know going into this presidency that whoever wound up in office would be a strong on IP. Let's not act like this is some kind of surprise. Sure, it'd be great if the Obama administration really could align with everyone, but that would be fantasy-land, not America.
That was quite honestly the worst piece of garb..literature he wrote, though.
Europe (+/-50 states): 10,180,000 km^2
US (50 states) (minus Alaska; shit-ton of area, mostly uninhabited): 9,826,630 km^2 - 1,717,854 km^2
No, not really as clear now, huh? Europe is more dense and even in its distribution, but America has less total land mass, and even in the highly concentrated areas, almost no inter-city or intra-region rail.
Yet, we have an interstate highway system that connects the entire United States. Interesting, huh?
That's funny, didn't we build the interstate system for precisely the same reason we're suggesting building a high-speed rail system? To quickly and efficiently move people from one city to another?
Futhermore, it's part of what dug us out of the last depression, creating thousands of jobs and enabling car companies to really thrive in America, creating billions of dollars worth of industry.
Even if the rail systems only connected major metropolitan areas, it'd be a hell of a lot better than what we can do now. Imagine being able to get from NYC to Chicago, or Seattle to San Fransisco without driving for at least 12 hours across some of the world's most traffic dense roads.
Yes. You said it yourself: x86-64 is a superset of x86; the architecture is reliant on instructions from the legacy set. No license to the legacy set, no dice on building the superset.
But that's okay, because there's no way Intel would ever pull the trigger. This is just corporate posturing to get a better crosslicensing agreement and a slice of the Foundry's pie. They'll fight it out for a couple more weeks and then a "settlement" will be reached behind some closed doors, probably with the Foundry agreeing not to mint over N non-x86 chips and some cash changing hands in whichever direction.
PyBank is similar. It also uses GObject-Introspection to automatically bind GObject libraries.
In fact, the Javascript side of this article is completely overlooking the technology that is GObject introspection; adding run-time dynamic introspection to C applications (and soon, reflection too).
And the last Pentium 4s are, as I said, two generations, three years. I guess you like to forget that there are still computers being built with Pentium 4s. Intel's plans to replace it, not replacing it, and your mom's Athlon XP machine are completely irrelevant to the fact that the computer was built in December 2005, and that the chip is, as I said, 3 years old.
And your comparison is as silly as mine; the point is that the chip is not old, unless, of course, you think of "modern" in terms of what came out 5 minutes ago and can't possibly imagine the possibility of using a one month old computer. And for the record, I do have 4 year old bulbs in my house (probably much, much older than 4 years in my basement and attic).
I hate to tell you but a P4 isn't modern any more. Not even "relatively" modern.
Relative to my car and house, the Pentium 4 is brand spanking new. It is relatively modern, in that it's only a couple of CPU generations old (literally; two generations, three years). Unless, of course, you think of "modern" in terms of what came out 5 minutes ago and can't possibly imagine the possibility of using a one month old computer.
The worst, most inefficient computer in my house uses roughly 250Wh in continuous draw (less if the monitor is off, which it usually is). Relatively modern machine too (Pentium 4, lots of disks, etc).
Unless you have some seriously fucked up computer with hairdryers instead of heatsinks or a g'damned Cray as your desktop I can't see how you'd use that cell up in a 'couple of days'.
You may or may not be surprised by this, but not all of the magic happens in hardware, which is why you don't see open sourced drivers for a lot of stuff.
That was true in the mid-90s, when drivers meant the difference between 10fps and 30fps. We're in the late 00s now, where drivers are as thin as possible, so that APIs are sitting right on top of hardware commands, and compiling shaders is the about the only thing left to do with software alone.
Any such optimizations or color corrections are typically done in baked-in firmware, if they are done at all. With GPGPU, there's just zero reason not to give programming languages and APIs full access to the hardware in the same way that Linux has full access to your CPU (minus a few notable exceptions, most of which are meaningless to most of us).
This is why AMD has opened up the floodgates on documentation of their hardware, and the open drivers have been improving ever since.
Older Linuxes are built on GCC 3.x or GCC 4.1.x. Since 4.2.x, GCC has produced absolute garbage code when the Gentoo flags are not enabled.
Since most distros don't ship with --funroll-loops -O19 --ZOMG-MAKE-CODE-FAST, almost everyone has experienced a huge code speed drop. Meanwhile, Apple, knowing that all of their x86 machines support SSE2 or better has no qualms doing said incantations and benefiting from the speedups in autovectorization and other areas where the GCC hackers and Apple have been spending time.
This leads us to the conclusion that a) Older Linuxes were better optimized (by the compiler, not the coder), b) Newer Linuxes are able to benefit but... c) Newer Linuxes are not benefiting because of their one-size-fits-all nature.
One of the saddest parts here is that some of the newer routers that Linksys et. al are shipping do WPA2 so slowly when you've got any number of wireless clients over two that TKIP is generally a godsend. Now that it's broken, it's time to upgrade, yet again... Probably a good excuse to get people to spend the extra buck for WirelessN.
Slashdot is more of a general forum for discussion, whereas blogs typically are not. Slashdot has a better set of regular contributors and more even opinions on topics than most blogs do (due to intellectual and geographic and other biases). There are a lot of advantages to discussing things on Slashdot, like having comments prefiltered and screened for content worth reading and adjustable filters to keep the noise floor low.
I could go on, but hopefully I've made my point.
No, his point was in its entirety: "Threefish is the name of the block cipher part of Skein."
Which is pretty much what I got from reading the introduction to said paper. My question was posited to discover why there was no information on it, which was more completely answered by later replies, which stated it was just published as a part of this paper; nobody has had time to run any independent cryptanalysis on it.
I normally don't read comments on random blogs, so I missed this piece of (important) trivia. Thanks.
Your powers of deduction are amazing Holmes.
Certainly it's related to Blowfish and Twofish, but I cannot find a word one on Threefish outside of this document. Anyone care to explain for some good karma?
But since anyone can manufacture files that match known MD5s, the minute said "Child-porn hash database" gets published (which, if you look hard enough, they already have been), all bets are off.
In this case, Ubuntu is the sum of the software it packages. But if one piece of software is slower, then Ubuntu's not slower, that piece of software is slower. 1 + 1 + 1 = 3, 3 != 1.
This would remain true if Ubuntu were replaced with $DISTRO.
First, Canonical chooses to pay some of the developers that work on Ubuntu, but they don't draw any lines with respect to what Ubuntu packages.
Secondly, Ubuntu is made up of packages that are their own, and packages that are Debian's. Ubuntu picks the important stuff (Linux, GCC, Xorg, GNOME versions), but the rest (50+%) of the software is simply imported from Debian.
Testing the performance between Debian builds and Ubuntu builds would be an interesting thing to do here, since it would point us in the correct direction as to whether it is GCC's fault for poorly optimizing code, as to whether it's the kernel's fault for being more aggressive about power management and/or I/O performance latency, whether the graphic slowdowns are due to commercial closed source drivers (which we can do nothing about) or due to Xorg changes, etc. etc.
Namely, graphics hardware. ATi graphics hardware and the FGLRX driver. FGLRX is known to have crappy 2D performance relative to its very strong 3D performance and the 2d performance that the open source driver excels at.
Meanwhile, 2D performance on Intel's hardware is smoking everyone else's pipe.
In this case, anyways. The benchmarks had everything to do with X, GCC and Kernel performance numbers, which all slid over the intervals measured.
In other words, Ubuntus' not getting slower. The software that Ubuntu bundles is getting slower.
It's likely due to GCC's epic failure to better optimize code as 4.x progresses, but I'm not putting my money on anything until they've tested at least one other distro which builds with a different GCC version.
Because of the time required to charge vehicles, we'd need a cord station at pretty much every parking space everywhere for widespread use of pure electrics to be tenable.
Surprise, that's exactly why they're starting the buildout now. You build it once, and you're done, you don't keep building it again and again, as you do with cars.
I'm not saying that we have to immediately switch over to everyone on electric either. I'm not even saying that petrol should go the way of the dinosaur (in this case, literally). But for most drivers, electric is more than enough for every day life. And even "slow" charging batteries are just fine, because most of us spend most of our days inside, whilst our cars sit outside doing nothing but collecting heat.
Yeah, but as has been said a billion times by now, the electrical grid is cheaper and cleaner than a half billion cars driving around burning hydrocarbons. Power plants make it a point to be as efficient as possible, whereas cars make almost the inverse point with IC engines.
Looking forward, the grid is a lot easier to update to cleaner technologies as they come available. It is extremely tough to get anyone to put a new engine in their car because it might improve their gas mileage.
1) Who the heck uses Git? I know a lot of important companies do, but most people do not.
Yeah, but all of the important infrastructural pieces on Linux are moving to Git, including Linux itself, Xorg and the surrounding lowlevel daemons (bluez, etc). If you're going to be pulling from a dozen git servers to build your stack, it's often easier just to manage your stack using git anyways.
2) Who the heck is going to download 2.1GB just to look at 1-2 files in the source-code? That's just insane.
Then you're clearly not the kind of person Google wants looking at the code anyways. Anybody who's really interested has no problem with downloading all of it, because they will eventually want all of it anyways, so they can build the environment and work on it.