If this is what I think, namely that IE doesn't close the connection after getting the response, the author may want to look into HTTP 1.1 and this thing called "persistent connections". If a browser expects to make multiple requests from a server, the browser is allowed to leave the connection open and make further requests over it.
You might want to look into HTTP 1.1 as well. In fact, so should Microsoft, because (if the article is accurate) they've apparently re-invented the wheel in square form.
Standard HTTP 1.1 keepalive still uses a regular, plain, vanilla TCP connection. No FIN packets until the connection actually is finished. It simply doesn't close the connection, allowing further requests on the same connection (because the connection is still open). The connection is closed - using the standard methods - when one side decides to close the connection (eg. after a timeout).
What is described in the article is a bastard half-closed connection, which is completely unnecessary unless your goal is gratuitous violation of the TCP spec.
If I read it before then I will probably not like the movie as much, how could it match my own imagination??
I wouldn't worry too much about that. I've read the books several times before watching the movie, and I would say that Peter Jackson et al did very well in bringing the book to life. Sure the movie has lots of things missing, and the occasional thing done not very well, but all in all a good job that even surpassed my imagination in some places.
I think the book touched me emotionally far more than the movie ever could. Tolkien's writing gives a supernatural splendor to the the most common things, contrasted against the looming darkness. The movie made me gawk at the amazing visuals.:) Book, then movie, and neither will take away from the other.
After reading the trilogy and watching all three movies (after they're released of course), go and read the Silmarillion. Read it more than once - the style of writing is very matter-of-fact, which makes for hard reading, but the second time is easier. It is truely epic, and if you manage to follow it you'll look at the story in the Lord of the Rings with a new perspective.
mySQL and Perl/PHP all run on windows, but ASP can connect to mySQL via ODBC. mySQL really is a snap if it meets your needs, and it runs beautifully.
I've been getting an ASP/MSSQL friend to take off the MS blinders. He's intrigued by PHP (it can do all his ASP-type stuff but multi-platform) but MySQL is a real turn-off to him, because he's used to "real database" features (subselects, stored procedures, etc). I've been telling him about PostgreSQL, and he sounds very interested, but getting it to run on Windows seems to be a real pain in the ass for a Windows guy. So he's been using MySQL on Windows and living with its limitations, which aren't that bad but could be avoided with PostgreSQL if he could get the darn thing to run.
DOM can be used to "play around" with HTML documents, after they have been loaded by the browser.
I seem to recall some web site using Javascript to expand and collapse discussion threads. Think it was kuro5hin. I'm not sure if it's using DOM to do that, but that is the sort of thing you can do with DOM.
Carmack has noted in the past that Nvidia's drivers are far better ("gold standard" were the words he used). But you have to keep in mind that as a 3D games guy, it is not in his best interests for a monopoly to emerge in the consumer 3D video card world. Competition keeps the new features coming, which gives Carmack new hardware to write new games for.
Right now postges sends a message to the application saying, this is locked retry transaction, this is just not up to real enterprise levels.
This can happen if you use the serializable transaction isolation level. It is not the default - you have to specify that isolation level for your transaction. And as far as I know, it is the only way to implement that isolation level while still allowing any kind of concurrency. I have never had to re-run a transaction with PostgreSQL, because I use the default transaction isolation level. You might want to read the relevant documentation.
I have seen the "re-run your transaction" message - using MS SQL. Yes, "real" databases do do this. Again, it depends on the transaction isolation level.
Most of your other points don't even apply to PostgreSQL. PostgreSQL has log-based transactions. It does not use one file per table (I can't remember how many files there were in my last PostgreSQL DB, but it wasn't many and certainly wasn't one-per-table). Others have commented on your other points (except XML) so I won't repeat them.
You might want to take another look at PostgreSQL. Don't assume that it is the same as MySQL (if that is where your criticisms are coming from).
I haven't tried MySQL so I really can't comment on it.
I put my 3.5" floppy drive on my mouse cable to keep the weight of the cable from pulling my mouse off my mousepad. Also, the reduced force on my mouse gives me the decisive edge in CS.
There is only one technology that can end the tyrannical reign of the floppy drive...
Wasn't it do with the lack of floating point unit on the 386DX? The supplementary maths coprocessor was integrated in to the main CPU in later generations of the Intel x86 line (either 486 or Pentiums).
Right. The 386 and 486SX did not have integrated FPUs. The 486DX and up did, and in the Pentium it was dramatically improved (which is why Quake required a Pentium).
The lack of FPU was the only difference between the 486 SX and DX. Reportedly, on early versions of the SX the FPU was actually present but disabled.
Telnet wins hands down. Just use a difficult password, and change it frequently.
Except telnet does zero encryption. It is a trivial matter to sniff passwords from an unencrypted link, and inserting data is not much harder. Changing passwords frequently is kind of pointless if you are setting your new password over an insecure link.
One-time passwords are better, but they are still vulnerable to TCP insertion attacks.
Yes, these things have been exploited in the wild. SSH exists for a reason.
If security problems in SSH itself worry you (and they should), privilidge-seperated ssh is the answer. By seperating the privilidged code from the code that talks to the client and defining a good interface between them, it limits the amount of stuff that can go wrong and the quantity of code that needs to be audited.
Re:Unworkable as Designed
on
DRM Helmet
·
· Score: 2
It should remain fogged and silenced unless it can verify that all photons and sound waves within visible and audible range have been licensed by the user.
Seriously, what they could do is have a decryption program in the helmet, and transmit the broadcast encrypted. Anyone not wearing the helmet with the appropriate decryption licence would only see static.
Fast forward ten years, and instead of a helmet it could be implants on the optic nerve.
I'm not kidding. All indications are that they want end-to-end control of "their" content. Well, one of those ends is your brain.
Design Patterns don't speed up development or execution speed of a system. They are tool used to describe a solution to a well known problem. Using a pattern "correctly" will only provide effecency in describing a problem/solution to another person versed in tht pattern.
Design patterns aren't just a dictionary to enhance your vocabulary. They are also tried and tested solutions to common problems.
If you already know that adding axles with round objects on the ends is a good way to make something mobile, knowing that the round thing is called a "wheel" does nothing more than allow you to describe with one word your thing's means of locomotion. On the other hand, if you're trying to make something mobile and have no idea how to do it, you will greatly speed up your development time and the efficiency of the end product by reading up on those "wheel" things instead of trying to invent your own solution.
Now that search engines are fast and cheap, paid keyword systems aren't needed. It's an idea that was overtaken by better technology.
Maybe, maybe not. Microsoft's motivations for killing RealNames will be revealed when they either create their own version of the technology - validating Teare's statements - or not.
Interestingly, I've seen(heard?:P) many people who claim to be able to do this fail in single-blind tests.
I did my tests by forming a single command that would play either the original.wav rip or the encoded MP3, with equal probability, based on a read from/dev/random. Then I put my ears to the cheap speaker, closed my eyes, and hit enter. Once I had made my determination I looked at the screen to see what was played.
At first I got it wrong, every time. I thought the 128k sounded better than the.wav. It sounded slightly louder, which to my non-audiophile ears sounded more crisp. In any event, it proved to me that there was a discernable difference.:) I concluded that the loundness was from noise introduced by the lossy encoding, and from there I was able to consistently and correctly tell 128k from the original.
At 192k I could not tell the difference. At least, not on my cheap speakers. I now have a non-sucky pair of headphones but have not yet re-run those tests.
Writing OSS is like playing solitaire, in that it is fun (you're solving little puzzles which are non-trivial, but not impossible), but when you've done it, you end up with a program that does what you like, and you can give it to people and they'll be impressed.
If only the OSS community could harness all those man-hours spent on solitaire... Holy shit.
We now know the true means Microsoft is using to counter Linux. It's not MS Office, or proprietary file formats, or embrace-and-extend, or FUD... It's solitaire!
Quick, somebody call the justice department, MS is bundling Solitaire with the OS! Alas, I fear the folks at the DoJ will not be able to intervene; they're too busy playing Solitaire.
Damn you Bill Gates!!
256 Kbps MP3 can be CD quality, not 128 Kbps.
on
Ogg Vorbis RC3 Released
·
· Score: 3, Informative
shows that only the very best listeners only sometimes could tell 128 kbps MP3 (FgH encoder, not Xing, Blade, etc) apart from the original material.
It's not 128 Kbps MP3, it's 256 Kbps MP3. I can consistently tell 128 Kbps MP3 from the original rip, even on cheap $15 multimedia speakers (although I have to hold them right up to my ears). And I'm no audiophile.
Go to http://www.r3mix.net/ and click on the "Quality" link for some links to the MP3 tests.
I found a "CFS", but the version was just for kernel 2.2.x. I didn't find a 2.4 port.
If it's the CFS originally by Matt Blaze, then it should work fine without any kernel support other than NFS client. CFS just runs as a user-mode NFS server. If you can mount an NFS filesystem, you can mount a CFS file system. CFS even works on non-linux systems, such as FreeBSD.
I mean none of the major exploits lately (code red, nimda, etc.) have used unpublished exploits.
That's actually an argument against full-disclosure. The worms are created with published exploits, so stop publishing the exploits and maybe the worms will go away.
Of course, that doesn't address the roots of the problem. There are far too many people out there who think security is only a matter of passwords and firewalls.
I didn't mean to imply that postgresql is hard to setup - I meant that I found it difficult to install, when I was making the database decision a couple of years ago. I spent a morning trying to get it to work, and failed - which reflects much more on my (lack of) knowledge of PostgreSQL than the product itself.
I had zero RDBMS admin experience, but managed to compile PostgreSQL 7.1.3 from source and install it. It was dead simple. Maybe things have improved?
One thing I did notice though, is that by default it doesn't accept connections from the outside world. I think this is a good default, but getting it to accept connections was harder than the rest of the setup. The PostgreSQL web site has a nice online book that explained everything; I would've been lost without it.
My hassles have all come _after_ PostgreSQL is set up. Mainly the difficulty in altering live tables. You can add columns with whatever constraints you like, but I have yet to figure out how to add foreign key constraints to existing columns. At least foreign key constraints are supported at all.:) But even simple things like removing a column are a pain in the but. The recommended way is "select into" to recreate the table with only the desired columns. I don't know if the new table picks up the constraints from the old table though.
I've also had problems performing table modifications when a daemon process held a connection to the database. The process had completed its queries and was sleeping, but I could not make table alterations until I killed it. Not a biggie... I've since modified the process to completely disconnect before sleeping.
PostgreSQL's locking seems to be better than MS SQL (version 7 I think it was; the only other RDBMS I have any experience with). A couple of times I've had to do a table-wide select in one db handle and a bunch of single-row updates in another. PostgreSQL handles this just fine. MS SQL tended to run for a while then deadlock, presumably when the row being updated was on the same page as an upcoming row in the select statement. MS SQL 2000 may be better but I haven't tried it.
Imagine a large room full of office workers. Now, imagine the same room with every worker talking to his wordprocessor or spreadsheet, trying to make him or herself heard over all the others, getting irritated and fatigued because of the constant noise of everybody else talking to their computers.
Yeah, but imagine a typical telemarketing firm. Dozens, even hundreds of cubicals. Everyone talking all at the same time. No problems communicating, because the microphone and speaker are mounted on the worker's head.
But what happens when a person gets incorrectly classified?
I know someone (in Canada) who has a "V" associated with their record in the RCMP database. "V" is for "Violent". Every time he gets pulled over he is subjected to a complete search of his car, no exceptions. But he has no idea of how he got this "V" associated with his record, or what to do about it. As far as I know, he does NOT have a criminal record (he has no problem crossing the border which is a pretty good indication).
I imagine some ethnic groups are treated similarly due to "racial profiling" (which is just a euphemism if you ask me). So I guess a system like what you have proposed, though probably more complex, is already in place. From what little I've seen I can't say that I like the results.
I've observed something over the years, and that is the command line is hated beyond measure by mainstream trade press and MS fans. For MS, removal of DOS was a good thing because it removed the command line, which is evil (DOS sucks,of course, but not because of its command line interface).
I disagree here. A significant amount of DOS's suckage comes from its primative command line interface. "Back in the day" most people didn't care about multitasking, but the annoying C:\> prompt was dreaded by most users.
Consider:
Command-line editing sucked. The arrow keys did not work like in a real editor. All you could do was backspace to your typo, fix it, then re-type everything you missed.
Limited command history. Press F3 to bring back the previous line, then use backspace as described above. Alternatively, there is a way to bring back the line one character at a time, then you can type onwards, or press the Insert key exactly the correct number of times to match the number of new characters you want to insert before bringing back the remainder of the line.
Doskey fixed the above two issues, but on most systems it was not loaded (probably due to ignorance). It also came around about the time of Windows 3, by which time hatred of the command line was firmly entrenched and many people were using menu-based shells to escape the torment.
Filename globbing is handled by the command, not the shell. And most commands were not very smart. In unix shells, you can do "cp *.foo *.bar/some/directory" because the cp command just wants a list of files with a destination as the last argument. The DOS copy command, on the other hand, only accepts two arguments. So you have to go "copy *.foo \some\directory" then "copy *.bar \some\directory". The more complex globbing and substitution commands availble in unix shells were totally absent in command.com.
Scripting sucked. All you could really do was concatenate a few static commands into a.bat file. Looping and conditional operations existed, but making them do anything useful required ugly/clever hacks that were beyond the ability of the average user and even most technical users.
Given those issues, and the fact that most PC users at the time were running MS-DOS and forced to endure the torment I have described, is it any wonder that CLIs are considered "primative" by the majority of the population?
Add to this the Mac. Most offices were PC based due to compatability requirements and investments in PC software, but many people could stop by schools or computer shops and have brief experiences with Macintoshes and be wowed by the pretty GUI and how easy it was to use compared to DOS. Those who couldn't, could hear stories from those who could. Is it any wonder the majority of the population considers GUIs to be the best way to interact with a computer?
So it is my theory that the 100% GUI / 0% CLI attitude, rather than a more balanced "right tool for the job" approach, is the consequence of historical Mac envy.
try/dev/hda1 for starters. what the fuck is that supposed to mean? damn. (i know its like the second hard drive or something, but still)
What are you doing that you need to use the/dev/hda1 device name? In my experience, the install sets up your/etc/fstab for you and you don't need to worry about the "/dev/hda1" thing (or even the "/etc/fstab" thing).
Slashdot Mirror
That depends on whether they wrote Windows in C/C++...
...or in VB. :p
You might want to look into HTTP 1.1 as well. In fact, so should Microsoft, because (if the article is accurate) they've apparently re-invented the wheel in square form.
Standard HTTP 1.1 keepalive still uses a regular, plain, vanilla TCP connection. No FIN packets until the connection actually is finished. It simply doesn't close the connection, allowing further requests on the same connection (because the connection is still open). The connection is closed - using the standard methods - when one side decides to close the connection (eg. after a timeout).
What is described in the article is a bastard half-closed connection, which is completely unnecessary unless your goal is gratuitous violation of the TCP spec.
I wouldn't worry too much about that. I've read the books several times before watching the movie, and I would say that Peter Jackson et al did very well in bringing the book to life. Sure the movie has lots of things missing, and the occasional thing done not very well, but all in all a good job that even surpassed my imagination in some places.
I think the book touched me emotionally far more than the movie ever could. Tolkien's writing gives a supernatural splendor to the the most common things, contrasted against the looming darkness. The movie made me gawk at the amazing visuals. :) Book, then movie, and neither will take away from the other.
After reading the trilogy and watching all three movies (after they're released of course), go and read the Silmarillion. Read it more than once - the style of writing is very matter-of-fact, which makes for hard reading, but the second time is easier. It is truely epic, and if you manage to follow it you'll look at the story in the Lord of the Rings with a new perspective.
I've been getting an ASP/MSSQL friend to take off the MS blinders. He's intrigued by PHP (it can do all his ASP-type stuff but multi-platform) but MySQL is a real turn-off to him, because he's used to "real database" features (subselects, stored procedures, etc). I've been telling him about PostgreSQL, and he sounds very interested, but getting it to run on Windows seems to be a real pain in the ass for a Windows guy. So he's been using MySQL on Windows and living with its limitations, which aren't that bad but could be avoided with PostgreSQL if he could get the darn thing to run.
Client:
GET / HTTP/1.1
Host: densestserver.sgi.com
Server:
Um... What's that?
Client:
Do you not understand HTTP 1.1?
Server:
Of course I do...?
Client:
Well then,
GET / HTTP/1.1
Host: densestserver.sgi.com
Server:
Okay... Would you like that biggie-sized?
Client:
wtf?
Server:
Oh, you want a web page. Okay, I get it now.
Client:
Great. Now send it, please.
Server:
Send what?
Client:
*sigh* Nevermind.
User:
Huh? What does "500 Server Error: Server too dense" mean?
DOM can be used to "play around" with HTML documents, after they have been loaded by the browser.
I seem to recall some web site using Javascript to expand and collapse discussion threads. Think it was kuro5hin. I'm not sure if it's using DOM to do that, but that is the sort of thing you can do with DOM.
Carmack has noted in the past that Nvidia's drivers are far better ("gold standard" were the words he used). But you have to keep in mind that as a 3D games guy, it is not in his best interests for a monopoly to emerge in the consumer 3D video card world. Competition keeps the new features coming, which gives Carmack new hardware to write new games for.
This can happen if you use the serializable transaction isolation level. It is not the default - you have to specify that isolation level for your transaction. And as far as I know, it is the only way to implement that isolation level while still allowing any kind of concurrency. I have never had to re-run a transaction with PostgreSQL, because I use the default transaction isolation level. You might want to read the relevant documentation.
I have seen the "re-run your transaction" message - using MS SQL. Yes, "real" databases do do this. Again, it depends on the transaction isolation level.
Most of your other points don't even apply to PostgreSQL. PostgreSQL has log-based transactions. It does not use one file per table (I can't remember how many files there were in my last PostgreSQL DB, but it wasn't many and certainly wasn't one-per-table). Others have commented on your other points (except XML) so I won't repeat them.
You might want to take another look at PostgreSQL. Don't assume that it is the same as MySQL (if that is where your criticisms are coming from).
I haven't tried MySQL so I really can't comment on it.
There is only one technology that can end the tyrannical reign of the floppy drive...
Trackballs!
Right. The 386 and 486SX did not have integrated FPUs. The 486DX and up did, and in the Pentium it was dramatically improved (which is why Quake required a Pentium).
The lack of FPU was the only difference between the 486 SX and DX. Reportedly, on early versions of the SX the FPU was actually present but disabled.
Except telnet does zero encryption. It is a trivial matter to sniff passwords from an unencrypted link, and inserting data is not much harder. Changing passwords frequently is kind of pointless if you are setting your new password over an insecure link.
One-time passwords are better, but they are still vulnerable to TCP insertion attacks.
Yes, these things have been exploited in the wild. SSH exists for a reason.
If security problems in SSH itself worry you (and they should), privilidge-seperated ssh is the answer. By seperating the privilidged code from the code that talks to the client and defining a good interface between them, it limits the amount of stuff that can go wrong and the quantity of code that needs to be audited.
Seriously, what they could do is have a decryption program in the helmet, and transmit the broadcast encrypted. Anyone not wearing the helmet with the appropriate decryption licence would only see static.
Fast forward ten years, and instead of a helmet it could be implants on the optic nerve.
I'm not kidding. All indications are that they want end-to-end control of "their" content. Well, one of those ends is your brain.
Do you consider an Aegis cruiser "something important"? That's a bit dated now, of course. Hopefully they would've learned their lesson back then. (Yeah, right.)
Design patterns aren't just a dictionary to enhance your vocabulary. They are also tried and tested solutions to common problems.
If you already know that adding axles with round objects on the ends is a good way to make something mobile, knowing that the round thing is called a "wheel" does nothing more than allow you to describe with one word your thing's means of locomotion. On the other hand, if you're trying to make something mobile and have no idea how to do it, you will greatly speed up your development time and the efficiency of the end product by reading up on those "wheel" things instead of trying to invent your own solution.
Maybe, maybe not. Microsoft's motivations for killing RealNames will be revealed when they either create their own version of the technology - validating Teare's statements - or not.
I did my tests by forming a single command that would play either the original .wav rip or the encoded MP3, with equal probability, based on a read from /dev/random. Then I put my ears to the cheap speaker, closed my eyes, and hit enter. Once I had made my determination I looked at the screen to see what was played.
At first I got it wrong, every time. I thought the 128k sounded better than the .wav. It sounded slightly louder, which to my non-audiophile ears sounded more crisp. In any event, it proved to me that there was a discernable difference. :) I concluded that the loundness was from noise introduced by the lossy encoding, and from there I was able to consistently and correctly tell 128k from the original.
At 192k I could not tell the difference. At least, not on my cheap speakers. I now have a non-sucky pair of headphones but have not yet re-run those tests.
If only the OSS community could harness all those man-hours spent on solitaire... Holy shit.
We now know the true means Microsoft is using to counter Linux. It's not MS Office, or proprietary file formats, or embrace-and-extend, or FUD... It's solitaire!
Quick, somebody call the justice department, MS is bundling Solitaire with the OS! Alas, I fear the folks at the DoJ will not be able to intervene; they're too busy playing Solitaire.
Damn you Bill Gates!!
It's not 128 Kbps MP3, it's 256 Kbps MP3. I can consistently tell 128 Kbps MP3 from the original rip, even on cheap $15 multimedia speakers (although I have to hold them right up to my ears). And I'm no audiophile.
Go to http://www.r3mix.net/ and click on the "Quality" link for some links to the MP3 tests.
If it's the CFS originally by Matt Blaze, then it should work fine without any kernel support other than NFS client. CFS just runs as a user-mode NFS server. If you can mount an NFS filesystem, you can mount a CFS file system. CFS even works on non-linux systems, such as FreeBSD.
That's actually an argument against full-disclosure. The worms are created with published exploits, so stop publishing the exploits and maybe the worms will go away.
Of course, that doesn't address the roots of the problem. There are far too many people out there who think security is only a matter of passwords and firewalls.
I had zero RDBMS admin experience, but managed to compile PostgreSQL 7.1.3 from source and install it. It was dead simple. Maybe things have improved?
One thing I did notice though, is that by default it doesn't accept connections from the outside world. I think this is a good default, but getting it to accept connections was harder than the rest of the setup. The PostgreSQL web site has a nice online book that explained everything; I would've been lost without it.
My hassles have all come _after_ PostgreSQL is set up. Mainly the difficulty in altering live tables. You can add columns with whatever constraints you like, but I have yet to figure out how to add foreign key constraints to existing columns. At least foreign key constraints are supported at all. :) But even simple things like removing a column are a pain in the but. The recommended way is "select into" to recreate the table with only the desired columns. I don't know if the new table picks up the constraints from the old table though.
I've also had problems performing table modifications when a daemon process held a connection to the database. The process had completed its queries and was sleeping, but I could not make table alterations until I killed it. Not a biggie... I've since modified the process to completely disconnect before sleeping.
PostgreSQL's locking seems to be better than MS SQL (version 7 I think it was; the only other RDBMS I have any experience with). A couple of times I've had to do a table-wide select in one db handle and a bunch of single-row updates in another. PostgreSQL handles this just fine. MS SQL tended to run for a while then deadlock, presumably when the row being updated was on the same page as an upcoming row in the select statement. MS SQL 2000 may be better but I haven't tried it.
Yeah, but imagine a typical telemarketing firm. Dozens, even hundreds of cubicals. Everyone talking all at the same time. No problems communicating, because the microphone and speaker are mounted on the worker's head.
It's a solved problem.
I know someone (in Canada) who has a "V" associated with their record in the RCMP database. "V" is for "Violent". Every time he gets pulled over he is subjected to a complete search of his car, no exceptions. But he has no idea of how he got this "V" associated with his record, or what to do about it. As far as I know, he does NOT have a criminal record (he has no problem crossing the border which is a pretty good indication).
I imagine some ethnic groups are treated similarly due to "racial profiling" (which is just a euphemism if you ask me). So I guess a system like what you have proposed, though probably more complex, is already in place. From what little I've seen I can't say that I like the results.
I disagree here. A significant amount of DOS's suckage comes from its primative command line interface. "Back in the day" most people didn't care about multitasking, but the annoying C:\> prompt was dreaded by most users.
Consider:
Given those issues, and the fact that most PC users at the time were running MS-DOS and forced to endure the torment I have described, is it any wonder that CLIs are considered "primative" by the majority of the population?
Add to this the Mac. Most offices were PC based due to compatability requirements and investments in PC software, but many people could stop by schools or computer shops and have brief experiences with Macintoshes and be wowed by the pretty GUI and how easy it was to use compared to DOS. Those who couldn't, could hear stories from those who could. Is it any wonder the majority of the population considers GUIs to be the best way to interact with a computer?
So it is my theory that the 100% GUI / 0% CLI attitude, rather than a more balanced "right tool for the job" approach, is the consequence of historical Mac envy.
But it's just a theory.
What are you doing that you need to use the