Tim Bradshaw <t...@cley.com> writes: >* Martin Cracauer wrote: >> Just faster isn't an impressive progres for me. >What do you want, magic?
I.E.: - massive multiprocessor systems - get rid of unreliable magnetic harddisks and tapes. While you're at it, get rid of the RAM/disk difference (like the Palm Pilot does). - much less power - Flat/thin screen are finally coming - Better input devices, like eye-following scrolling
Yes, most of this requires software changes. However, it is wrong to say that hardware make better progress than software.
* Martin Cracauer wrote: > I.E.: > - massive multiprocessor systems
Built, no one could program them, because they don't look enough like a PDP11, which we finally worked out how to program.
> - get rid of unreliable magnetic harddisks and tapes. While you're at > it, get rid of the RAM/disk difference (like the Palm Pilot does).
Disks are *not* unreliable. If you're unhappy with the reliability of a single disk, mirror it. It's easy (and cheap) to construct disk subsystems with MTBFs of hundreds or thousands of years.
Getting rid opf the ram/disk difference is called virtual memory, I think: kind of a solved problem. The xerox Dmachines and so on even had the software to exploit this at the user level.
> - much less power
Low power systems can easily be bought. Palm pilots, mobile phones and so on. I change the batteries in my HP48 (which has more than 1Mb of memory and runs a reasonably sophisticated OS) a few times a year: I guess palm pilots are similar. Sure it would be nice to only change them once every two years, but I'd not upgrade for that.
> - Flat/thin screen are finally coming > - Better input devices, like eye-following scrolling
* Tim Bradshaw <t...@cley.com> | Getting rid opf the ram/disk difference is called virtual memory, I | think: kind of a solved problem. The xerox Dmachines and so on even | had the software to exploit this at the user level.
I think he maans the MULTICS way to deal with disks. Not just kind of a solved problem, but kind of a not-a-desirable-solution-problem.
There's another way to look at this: Opening files for reading as streams is a very serious bottleneck to the development of much more interesting ways to deal with persistent data, and I'm not talking about "persistent objects" and databases as a solution to this particular problem, but the inability to think about it when data is stored on disks that are conceptually still thought of as serial input devices because that's what they were in 1950. Streams with sequential access is OK for serial input, such as network protocols, users, and time-based data (audio, video, etc), but it is not OK for data that is mapped into memory on demand. Not just virtual memory, but the management of input sources.
#:Erik -- If this is not what you expected, please alter your expectations.
I find this thread really interesting. Just I don't see the following things mentioned.
Why should using Emacs be a bad decision?
I can't see that anything has occured that suggest that programming can be done better with anything else but written text. And Editors are there to handle text. And Emacs does a good job on this IMHO.
And because I do not see any other workable approach one may ask if programming by writing down text isn't the optimal thing. I guess hardly many people would feel that using a hammer for nailing is quite an optimal solution. And the idea of a hammer is quite old ;-)
Tim Bradshaw <t...@cley.com> writes: > * Martin Cracauer wrote:
> > I.E.: > > - massive multiprocessor systems
> Built, no one could program them, because they don't look enough like > a PDP11, which we finally worked out how to program.
> > - get rid of unreliable magnetic harddisks and tapes. While you're at > > it, get rid of the RAM/disk difference (like the Palm Pilot does).
> Disks are *not* unreliable. If you're unhappy with the reliability of > a single disk, mirror it. It's easy (and cheap) to construct disk > subsystems with MTBFs of hundreds or thousands of years.
> Getting rid opf the ram/disk difference is called virtual memory, I > think: kind of a solved problem. The xerox Dmachines and so on even > had the software to exploit this at the user level.
it's not really solved hardware-wise. ram is about 10^5 times faster than disk. while disk is getting faster, ram seems to be getting faster even more quickly and cpu speed increase rates are outpacing both ram and disk. if anything, the ram/disk problem is worse than ever. virtual memory does not solve it since active swapping is not viable option (as opposed to simply swapping out dormant space). a one day job in ram turns into a five year job on disk. you may as well just crash.
* Friedrich Dominicus <Friedrich.Domini...@inka.de> | Why should using Emacs be a bad decision?
The argument is not against Emacs, but Emacs Lisp. Huge difference.
| I can't see that anything has occured that suggest that programming | can be done better with anything else but written text.
Well, I think GUIs to GUI builders that let me worry less about the stupid and repetitive code that is so often required to make these things fly at all is a huge win.
| And because I do not see any other workable approach one may ask if | programming by writing down text isn't the optimal thing.
It depends on your typing speed and accuracy. Some people are incredibly inept typers. In fact, so incredibly inept that using a freaking electronic _rodent_ and looking at the same stupid menus over and over and over is faster than typing to these people.
#:Erik -- If this is not what you expected, please alter your expectations.
>>>>> "Erik" == Erik Naggum <e...@naggum.no> writes:
Erik> * Friedrich Dominicus <Friedrich.Domini...@inka.de>
Erik> | And because I do not see any other workable approach one may ask if Erik> | programming by writing down text isn't the optimal thing.
Erik> It depends on your typing speed and accuracy. Some people are Erik> incredibly inept typers. In fact, so incredibly inept that using a Erik> freaking electronic _rodent_ and looking at the same stupid menus Erik> over and over and over is faster than typing to these people.
Hear, hear!
As a reasonably fast touch typist, I usually can't stand the GUI thingies because having to reach for anything other than the keyboard really slows things done. I don't even like reaching for the arrow keys because it takes my hands away from the home row.
Raymond Toy <t...@rtp.ericsson.se> writes: > I don't even like reaching for the arrow keys because it takes my > hands away from the home row.
hear, hear :-)
My arrow keys (and the 'numpad') are covered by a CD cover half, which I put my 'rodent' (which I mainly use for netscapism and window selection) on to keep it close to the keyboard... (but now my *left* arm is stiffer than the right, it's hit by the Escape Meta Alt Control Shift Disease!)
Keyboards are perhaps the most disturbing proof of lack of innovation in the computer industry (right now I'm typing from home on a Apple Ergonomic Keyboard, I don't think they make them anymore :-(). -- (espen)
* Johan Kullstam wrote: > it's not really solved hardware-wise. ram is about 10^5 times faster > than disk. while disk is getting faster, ram seems to be getting > faster even more quickly and cpu speed increase rates are outpacing > both ram and disk. if anything, the ram/disk problem is worse than > ever. virtual memory does not solve it since active swapping is not > viable option (as opposed to simply swapping out dormant space). a > one day job in ram turns into a five year job on disk. you may as > well just crash.
But that's what life is going to be like, you need to get used to it. Uniform access speeds are something you can get if your machine is slow enough, and something you have to give up when it gets fast: at 1GHz light travels 0.3m in one cycle.
Of course to say `x is faster than y' is fairly meaningless in this context: disk (and any other non-local storage) has unavoidably longer *latency* than more local storage, but it may have as much bandwidth. Even today it's perfectly possible to design machines with disk systems that can saturate the processor: such machines exist.
This is what I meant by my remark about the PDP11 earlier in the thread. That was a nice slow machine with a flat memory space with uniform access time. And we worked out how to program that eventually, and that's what software people usually think they're using still. But modern machines are nothing like that, and they *will never be like that again*, unless hardware people discover that the physics we know is wrong, and Gallileo was right after all.
So in fact the HW people spend huge amounts of time and effort taking a modern machine and faking it up look like a huge PDP11: several levels of cache, intelligent prefetching, cache-coherent shared-memory multiprocessors and so on. All this effort trying to hide latency because the software people are stuck in the 60s.
Occasionally HW people get uppity and try and build machines that don't expend all this effort on pretending to be a PDP11: the Cray t3d is a relatively recent example at the MPP level (no shared memory, no cache coherency), and Tera are a recent example at the single-processor level (no data cache). But those machines don't look anything like PDP11s, and they're generally just too hard for people to program as a result.
Tim Bradshaw <t...@cley.com> writes: > * Johan Kullstam wrote:
> > it's not really solved hardware-wise. ram is about 10^5 times faster > > than disk. while disk is getting faster, ram seems to be getting > > faster even more quickly and cpu speed increase rates are outpacing > > both ram and disk. if anything, the ram/disk problem is worse than > > ever. virtual memory does not solve it since active swapping is not > > viable option (as opposed to simply swapping out dormant space). a > > one day job in ram turns into a five year job on disk. you may as > > well just crash.
> But that's what life is going to be like, you need to get used to it. > Uniform access speeds are something you can get if your machine is > slow enough, and something you have to give up when it gets fast: at > 1GHz light travels 0.3m in one cycle.
> Of course to say `x is faster than y' is fairly meaningless in this > context: disk (and any other non-local storage) has unavoidably longer > *latency* than more local storage, but it may have as much bandwidth. > Even today it's perfectly possible to design machines with disk > systems that can saturate the processor: such machines exist.
> This is what I meant by my remark about the PDP11 earlier in the > thread. That was a nice slow machine with a flat memory space with > uniform access time. And we worked out how to program that > eventually, and that's what software people usually think they're > using still. But modern machines are nothing like that, and they > *will never be like that again*, unless hardware people discover that > the physics we know is wrong, and Gallileo was right after all.
> So in fact the HW people spend huge amounts of time and effort taking > a modern machine and faking it up look like a huge PDP11: several > levels of cache, intelligent prefetching, cache-coherent shared-memory > multiprocessors and so on. All this effort trying to hide latency > because the software people are stuck in the 60s.
> Occasionally HW people get uppity and try and build machines that > don't expend all this effort on pretending to be a PDP11: the Cray t3d > is a relatively recent example at the MPP level (no shared memory, no > cache coherency), and Tera are a recent example at the > single-processor level (no data cache). But those machines don't look > anything like PDP11s, and they're generally just too hard for people > to program as a result.
> --tim (a software person, stuck in the 60s too)
being stuck in the 60s isn't so bad. it beats getting stuck in the 80s. remember pascal?
there is a silver lining in all this, generational garbage collection can be a big win. there was thread a while back about moving dormant data to disk in a smarter virtual memory scheme. lisp has a good position here. C++, of course, deserves to lose. ;-)
-- J o h a n K u l l s t a m [kulls...@ne.mediaone.net] Don't Fear the Penguin!
Raymond Toy <t...@rtp.ericsson.se> writes: > As a reasonably fast touch typist, I usually can't stand the GUI > thingies because having to reach for anything other than the keyboard > really slows things done. I don't even like reaching for the arrow > keys because it takes my hands away from the home row.
I agree with this. When I had a job that required me to use Microsoft OS's and apps, the one thing I really did like was that I could go *days* without even touching a mouse. I know this, because I'd occasionally find the thing pushed way back on my desk and covered with dust.
As for arrow keys, I don't mind them on my Kinesis contour keyboard.
> FWIW, it's a lot less modern than that. Several ridiculously simple > improvements to Emacs Lisp have been turned down because they were > deemed to be moving it in the direction of Common Lisp, when some > folks behind Emacs have gone off and created this cretinous Scheme > bastard called GUILE and want to base Emacs on it. Phooey!
I started working on Kawa (http://www.gnu.org/software/kawa/) mainly in reaction to political and technical frustrations with Guile. The situation has much improved - but I think Kawa is still technically superior, in spite of (or perhaps because) it is a mostly-one-man project.
Partly in reaction to the plan of basing Emacs on Guile, I started the JEmacs project (http://www.JEmacs.net/). Instead of compiling Emacs Lisp to Guile source code, I am compiling ELisp to Java bytecodes, using the Kawa compiler. I have been making good progress; see the screenshots at the web site.
The last week or so I have been concentrating on improving the ELisp functionality, so I can compile and run existing Emacs sources, as much as possible un-modified.
Unlike (say) RMS, I have no problems increasing Common Lisp compatibility. For example, I have implemented default arguments and (a subset of) typep - because I find them necessary or convenient for writing low-level ELisp routines. (That way I can write them in extended ELisp, instead of having to drop down to Java or Scheme.)
I have decided to add "Common Lisp" as a third language (after Scheme and ELisp) that Kawa can compile. This will be a very pathetic subset of CL - initially just Emacs Lisp with lexical scoping. However, it should be easy to add Common Lisp features as time permits or as contributed by volunteers.
Of source I will continue to support using Scheme as an Emacs scripting/extension language. -- --Per Bothner p...@bothner.com http://www.bothner.com/~per/
>> - Using dynamic scope, by default, which means preserving state is >> rather more complex than with static scoping, and rather more >> time-consuming, and;
>What do these two terms mean, and what are the differences between >them?
Um. Brain fart.
"Dynamic scope" indicates having _indefinite_ scope, that is, there is no definite limit to where a binding may be accessible, as well as dynamic extent, defined as an extent whose duration is bounded by points of establishment and disestablishment within the execution of a particular form. [See the ANSI CL glossary.]
Rather than "static scope," I intended to write "lexical scope," defined in the ANSI CL glossary as scope that is limited to a spatial or textual region within the establishing form.
Emacs Lisp uses dynamic scope, as was common for early Lisps; Scheme was one of the "pioneers" in supporting lexical scoping, and that _appears_ to be the route whereby lexical scoping ultimately entered Common Lisp.
The use of lexical scoping strictly limits the contexts in which bindings are accessible, which makes it rather easier to optimize the code, and probably has other useful effects.
<http://www.xemacs.org/Architecting-XEmacs/index.html> has some interesting links on this. I can find quite a lot of places that claim that lexical scoping is preferable to dynamic scoping; it is certainly easier to _understand_. It is not as easy to find references to why it would be preferable from a performance standpoint, and I don't think I can explain it terribly coherently. -- cbbro...@ntlug.org - <http://www.ntlug.org/~cbbrowne/emacs.html> "All language designers are arrogant. Goes with the territory..." -- Larry Wall
>I think it's quite relevant to this NG. It has bothered me that the >whole Unix/gcc/emacs world seems to be dominated by people, ideas, and >tools from the 1970's. Compared to developments in computer hardware, >that is incredible stagnation. A good example, just how modern is emacs >Lisp?
Can I throw a flip side of the coin (possibly a nickel :-)) into the fray?
The automobile industry has had various developments, and lacks there of, over the years; it remains a constant that we still use that thousands-of-years-old invention, The Wheel. The point being? Some of these things may be "old" because the "old" stuff still happens to be useful.
- It is quite unfortunate that Elisp hasn't progressed too much since the '70s; there _are_ newer things worth learning from.
- On the other hand, the _popular_ newer developments in computer languages could be mistaken for developments by people that never _bothered_ to read the literature of the '70s, but merely distilled bits of C and Simula, which were "'60s-based." (I _know_ GLS was involved with CL and Scheme; I'm disappointed that Java _isn't_ better than it is... I'd like to blame that on him not being as influential in its design as he should have been...)
- Another flip side (how many sides does this nickel have :-)) is that the "conventional world of development" has a mindset dominated by the "pundit circuit."
- Some years ago, the buzzword was "structured programming." At which point people learned to write ugly-looking PL/1.
- Then, they headed of into "SQL world." And C.J. Date is still griping about how badly they muffed up the implementation of relational database systems. Effectively, the PL/1 guys seem to have decided that SQL was a somewhat more robust way of accessing flat files. They hadn't figured out Structured Programming yet, by the way...
- Then they learned about Object Oriented Analysis, and everyone started building GUIed applications using Bad C++. (Which begs the question of whether or not (GOODP app-in-c++) could ever *not* evaluate to NIL...) So we're on to OOA, after the populace didn't "Get" Structured Analysis _or_ SQL.
- More recently, the programming methodology folks headed on to UML, and so we have a "Unified Modelling Language," which is, in no way, unified, but rather represents a conglomeration of a dozen different diagramming schemes. Thus, the pundits are now selling UML. Thus continuing the sequence, where the populace couldn't "get" SSA, SQL, OOA, or, now, UML.
- Most recently, development has headed into "Internet applications," built "on Internet Time," which, as near as I can tell, means that you get someone's application framework, add a scripting language, and hack it until it "sort-of works," and then deploy that, within 60 days, because if you wait any longer, someone will patent the techniques, and you'll get your pants sued off. [And if _that_ happens, then there's a sexual harassment suit in the wings since you've taken your pants off...]
- The next "thing" appears to be using XML for data interchange. Unfortunately, people didn't figure out SSA, SQL, OOA, UML, or the Internet, and so the results seem easy to predict. Throw in Peter Flynn's comments of some years ago, and it just strengthens the result...
"DTDs are not common knowledge because programming students are not taught markup. A markup language is not a programming language." -- Peter Flynn <silma...@m-net.arbornet.org>
People never finish figuring out the existing stuff before trying to adopt the next thing [that _also_ doesn't work], so that having some "stagnant" things around that still work means that you can have functioning systems despite all the pundits... -- cbbro...@acm.org - <http://www.hex.net/~cbbrowne/languages.html> "You're one of those condescending Unix computer users!" "Here's a nickel, kid. Get yourself a real computer" - Dilbert.
> | I can't see that anything has occured that suggest that programming > | can be done better with anything else but written text.
> Well, I think GUIs to GUI builders that let me worry less about the > stupid and repetitive code that is so often required to make these > things fly at all is a huge win.
Now this takes away one sort of work and may be a good or even best solution for creating GUIS, neverthelsss you add the functionality by writing down text. I have heard from languages in which you do programming by choosing some sort of icons and place them on your desktop but I hardly believe that many people use that kind of programming. So probably typing is simpler and more adequate for programming.
> | And because I do not see any other workable approach one may ask if > | programming by writing down text isn't the optimal thing.
> It depends on your typing speed and accuracy. Some people are > incredibly inept typers. In fact, so incredibly inept that using a > freaking electronic _rodent_ and looking at the same stupid menus > over and over and over is faster than typing to these people.
Now it's not too difficult to improve on typing speed and accuracy. I think a programmer better takes care that he/she can type well. In fact all the programmers I've seen which I regard as good are quite fast and accurat typers. It's interesting to see what happens if they find a keyboard which does not have the characters at the places they expect them to be. But I guess that's going off-topic here.
cbbro...@news.hex.net (Christopher Browne) writes: > - Most recently, development has headed into "Internet > applications," built "on Internet Time," which, as near as I can > tell, means that you get someone's application framework, add a > scripting language, and hack it until it "sort-of works," and > then deploy that, within 60 days, because if you wait any longer, > someone will patent the techniques, and you'll get your pants > sued off. [And if _that_ happens, then there's a sexual > harassment suit in the wings since you've taken your pants > off...]
"It compiles... ship it!"
-- vsync http://quadium.net/ - last updated Mon Jun 12 23:31:13 MDT 2000 Orjner.
Erik Naggum <e...@naggum.no> wrote: >* Friedrich Dominicus <Friedrich.Domini...@inka.de> >| Why should using Emacs be a bad decision?
> The argument is not against Emacs, but Emacs Lisp. Huge difference.
>| I can't see that anything has occured that suggest that programming >| can be done better with anything else but written text.
> Well, I think GUIs to GUI builders that let me worry less about the > stupid and repetitive code that is so often required to make these > things fly at all is a huge win.
Instead of using a GUI builder I prefer to add abstraction layers (text) that eases programming of dialogs , increases reuse, simplifies maintenance and improves portability. I use ACL on Windows for a while, have written applications with a lot of dialogs (hundreds) but never use the GUI builder. -- Francis Leboutte f...@algo.be www.algo.be +32-(0)4.388.39.19
Tim wrote: > Of course to say `x is faster than y' is fairly meaningless in this > context: disk (and any other non-local storage) has unavoidably longer > *latency* than more local storage, but it may have as much bandwidth. > Even today it's perfectly possible to design machines with disk > systems that can saturate the processor: such machines exist.
I not sure about how true (or relevant) this is but here goes: I was talking to a bloke who was working on the online processing system for Hertz cars in the states. This consists of a continental size Oracle database that sits in about 4GB of memory and so never touches disk. This `single' instance services the whole of the US.
To back this up, when a checkpoint is called on the DB the 4GB is flushed to some DEC solid-state backup (effectively some persistant memory) which is then dumped to disk/tape for long term storage.
Best Regards,
:) will
ps: my apologies for this being a database example ;)
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes: > My arrow keys (and the 'numpad') are covered by a CD cover half, which > I put my 'rodent' (which I mainly use for netscapism and window > selection) on to keep it close to the keyboard...
-- mailto:j...@acm.org phone:+49-7031-464-7698 (HP TELNET 778-7698) http://www.bawue.de/~jjk/ fax:+49-7031-464-7351 PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish, 0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
* Friedrich Dominicus <Friedrich.Domini...@inka.de> | Now it's not too difficult to improve on typing speed and accuracy.
You'd think it would be worth the investment in time and effort to learn to type really fast and accurately, but people don't do this, even when they are working in environments where typing speed has become the predominant productivity factor.
Most people think much faster than they type, but they also find that the computer is not responding fast enough, so there's no point in typing at maximum speed.
| In fact all the programmers I've seen which I regard as good are | quite fast and accurat typers. It's interesting to see what happens | if they find a keyboard which does not have the characters at the | places they expect them to be. But I guess that's going off-topic | here.
Heh, I get completely lost when the keyboard is wrong, like having a Norwegian layout. The QWERTY keyboard is also wrong: Parentheses have no business being shifted, we have much less need for [ and ] than parens, and { and } are useless unless you are C-damaged, and : and ; are swapped, and so are + and =, ` and ~, and ' and ". OK, so I hae made myself efficient on my keyboard, but it's hard to use somebody else's "standard" keyboard...
#:Erik -- If this is not what you expected, please alter your expectations.
>>>>> "Erik" == Erik Naggum <e...@naggum.no> writes:
Erik> Heh, I get completely lost when the keyboard is wrong, like having a Erik> Norwegian layout. The QWERTY keyboard is also wrong: Parentheses Erik> have no business being shifted, we have much less need for [ and ] Erik> than parens, and { and } are useless unless you are C-damaged, and : Erik> and ; are swapped, and so are + and =, ` and ~, and ' and ". OK, so Erik> I hae made myself efficient on my keyboard, but it's hard to use Erik> somebody else's "standard" keyboard...
Many years ago, for kicks, I set a dip switch on my old Northgate keyboard to Dvorak style. I got reasonably efficient with it after a few hours. When I went to use someone elses standard QWERTY keyboard, my typing speed dropped to essentially zero. At that point I switched my keyboard back and took even longer to go from Dvorak to QWERTY than from QWERTY to Dvorak and also vowed never to use any other keyboard than QWERTY. (However, I do swap control and capslock and put ESC next to 1 on my PC keyboards.)
That also means I never redefine standard keys in Emacs. If I use someone's setup, I'd be totally lost and confused.
<t...@rtp.ericsson.se> wrote: > >>>>> "Erik" == Erik Naggum <e...@naggum.no> writes:
> Erik> Heh, I get completely lost when the keyboard is wrong, like having a > Erik> Norwegian layout. The QWERTY keyboard is also wrong: Parentheses > Erik> have no business being shifted, we have much less need for [ and ] > Erik> than parens, and { and } are useless unless you are C-damaged, and : > Erik> and ; are swapped, and so are + and =, ` and ~, and ' and ". OK, so > Erik> I hae made myself efficient on my keyboard, but it's hard to use > Erik> somebody else's "standard" keyboard...
> Many years ago, for kicks, I set a dip switch on my old Northgate > keyboard to Dvorak style. I got reasonably efficient with it after a > few hours. When I went to use someone elses standard QWERTY keyboard, > my typing speed dropped to essentially zero. At that point I switched > my keyboard back and took even longer to go from Dvorak to QWERTY than > from QWERTY to Dvorak and also vowed never to use any other keyboard > than QWERTY. (However, I do swap control and capslock and put ESC > next to 1 on my PC keyboards.)
> That also means I never redefine standard keys in Emacs. If I use > someone's setup, I'd be totally lost and confused.
* William Deakin wrote: > I not sure about how true (or relevant) this is but here goes: I was > talking to a bloke who was working on the online processing system for > Hertz cars in the states. This consists of a continental size Oracle > database that sits in about 4GB of memory and so never touches disk. This > `single' instance services the whole of the US.
I think this is an interesting datapoint -- I have a theory that a lot of databases will actually fit in core. However think of people like supermarkets, who are busy acquiring records of every transaction, or telcos who are doing the same. Those databases will not fit in core: not even a day's worth I expect.
Centuries ago, Nostradamus foresaw a time when Tim Bradshaw would say:
>* William Deakin wrote:
>> I not sure about how true (or relevant) this is but here goes: I was >> talking to a bloke who was working on the online processing system for >> Hertz cars in the states. This consists of a continental size Oracle >> database that sits in about 4GB of memory and so never touches disk. This >> `single' instance services the whole of the US.
>I think this is an interesting datapoint -- I have a theory that a lot >of databases will actually fit in core. However think of people like >supermarkets, who are busy acquiring records of every transaction, or >telcos who are doing the same. Those databases will not fit in core: >not even a day's worth I expect.
... Which means that you probably want "transactions" to stream off into lower-performance secondary storage, whilst "inventory" and "configuration" sits in memory.
Yes, I'd think this to be a big win... -- aa...@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/> Rules of the Evil Overlord #103. "I will make it clear that I do know the meaning of the word "mercy"; I simply choose not show them any." <http://www.eviloverlord.com/>
Tim wrote: > I think this is an interesting datapoint -- I have a theory that a lot > of databases will actually fit in core.
Yes. I particularly liked the solidstate backup idea too. I would imagine it to use this to dump a lisp memory image to this kind of `solid-state' backup straight after gc. That is, if somebody isn't already doing this.
> However think of people like supermarkets, who are busy acquiring records > of every transaction, or telcos who are doing the same. Those databases > will not fit in core: not even a day's worth I expect.
True. (This sounds a bit like something we discussed a while back). I suppose this is where `data-mining' and `data-warehousing' rear their ugly heads. Or you dump the whole lot to a really, really big parallel disk storage array and try to make sense of it later.
<ramble> IIRC there was an article a read some time ago that the run away success of introducting loyalty cards in supermarkets in the UK caused massive headaches for the IT and marketing departments because you then end up with more data than you can shake a stick at. Sounds like you need a high-energy particle physicist to sort it out for you, </ramble>
