I'm aware that hard disk capacity follows a trend similar to Moore's law in that capacity roughly doubles every two years or thereabouts, but much like the CPU industry, does anyone know how far into the future magnetic storage will continue to scale at that pace?
I don't work in the industry, but I did a bit of research on this recently. As I understand it, we're currently able to get several hundred Gb/sq. in. (bits, not bytes) with the perpendicular recording that we've been using since about 2005. Back in 2009, experts were predicting that perpendicular recording as it operates now would probably not be able to exceed 1 Tb/sq. in because of the interference problems at that density. Some of the major drive makers are pursuing alternatives and/or extensions to current recording technology. A couple of the major ones are Heat Assisted Magnetic Recording (HAMR, aka TAR), in which the physical/magnetic properties of the recording surface are altered with heat from a laser or other heat source, and Bit Patterned Media (BPM), in which bit boundaries are actually delineated using non-magnetic material (as opposed to the uniform recording surfaces of today). There are others like Microwave Assisted Recording and Domain-Wall Assisted Recording, but it sounds like these are less likely to be used, at least at first. Recently, there was also a story on Ars Technica describing an effort to combine HAMR and BPM in order to overcome some of the shortcomings of each. Common predictions seem to be that these new technologies would move the density limit up from about 1 Tb/sq. in. to something more like 10 Tb./sq. in. The growth rate has been in decline during this decade, despite the adoption of perpendicular recording, but the hope seems to be that it might rise back up to how it was in the 90s with the next advancement.
GPG is a name chosen to describe the free version.
This sentence is neither informative nor funny.
No, GnuPG is not the same as PGP. GnuPG was in fact developed to replace PGP, both because PGP is covered by a non-commercial use only license, and (probably) because it by default incorporates the patented IDEA algorithm. Yes, PGP Freeware and GPG are both free and interoperable, but they are not the same thing.
if they choose to sell it to you anyway, they do so with no binding agreement in place?
I think if you didn't agree to the EULA, you would not be legally permitted to use the software (just like with the GPL). I don't think the act of providing it to you gives you any new legal privileges except to use the install CD as a coaster. Of course, that assumes you take the EULA seriously to begin with and respect copyright laws and such, but you must at least a bit if you actually go to the trouble of rejecting it in writing to protect yourself.
Google needs to find a way to get some exposure in China, rather than just being blocked out completely. Or do you not think that would happen?
Google is not "enslaving" anyone - just making it harder to use their private search engine effectively, which they are of course free to do. As far as I can tell, they are trying to prevent Google from becoming completely inaccessible to China's citizens, even if that means the Chinese version must be crippled. Why are you opposed to the idea of "something is better than nothing"?
Please read the definitions of "literal" and "literally". You are making things worse.
Uh huh, not only can users in the admin group mess with ordinary things like that, but they can become root simply by running 'sudo sh' and entering their own password. If you don't want someone to have root access, they don't belong in the admin group, because that's what it's all about -- letting them act as root when necessary, but as an ordinary user when they don't need special privileges.
I don't think anyone said anything about using a passphrase as the key--only using it to generate the key (a key that shouldn't be thought of as a string characters). Go ahead and use a 4-page essay as your passphrase. It'll still get crammed into the 256-bit (or other fixed-length) key, but it will be harder to find anyway. At some point, I would imagine, it becomes easier to crack the key itself than the text it is generated from, especially taking the message digest overhead of passphrased-based keys into account.
Are there really any encryption systems that cannot be cracked in 28 days, but which can be cracked in 90?
Probably, but since encrypted hard drives usually involve a passphrase being converted into a key of suitable length by one-way hash algorithms, why not crack the passphrase instead of the actual key? Even with 256-bit AES (or something like it), a weak passphrase-based key is probably one of the easier ways to go after the data. Of course, if the suspect carries their completely random key around on a USB drive of some sort, that's a different matter.
I was once guilty of this crime. Fortunately,
it eventually became apparent that if
"redicule" is not a word,
there is probably not an adjective
based on it either. I have recovered (there's
almost no
chance of me spelling it that way anymore),
and now it bothers me (strange feeling in the head)
to see it just like so many other spelling
errors do, in part because it is a reminder of my
own past.
md5 is also used for verifying that a package
retrieved from a mirror is in fact authentic.
If the main site can't handle all the download
traffic, or something like ports/portage/pkgsrc
wants to use its own mirror list, it is usually
wise to check the file against a reliable hash
from the official server. A problem like this could
potentially allow mirror owners to create fake
packages which pass the checks employed by
package managers or humans, though I'm pretty
sure pkgsrc uses both md5 and sha1 at the moment.
Of course, the likelihood of a mirror owner
wanting to do something evil isn't too high, but
it's clearly something which has been given
consideration.
Some browsers also support link numbering, so you can just type the number next to a link to select it. As others have said, poor or limited UI design doesn't make the input device itself the problem. The same goes for mice and mouse interfaces, by the way.
But if the users care enough about
their own "freedom", they will probably prefer
something like Linux over Mac OS X anyway. With
Linux, they can figure out how it works, improve
it, make it worse, redistribute it, etc. Mac OS X
is something entirely different. If
somebody decides that Mac OS X is better for
the job, and they're okay with using that type of
software,
why should anyone care? Yes, having a large
install-base is nice, both so you can claim
big numbers and receive more
bug reports and patches, but I
don't think that OS X has much of a chance of
"hurting" Linux, even if it is eventually
released for use on regular non-Apple PC hardware.
Those who would switch from Linux (or anything) to
OS X as a result might just as well have switched
to Windows or bought a Mac. Others like Linux
(or whichever OS they use) for other reasons and
probably have no real reason to switch, just
because another big proprietary commercial OS
is now at their disposal.
You use FAT because it's very well-supported, well-tested, and simple enough to not waste much space on small devices.
As far as I know, there are no (known) patents covering it. As is mentioned in the article, Microsoft's recent attempt to patent it failed. Why would consumer devices be restricted, but not Linux?
While this would probably seldom provide a speed boost due to better response times or throughput, zlib compression (supported by many "modern" browsers) should help just about anyone by allowing more than one packetworth of data to be crammed into a single one. As long as the computer itself can decompress fast enough, dialup users should benefit from that part.
I'm a little surprised the original poster's comment was moderated completely down while this one is standing at +5... If my interpretation of the original statement is correct, then a more sensible way to put it is "They should be free to sell their product however they want, but not to prevent you from circumventing any copy-protection schemes they have in place".
This isn't just 'flamebait' -- it actually makes a lot of sense, and it would solve a lot of problems, since the simple "DRM" of today really doesn't stand a chance against those determined enough to get at the content. Of the future, however, nobody can be certain.
I think you may have overlooked one of the most common ways of labelling a work as Creative Commons licensed, which is using RDF and strange tags like and <permits>. Check out the HTML source of a document if you don't have a fancy browser that can interpret that.
Would it really be all that beneficial to be able to edit the real Wikipedia article directly from a mirrored version? Unofficial mirrors can't be completely up-to-date with Wikipedia itself, so somebody might see an error or missing content and say "I should fix that!", only to realize that it's already been fixed in the real article. On the other hand, those who are actually interested in editing Wikipedia content are likely to use wikipedia.org and not a third-party mirror to view the content. Having a link to the article itself makes sense, but an edit link is a bit different, since it may not apply to the version currently being viewed.
I'm sure it's already been mentioned that SHA-1 and other algorithms like MD5 are used for verifying passwords, and any collision, however meaningless it is, may be enough to match the hash stored on the system verifying the password, therefore granting the login request. Of course, this would require the hash to have been leaked first, which is also not very likely.
I imagine anyone dedicated enough to run a supernode probably has the resources to run other types of servers as well. Even if they are using a firewall, it's not going to just block all incoming connections. If this type of "increased security consciousness" affected everyone, web servers wouldn't work either.
I don't think that DHCP is especially useful on a small network where each computer can be manually set up (simplifying things a bit), but it's even stranger to see a story like this on Slashdot. People who need to know how to set up DHCP servers should go to google. And while they're at it, they can google for all the other computer-related subjects that don't need to become news stories.
I know nothing about the specific file format being used here, but the fact that the images are quite large might suggest that they contain an uncompressed representation of the image data, possibly viewable with a raw image data loader (such as the GIMP plugin called raw.c). Of course, even if that is the case, it might not be possible to get a decent picture from it, but it's worth a shot.
I see at least five proposed systems on that page, and I'm sure there are others in existence. It's usually good to have a variety of things to choose from, but it seems like it will be difficult to get any one system fully accepted when there are various different advantages and disadvantages associated with each, especially since some people have already decided on SPF, Domainkeys, or other options. It's quite convenient that almost any mailserver speaks SMTP, but I wonder how long it will take before every mailserver uses the adopted sender authentication system.
I'm aware that hard disk capacity follows a trend similar to Moore's law in that capacity roughly doubles every two years or thereabouts, but much like the CPU industry, does anyone know how far into the future magnetic storage will continue to scale at that pace?
I don't work in the industry, but I did a bit of research on this recently. As I understand it, we're currently able to get several hundred Gb/sq. in. (bits, not bytes) with the perpendicular recording that we've been using since about 2005. Back in 2009, experts were predicting that perpendicular recording as it operates now would probably not be able to exceed 1 Tb/sq. in because of the interference problems at that density. Some of the major drive makers are pursuing alternatives and/or extensions to current recording technology. A couple of the major ones are Heat Assisted Magnetic Recording (HAMR, aka TAR), in which the physical/magnetic properties of the recording surface are altered with heat from a laser or other heat source, and Bit Patterned Media (BPM), in which bit boundaries are actually delineated using non-magnetic material (as opposed to the uniform recording surfaces of today). There are others like Microwave Assisted Recording and Domain-Wall Assisted Recording, but it sounds like these are less likely to be used, at least at first. Recently, there was also a story on Ars Technica describing an effort to combine HAMR and BPM in order to overcome some of the shortcomings of each. Common predictions seem to be that these new technologies would move the density limit up from about 1 Tb/sq. in. to something more like 10 Tb./sq. in. The growth rate has been in decline during this decade, despite the adoption of perpendicular recording, but the hope seems to be that it might rise back up to how it was in the 90s with the next advancement.
GPG is a name chosen to describe the free version.
This sentence is neither informative nor funny.
No, GnuPG is not the same as PGP. GnuPG was in fact developed to replace PGP, both because PGP is covered by a non-commercial use only license, and (probably) because it by default incorporates the patented IDEA algorithm. Yes, PGP Freeware and GPG are both free and interoperable, but they are not the same thing.
if they choose to sell it to you anyway, they do so with no binding agreement in place?
I think if you didn't agree to the EULA, you would not be legally permitted to use the software (just like with the GPL). I don't think the act of providing it to you gives you any new legal privileges except to use the install CD as a coaster. Of course, that assumes you take the EULA seriously to begin with and respect copyright laws and such, but you must at least a bit if you actually go to the trouble of rejecting it in writing to protect yourself.
Uh huh, not only can users in the admin group mess with ordinary things like that, but they can become root simply by running 'sudo sh' and entering their own password. If you don't want someone to have root access, they don't belong in the admin group, because that's what it's all about -- letting them act as root when necessary, but as an ordinary user when they don't need special privileges.
I don't think anyone said anything about using a passphrase as the key--only using it to generate the key (a key that shouldn't be thought of as a string characters). Go ahead and use a 4-page essay as your passphrase. It'll still get crammed into the 256-bit (or other fixed-length) key, but it will be harder to find anyway. At some point, I would imagine, it becomes easier to crack the key itself than the text it is generated from, especially taking the message digest overhead of passphrased-based keys into account.
Are there really any encryption systems that cannot be cracked in 28 days, but which can be cracked in 90?
Probably, but since encrypted hard drives usually involve a passphrase being converted into a key of suitable length by one-way hash algorithms, why not crack the passphrase instead of the actual key? Even with 256-bit AES (or something like it), a weak passphrase-based key is probably one of the easier ways to go after the data. Of course, if the suspect carries their completely random key around on a USB drive of some sort, that's a different matter.
I was once guilty of this crime. Fortunately, it eventually became apparent that if "redicule" is not a word, there is probably not an adjective based on it either. I have recovered (there's almost no chance of me spelling it that way anymore), and now it bothers me (strange feeling in the head) to see it just like so many other spelling errors do, in part because it is a reminder of my own past.
I have a feeling OpenWindows wouldn't be the best choice of names.
No, I'm wrong. That's just not how it works.
This wouldn't apply.
Sorry.
md5 is also used for verifying that a package retrieved from a mirror is in fact authentic. If the main site can't handle all the download traffic, or something like ports/portage/pkgsrc wants to use its own mirror list, it is usually wise to check the file against a reliable hash from the official server. A problem like this could potentially allow mirror owners to create fake packages which pass the checks employed by package managers or humans, though I'm pretty sure pkgsrc uses both md5 and sha1 at the moment. Of course, the likelihood of a mirror owner wanting to do something evil isn't too high, but it's clearly something which has been given consideration.
Some browsers also support link numbering, so you can just type the number next to a link to select it. As others have said, poor or limited UI design doesn't make the input device itself the problem. The same goes for mice and mouse interfaces, by the way.
But if the users care enough about their own "freedom", they will probably prefer something like Linux over Mac OS X anyway. With Linux, they can figure out how it works, improve it, make it worse, redistribute it, etc. Mac OS X is something entirely different. If somebody decides that Mac OS X is better for the job, and they're okay with using that type of software, why should anyone care? Yes, having a large install-base is nice, both so you can claim big numbers and receive more bug reports and patches, but I don't think that OS X has much of a chance of "hurting" Linux, even if it is eventually released for use on regular non-Apple PC hardware. Those who would switch from Linux (or anything) to OS X as a result might just as well have switched to Windows or bought a Mac. Others like Linux (or whichever OS they use) for other reasons and probably have no real reason to switch, just because another big proprietary commercial OS is now at their disposal.
well-tested, and simple enough to not waste much
space on small devices.
covering it. As is mentioned in the article,
Microsoft's recent attempt to patent it failed.
Why would consumer devices be restricted, but not
Linux?
While this would probably seldom provide a speed boost due to better response times or throughput, zlib compression (supported by many "modern" browsers) should help just about anyone by allowing more than one packetworth of data to be crammed into a single one. As long as the computer itself can decompress fast enough, dialup users should benefit from that part.
I'm a little surprised the original poster's comment was moderated completely down while this one is standing at +5... If my interpretation of the original statement is correct, then a more sensible way to put it is "They should be free to sell their product however they want, but not to prevent you from circumventing any copy-protection schemes they have in place".
This isn't just 'flamebait' -- it actually makes a lot of sense, and it would solve a lot of problems, since the simple "DRM" of today really doesn't stand a chance against those determined enough to get at the content. Of the future, however, nobody can be certain.
I use a text-based browser most of the time, and a browser that doesn't support Javascript the rest of the time. So what?
If I want to view someone's web content in raw HTML form, printed out on paper, or stipped of ads, whose business is that but mine?
I think you may have overlooked one of the most common ways of labelling a work as Creative Commons licensed, which is using RDF and strange tags like and <permits>. Check out the HTML source of a document if you don't have a fancy browser that can interpret that.
Would it really be all that beneficial to be able to edit the real Wikipedia article directly from a mirrored version? Unofficial mirrors can't be completely up-to-date with Wikipedia itself, so somebody might see an error or missing content and say "I should fix that!", only to realize that it's already been fixed in the real article. On the other hand, those who are actually interested in editing Wikipedia content are likely to use wikipedia.org and not a third-party mirror to view the content. Having a link to the article itself makes sense, but an edit link is a bit different, since it may not apply to the version currently being viewed.
I'm sure it's already been mentioned that SHA-1 and other algorithms like MD5 are used for verifying passwords, and any collision, however meaningless it is, may be enough to match the hash stored on the system verifying the password, therefore granting the login request. Of course, this would require the hash to have been leaked first, which is also not very likely.
I imagine anyone dedicated enough to run a supernode probably has the resources to run other types of servers as well. Even if they are using a firewall, it's not going to just block all incoming connections. If this type of "increased security consciousness" affected everyone, web servers wouldn't work either.
I don't think that DHCP is especially useful on a small network where each computer can be manually set up (simplifying things a bit), but it's even stranger to see a story like this on Slashdot. People who need to know how to set up DHCP servers should go to google.
And while they're at it, they can google for all the other computer-related subjects that don't need to become news stories.
This is quite true, but it's also helpful to have a way to rapidly add URLs without typing out
What might be helpful is a simple plain text file format such as:
-- Heading
* http://url/ Title Text
This could then be converted into HTML automatically. I think txt2tags is one such tool (with a somewhat different input format).
I know nothing about the specific file format being used here, but the fact that the images are quite large might suggest that they contain an uncompressed representation of the image data, possibly viewable with a raw image data loader (such as the GIMP plugin called raw.c).
Of course, even if that is the case, it might not be possible to get a decent picture from it, but it's worth a shot.
I see at least five proposed systems on that page, and I'm sure there are others in existence. It's usually good to have a variety of things to choose from, but it seems like it will be difficult to get any one system fully accepted when there are various different advantages and disadvantages associated with each, especially since some people have already decided on SPF, Domainkeys, or other options.
It's quite convenient that almost any mailserver speaks SMTP, but I wonder how long it will take before every mailserver uses the adopted sender authentication system.