You've misread the post, I think - the only claim was that there was not more data transferred. The maximally compressed 100MB became a redundant 200MB, but only 100MB needed to be transmitted before it was "complete" (the remainder being redundant). So, apart from overhead, the actual amount of data downloaded is the same as it ever was.
However, because of the redundant data, you can now grab any one of a large set of possible 100MB files - so not only have you downloaded the file in a different order compared to other peers, you've probably downloaded a different file. At the end, you reconstruct the redundant 200MB file from whatever 100MB you got hold of, and extract the original 100MB of useful data.
Or that's my understanding, anyway. Obviously, it's all more complicated than that, but that's the principle, right?
Well, just to further correct that correction (or enhance it, as the case may be) According to the Director's Behind the Scenes Thingy, an earlier attempt to make what later turned out to be this project led to a discussion in which Adams specifically said he really wanted the part of Agrajag. So although he didn't actually record it for this, he certainly saw it coming. Or something.
This is extremely pedantic, but "-centric" is most definitely not a prefix - "pre-" being Lating for "before" and all. What you meant was "suffix"; or, in general, "affix".
However, dates in Arabic are commonly right->left, (yyyy/mm/dd)
You mean, just like they are in many locales, and even certain standard formats? I don't think that really counts as "right->left", it's just one of those unfathomable rules of the universe that every culture shall have a different ordering convention for written dates - and maybe several...
This discussion is going round in circles - probably cos everyone basically agrees: it's about priorities, and it's a bitch that we have to make those decisions.
"Why buy caviar, when you could get far more strawberries and cream for the same money?" Unless you're Bill Gates, or that Ikea guy who's bizarrely even richer, you have a limited amount of money to spend at any time, and you have to choose how to spend it. Fact.
When we say "can't afford", we just mean "can't afford along with all the other things I've bought".
Erm, isn't that a bit like saying "if you can afford one holiday a year, you must be able to afford to spend the whole year on holiday"? Or, to use a popular object of examples: "if you can't afford to buy a drink for everyone in the pub, how come you've bought yourself a beer?"
Money doesn't work like that - you spend it, and then you don't have it any more!
Um, I think you're getting a bit confused - that's a completely different experiment, entirely unrelated. This is just a load of clever deductions based on some cool telescopic images, revealing a distant planet. The only connection is they both make use of the gory details of Einsteinian physics.
As far as I know, the satellite you're thinking of has to sit up there for a few months yet, so that we can see if it's moved by a few gazillionths of a millimetre or something - I can hardly wait!;-)
...some may argue that it was Berners-Lee at CERN, since the concept was born there...
*ahem* That was the World-Wide Web, not the Internet itself. You're turning history inside out there, methinks - there'd be no WWW without a 'net to weave it onto!
That's a different kind of memory - it's usually referred to as Prospective Memory, the kind of memory that holds plans for the future rather than events from the past. Poor visio-spatial working memory (as discussed here) would be if you couldn't remember what the stairs looked like as soon as you glanced away... </pedantic>
One major problem with using performance at short-term/working memory to benchmark reliability of longer term memories is the uncertainty surrounding so-called "implicit memory". Some research suggests that it is possible to remember things of which you weren't conciously aware at the time. There is some debate about the extent of this ability (there's always debate in psychology!) and how it would relate to working memory is at best unclear - but it certainly raises the possibility that long-term memories could be accurate without requiring a piece of working memory.
Indeed. One very early "model" of long-term memory saw the brain as an aviary, with each memory as a bird which had to be caught in order to remember something.
Not to mention the incredibly popular view of the brain as a set of homunculi performing different tasks - an analogy despised by "modern" scientists as breaking the problem down without ever explaining how anything works.
There are 3 types of memory. I'm not sure of thier "official" names but...
Well, depending who you ask, there are probably slightly more than that, including:
Episodic / Autobiographical Memory - memories of specific events that happened to you in the past; gradually sorted into a kind of template-based hierarchy.
Prospective Memory - the forward memories of things you plan to do, like grab a drink from the kitchen or phone a friend after lunch.
Semantic Memory - the long-term store of abstract facts; may tie in fairly closely with longer term autobiographical memory.
Procedural Memory - knowing how to perform certain tasks, without having to remember the instructions as a series of facts.
Working Memory - a limited temporary store of items currently being processed; seems to have seperate stores for auditory and visio-spatial information, and one or more central/control structures. Is used in many cognitively demanding tasks, and may also be involved in attention.
There is also a highly debated distinction between short-term and long-term memory, although it is not clear whether this would be orthogonal to the above break-down.
[I'd link to some Wikipedia articles, but I'd have to [re-]write them first:-/]
It was found that the famous "5-9 digits" resulted from a bogus test. Rather than testing short-term memory, it was testing the "auditory loop"...
Just to be clear, this doesn't make the test "bogus", it merely defines it more narrowly: the modern Working Memory Model includes an Auditory Loop, a Visio-Spatial Sketchpad - for dealing with different kinds of short-term memory - and various other, less well-defined, components. So the 7+/-2 chunks very much is how much we can remember (via internal 'rehearsal' - mentally replaying, as you say), but it's a different part of memory than the one studied here - the Auditory/Phonological component rather than the Visio-Spatial one.
But the point is, why use numbers at all if you're not going to use them consistently? If it's Java v.2, then you should implement it using the Java SDK v.2.x And if you don't like starting new software at version 2, don't call the new version "2"! It's not like numbers are the only way of distinguishing a new version of something - how about:
letters - A,B,...
too boring? Alpha and Beta have established meaning with software, but how about Aleph, Beth, etc. They sound cool.
meaningful suffixes - like "32" for a 32-bit rewrite. That way, people can use your suffix on their derivatives, even if they didn't have a previous version. (Like the early Win32 apps having "32" in their names).
arbitrary suffixes - an acronym for Next Generation, or New Technology, perhaps. That way, you can even carry on working on both codebases if you want to (a la "Windows NT"). Not to mention "Windows 98 S.E."
codenames - just pick a cool-sounding word, and use that to distinguish. Do Intel have the Pentium 4, version 5? No, they have the Pentium 4 Prescott.
Is is just me, or is it kind of daft to declare that "Firebird 1.5 is the first release of the Firebird 2 codebase"
I mean, if it's Firebird 2, call it Firebird 2, for crying out loud! It reminds me of Sun, and their wonderful numbering "system" for Java:
"At the second JavaOne conference, Sun will announce version 1.4 of Java 2 Enterprise Edition, along with version 1.4.1 of Java 2 Standard Edition and JavaBeans version 2.9" [Not a real quote, but close enough...]
For those too lazy/rushed to RTFA, the key point of this research is this:
Given a load of spheres, shaking them about won't get them packed as tight as if you stacked them all up neatly by hand. But take a load of squashed spheres (e.g. M&Ms) and shake them about randomly, and they take up much less room, because they naturally find a good formation. Even better if they're asymetrical in another dimension too (e.g. nutty M&Ms).
Yeah, great. But I suppose it's important to someone to know what shape will find its way into tight formations best.
"...I really suggest you just go actually download Mozilla..."
That suggests Mozilla to me, and that's what I was reacting to. If I hadn't put "just about", you might have a point, but I'm not foolish enough to claim that no browser has decent support.
My unnecessary closing sentence was just a parody of your unnecessary closing sentence, but I stand by my original post: the majority of modern browsers have incomplete support, and this includes current trunk builds of Mozilla (which still use Seamonkey, not *bird).
That Firebird has decent support is interesting to know, and encouraging for those still maintaining gopherspaces, but I'd have thought it added to the original point rather than subtracting from it.
I'm glad there is a working handler in Firebird, but that doesn't prove that "mozilla's gopher:// handler" works, does it? And as a Mozilla user, I can assure you that it doesn't.
I use Mozilla 1.6, and can assure you that the two links do not look the same - the gopher: link shows none of the supplementary text, only the menu choices. The only build of Firebird I have at present predates the 0.7 release by a few days, and has the same behaviour, but it may well be that somebody's written a better handler now.
If anyone cares, they can dig through bugzilla and discover what was changed in what build, but I really suggest you check your facts before you run your mouth off.
erm, do you mean either Mosaic or Netscape , by any chance? Mozilla didn't become the name of a browser until some time around 1998, by which time I'm pretty sure there were plenty of HTTP servers around...
I've never used gopher myself (other than for seeing what it looked like), but you may all want to check out Floodgap Gopher-HTTP Proxy
And yes, you do need a proxy, as just about all modern browsers (yes, even Mozilla) don't render gopher correctly - compare your browser with what it should look like.
And naturally, the proxy links to lots of still-existent gopherspaces, for all you wondering if there are any still out there...
The choice is "important" in terms of minimising workload / maximising efficiency - the different approaches allow you to do different things more or less easily.
This discussion is not particularly important, the poster was just "curious" - although people may well give useful information to each other as a direct result of its existence...
No, no prediction required. Slashdot knows when a link is about to appear on Slashdot; Slashdot has the capacity to cope with the traffic that Slashdot receives*; Slashdot has control over whether it links to a mirror or the real thing; so, Slashdot has the ability to cache a version of a page it's about to link to to avoid that page being Slashdotted.
* [granted, a lot of Slashdotted links require more bandwidth to serve than Slashdot's interface, but it's not a quantum leap surely?]
Slashdot Mirror
You've misread the post, I think - the only claim was that there was not more data transferred. The maximally compressed 100MB became a redundant 200MB, but only 100MB needed to be transmitted before it was "complete" (the remainder being redundant). So, apart from overhead, the actual amount of data downloaded is the same as it ever was.
However, because of the redundant data, you can now grab any one of a large set of possible 100MB files - so not only have you downloaded the file in a different order compared to other peers, you've probably downloaded a different file. At the end, you reconstruct the redundant 200MB file from whatever 100MB you got hold of, and extract the original 100MB of useful data.
Or that's my understanding, anyway. Obviously, it's all more complicated than that, but that's the principle, right?
Well, just to further correct that correction (or enhance it, as the case may be) According to the Director's Behind the Scenes Thingy, an earlier attempt to make what later turned out to be this project led to a discussion in which Adams specifically said he really wanted the part of Agrajag. So although he didn't actually record it for this, he certainly saw it coming. Or something.
This is extremely pedantic, but "-centric" is most definitely not a prefix - "pre-" being Lating for "before" and all. What you meant was "suffix"; or, in general, "affix".
Ditto.
You mean, just like they are in many locales, and even certain standard formats? I don't think that really counts as "right->left", it's just one of those unfathomable rules of the universe that every culture shall have a different ordering convention for written dates - and maybe several...
This discussion is going round in circles - probably cos everyone basically agrees: it's about priorities, and it's a bitch that we have to make those decisions.
"Why buy caviar, when you could get far more strawberries and cream for the same money?" Unless you're Bill Gates, or that Ikea guy who's bizarrely even richer, you have a limited amount of money to spend at any time, and you have to choose how to spend it. Fact.
When we say "can't afford", we just mean "can't afford along with all the other things I've bought".
Erm, isn't that a bit like saying "if you can afford one holiday a year, you must be able to afford to spend the whole year on holiday"? Or, to use a popular object of examples: "if you can't afford to buy a drink for everyone in the pub, how come you've bought yourself a beer?"
Money doesn't work like that - you spend it, and then you don't have it any more!
Interestingly, Googling "firebird" still returns the now-renamed browser as the first result, and the database as the second. Go figure!
Um, I think you're getting a bit confused - that's a completely different experiment, entirely unrelated. This is just a load of clever deductions based on some cool telescopic images, revealing a distant planet. The only connection is they both make use of the gory details of Einsteinian physics.
;-)
As far as I know, the satellite you're thinking of has to sit up there for a few months yet, so that we can see if it's moved by a few gazillionths of a millimetre or something - I can hardly wait!
...some may argue that it was Berners-Lee at CERN, since the concept was born there...
*ahem* That was the World-Wide Web, not the Internet itself. You're turning history inside out there, methinks - there'd be no WWW without a 'net to weave it onto!
That's a different kind of memory - it's usually referred to as Prospective Memory, the kind of memory that holds plans for the future rather than events from the past. Poor visio-spatial working memory (as discussed here) would be if you couldn't remember what the stairs looked like as soon as you glanced away...
</pedantic>
One major problem with using performance at short-term/working memory to benchmark reliability of longer term memories is the uncertainty surrounding so-called "implicit memory". Some research suggests that it is possible to remember things of which you weren't conciously aware at the time. There is some debate about the extent of this ability (there's always debate in psychology!) and how it would relate to working memory is at best unclear - but it certainly raises the possibility that long-term memories could be accurate without requiring a piece of working memory.
Indeed. One very early "model" of long-term memory saw the brain as an aviary, with each memory as a bird which had to be caught in order to remember something.
Not to mention the incredibly popular view of the brain as a set of homunculi performing different tasks - an analogy despised by "modern" scientists as breaking the problem down without ever explaining how anything works.
Well, depending who you ask, there are probably slightly more than that, including:
There is also a highly debated distinction between short-term and long-term memory, although it is not clear whether this would be orthogonal to the above break-down.
[I'd link to some Wikipedia articles, but I'd have to [re-]write them first
It was found that the famous "5-9 digits" resulted from a bogus test. Rather than testing short-term memory, it was testing the "auditory loop"...
Just to be clear, this doesn't make the test "bogus", it merely defines it more narrowly: the modern Working Memory Model includes an Auditory Loop, a Visio-Spatial Sketchpad - for dealing with different kinds of short-term memory - and various other, less well-defined, components. So the 7+/-2 chunks very much is how much we can remember (via internal 'rehearsal' - mentally replaying, as you say), but it's a different part of memory than the one studied here - the Auditory/Phonological component rather than the Visio-Spatial one.
But the point is, why use numbers at all if you're not going to use them consistently? If it's Java v.2, then you should implement it using the Java SDK v.2.x And if you don't like starting new software at version 2, don't call the new version "2"! It's not like numbers are the only way of distinguishing a new version of something - how about:
Is is just me, or is it kind of daft to declare that
"Firebird 1.5 is the first release of the Firebird 2 codebase"
I mean, if it's Firebird 2, call it Firebird 2, for crying out loud!
It reminds me of Sun, and their wonderful numbering "system" for Java:
"At the second JavaOne conference, Sun will announce version 1.4 of Java 2 Enterprise Edition, along with version 1.4.1 of Java 2 Standard Edition and JavaBeans version 2.9"
[Not a real quote, but close enough...]
For those too lazy/rushed to RTFA, the key point of this research is this:
Given a load of spheres, shaking them about won't get them packed as tight as if you stacked them all up neatly by hand. But take a load of squashed spheres (e.g. M&Ms) and shake them about randomly, and they take up much less room, because they naturally find a good formation. Even better if they're asymetrical in another dimension too (e.g. nutty M&Ms).
Yeah, great. But I suppose it's important to someone to know what shape will find its way into tight formations best.
"...I really suggest you just go actually download Mozilla..."
That suggests Mozilla to me, and that's what I was reacting to. If I hadn't put "just about", you might have a point, but I'm not foolish enough to claim that no browser has decent support.
My unnecessary closing sentence was just a parody of your unnecessary closing sentence, but I stand by my original post: the majority of modern browsers have incomplete support, and this includes current trunk builds of Mozilla (which still use Seamonkey, not *bird).
That Firebird has decent support is interesting to know, and encouraging for those still maintaining gopherspaces, but I'd have thought it added to the original point rather than subtracting from it.
And? Mozilla != Firebird (Yet)
I'm glad there is a working handler in Firebird, but that doesn't prove that "mozilla's gopher:// handler" works, does it? And as a Mozilla user, I can assure you that it doesn't.
Mozilla Firebird != Mozilla
I use Mozilla 1.6, and can assure you that the two links do not look the same - the gopher: link shows none of the supplementary text, only the menu choices. The only build of Firebird I have at present predates the 0.7 release by a few days, and has the same behaviour, but it may well be that somebody's written a better handler now.
If anyone cares, they can dig through bugzilla and discover what was changed in what build, but I really suggest you check your facts before you run your mouth off.
erm, do you mean either Mosaic or Netscape , by any chance? Mozilla didn't become the name of a browser until some time around 1998, by which time I'm pretty sure there were plenty of HTTP servers around...
I was testing out mozilla's gopher:// handler. It actually works :)
Actually, no it doesn't - try comparing this gopher link with this html proxied version - not the same, I think you'll agree.
I've never used gopher myself (other than for seeing what it looked like), but you may all want to check out Floodgap Gopher-HTTP Proxy
And yes, you do need a proxy, as just about all modern browsers (yes, even Mozilla) don't render gopher correctly - compare your browser with what it should look like.
And naturally, the proxy links to lots of still-existent gopherspaces, for all you wondering if there are any still out there...
The choice is "important" in terms of minimising workload / maximising efficiency - the different approaches allow you to do different things more or less easily.
This discussion is not particularly important, the poster was just "curious" - although people may well give useful information to each other as a direct result of its existence...
No, no prediction required. Slashdot knows when a link is about to appear on Slashdot; Slashdot has the capacity to cope with the traffic that Slashdot receives*; Slashdot has control over whether it links to a mirror or the real thing; so, Slashdot has the ability to cache a version of a page it's about to link to to avoid that page being Slashdotted.
* [granted, a lot of Slashdotted links require more bandwidth to serve than Slashdot's interface, but it's not a quantum leap surely?]