What kind of connection? TCP/IP won't let you do it that way, and anything else would require special software on the NAT box. Their real IPs are not globally routable, so it won't work unless they're on the same LAN.
If the connection is set up by the server, the voice traffic must be relayed by the server. As the site notes: "two people behind different NATs can't open up connections to each other in the usual way - ever!" That means that any data they transmit to each other MUST pass through a third non-NATed box.
Actually, Makefiles don't have to be single monolithic files. GNU make supports the include command, which takes wildcards.
So in MakefileRC5, "include/etc/makerc5.d/*" would include all the makefiles in the specified directory. Such makefiles would be lpd.mk and ntpd.mk, etc.
Good typesetting. not crap like the html rendering
It's a flexibility tradeoff. Really, it's a microcosm of the difference between PDF and HTML. The whole difference is that PDF is designed to look exactly the same, no matter where you use it. While HTML was never meant to look the same everywhere-- it was meant to be rendered to suit the particular viewing environment. And I greatly prefer the hinted fonts I get from HTML documents to the fuzzy text that's always too big or too small in a PDF.
Vector charts: ditto for svg. not hear yet. Lack of vector support isn't a fatal flaw. You're seeing bitmaps anyhow.
Also i can save a pdf on disk or print it You can print web pages. I agree that saving them is problematic.
I wonder what problems everybody has with the page nature of pdf. I actually read a lot more text in books than on screen, and imho there is nothing wrong with defining a fixed lines per page relation or using the unit "page" to divide a bigger document in manageble portions. I think PDF is an excellent way of transmitting documents for printing purposes. I read a lot of text in book form too. It's easier on the eyes, but it doesn't have hyperlinks or search facilities. On the web, there are better units than "page" for dividing information. For long articles, it's usually the "section". Since it divides the article into different topics, it makes more sense than divisions based on font metrics and page dimensions. PDF documents will often divide by section, but that means scrolling through a whole bunch of white space until the next page break.
There is definitely value in PDF. In my day job, I write and maintain a program that generates reports in PDF format. But that's 'cause we're targeting printed output.
Viewing PDFs on the web isn't nearly as good as HTML though. HTML documents are easier and more comfortable to read. There's no concept of "the real page size", so you don't have different zoom levels and different page-layout modes. And fonts are hinted well.
With a SHA-1 hash, you should not be able to recreate the original. This is an important propery of hashes.
http://www.itl.nist.gov/fipspubs/fip180-1.htm
"The SHA-1 is called secure because it is computationally infeasible to find a message which corresponds to a given message digest, or to find two different messages which produce the same message digest."
Actually, they used to say the same thing about MD5, but nowadays, there's some concern that MD5 may be breakable. As far as I know, it hasn't actually been broken, but given enough time, motivation, resources. ..
For secure uses, SHA-1 is the recommended algorithm nowadays, because it's considered impossible to reconstruct the original from a hash.
If "MD5 hashing is a very different kettle of fish", why should we think of it as a kind of lossy compression?
Conceptually, hashing is a way of producing a fairly unique identifier for something, while compression is about reducing redundancy in the storage format, and lossy compression is about treating non-redundant things as redundant in order to achieve higher compression ratios.
You can say they're the same, but you also say they're not. I say they're not.
Hashes and lossy compression are different things. They're designed for completely different purposes and implemented for the purpose they serve. That's why LAME won't compress an mp3 to less than 8kbps, much less 128 bits. It's why md5sum doesn't have a --reproduce-original switch.
For a given input and parameters, any two (independently-developed) MP3 encoders will almost certainly produce different outputs. For a given input and parameters, different md5 implementations will produce the same result.
But lossily compressed things are derived works-- Otherwise the RIAA wouldn't be suing 12-year-old P2P users. I'd draw the distinction that with lossy compression, the expression isn't lost. Whereas with MD5 (and other hashes), the expression is irretrievably lost.
No, you don't add informative comments if you can help it. Comments get out of date much more easily than program code (out-of-date program code has a sulky way of getting you to fix it). A false, out-of-date comment is worse than nothing.
Ideally, program code is self-documenting-- small functions with descriptive names, well-chosen variable and type names, etc. Of course, nobody's ideal.
In this case, you can see that some of the type names (u_long) differ between SCO's version and Linux's version. It's quite possible that the swap map unit in Linux is no longer 512 bytes, or that someone realized that it would likely cease to be 512 bytes in the future.
"Security though obscurity" is not as broad as you're making it out to be. "Obscurity" means secrecy about how the systems operate, not any secret at all.
PGP would be a classic example of the other approach. The system is designed so that knowing the design isn't enough to allow it to be cracked.
It's the difference between/usr/src/linux and/etc/shadow. No one's arguing that you should publish your/etc/shadow.
In the email example you give, SMTP is the open standard, and your particular email address is the secret.
If the source was available for the power system control software, people could check it for bugs and send patches to the vendor, but no one who didn't have a password would be able to log in.
While I wouldn't want to run the risk of blackouts, that risk might actually be outweighed by the good of making sure the sofware was rock-solid. After all, there's no reason to believe this blackout was triggered by malicious activity. It's unlikely, but maybe it could have been prevented if the software was open-source.
In fact, you could have security company review the code prior to releasing the source, and then any attacks based on that code would be the fault of the auditors.
No, you aren't necessarily violating copyright. As long as you follow the GPL, you're not violating copyright.
C and D are true, though distributing the whole work will never be "fair use".
Remember that even people who distribute binaries based on unmodified source are required to provide access to the source they used. I stand by A and B.
If someone acquires your derived-from-GPL source and distributes it, you can sue them, but the original author will sue you for copyright infringement.
You're complaining they use libraries for HTTP and XML? I say "good on them". Libraries are a way of pooling resources. If you use libraries instead of rolling your own, you get
1. More testing 2. More bugs fixed, more correct implementation 3. More features 4. More programmers who understand your HTTP/XML/whatever code
The Holy GPL sayeth: "You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works."
If you distribute GPLed code you either a) have accepted the GPL implicitly b) are violating the copyright on the GPLed work
Slashdot Mirror
"Work" doesn't mean "coding" either. Torvald's current work is in coding and "herding cats".
You can't embed an image in the href text, so I don't see how this suggestion gains us anything at all.
Actually, you can.
data URL examples
Sick, eh?
Did anyone else misread the headline?
Yes, but with Knoppix, it's really easy to use the distro without even touching the hard disks.
The argument is that using lsh makes you a minority group that's not worth targetting for worm writers. So it certainly could increase your security.
There is a Win95 livecd, but they're not sharing.
What kind of connection? TCP/IP won't let you do it that way, and anything else would require special software on the NAT box. Their real IPs are not globally routable, so it won't work unless they're on the same LAN.
If the connection is set up by the server, the voice traffic must be relayed by the server. As the site notes: "two people behind different NATs can't open up connections to each other in the usual way - ever!" That means that any data they transmit to each other MUST pass through a third non-NATed box.
Actually, Makefiles don't have to be single monolithic files. GNU make supports the include command, which takes wildcards.
/etc/makerc5.d/*" would include all the makefiles in the specified directory. Such makefiles would be lpd.mk and ntpd.mk, etc.
So in MakefileRC5, "include
I think that might actually work!
Good typesetting. not crap like the html rendering
It's a flexibility tradeoff. Really, it's a microcosm of the difference between PDF and HTML. The whole difference is that PDF is designed to look exactly the same, no matter where you use it. While HTML was never meant to look the same everywhere-- it was meant to be rendered to suit the particular viewing environment. And I greatly prefer the hinted fonts I get from HTML documents to the fuzzy text that's always too big or too small in a PDF.
Vector charts: ditto for svg. not hear yet.
Lack of vector support isn't a fatal flaw. You're seeing bitmaps anyhow.
Also i can save a pdf on disk or print it
You can print web pages. I agree that saving them is problematic.
I wonder what problems everybody has with the page nature of pdf. I actually read a lot more text in books than on screen, and imho there is nothing wrong with defining a fixed lines per page relation or using the unit "page" to divide a bigger document in manageble portions.
I think PDF is an excellent way of transmitting documents for printing purposes. I read a lot of text in book form too. It's easier on the eyes, but it doesn't have hyperlinks or search facilities. On the web, there are better units than "page" for dividing information. For long articles, it's usually the "section". Since it divides the article into different topics, it makes more sense than divisions based on font metrics and page dimensions. PDF documents will often divide by section, but that means scrolling through a whole bunch of white space until the next page break.
There is definitely value in PDF. In my day job, I write and maintain a program that generates reports in PDF format. But that's 'cause we're targeting printed output.
Viewing PDFs on the web isn't nearly as good as HTML though. HTML documents are easier and more comfortable to read. There's no concept of "the real page size", so you don't have different zoom levels and different page-layout modes. And fonts are hinted well.
That's like saying "should not be able to" and "cannot" are EFFECTIVELY the same thing!
With a SHA-1 hash, you should not be able to recreate the original. This is an important propery of hashes.
.
http://www.itl.nist.gov/fipspubs/fip180-1.htm
"The SHA-1 is called secure because it is computationally infeasible to find a message which corresponds to a given message digest, or to find two different messages which produce the same message digest."
Actually, they used to say the same thing about MD5, but nowadays, there's some concern that MD5 may be breakable. As far as I know, it hasn't actually been broken, but given enough time, motivation, resources. .
For secure uses, SHA-1 is the recommended algorithm nowadays, because it's considered impossible to reconstruct the original from a hash.
If "MD5 hashing is a very different kettle of fish", why should we think of it as a kind of lossy compression?
Conceptually, hashing is a way of producing a fairly unique identifier for something, while compression is about reducing redundancy in the storage format, and lossy compression is about treating non-redundant things as redundant in order to achieve higher compression ratios.
You can say they're the same, but you also say they're not. I say they're not.
Hashes and lossy compression are different things. They're designed for completely different purposes and implemented for the purpose they serve. That's why LAME won't compress an mp3 to less than 8kbps, much less 128 bits. It's why md5sum doesn't have a --reproduce-original switch.
For a given input and parameters, any two (independently-developed) MP3 encoders will almost certainly produce different outputs. For a given input and parameters, different md5 implementations will produce the same result.
But lossily compressed things are derived works-- Otherwise the RIAA wouldn't be suing 12-year-old P2P users. I'd draw the distinction that with lossy compression, the expression isn't lost. Whereas with MD5 (and other hashes), the expression is irretrievably lost.
Well, Cairo supports translucency. Maybe you'll get your alpha-blending from Cairo?
If you don't understand that error, you probably shouldn't be compiling your own kernel.
No, absolute pitch is perfect pitch. The ability to recognize a given pitch in context is relative pitch.
No, you don't add informative comments if you can help it. Comments get out of date much more easily than program code (out-of-date program code has a sulky way of getting you to fix it). A false, out-of-date comment is worse than nothing.
Ideally, program code is self-documenting-- small functions with descriptive names, well-chosen variable and type names, etc. Of course, nobody's ideal.
In this case, you can see that some of the type names (u_long) differ between SCO's version and Linux's version. It's quite possible that the swap map unit in Linux is no longer 512 bytes, or that someone realized that it would likely cease to be 512 bytes in the future.
Using power control software that isn't rock solid is insane.
"Security though obscurity" is not as broad as you're making it out to be. "Obscurity" means secrecy about how the systems operate, not any secret at all.
/usr/src/linux and /etc/shadow. No one's arguing that you should publish your /etc/shadow.
PGP would be a classic example of the other approach. The system is designed so that knowing the design isn't enough to allow it to be cracked.
It's the difference between
In the email example you give, SMTP is the open standard, and your particular email address is the secret.
If the source was available for the power system control software, people could check it for bugs and send patches to the vendor, but no one who didn't have a password would be able to log in.
While I wouldn't want to run the risk of blackouts, that risk might actually be outweighed by the good of making sure the sofware was rock-solid. After all, there's no reason to believe this blackout was triggered by malicious activity. It's unlikely, but maybe it could have been prevented if the software was open-source.
In fact, you could have security company review the code prior to releasing the source, and then any attacks based on that code would be the fault of the auditors.
No, you aren't necessarily violating copyright. As long as you follow the GPL, you're not violating copyright.
C and D are true, though distributing the whole work will never be "fair use".
Remember that even people who distribute binaries based on unmodified source are required to provide access to the source they used. I stand by A and B.
If someone acquires your derived-from-GPL source and distributes it, you can sue them, but the original author will sue you for copyright infringement.
You're complaining they use libraries for HTTP and XML? I say "good on them". Libraries are a way of pooling resources. If you use libraries instead of rolling your own, you get
1. More testing
2. More bugs fixed, more correct implementation
3. More features
4. More programmers who understand your HTTP/XML/whatever code
The Holy GPL sayeth:
"You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works."
If you distribute GPLed code you either
a) have accepted the GPL implicitly
b) are violating the copyright on the GPLed work