Or at least shift the video drivers from XFree into the kernel.
You might want to look at the kernel framebuffer support. That's exactly what it does. My [somewhat uninformed] understanding of why there are still video drivers in both places is that:
The Linux kernel framebuffer support is not yet all that mature.
XFree86 is designed to be used with more systems than just Linux, and as such, cannot rely on the existence of an underlying framebuffer API.
I'll second the notion that the half-qwerty concept is very useful. It has a much more shallow learning curve than nearly any other "nonstandard" (meaning different from whatever you're already used to) keyboard layout, because it exploits your innate ability to think of your hands as mirror images of one another.
In addition to the hardware implementation for Palm and commercial software implementations for Windows and Mac (all available from the site which the parent poster mentioned), there is also a free implementation for Linux in the form of a kernel patch.
Actually, I *was* talking about "cleartool rmname" (which ClearCase allows you to abbreviate as "cleartool rm"). "cleartool rmelem" does not preserve an element's history at all; that's exactly its point.
I've used gvim in various versions quite happily on W95, W98, and W2K, and I am having a hard time thinking of any *more* stable application I've ever run on any of those systems.
Cleartool does indeed have a subcommand for marking an element as deleted while preserving its history for later recovery ("cleartool rm"). However, it does not have a simple command to do the later recovery. For that, you have to manually root around in the "lost&found" section of the vob, which is a major pain in the rump. This is especially painful when you run "cleartool rm" on a directory but not on any files or subdirectories inside it.
My general feeling about ClearCase is that it makes just about every SCM-related operation possible, but many of them are needlessly awkward.
Is this true? Is the resolution used for projecting AOTC in DLP really 1280x1024? That's horrible! Stretching 640x480 resolution to display on a 21" monitor is bad enough. Stretching a conventional monitor's resolution to display on a theatre screen is just plain ludicrous.
When I went to see AOTC last night, I noticed that the pixellation was rather bad during the closing credits, but wasn't distracted by it during the main movie. I guess I was just too interested in the film itself to care.
It cannot be overemphasized the distinction that Syncronis is making. MIDI was originally designed as a realtime control protocol for use by musicians, not an offline file format for storing recorded music in a compressed form.
MIDI can be used quite effectively by a musician to control very detailed aspects of the music, but to do so goes beyond the lowest common denominator of the General MIDI spec. Therefore, a professional use of MIDI will not allow you to substitute an arbitrary sound card, or even an arbitrary professional level synth for the particular one which the musician used when recording or writing the MIDI file.
MIDI gets a bad rap because of General MIDI. Yes, it has some problems (too piano-centric unless you use the unreserved CC's and sysex), but the point is that it provides ample mechanisms to correct any initial flaws.
By [at least one logical] definition, a high level language is one that uses constructs which do not map directly to those supported by the hardware on which it is running.
C is considered [by many] to be a low level language because it only uses constructs which are available on the majority of modern hardware platforms. However, C relies heavily on the construct of accessing the heap. On a purely stack-based machine which has no heap (some embedded systems, for example), you would have to emulate a heap in terms of stacks. C would therefore be a high level language on that platform, while Forth, a language based around the use of stacks, would be low level.
Sometimes the situation is reversed... people design the hardware to match the constructs used by a particular language. This was so in the case of the old Lisp Machines, or Sun's picoJava chips.
Few languages these days are strictly interpreted, as in parsing each line of source code just before executing it. Many are compiled into an intermediate form, sometimes called bytecode. This bytecode, in turn, may or may not be a high level language for a particular machine, depending on how closely its constructs match the underlying hardware ones.
Even in a purely compiled language without an explicit "bytecode" stage, the further the language's constructs are from those of the hardware, the more instructions it will take to process each statement.
In short, there are plenty of high level languages which can compile to native code. But this does not mean they will run as fast as carefully crafted assembly!
For me, at least, the tactile feedback is the important thing, and the audio feedback is an annoying side effect. Has anyone ever built a keyboard which felt like an IBM Model M, but didn't make any noise? (I'm more sensitive about keyboards than mice, but the same principle applies.)
My cat Melody doesn't just sit on top of the synthesizer, she changes the presets and walks along the keys while I'm playing. I don't know if this is because she enjoys the sound though; she does the same thing even when I'm using headphones. And no, she has never successfully played the old piano solo "Kitten on the Keys".
While you are right about people stressing the wrong differences, your claim about AV and Google's respective syntaxes being interchangable is false.
In AV's simple syntax, unadorned terms are not required to be in the results, they are only preferred. If you want to require a term, you must prepend a plus sign. Google does not allow you to distinguish between required and preferred terms. This may arguably be simpler, but it takes away control from you, the user.
AV also offers a separate advanced syntax which provides support for nested booleans, and positional operators like "near", "within", "before", and "after". Google, while it allows a single level of simple booleans, does not provide any means by which to nest them. It completely lacks positional operators other than phrase matching. Again this takes control away from you, the user.
It never fails to mystify me why Slashdot readers, a crowd biased strongly towards programmers, engineers, and Unix users, namely people who love to have lots of control over things, would favor a dumbed down search service! (I agree that there are other problems with AltaVista, such as the annoying popunder ads. However, these have nothing to do with the quality of its search syntax.)
The original poster is unlikely to be interested, but some of the other readers might be... I would recommend PLT Scheme. It is a very complete, powerful, and polished environment for Scheme programming, which includes an interpreter, a compiler, an IDE with project management and a Scheme-specific intelligent editor, an interactive debugger, and lots of powerful libraries including multithreading, high and low level networking, cross-platform GUI-building based on WX, regexes, XML handling, etc. It runs on Windows, Mac, and several Unixes, and is both free and libre. Try it!
Of course Lisp should not be the poster-boy for functional programming. Lisp's great strength is that it is not rooted immovably in any single programming paradigm. As a language, it gives no favoritism to functional, procedural, declarative, or object-oriented styles. It handles them all in the same syntax, and has standardized or readily-available library support for features which make them respectively convenient to use. Particular implementations may well be have performance optimizations for one or the other of the above, but they are not inherent to the language.
Your answer, while true for edit-compile-run languages (C, C++, Java, Fortran, etc), is not true for fully interactive languages (Lisp, ML, Perl, Python, TCL, etc). In an interactive language, there's really no such thing as hardcoding; the program is not run monolithically, but defined in small reusable pieces which you can recombine at runtime using the full expressiveness of the language.
Why do people get in such a huff about learning new programming models? Neither Lisp, nor C, nor Java requires you to learn a new programming model to start writing programs.
You can write predominantly linear or iterative programs in Lisp.
You can write predominantly functional, recursive programs in C and Java.
You can write predominantly object oriented programs in C.
You can write predominantly procedural programs in Java.
None of the above is the optimal programming model for each of the languages, and would not normally be used for a large scale or high performance application. However, large scale and high performance applications are not tasks for beginning programmers, and only a beginner would shy away from an opportunity to learn a new, potentially useful programming model.
I'm a C programmer, and I'm rather proud of the LISP code embedded within me.:-)
Actually, s-expressions are a rather useful storage type, even in C. Implementing an s-expression library for C took me only a few hours and a couple hundred lines of code. Note that this is not an embedded LISP interpreter, although it be turned into one fairly easily.
As with nearly every question pertaining to audio, MIDI, and music on Linux, Dave Philips' site is pretty much the definitive resource. You'll probably want the section on HDR software.
From the discussion on the Linux Audio Developers' mailing list, Ardour seems to be the most powerful of your options, designed to beat even ProTools.
Mice have plenty of uses for which a keyboard is inappropriate... selected applications in graphics, CAD, VR, music, cartography, etc. It's only when they are used in a WIMP interface (windows, icons, menus, pointers) where the keyboard is faster for many users.
Not that I recommend doing it, but I've personally run KDE 1.1 under Linux on a 486 with 20 MB of memory. It ran with no snags whatsoever, other than lots of annoying paging. Of course, it was just an experiment, but it seemed successful.
Slashdot Mirror
You might want to look at the kernel framebuffer support. That's exactly what it does. My [somewhat uninformed] understanding of why there are still video drivers in both places is that:
I'll second the notion that the half-qwerty concept is very useful. It has a much more shallow learning curve than nearly any other "nonstandard" (meaning different from whatever you're already used to) keyboard layout, because it exploits your innate ability to think of your hands as mirror images of one another.
In addition to the hardware implementation for Palm and commercial software implementations for Windows and Mac (all available from the site which the parent poster mentioned), there is also a free implementation for Linux in the form of a kernel patch.
Actually, I *was* talking about "cleartool rmname" (which ClearCase allows you to abbreviate as "cleartool rm"). "cleartool rmelem" does not preserve an element's history at all; that's exactly its point.
I've used gvim in various versions quite happily on W95, W98, and W2K, and I am having a hard time thinking of any *more* stable application I've ever run on any of those systems.
Cleartool does indeed have a subcommand for marking an element as deleted while preserving its history for later recovery ("cleartool rm"). However, it does not have a simple command to do the later recovery. For that, you have to manually root around in the "lost&found" section of the vob, which is a major pain in the rump. This is especially painful when you run "cleartool rm" on a directory but not on any files or subdirectories inside it.
My general feeling about ClearCase is that it makes just about every SCM-related operation possible, but many of them are needlessly awkward.
Hmm, I probably saw you there last night. :-)
I'm glad your assessment matches mine.
Um, wasn't Yoda CG in this episode? As in, Frank Oz only did the voice, not the usual puppetry?
Is this true? Is the resolution used for projecting AOTC in DLP really 1280x1024? That's horrible! Stretching 640x480 resolution to display on a 21" monitor is bad enough. Stretching a conventional monitor's resolution to display on a theatre screen is just plain ludicrous.
When I went to see AOTC last night, I noticed that the pixellation was rather bad during the closing credits, but wasn't distracted by it during the main movie. I guess I was just too interested in the film itself to care.
My favorite prof Perry Cook had a similar project going at one time: the Rbow.
It cannot be overemphasized the distinction that Syncronis is making. MIDI was originally designed as a realtime control protocol for use by musicians, not an offline file format for storing recorded music in a compressed form.
MIDI can be used quite effectively by a musician to control very detailed aspects of the music, but to do so goes beyond the lowest common denominator of the General MIDI spec. Therefore, a professional use of MIDI will not allow you to substitute an arbitrary sound card, or even an arbitrary professional level synth for the particular one which the musician used when recording or writing the MIDI file.
MIDI gets a bad rap because of General MIDI. Yes, it has some problems (too piano-centric unless you use the unreserved CC's and sysex), but the point is that it provides ample mechanisms to correct any initial flaws.
By [at least one logical] definition, a high level language is one that uses constructs which do not map directly to those supported by the hardware on which it is running.
C is considered [by many] to be a low level language because it only uses constructs which are available on the majority of modern hardware platforms. However, C relies heavily on the construct of accessing the heap. On a purely stack-based machine which has no heap (some embedded systems, for example), you would have to emulate a heap in terms of stacks. C would therefore be a high level language on that platform, while Forth, a language based around the use of stacks, would be low level.
Sometimes the situation is reversed ... people design the hardware to match the constructs used by a particular language. This was so in the case of the old Lisp Machines, or Sun's picoJava chips.
Few languages these days are strictly interpreted, as in parsing each line of source code just before executing it. Many are compiled into an intermediate form, sometimes called bytecode. This bytecode, in turn, may or may not be a high level language for a particular machine, depending on how closely its constructs match the underlying hardware ones.
Even in a purely compiled language without an explicit "bytecode" stage, the further the language's constructs are from those of the hardware, the more instructions it will take to process each statement.
In short, there are plenty of high level languages which can compile to native code. But this does not mean they will run as fast as carefully crafted assembly!
Hum it? I frequently find myself falling into live improvisations based on it, on the piano and synth.
For me, at least, the tactile feedback is the important thing, and the audio feedback is an annoying side effect. Has anyone ever built a keyboard which felt like an IBM Model M, but didn't make any noise? (I'm more sensitive about keyboards than mice, but the same principle applies.)
My cat Melody doesn't just sit on top of the synthesizer, she changes the presets and walks along the keys while I'm playing. I don't know if this is because she enjoys the sound though; she does the same thing even when I'm using headphones. And no, she has never successfully played the old piano solo "Kitten on the Keys".
While you are right about people stressing the wrong differences, your claim about AV and Google's respective syntaxes being interchangable is false.
In AV's simple syntax, unadorned terms are not required to be in the results, they are only preferred. If you want to require a term, you must prepend a plus sign. Google does not allow you to distinguish between required and preferred terms. This may arguably be simpler, but it takes away control from you, the user.
AV also offers a separate advanced syntax which provides support for nested booleans, and positional operators like "near", "within", "before", and "after". Google, while it allows a single level of simple booleans, does not provide any means by which to nest them. It completely lacks positional operators other than phrase matching. Again this takes control away from you, the user.
It never fails to mystify me why Slashdot readers, a crowd biased strongly towards programmers, engineers, and Unix users, namely people who love to have lots of control over things, would favor a dumbed down search service! (I agree that there are other problems with AltaVista, such as the annoying popunder ads. However, these have nothing to do with the quality of its search syntax.)
The original poster is unlikely to be interested, but some of the other readers might be... I would recommend PLT Scheme. It is a very complete, powerful, and polished environment for Scheme programming, which includes an interpreter, a compiler, an IDE with project management and a Scheme-specific intelligent editor, an interactive debugger, and lots of powerful libraries including multithreading, high and low level networking, cross-platform GUI-building based on WX, regexes, XML handling, etc. It runs on Windows, Mac, and several Unixes, and is both free and libre. Try it!
Of course Lisp should not be the poster-boy for functional programming. Lisp's great strength is that it is not rooted immovably in any single programming paradigm. As a language, it gives no favoritism to functional, procedural, declarative, or object-oriented styles. It handles them all in the same syntax, and has standardized or readily-available library support for features which make them respectively convenient to use. Particular implementations may well be have performance optimizations for one or the other of the above, but they are not inherent to the language.
ROTFL! I wish I had moderator points today. Thanks!
Your answer, while true for edit-compile-run languages (C, C++, Java, Fortran, etc), is not true for fully interactive languages (Lisp, ML, Perl, Python, TCL, etc). In an interactive language, there's really no such thing as hardcoding; the program is not run monolithically, but defined in small reusable pieces which you can recombine at runtime using the full expressiveness of the language.
Why do people get in such a huff about learning new programming models? Neither Lisp, nor C, nor Java requires you to learn a new programming model to start writing programs.
None of the above is the optimal programming model for each of the languages, and would not normally be used for a large scale or high performance application. However, large scale and high performance applications are not tasks for beginning programmers, and only a beginner would shy away from an opportunity to learn a new, potentially useful programming model.
I'm a C programmer, and I'm rather proud of the LISP code embedded within me. :-)
Actually, s-expressions are a rather useful storage type, even in C. Implementing an s-expression library for C took me only a few hours and a couple hundred lines of code. Note that this is not an embedded LISP interpreter, although it be turned into one fairly easily.
As with nearly every question pertaining to audio, MIDI, and music on Linux, Dave Philips' site is pretty much the definitive resource. You'll probably want the section on HDR software.
From the discussion on the Linux Audio Developers' mailing list, Ardour seems to be the most powerful of your options, designed to beat even ProTools.
Read Isaac Asmimov's short story "The Final Question" (if I remember the name correctly) for a nice take on the idea of God as a programmer.
Mice have plenty of uses for which a keyboard is inappropriate... selected applications in graphics, CAD, VR, music, cartography, etc. It's only when they are used in a WIMP interface (windows, icons, menus, pointers) where the keyboard is faster for many users.
Not that I recommend doing it, but I've personally run KDE 1.1 under Linux on a 486 with 20 MB of memory. It ran with no snags whatsoever, other than lots of annoying paging. Of course, it was just an experiment, but it seemed successful.