[ true ] returns 0 because true is indeed an existent argument to [. Which is really not the intended application of [. while true is much more to the point. while: makes you look even more savvy.
wget -O - URL >/dev/null
[Shakes head] Why not wget -O/dev/null URL? Or better yet, curl -o/dev/null URL?
Let's look at this again:
while:; do curl -o/dev/null http://www.thebulkclub.com/; done
What's worse is when you try pasting something into a text input box on a web page, inside a web browser, and the page has some bit of Javascript that automatically selects everything in the text box upon receiving keyboard focus. So then you have to erase the text, go back to the program you made the original selection in to reselect the text, and go back to the web browser.
That drives me up the wall.
I seem to recall using a GTK or Gnome program that had this behavior on its own (!), but can't remember what it was.
Freenet6 is nice in that it's very easy to get started with. (Debian users: apt-get install freenet6, and your tunnel Just Works.) They also offer fast tunnel updates, for people with dynamic IPv4 addresses that change often. However, it has been extremely unreliable for me. About once every week or two, service will go down for anywhere from an hour to a couple days, intermittently.
For those that are looking for their first (or a new) tunnel broker, I'd advise looking elsewhere.
The GNU/Linux default security model that my family run all their machines on does not run arbitrary software with elevated privileges as Microsoft does. It never has.
Does it really matter? For the few multi-user systems, it does. For everyone else, guess what a user (the only user on the computer) cares about? Their documents and projects and such. Not being root when their application ends up getting exploited won't save that information from being read, tampered with, or destroyed.
In the context of this article, it wouldn't matter if normal home computer users always ran with lower priviledges than root: normal users can still bind to high ports (for running web sites for spam e-mail), and they can still open outgoing TCP connections (for spamming).
Of course this is a security bug; it's a bug in an authentication program which, when exploited, allows an attacker access to a computer that they wouldn't have otherwise had. How is that not a security bug?
Personal computers and workstations make no attempt to be secure against physical access. I just changed two Mac OS X root passwords so I could create an account for myself on some pc's last week. I'm not a regular mac user, I just did a google search and found three or four ways to do it, the easiest was to just boot into single user mode, turn on the standard password authentication mechanism, and then type passwd...
If the user cared about security, they'd enable the OpenFirmware password feature. Without the password, you won't be able to boot in any way but from the default disk and with no special boot arguments.
I've never met a Sun workstation that didn't give you fully fledged debug console at Meta-A..
Then you've never met a Sun workstation with its OpenProm password enabled. You can interrupt the machine with L1-A (and it's L1-A, aka Stop-A, not Meta-A), but you can't get anywhere without the password. I do this on my Ultra 1 and my Sparcstation LX.
Lilo lets you enter single user mode with just a kernel parameter to linux...
Unless the 'password' option in lilo.conf is in use.
You can overwrite the password files in Windows, etc.
I'm not very familiar with Windows security, but as far as I understand, if you can prevent the hard disk from being removed from the machine, and you can prevent the machine from booting anything but the hard disk, Windows can be configured so that you cannot simply overwrite password files (or any other files, for that matter).
Keep in mind that on PCs, the BIOS can be protected from booting from anything but a hard disk.
Many PC cases, and every Sun case I've seen, have the option for installing a lock into place, so that the case cannot be removed without damaging the case or damaging the lock. Since the only way to circumvent a PC BIOS, OpenFirmware, or OpenProm password is to open the case, a security-conscious person would inspect the lock to ensure it hasn't been tampered with. If it hasn't, then it is extremely unlikely an attacker could have, for instance, booted their own OS and installed a trojan horse to the computer's disk which intercepts passwords and passphrases.
How did this get modded to +5? Congestion created by Microsoft worms is noticable by non-Microsoft users. And everyone knows there have been Linux worms (even in the past couple years).
IPv6 sounds great but I see that we will need more TLDs and a domain name will be absolutely necessary.
Maybe this was a joke, but IPv6 doesn't need or use new domain names. It uses the same DNS that IPv4 servers and clients do.
AAAA records are used for forward lookups.
The same records currently used for n4.n3.n2.n1.in-addr.arpa IPv4 reverse-lookups (PTR records) are used for reverse IPv6 lookups, only the format is n32.n31.n30...n1.ip6.arpa or n32.n31.n30...n1.ip6.int (the latter apparently preferred?), where n1 through n32 are each of the IPv6 hexidecimal digits.
The reverse-lookup entry for the IPv6 address 2001:200:0:8002:203:47ff:fea5:3085 would look like this in a BIND zone file:
5.8.0.3.5.a.e.f.f.f.7.4.3.0.2.0.2.0.0.8.0.0.0.0.0. 0.2.0.1.0.0.2.ip6.arpa. 86400 IN PTR orange.kame.net.
(Slashcode will have split that ip6.arpa name into pieces. Go Slashdot.)
too bad they didn't come up with a better notation. instead of hex 0-F just use 0-9,a-Z and 128bits can be represented in a legible string of characters.
RFC 1924 defines Base-85, a compact encoding scheme for 128-bit IPv6 addresses. An address represented in the usual form would be '
1080:0:0:0:8:800:200c:417a'. That same address in Base-85 becomes '4)+k&C#VzJ4br>0wv%Yp'. Unfortunately, Base-85 addresses aren't very memorable, and worst of all, they're case-sensitive. Try reading that out over a phone. RFC 1924 was released on an April 1st, so it's probably not serious.
you could even argue the need for a dns system since you wouldn't need any service to associate "google.com" with an ip.. the ip could very well be "google.com"
That would be bad:
Routing would necessarily have to be based on domains (eg, a packet travels to a router responsible for "com", then one responsible for "google", then one responsible for "www").
It wouldn't be compatible with the existing DNS. "www.google.com" in such a system may not necessarily have anything to do with the current owners of the google.com domain. Talk about squatting possibilities, and confusion.
The existing DNS adds indirection. "google.com" and "www.google.com" can have identical IP addresses in the current system, and hence be routed identically. In your system, those would be two separate nodes, which would reduce flexibility.
And, since addresses would be variable-length, routers would have a hell of a time parsing packets.
Stallman had a previous naming campaign: Lignux. Now that's sad.
Google for it, you'll find references that go back to 1996 or earlier. I don't know if that's significantly prior to the current "GNU/Linux" naming campaign. Amusing either way.
Lack of bloat was one of it's earlier strengths on low-end SPARC desktop hardware, there seems little point in using it these days, especially since there are so few SPARC/Linux applications. [Emphasis added]
There is a lack of Linux SPARC apps? The great thing about sticking with free/open-source software is its almost guaranteed availability on non-i386 archetectures. I'm using Debian on a Power Mac 9500 and a Sun Ultra 1, and aside from i386-specific packages (like lilo), I haven't found one package that's not available in either architectures.
It's my belief that most of Debian's thousands of packages are available for its non-i386 architectures. Debian developers (the hundreds of people that package programs for Debian) have shell access to some non-i386 systems for testing and building. Debian porters do a lot or most of the work porting packages to their preferred architectures, collaborating with package maintainers.
So, do you mean commercial apps? (FWIW, I'm typing this on Opera 6.12 for Linux PowerPC; they're one of the few software companies that acknowledge non-i386 Linux users.)
... Anywayz... kinda lost my train of thought... oh, yeah. Anywayz,...
I don't think many readers care about the mental process you went through while you wrote this comment. There's no good reason to have told us that you had lost your train of thought while writing. After all, you are writing, not talking.
As soon as you get a connection from a mail server to one of these addresses, you *know* it's an open relay, and you put it in your database -- automatically, with no interaction required.
Great. What do you do when some jackass (read: spammer with a cause) finds your honeypot addresses and gets e-mail sent to them? You end up blacklisting mail from legitimate sources. Oops. Mail sources could include:
FTP was designed for interfacing with the filesystem of a remote Unix system, with the filesystem permissions that are granted to the user you log in as. FTP lets you browse the hierarchy, including examining ownership, permission, and symlink targets; pretty much the same as what you get with 'ls -l'. Apache does file listings, but only shows file names, last modification dates, and size. This makes FTP more suitable than HTTP for remote mirroring of directory trees. This also makes it easier to "browse" what an FTP server has to offer, on a directory-by-directory basis.
With FTP, the server prints a response when a client connects. Usually, the client sends a user name, password, the 'SYST' command, and asks for the current working directory, tells the server what mode (ASCII or binary) it wants, changes to the directory with the file it needs, sends a PORT command, then finally requests the file. With HTTP, the client connects, sends a request, and the server responds. That's 8 client commands and 9 server responses with FTP, as opposed to 1/1 with HTTP. Each time a command is sent, the client has to wait for the server to respond. The latency adds up, and that means, especially on high-latency connections, FTP is slower to initiate and begin downloading than HTTP. Who said HTTP is slower?
Regarding reliability, both protocols and modern implementations of their clients and servers have features to resume a broken download from where it left off. Who says one is more reliable than the other?
HTTP is more simple than FTP. As far as I can tell, in FTP "active mode", the client sends a PORT command with an IP address and port number that is listening. In "passive mode", the server sends an IP address and port number that is listening, after the PASV command. These address/port combinations are used for the actual file transfer.
Active mode doesn't work if there is NAT between the client and the server, unless the NAT system rewrites the packets so that the IP address the server sees in the PORT command is the outside, external address of the NAT system. When an FTP server is behind NAT, passive mode cannot be used without a similar kluge; it must get an outside-world IP address to connect to from the client, which active-mode PORT does. If both client and server are behind NAT, then one of these NAT kluges must be in effect for file transfer to be possible.
This address/port nonsense could be part of the security concern with FTP. I also believe older FTP implementations allowed the client (in active mode) or server (in passive mode) to specify arbitrary address/port combinations, so that the FTP server or client could be used as a proxy in an attack. Is this still the case?
With HTTP, transfers are conducted on the same TCP connection as control is on, and therefore doesn't need to concern itself with IP addresses and ports, and the people using it have fewer NAT headaches.
name one easy to use non profit linux thats designed for newbies. Just one
Just because it doesn't currently exist doesn't mean it can't. Can you give me an explanation why it couldn't?
By the way, KDE and Gnome arent distos they are applications. Big difference here.
No, they're desktop environments, big difference. The comparison was used to illustrate that non-commercial hackers aren't inherently out of touch with good user interface design.
Not to mention most KDE and Gnome developers are paid developers.
If you read the article, you'd know the author was suggesting a non-profit organization funded by the community. There would be some paid developers. Just like KDE (and maybe GNOME--not sure if they're actually funded).
I fail to see how a fork of Mandrake managed by a non-profit would degrade its ease of use, and have a more zealous and selfish user base. That makes no sense.
Focusing on "hardcore Linux users will take over operations and make it worthless to the common joe sixpack", your point seems to be that volunteers have no idea how to engineer an easy-to-use operating system *and* are zealous bastards to boot. That makes no sense. Look at KDE and GNOME (both under non-profits). Those volunteers seem to be doing a reasonable job writing easy-to-use interfaces.
Am I replying to a troll? Somebody, please moderate accordingly.
Can you please read your own quote of the article?
The program converts to HTML.
The way I read the article and author's site, this program reduces/removes the DRM protection of a LIT file so that it may be converted to HTML by a separate program, like Microsoft Reader itself. (If that's even possible.)
I took a look at the source (recently published on the author's site); it appears to also support conversion to "an OEBPS compliant package". It seems like there's some HTML conversion stuff too, but that's not mentioned on the web site or the README file.
The guy didn't hand out the source (which is a shame, or else Linux folks could be reading eBooks right now).
Article:
Convert Lit or "Clit.exe" is a command line utility that can downgrade the DRM5 security to DRM1. From there, the formerly encrypted Lit book can be converted to HTML, text, or any other format.
You mean to suggest there's a Microsoft Reader port to Linux?
Slashdot Mirror
Of course it would be wrong!
[ true ] returns 0 because true is indeed an existent argument to [. Which is really not the intended application of [. while true is much more to the point. while : makes you look even more savvy.
[Shakes head] Why not wget -O /dev/null URL ? Or better yet, curl -o /dev/null URL ?
Let's look at this again:
Ahh, much better!
What's worse is when you try pasting something into a text input box on a web page, inside a web browser, and the page has some bit of Javascript that automatically selects everything in the text box upon receiving keyboard focus. So then you have to erase the text, go back to the program you made the original selection in to reselect the text, and go back to the web browser.
That drives me up the wall.
I seem to recall using a GTK or Gnome program that had this behavior on its own (!), but can't remember what it was.
Freenet6 is nice in that it's very easy to get started with. (Debian users: apt-get install freenet6, and your tunnel Just Works.) They also offer fast tunnel updates, for people with dynamic IPv4 addresses that change often. However, it has been extremely unreliable for me. About once every week or two, service will go down for anywhere from an hour to a couple days, intermittently.
For those that are looking for their first (or a new) tunnel broker, I'd advise looking elsewhere.
Does it really matter? For the few multi-user systems, it does. For everyone else, guess what a user (the only user on the computer) cares about? Their documents and projects and such. Not being root when their application ends up getting exploited won't save that information from being read, tampered with, or destroyed.
In the context of this article, it wouldn't matter if normal home computer users always ran with lower priviledges than root: normal users can still bind to high ports (for running web sites for spam e-mail), and they can still open outgoing TCP connections (for spamming).
Of course this is a security bug; it's a bug in an authentication program which, when exploited, allows an attacker access to a computer that they wouldn't have otherwise had. How is that not a security bug?
If the user cared about security, they'd enable the OpenFirmware password feature. Without the password, you won't be able to boot in any way but from the default disk and with no special boot arguments.
Then you've never met a Sun workstation with its OpenProm password enabled. You can interrupt the machine with L1-A (and it's L1-A, aka Stop-A, not Meta-A), but you can't get anywhere without the password. I do this on my Ultra 1 and my Sparcstation LX.
Unless the 'password' option in lilo.conf is in use.
I'm not very familiar with Windows security, but as far as I understand, if you can prevent the hard disk from being removed from the machine, and you can prevent the machine from booting anything but the hard disk, Windows can be configured so that you cannot simply overwrite password files (or any other files, for that matter).
Keep in mind that on PCs, the BIOS can be protected from booting from anything but a hard disk.
Many PC cases, and every Sun case I've seen, have the option for installing a lock into place, so that the case cannot be removed without damaging the case or damaging the lock. Since the only way to circumvent a PC BIOS, OpenFirmware, or OpenProm password is to open the case, a security-conscious person would inspect the lock to ensure it hasn't been tampered with. If it hasn't, then it is extremely unlikely an attacker could have, for instance, booted their own OS and installed a trojan horse to the computer's disk which intercepts passwords and passphrases.
How did this get modded to +5? Congestion created by Microsoft worms is noticable by non-Microsoft users. And everyone knows there have been Linux worms (even in the past couple years).
FUDish, not insightful!
Maybe this was a joke, but IPv6 doesn't need or use new domain names. It uses the same DNS that IPv4 servers and clients do.
AAAA records are used for forward lookups.
The same records currently used for n4.n3.n2.n1.in-addr.arpa IPv4 reverse-lookups (PTR records) are used for reverse IPv6 lookups, only the format is n32.n31.n30...n1.ip6.arpa or n32.n31.n30...n1.ip6.int (the latter apparently preferred?), where n1 through n32 are each of the IPv6 hexidecimal digits.
The reverse-lookup entry for the IPv6 address 2001:200:0:8002:203:47ff:fea5:3085 would look like this in a BIND zone file:
(Slashcode will have split that ip6.arpa name into pieces. Go Slashdot.)
That's Tom Cruise, not Tom Hanks.
RFC 1924 defines Base-85, a compact encoding scheme for 128-bit IPv6 addresses. An address represented in the usual form would be ' 1080:0:0:0:8:800:200c:417a'. That same address in Base-85 becomes '4)+k&C#VzJ4br>0wv%Yp'. Unfortunately, Base-85 addresses aren't very memorable, and worst of all, they're case-sensitive. Try reading that out over a phone. RFC 1924 was released on an April 1st, so it's probably not serious.
That would be bad:
Shouldn't you be studying?
Ho-hum.
(I appreciate the fact you're trolling. YHL. HAND.)
Google for it, you'll find references that go back to 1996 or earlier. I don't know if that's significantly prior to the current "GNU/Linux" naming campaign. Amusing either way.
There is a lack of Linux SPARC apps? The great thing about sticking with free/open-source software is its almost guaranteed availability on non-i386 archetectures. I'm using Debian on a Power Mac 9500 and a Sun Ultra 1, and aside from i386-specific packages (like lilo), I haven't found one package that's not available in either architectures.
It's my belief that most of Debian's thousands of packages are available for its non-i386 architectures. Debian developers (the hundreds of people that package programs for Debian) have shell access to some non-i386 systems for testing and building. Debian porters do a lot or most of the work porting packages to their preferred architectures, collaborating with package maintainers.
So, do you mean commercial apps? (FWIW, I'm typing this on Opera 6.12 for Linux PowerPC; they're one of the few software companies that acknowledge non-i386 Linux users.)
I don't think many readers care about the mental process you went through while you wrote this comment. There's no good reason to have told us that you had lost your train of thought while writing. After all, you are writing, not talking.
Paragraphs would have helped, too.
Sorry to be so picky, I just can't help myself.
You think these stories are obvious? Check out the OpenBSD Journal. Yeech.
For that matter, Natalie Portman has a Bacon Number of 2. Hrms.
Great. What do you do when some jackass (read: spammer with a cause) finds your honeypot addresses and gets e-mail sent to them? You end up blacklisting mail from legitimate sources. Oops. Mail sources could include:
You could end up blocking mail from servers having anything to do with the above.
Parent-parent posting was worded cleverly (or stupidly, depending on intent):
"Fight it", not "fight for it".
<joke obviousness="100%">
Will you be surprised when it makes Slashdot twice?
</joke>
Each has their place.
FTP was designed for interfacing with the filesystem of a remote Unix system, with the filesystem permissions that are granted to the user you log in as. FTP lets you browse the hierarchy, including examining ownership, permission, and symlink targets; pretty much the same as what you get with 'ls -l'. Apache does file listings, but only shows file names, last modification dates, and size. This makes FTP more suitable than HTTP for remote mirroring of directory trees. This also makes it easier to "browse" what an FTP server has to offer, on a directory-by-directory basis.
With FTP, the server prints a response when a client connects. Usually, the client sends a user name, password, the 'SYST' command, and asks for the current working directory, tells the server what mode (ASCII or binary) it wants, changes to the directory with the file it needs, sends a PORT command, then finally requests the file. With HTTP, the client connects, sends a request, and the server responds. That's 8 client commands and 9 server responses with FTP, as opposed to 1/1 with HTTP. Each time a command is sent, the client has to wait for the server to respond. The latency adds up, and that means, especially on high-latency connections, FTP is slower to initiate and begin downloading than HTTP. Who said HTTP is slower?
Regarding reliability, both protocols and modern implementations of their clients and servers have features to resume a broken download from where it left off. Who says one is more reliable than the other?
HTTP is more simple than FTP. As far as I can tell, in FTP "active mode", the client sends a PORT command with an IP address and port number that is listening. In "passive mode", the server sends an IP address and port number that is listening, after the PASV command. These address/port combinations are used for the actual file transfer.
Active mode doesn't work if there is NAT between the client and the server, unless the NAT system rewrites the packets so that the IP address the server sees in the PORT command is the outside, external address of the NAT system. When an FTP server is behind NAT, passive mode cannot be used without a similar kluge; it must get an outside-world IP address to connect to from the client, which active-mode PORT does. If both client and server are behind NAT, then one of these NAT kluges must be in effect for file transfer to be possible.
This address/port nonsense could be part of the security concern with FTP. I also believe older FTP implementations allowed the client (in active mode) or server (in passive mode) to specify arbitrary address/port combinations, so that the FTP server or client could be used as a proxy in an attack. Is this still the case?
With HTTP, transfers are conducted on the same TCP connection as control is on, and therefore doesn't need to concern itself with IP addresses and ports, and the people using it have fewer NAT headaches.
Just because it doesn't currently exist doesn't mean it can't. Can you give me an explanation why it couldn't?
No, they're desktop environments, big difference. The comparison was used to illustrate that non-commercial hackers aren't inherently out of touch with good user interface design.
If you read the article, you'd know the author was suggesting a non-profit organization funded by the community. There would be some paid developers. Just like KDE (and maybe GNOME--not sure if they're actually funded).
I fail to see how a fork of Mandrake managed by a non-profit would degrade its ease of use, and have a more zealous and selfish user base. That makes no sense.
Focusing on "hardcore Linux users will take over operations and make it worthless to the common joe sixpack", your point seems to be that volunteers have no idea how to engineer an easy-to-use operating system *and* are zealous bastards to boot. That makes no sense. Look at KDE and GNOME (both under non-profits). Those volunteers seem to be doing a reasonable job writing easy-to-use interfaces.
Am I replying to a troll? Somebody, please moderate accordingly.
The way I read the article and author's site, this program reduces/removes the DRM protection of a LIT file so that it may be converted to HTML by a separate program, like Microsoft Reader itself. (If that's even possible.)
I took a look at the source (recently published on the author's site); it appears to also support conversion to "an OEBPS compliant package". It seems like there's some HTML conversion stuff too, but that's not mentioned on the web site or the README file.
Article:
You mean to suggest there's a Microsoft Reader port to Linux?