You mean a.out, not ELF. This change was important because it allowed shared libraries to just work; a.out's shared library implementation was horrible. The downside was more overhead; I think shared libraries didn't have to be position independant before ELF, so they could be slightly more efficient.
COFF is a third binary format used by older Unices and (IIRC) NT. It hasn't been widely used with Linux.
That was a long time ago, though. More recently, the change from libc5 to glibc (libc6) caused similar problems.
Yeah, I wish they'd just get rid of the whole allocator concept entirely. I've used templates fairly extensively, and have *never* seen any use of allocators other than the default. My understanding is that the whole allocator scheme was invented to overcome limitations back when we had 16-bit compilers and "far" pointers. All they seem to do is clutter up type names and obfuscate error messages.
Are there any useful applications of allocators, that can't be done better by overloading new?
In terms of preciseness, English is a lightweight. Try conjugating a verb in almost any other language and you'll find it encodes much more information, so much so you can often leave off the pronoun (it becomes redundant). Plus English completely lacks noun cases, which encodes yet more information, making word order redundant (e.g. "John hit the men" vs "The men hit John" - the meaning relies on word order in English).
This is good advice, but keep in mind there are some bugs for which it is really hard or impossible to do this. Take, for example, a bug which cannot be reproduced easily. Unfortunately, these are usually not that rare on any largish project.
Sometimes, you just need a lot a raw data ("I got this problem doing this, with this config") to track them down. No, they aren't good bug reports, but they are necessary to find some bugs.
What about the START button in the bottom left - and top left on Macs?
Bad example. On Windows (up to 2K, anyways), the start button is slightly off the corner. If you whip the mouse down to the lower right until it hits the edge, you'll actually be past it! Those extra pixels between the edge of the screen and the Start button just sit there being wasted. Gnome gets this right, and I suspect KDE and the Mac do a better job, too.
Spyglass owned Mosaic, the original NCSA browser, which they licensed to MS. Netscape hired away the primary developers of Mosaic, Marc Andreesen and Eric Bina, who were pissed off at NSCA for not giving them any recognition for Mosaic. Netscape (confusing called Mosaic-Netscape, at the start) redeveloped their browser from scratch.
That didn't stop Spyglass from threatening legal action, which resulted in the company being renamed Netscape from Mosaic Communications. Their original domain name, www.mcom.com still works to this day.
So in short, Netscape was never a Spyglass customer.
Actually they knew about Enigma right from the start of the war. The Enigma wasn't much of a secret: a commercial version was available to civilians long before the Nazi's adopted it. Plus the Poles had been breaking Enigma for a few years before WWII, and they turned over all their intelligence to the Brits shortly before Germany attacked. The Poles figured out the details of the military Enigma through good old-fashioned espionage.
And they didn't break the codes by brute force. They exploited both misuse of the Enigma and flaws in the machine's design. If they had to brute force it, the war would've been long over by the time they were done.
The Code Book, by Simon Singh has more details on Enigma and the code breakers at Bletchley Park.
The point is this: you are much better off getting the information from another source rather than analyzing the data. And, your best chance of cracking a code lies in human error: flawed use of crypto.
While parrot sounds interesting, I'd like to it compared to other bytecode interpreters like the JVM and.NET's CLR. How similar/different are they? Is parrot more suited to scripting tasks? Does it have a robust security model like Java/.NET? Does it have any neat features that the others are missing?
A checksum is used. The way it works is that a simple rolling checksum is computed on the fly. The checksum is easy to compute but isn't 100% accurate. So a strong message digest algorithm (MD4, not MD5, I think) is used to ensure everything came out consistant.
The message digest is necessary, simply to back up the rolling checksum. After all, if rsync was unreliable at exactly duplicating files it would be useless.
I'm guessing icc beats the others mainly on instruction scheduling. In other words, Intel has put a lot of effort into generating code that is parallelizable by spreading out close instructions to different pipelines.
Since AMDs chips are pipelined, they are likely to benefit even if the pipelines aren't exactly the same.
Apple is a monopolist? What do they have a monopoly on? Translucent plastic cases? Selling a system with a closed architecture is different than being a monopolist. A monopoly exists when you control all of (or almost all of) a particular market, not just a product.
Yeah, I built some of the software for those internet phones. You can see pictures of them here. They've got them in the Toronto, Vancouver, and Calgary airports now, too. The usage started out slow, but it is slowly growing; the business case is actually pretty good if its a good location. For the curious, the phones run an embedded Linux kernel with a bunch of custom software.
Wow, that is quite surprising -- so much so that I tried it myself. I reproduced this test on Linux with similar results.
I've tried to figure it out: first I thought maybe the Java compiler did some heavy optimization, but inspecting the bytecode with javap showed it was a straight forward translation of the source.
My other thought is this particular example plays right into the strength of Java's JIT. Since the same code is run over and over, it can be compiled once at runtime. The code is very short, so the just-in-time compilation doesn't take much time. And it can fully exploit Java's key performance advantage: the ability to incorporate runtime profiling information into the optimization process.
Don't get me wrong, this is extremely impressive. But it *is* a contrived example that shows off Java in its best light.
The mozilla mail client is getting a Bayesian mail filter, too. See http://bugzilla.mozilla.org/show_bug.cgi?id=163188 . Unfortunately, it probably won't show up until after version 1.2 is released.
Calm down. You said you were trying to add RTSP/RTP support to wget. I just wanted to ensure you knew about the relevent documentation and remind other readers that RTSP/RTP is an open protocol. You seemed to want to open a discussion on RTSP/RTP and I thought that might be helpful. No need to get all defensive, I didn't suggest you were clueless in your attempt.
Their suggestion to use sudo is good advice for *any* Unix, not just MacOS X. Since I started to use it, I've reduced the time I spend as root by 80%, which probably reduces my chances of making a really ugly mistake by the same amount. I have to shake my head when I see people who do all their work in Unix as root -- it is only a matter of time before you make some fatal typo.
On the other hand, their advice to use tcsh/bash as a sudo command is poorly thought out. How is that any better than su? Better to use sudo with a few simple commands and scripts that need root for 80% of cases, and use su for the rest.
Ever look at the linux kernel code? Besides, who ever pronounces them out loud anyway?
Yes, it's an example of good code. The variable names are meaningful but short and to the point.
C'mon man, we're talking about programmers here. Who the fux comments as much as they should, if at all?
Ok, programmers are lazy. What happens when a boolean needs to be changed to an enumerated type? Or an int to a struct or class? Is the programmer going to change the variable name in each instance?
The point is, the type information is already provided in the source. Repeating it with redundant and confusing abbreviations throughout the code just clutters the code.
It was a technique for making types easy to identify in a language
Yes, but the value of having the type information accessible in the variable name has to be weighed against the confusion and clutter that adding that information causes.
The names it creates are hard to read and remember, impossible to pronounce. It doesn't scale very well beyond a few native types, like BASIC and perl -- how many meaningful prefixes is a programmer supposed to remember? How many characters of a variable name are you willing to devote to type information? And finally, the type of a variable is usually obvious from it's context, and it can be commented where it isn't.
I've never met anyone who has asserted that Hungarian notation is worth using. It is ugly and confusing, plain and simple.
This is a good thing. Maybe the big chip vendors will stop focusing on Mhz numbers and start making smaller, cooler and more efficient chips.
If I have the choice between a giant-ass chip with multiple fans that takes 100+ Watts vs. a slightly slower, fanless, power sipping version, I'd definately take the latter. I'm definately keeping my eye on the Via C3...
France has Minitel, the teletext system you are thinking of. Minitel held on for as long as it did, despite its inferiority to the internet because of the strong business model it provided. A service provider could provide a service, and the phone company that administered the system charged a usage fee to the user directly on their phone bill. A slice of that went directly back to the provider.
No need to fuss with credit cards, PayPal, etc. or even the backend billing system; it all was handled automatically. Lots of useful services sprang up and took advantage of this infrastructure, and were slow to give it up for the great unknown of the internet. Unfortunately, the system wasn't as great for the users: every service was metered, and the speed was deliberately held back because the providers wanted to keep the users online as long as possible.
Some of these devices will draw power even when they are switched off. For example, TV's will draw enough power to keep the CRT tube warm (which is why TV's don't need to "warm up" like they used to) and accept signals from the remote control. The only way to ensure it doesn't draw any power is to unplug it.
Slashdot Mirror
You mean a.out, not ELF. This change was important because it allowed shared libraries to just work; a.out's shared library implementation was horrible. The downside was more overhead; I think shared libraries didn't have to be position independant before ELF, so they could be slightly more efficient.
COFF is a third binary format used by older Unices and (IIRC) NT. It hasn't been widely used with Linux.
That was a long time ago, though. More recently, the change from libc5 to glibc (libc6) caused similar problems.
Yeah, I wish they'd just get rid of the whole allocator concept entirely. I've used templates fairly extensively, and have *never* seen any use of allocators other than the default. My understanding is that the whole allocator scheme was invented to overcome limitations back when we had 16-bit compilers and "far" pointers. All they seem to do is clutter up type names and obfuscate error messages.
Are there any useful applications of allocators, that can't be done better by overloading new?
In terms of preciseness, English is a lightweight. Try conjugating a verb in almost any other language and you'll find it encodes much more information, so much so you can often leave off the pronoun (it becomes redundant). Plus English completely lacks noun cases, which encodes yet more information, making word order redundant (e.g. "John hit the men" vs "The men hit John" - the meaning relies on word order in English).
This is good advice, but keep in mind there are some bugs for which it is really hard or impossible to do this. Take, for example, a bug which cannot be reproduced easily. Unfortunately, these are usually not that rare on any largish project.
Sometimes, you just need a lot a raw data ("I got this problem doing this, with this config") to track them down. No, they aren't good bug reports, but they are necessary to find some bugs.
What about the START button in the bottom left - and top left on Macs?
Bad example. On Windows (up to 2K, anyways), the start button is slightly off the corner. If you whip the mouse down to the lower right until it hits the edge, you'll actually be past it! Those extra pixels between the edge of the screen and the Start button just sit there being wasted. Gnome gets this right, and I suspect KDE and the Mac do a better job, too.
Umm, take your pick from XFS from SGI (Irix) or JFS from IBM (AIX). Both are now in the Linux kernel, both work well.
Spyglass owned Mosaic, the original NCSA browser, which they licensed to MS. Netscape hired away the primary developers of Mosaic, Marc Andreesen and Eric Bina, who were pissed off at NSCA for not giving them any recognition for Mosaic. Netscape (confusing called Mosaic-Netscape, at the start) redeveloped their browser from scratch.
That didn't stop Spyglass from threatening legal action, which resulted in the company being renamed Netscape from Mosaic Communications. Their original domain name, www.mcom.com still works to this day.
So in short, Netscape was never a Spyglass customer.
Actually they knew about Enigma right from the start of the war. The Enigma wasn't much of a secret: a commercial version was available to civilians long before the Nazi's adopted it. Plus the Poles had been breaking Enigma for a few years before WWII, and they turned over all their intelligence to the Brits shortly before Germany attacked. The Poles figured out the details of the military Enigma through good old-fashioned espionage.
And they didn't break the codes by brute force. They exploited both misuse of the Enigma and flaws in the machine's design. If they had to brute force it, the war would've been long over by the time they were done.
The Code Book, by Simon Singh has more details on Enigma and the code breakers at Bletchley Park.
The point is this: you are much better off getting the information from another source rather than analyzing the data. And, your best chance of cracking a code lies in human error: flawed use of crypto.
While parrot sounds interesting, I'd like to it compared to other bytecode interpreters like the JVM and .NET's CLR. How similar/different are they? Is parrot more suited to scripting tasks? Does it have a robust security model like Java/.NET? Does it have any neat features that the others are missing?
A checksum is used. The way it works is that a simple rolling checksum is computed on the fly. The checksum is easy to compute but isn't 100% accurate. So a strong message digest algorithm (MD4, not MD5, I think) is used to ensure everything came out consistant.
The message digest is necessary, simply to back up the rolling checksum. After all, if rsync was unreliable at exactly duplicating files it would be useless.
Actually, rsync uses (or used, perhaps it has changed) MD4, not MD5. Regardless, the cost of MD4 is comparable to MD5.
I'm guessing icc beats the others mainly on instruction scheduling. In other words, Intel has put a lot of effort into generating code that is parallelizable by spreading out close instructions to different pipelines.
Since AMDs chips are pipelined, they are likely to benefit even if the pipelines aren't exactly the same.
Apple is a monopolist? What do they have a monopoly on? Translucent plastic cases? Selling a system with a closed architecture is different than being a monopolist. A monopoly exists when you control all of (or almost all of) a particular market, not just a product.
Advancing the plot is nice, as long as the game doesn't force you into a linear, predermined path. Open-endedness makes games so much more immersive.
You forgot to include Ultima 7, clearly a candidate for the best ever. Or any of the Ultimas, except maybe 8 & 9.
Yeah, I built some of the software for those internet phones. You can see pictures of them here. They've got them in the Toronto, Vancouver, and Calgary airports now, too. The usage started out slow, but it is slowly growing; the business case is actually pretty good if its a good location. For the curious, the phones run an embedded Linux kernel with a bunch of custom software.
Wow, that is quite surprising -- so much so that I tried it myself. I reproduced this test on Linux with similar results.
I've tried to figure it out: first I thought maybe the Java compiler did some heavy optimization, but inspecting the bytecode with javap showed it was a straight forward translation of the source.
My other thought is this particular example plays right into the strength of Java's JIT. Since the same code is run over and over, it can be compiled once at runtime. The code is very short, so the just-in-time compilation doesn't take much time. And it can fully exploit Java's key performance advantage: the ability to incorporate runtime profiling information into the optimization process.
Don't get me wrong, this is extremely impressive. But it *is* a contrived example that shows off Java in its best light.
The mozilla mail client is getting a Bayesian mail filter, too. See http://bugzilla.mozilla.org/show_bug.cgi?id=163188 . Unfortunately, it probably won't show up until after version 1.2 is released.
Calm down. You said you were trying to add RTSP/RTP support to wget. I just wanted to ensure you knew about the relevent documentation and remind other readers that RTSP/RTP is an open protocol. You seemed to want to open a discussion on RTSP/RTP and I thought that might be helpful. No need to get all defensive, I didn't suggest you were clueless in your attempt.
RTSP and RTP are open protocols; did you try reading this and this?
Their suggestion to use sudo is good advice for *any* Unix, not just MacOS X. Since I started to use it, I've reduced the time I spend as root by 80%, which probably reduces my chances of making a really ugly mistake by the same amount. I have to shake my head when I see people who do all their work in Unix as root -- it is only a matter of time before you make some fatal typo.
On the other hand, their advice to use tcsh/bash as a sudo command is poorly thought out. How is that any better than su? Better to use sudo with a few simple commands and scripts that need root for 80% of cases, and use su for the rest.
Ever look at the linux kernel code? Besides, who ever pronounces them out loud anyway?
Yes, it's an example of good code. The variable names are meaningful but short and to the point.
C'mon man, we're talking about programmers here. Who the fux comments as much as they should, if at all?
Ok, programmers are lazy. What happens when a boolean needs to be changed to an enumerated type? Or an int to a struct or class? Is the programmer going to change the variable name in each instance?
The point is, the type information is already provided in the source. Repeating it with redundant and confusing abbreviations throughout the code just clutters the code.
It was a technique for making types easy to identify in a language
Yes, but the value of having the type information accessible in the variable name has to be weighed against the confusion and clutter that adding that information causes.
The names it creates are hard to read and remember, impossible to pronounce. It doesn't scale very well beyond a few native types, like BASIC and perl -- how many meaningful prefixes is a programmer supposed to remember? How many characters of a variable name are you willing to devote to type information? And finally, the type of a variable is usually obvious from it's context, and it can be commented where it isn't.
I've never met anyone who has asserted that Hungarian notation is worth using. It is ugly and confusing, plain and simple.
This is a good thing. Maybe the big chip vendors will stop focusing on Mhz numbers and start making smaller, cooler and more efficient chips.
If I have the choice between a giant-ass chip with multiple fans that takes 100+ Watts vs. a slightly slower, fanless, power sipping version, I'd definately take the latter. I'm definately keeping my eye on the Via C3...
France has Minitel, the teletext system you are thinking of. Minitel held on for as long as it did, despite its inferiority to the internet because of the strong business model it provided. A service provider could provide a service, and the phone company that administered the system charged a usage fee to the user directly on their phone bill. A slice of that went directly back to the provider.
No need to fuss with credit cards, PayPal, etc. or even the backend billing system; it all was handled automatically. Lots of useful services sprang up and took advantage of this infrastructure, and were slow to give it up for the great unknown of the internet. Unfortunately, the system wasn't as great for the users: every service was metered, and the speed was deliberately held back because the providers wanted to keep the users online as long as possible.
Some of these devices will draw power even when they are switched off. For example, TV's will draw enough power to keep the CRT tube warm (which is why TV's don't need to "warm up" like they used to) and accept signals from the remote control. The only way to ensure it doesn't draw any power is to unplug it.