On some books, they do. When I "registered" my copy of this book, I was given a link to download a.PDF of it. Be aware that on some books (mostly older ones) the.pdf file(s) were contained in a Windows.exe.
If enough people care, I'll make them produce a HTML file or something.
One of my books finally made it onto Slashdot. I wrote the "Worm Turns" chapter with Tim Mullen, acted as tech editor for the book, and wrote the overall outline. Pretty easy book to be a tech editor on. I'll be watching this thread if there are any questions I can answer.
Most round-robin DNS servers will randomize the order of the list of servers they reply with. So even stupid client apps that simply grab the first IP from the list will get some distribution.
Still, the point remains... RRDNS is a truly bad solution to distributed/redundant servers. When one of the servers dies, 1/n of the clients or 1/n of the time still try the down server, on average for half of the cache timeout.
Someone could write an IDS that does something better than Snort in one or two areas, but it would take quite some time to build the same breadth that Snort has. Plus, Snort has good community support behind it, and the rule format is a de facto standard. Ever notice that most of the commercial IDS products support Snort rules?
Point being that I don't think Snort is going away any time soon.
The book I helped on has been getting really good reviews on Amazon, and sales have been great. It was written by some great guys from the Snort community, notably Brian Caswell who runs snort.org and Jay Beale, who people will probably recognize from the Bastille project.
I have barely looked at it long enough to compile and example and run it, but it's free and the results look decent. It's designed as a library, though... so more programming involved than the asker probably wants.
I figured they probably would, given that they support the iPod for Windows.
My basic point was, though, that the various services need to just sell the songs for $.xx/song, with no monthly fees, etc... I think Apple does this, no?
Reason being that I want to see all the competition, full selection, search engines, price comparison sites, the whole ecology. Yes, it's a bit of a consumer-centric attitude, but hey, that's my role in the whole thing.:)
I also think (hope?) that that's what the market will support, too.
I just subscribed to a trial of Rhapsody from Best Buy. (Is this the same as Real Rhapsody? No name confusion there...) (another side note, it's scary how much info Best Bad had based on my phone number at the cash register, but that's a YRO topic...)
I've also been interested in iTunes, if they make a Windows version. This sounds interesting, too.
Problem is, the two Rhapsody's are subscription-based. Presumably, due to partnerships, etc... all these various services will have somewhat different catalogs. I can afford to buy as much as I can afford at $.99/pop or whatever the price is... but I can't afford $10/service/month to have access to all the different songs to buy them.
Hopefully they'll all figure out soon that the model should be $.xx/song with no membership fees. I think the only way this is going to work out is if consumers have unfettered access to buy all songs available regardless of who is offering them.
To be fair, the Rhapsody from Best Buy seems to let me just download as much as I can eat, and burn them to CD if I want. I haven't read through all the license stuff yet, but obviously practically speaking, I'm buying copies of the songs. At $10/mo, that's only 10 songs to break even (assuming $1/song is fair). That's attractive, if the song catalog is sufficient.
Hmm... that would take a fair amount of change to the BitTorrent protocol, which is currently designed around single-file downloads. (Correct to the extent that I understand it, mind you... I'm no master of BitTorrent.)
Yes, for web site usage, that's a good point. I may just want the JATO AIBO movie, and not the DOGCAM ones.
Well, maybe it's not as bad as I think. If the client end gets the directory section of the file early on... and if that directory covers what portions of the file belong to which files... (I think it would have to) then yes, the client can essentially request particular files, or at least the chunks that cover that file (you'd end up with a bit more... ala the clustering "waste" on a typical harddrive.)
Yes, it's possible that could happen on just the client side...
I used BT to get RH9. I had a good rate, it filled my downstream pipe. But that was when there was all the BT/RH9 hype, so I probably had more peers.
It does tend to speed up if you let it go for a while, not taking into account thinks like peers dropping off an such.
There are a few advantages to getting it from BT rather than FTP. Built-in download resume, and an extra layer of integrity check to name a couple. (Yes, I realize that under some circumstances you can resume FTP and HTTP downloads, but it's problematic at times and server-dependent.)
Oh, and I hear that Edison was torn about promoting the use of electricity, because it would enevitably cut into his wax cylinder business. Similar to the dilemma that Sony faces today.
That was one of the big reasons he was pissed at Tesla for introducing AC, because Edison felt he could do better DRM enforcement with DC.
Fortunatly, AC won out. Dodged a bullet on that one, whew.
Aha. I think I was mistaking a.torrent of a directory with a.zip of a directory that gets automatically unpacked. I'm guessing that the latter doesn't happen, just that I had a few.torrents of an entire directory in the past. Makes more sense that way, actually...
I hate it when it automatically unpacks all the files. I'd much rather have a.zip.
I've seen it used mostly when there are multiple files involved. For example, a 100 file picture set, or an album's worth of mp3s. I certainly wouldn't want to download each file individually.
You could do that right now, if the browser supported it. BitTorrent can already automatically ship around a.zip file and unpack it. It would be a matter of the browser properly interpreting the content. It's not quite as simple as one might think; you either have to make sure the content is all relative links, or hook the browser so that it doesn't know it's not getting the files from the original location. You'd probably want to do the latter, because otherwise you have to deal with interesting problems like security zones, dynamic web pages, missing files, etc...
Obviously, for a site like Slashdot, it would be useless, unless you're talking about for archive purposes. For someone's home web server that has almost all static, large contents (say, movies of them strapping a JATO to an AIBO or something), it would be perfect. Even if they had a little dynamic content like a guestbook, you just leave that page out, and the browser knows it has to go to the original site to get it/post to it.
All of which means that a person probably also has to intelligently pack the web site to prep it for BitTorrent use.
You've been asked on the mailing list a couple of times, and I haven't seen an answer.
What are your plans for the future direction of BitTorrent? Do you have any plans to design a protocol to enable trackers to coordinate? Any plans to enable BitTorrent to dynamically start sharing a file from an "upload" directory, based on distributed searches? In other words, are you interested in making BitTorrent a "full-service" P2P app in the style of Kazaa, etc...? Or are you happy with the functionality as it is?
Or are you perhaps waiting for the BitTorrent community to start chipping in some of the work, rather than leaving you to do all of it?:)
(Note: I'm not saying that it's somehow insufficient the way it is. I'm really just curious about what your plans are. One thing that keeps me from attempting to help with coding at all is that I have no idea where BitTorrent is headed, or if you even want any code contributions at this point.)
My understanding of C++ compilation is that all of the template and class information, including the object structure etc, is effectively lost when it is compiled.
Sure. That stuff doesn't exist at the machine-code level. An object turns into a bunch of function that all pass around a pointer to the same structure. Virtual functions turn into however many versions of the actual function that are requried.
The only way that functions could be determined is through laborious tracking... but then it won't be pretty either, with no function-names etc. About the only things where function-names would be recoverable would be the ones that have external entry-points.
Same as a C program. There are often clues that help you name the fucntions again. For example, authors have a habit of using the filename or function name as part of their assert messages. Those show up as simple strings in the binary. For functions with no clues, you name them based on what they are doing.
I'll second that. If the kind of security you're interested in learning is at the bit level, then one of the best things you can do is get a really, really good understanding on IP and related protocols.
Lemme get this straight: You agree that the author has shown how to decompile some C++ code, but then complain that he hasn't shown how to decompile C++ code?
No. I agree that the bit of code shown is C++. He didn't disassemble that bit. Even if he had, that's not the interesting bit about disassembling C++. All the interesting (PITA) stuff for disassembling C++ comes in when the programmer is using objects, member fucntions, constructors, destructores, etc...
The other issue here is the nature of the beast: There is nothing in C++ that can not be expressed in C.... it might be a little more confusing to read, but hey... at least he's not just converting the.exe to assembler =)
Not true. You can express any algorithm in either, they're both Turing complete. You can absolutely use some very different syntax in C++, that's the point if it existing.:)
And yes, I don't know if you're being sarcastic, but he did just bascially convert the.exe to assembler.
Slashdot Mirror
On some books, they do. When I "registered" my copy of this book, I was given a link to download a .PDF of it. Be aware that on some books (mostly older ones) the .pdf file(s) were contained in a Windows .exe.
If enough people care, I'll make them produce a HTML file or something.
In one of the stories, a book author beats the anonymous coward for first post on his book review story.
One of my books finally made it onto Slashdot. I wrote the "Worm Turns" chapter with Tim Mullen, acted as tech editor for the book, and wrote the overall outline. Pretty easy book to be a tech editor on. I'll be watching this thread if there are any questions I can answer.
No, goth.
Most round-robin DNS servers will randomize the order of the list of servers they reply with. So even stupid client apps that simply grab the first IP from the list will get some distribution.
Still, the point remains... RRDNS is a truly bad solution to distributed/redundant servers. When one of the servers dies, 1/n of the clients or 1/n of the time still try the down server, on average for half of the cache timeout.
Discussed in the Q thread:
l d=0&commentsort=0&tid=95&mode=thread&cid=60584 37
http://slashdot.org/comments.pl?sid=65711&thresho
There's no authentication mechanism. Slashdot could put up a tracker (and I'd love to have it) but it wouldn't be for subscribers only.
Someone could write an IDS that does something better than Snort in one or two areas, but it would take quite some time to build the same breadth that Snort has. Plus, Snort has good community support behind it, and the rule format is a de facto standard. Ever notice that most of the commercial IDS products support Snort rules?
Point being that I don't think Snort is going away any time soon.
I haven't read Koziol's book. The other books the reviewer mentions are:
Snort 2.0 Intrusion Detection
Which is the one I helped out with, and:
Snort 2.0 : The Complete Guide to Intrusion Detection
which isn't out yet. The Syngress book came out really well. Jeff, Dragos, and Jed are all really sharp guys, so I don't doubt their book will be good too, but it's not out quite yet.
The book I helped on has been getting really good reviews on Amazon, and sales have been great. It was written by some great guys from the Snort community, notably Brian Caswell who runs snort.org and Jay Beale, who people will probably recognize from the Bastille project.
Is that an invitation to plug my new book?
;)
Stealing The Network
After you get done reading all the excellent suggestions here written by really good authors, check mine out.
I don't think I saw this mentioned yet:
http://www.cdxlib.com/main.htm
I have barely looked at it long enough to compile and example and run it, but it's free and the results look decent. It's designed as a library, though... so more programming involved than the asker probably wants.
I figured they probably would, given that they support the iPod for Windows.
:)
My basic point was, though, that the various services need to just sell the songs for $.xx/song, with no monthly fees, etc... I think Apple does this, no?
Reason being that I want to see all the competition, full selection, search engines, price comparison sites, the whole ecology. Yes, it's a bit of a consumer-centric attitude, but hey, that's my role in the whole thing.
I also think (hope?) that that's what the market will support, too.
I'm seeing a problem.
I just subscribed to a trial of Rhapsody from Best Buy. (Is this the same as Real Rhapsody? No name confusion there...) (another side note, it's scary how much info Best Bad had based on my phone number at the cash register, but that's a YRO topic...)
I've also been interested in iTunes, if they make a Windows version. This sounds interesting, too.
Problem is, the two Rhapsody's are subscription-based. Presumably, due to partnerships, etc... all these various services will have somewhat different catalogs. I can afford to buy as much as I can afford at $.99/pop or whatever the price is... but I can't afford $10/service/month to have access to all the different songs to buy them.
Hopefully they'll all figure out soon that the model should be $.xx/song with no membership fees. I think the only way this is going to work out is if consumers have unfettered access to buy all songs available regardless of who is offering them.
To be fair, the Rhapsody from Best Buy seems to let me just download as much as I can eat, and burn them to CD if I want. I haven't read through all the license stuff yet, but obviously practically speaking, I'm buying copies of the songs. At $10/mo, that's only 10 songs to break even (assuming $1/song is fair). That's attractive, if the song catalog is sufficient.
Hmm... that would take a fair amount of change to the BitTorrent protocol, which is currently designed around single-file downloads. (Correct to the extent that I understand it, mind you... I'm no master of BitTorrent.)
Yes, for web site usage, that's a good point. I may just want the JATO AIBO movie, and not the DOGCAM ones.
Well, maybe it's not as bad as I think. If the client end gets the directory section of the file early on... and if that directory covers what portions of the file belong to which files... (I think it would have to) then yes, the client can essentially request particular files, or at least the chunks that cover that file (you'd end up with a bit more... ala the clustering "waste" on a typical harddrive.)
Yes, it's possible that could happen on just the client side...
I used BT to get RH9. I had a good rate, it filled my downstream pipe. But that was when there was all the BT/RH9 hype, so I probably had more peers.
It does tend to speed up if you let it go for a while, not taking into account thinks like peers dropping off an such.
There are a few advantages to getting it from BT rather than FTP. Built-in download resume, and an extra layer of integrity check to name a couple. (Yes, I realize that under some circumstances you can resume FTP and HTTP downloads, but it's problematic at times and server-dependent.)
Oh, and I hear that Edison was torn about promoting the use of electricity, because it would enevitably cut into his wax cylinder business. Similar to the dilemma that Sony faces today.
That was one of the big reasons he was pissed at Tesla for introducing AC, because Edison felt he could do better DRM enforcement with DC.
Fortunatly, AC won out. Dodged a bullet on that one, whew.
Heh.
"Bob Metcalfe, how do you feel about your invention being used primarily to transport unathorized copies of copyrighted works?"
BTW, thanks for correcting my misconception. Don't want to seem ungrateful, just because I disagree with your tastes on file packing. :)
Aha. I think I was mistaking a .torrent of a directory with a .zip of a directory that gets automatically unpacked. I'm guessing that the latter doesn't happen, just that I had a few .torrents of an entire directory in the past. Makes more sense that way, actually...
.zip.
I hate it when it automatically unpacks all the files. I'd much rather have a
I've seen it used mostly when there are multiple files involved. For example, a 100 file picture set, or an album's worth of mp3s. I certainly wouldn't want to download each file individually.
You could do that right now, if the browser supported it. BitTorrent can already automatically ship around a .zip file and unpack it. It would be a matter of the browser properly interpreting the content. It's not quite as simple as one might think; you either have to make sure the content is all relative links, or hook the browser so that it doesn't know it's not getting the files from the original location. You'd probably want to do the latter, because otherwise you have to deal with interesting problems like security zones, dynamic web pages, missing files, etc...
Obviously, for a site like Slashdot, it would be useless, unless you're talking about for archive purposes. For someone's home web server that has almost all static, large contents (say, movies of them strapping a JATO to an AIBO or something), it would be perfect. Even if they had a little dynamic content like a guestbook, you just leave that page out, and the browser knows it has to go to the original site to get it/post to it.
All of which means that a person probably also has to intelligently pack the web site to prep it for BitTorrent use.
You've been asked on the mailing list a couple of times, and I haven't seen an answer.
:)
What are your plans for the future direction of BitTorrent? Do you have any plans to design a protocol to enable trackers to coordinate? Any plans to enable BitTorrent to dynamically start sharing a file from an "upload" directory, based on distributed searches? In other words, are you interested in making BitTorrent a "full-service" P2P app in the style of Kazaa, etc...? Or are you happy with the functionality as it is?
Or are you perhaps waiting for the BitTorrent community to start chipping in some of the work, rather than leaving you to do all of it?
(Note: I'm not saying that it's somehow insufficient the way it is. I'm really just curious about what your plans are. One thing that keeps me from attempting to help with coding at all is that I have no idea where BitTorrent is headed, or if you even want any code contributions at this point.)
My understanding of C++ compilation is that all of the template and class information, including the object structure etc, is effectively lost when it is compiled.
Sure. That stuff doesn't exist at the machine-code level. An object turns into a bunch of function that all pass around a pointer to the same structure. Virtual functions turn into however many versions of the actual function that are requried.
The only way that functions could be determined is through laborious tracking... but then it won't be pretty either, with no function-names etc. About the only things where function-names would be recoverable would be the ones that have external entry-points.
Same as a C program. There are often clues that help you name the fucntions again. For example, authors have a habit of using the filename or function name as part of their assert messages. Those show up as simple strings in the binary. For functions with no clues, you name them based on what they are doing.
I'll second that. If the kind of security you're interested in learning is at the bit level, then one of the best things you can do is get a really, really good understanding on IP and related protocols.
Lemme get this straight: You agree that the author has shown how to decompile some C++ code, but then complain that he hasn't shown how to decompile C++ code?
.exe to assembler =)
:)
.exe to assembler.
No. I agree that the bit of code shown is C++. He didn't disassemble that bit. Even if he had, that's not the interesting bit about disassembling C++. All the interesting (PITA) stuff for disassembling C++ comes in when the programmer is using objects, member fucntions, constructors, destructores, etc...
The other issue here is the nature of the beast: There is nothing in C++ that can not be expressed in C.... it might be a little more confusing to read, but hey... at least he's not just converting the
Not true. You can express any algorithm in either, they're both Turing complete. You can absolutely use some very different syntax in C++, that's the point if it existing.
And yes, I don't know if you're being sarcastic, but he did just bascially convert the