The word you're looking for is "extrasolar" - outside the solar system (the planetary system of our sun, Sol). All planets other than Earth are "extraterrestrial", including the local ones like Mercury and Jupiter.
And in response to a different message, Jupiter's surface gravity is about 2.5 G. Yes, Jupiter has way more than 2.5 times Earth's mass, but it has a much larger radius, too; g = (G*m1*m2)/r^2
No, really, he did die in 1964. What you saw on the TV show in 1965 and 1966 was actually an audioanimatron of Disney. Eventually it wore out so in 1966 they staged its death.
On a quick look at that GraphOn patent I was reminded of the technique that the NAPLPS protocol specifies for transmitting coordinate information (both X,Y coordinates and R,G,B coordinates for color info), where the bits for each value are split up and reshuffled into bytes (most significant bits first) such that the receiving app can ignore all the coordinate bytes after it has received the max resolution it can handle. (That is, each byte includes a few bits of each coordinate.)
The NAPLPS specification predates the patent by a good five or six years.
The Fisher-Price site says the program runs under Windows 3.1 (and up), so perhaps it works alright under WINE?
I'd love to see more of the popular kids' educational/entertainment titles for Linux. My daughter has been playing with this stuff on the Mac since she was three, but most of the machines in the house run Linux (x86 mostly). I really should try running some of her stuff (many of the CDs have both Mac & Windows version on them) under WINE.
Meanwhile, interested parents (uncles, aunts) might check out LinuxForKids and Childrens Linux Titles for more. (I haven't checked out these sites very thoroughly, they seem to be fairly new).
What does Motif provide that other window managers and complete enviroments (GNOME etc) don't provide?
Well, Motif is a GUI toolkit, not just a window manager (but includes mwm) or environment (but these days includes CDE).
As for what it provides that GTK or Qt don't: compatibility with the source code of zillions of apps (many for in-house use) originally developed on one of the proprietary unices, and compatibility with the expertise of the zillions of long-time Unix programmers who wrote those apps. And while Motif itself may not be open-source, Lesstif is, and is completely compatible with all the Motif programs I had lying around to try it with (none of which use the more obscure corners of Motif that Lesstif hasn't got to yet).
Back in the earlier GUI toolkit wars (OpenLook vs Motif) I favored OpenLook, but Motif won out and I've used it for years. If I'm developing an app even for Linux I'll use {Mo,Less}tif as first choice because it does the job and I can't be bothered (yet) to learn Qt or GTK.
There's also a hell of a lot more documentation (books, etc.) on the Motif API and Motif style guides, etc, (all applicable of course to Lesstif) than there is for either GTK or Qt.
Qt and GTK have their own advantages, of course, but the "installed base" of {Mo,Less}tif apps and expertise (and adjuncts like GUI builders) is too large for it to be casually dismissed.
And Motif is vital for any enterprise who wants to move their legacy Unix apps to Linux.
The above linked page is pretty sparse on info, bascially saying the ISP seems to have shut down the website "for copyright violation". This isn't exactly legal action (yet). Where's the rest of the story?
Legal offices have a long history of preferring Word Perfect for their document processing. I don't know the specifics of why, other than perhaps conservatism (time was when Word Perfect was the preferred word processor on PCs) and not wanting to convert all their boilerplate. There may also be technical reasons, legal documents have some particular formatting requirements.
And PDF of course is a popular way of distributing docs on the web.
The lack of a Word format copy isn't necessarily a deliberate slight against Microsoft.
With improvements in video projection technology (eg extremely high definition), digital video and increased bandwidth, release of films to theatres on filmstock is going to be obsolete in a few years anyway. The trend to smaller theatres helps, since a smaller screen means less energy output required for the projector (which makes it easier/cheaper to build, etc.)
New (or retrofitted) theatres will have some sort of high-end digital video projection system and the films will be distributed either by a server and high bandwidth feed (possibly a dedicated satellite link) or high capacity digital medium (multiple DVDs?), saving money on the film stock, film duplication process, and shipping costs of those reels.
This also allows for wider simultaneous release, although possible censorship/language/etc issues in other countries may still mean delays in international release.
Movie theatres won't go away, but movies won't be "films" for much longer.
That came out of Bell Labs, it was (in some form or another) a feature of the Version 8 research kernel (the Labs' internal successor to Version 7, while the commerical side was going with the V7-based System III and System V). I heard Rob Pike give a talk on it at a Usenix back in, oh, 1985 or '86.
I agree on the importance though. Beats hell out of grubbing through/dev/kmem.
Yep. Grep through/usr/include on commerical Unixen and you may well stumble across the odd Mic rosoft copyright notice, dating back to Xenix days. Certainly was true of OSF/1 a year or so ago (last time I was using a non-free Unix). I think it was in some stuff for reading DOS filesystems.
While it's true in one sense that only the (copyright) owner can relicense code, it is also true that some licenses (e.g. BSD) specifically authorize inclusion in derived works without influencing the license of that derived work. Under copyright law, a derived work is not the same as the original work(s) from which it was derived, although it may infringe on the original(s) unless such inclusion/derivation is authorized. The change to make it a derived work might be quite trivial, so long as you do something differentiate it.
The BSD allows derivation without restriction. The GPL allows derivation with the restriction that the derived work be GPL'd. Other licenses place even more restrictions on derivation. (Well, strictly speaking, not on derivation but on distribution of derived works.)
Since the BSD license lets you do whatever the heck you like with the code, as long as you retain copyright notices, you can indeed redistribute derived code under the GPL.
You just need to include something like the following in your header: "includes code copyright (c) by [whomever], with permission" (details depend on the BSD license) but the derived work (and the change may be trivial) comes under a new copyright and whatever license you, the new copyright holder, choose to slap on it. If someone you distribute it to doesn't like it, they're free to go back to the original BSD version (if they can find it), but it won't have your changes. If they want your version they have to live with whatever license you've put on it, including the GPL.
(The GPL doesn't have a problem with including BSD code because for the purposes of the GPL, the whole derived work can come under a new license, since the BSD does not prohibit that. Other licenses may prohibit that, and those are "GPL-incompatible".)
A GPL violation is a violation of copyright law, since (for so-licensed works) only the GPL licenses the making of copies. There are a variety of remedies, both civil and criminal, for copyright violation (recall the "FBI Warning" at the beginning of commercial videotapes).
Mind, prosecution of copyright violations against oerations in some places (eg China) has not been widely noted for its effectiveness. Elsewhere however the potential sting of a copyright infringement suit has been enough to cause companies to back off and fix it (somebody mentioned NeXT).
Benyus's book isn't bad, but she needlessly invents a new term, biomimicry, when the perfectly good "bionics" (original meaning) has been around for decades.
(And yes, the less-complete dictionaries only list the definition of bionics popularized by "The Six Million Dollar Man", i.e. machinery replacing/augmenting the organism, but the original definition was the study of biological systems. To quote Martin Caidin's "Cyborg" (which inspired the TV show):
"The term itself, bionics, still found ready understanding within only a limited area. Originally it was coined by Major Jack E. Steele, who had been a research psychiatrist at the Aerospace Research Laboratory in Ohio. . . . He created the word bionics as a combination of the Greek bios, meaning life, and the suffix ics, meaning after the manner of, or resembling. Steele taught his coworkers that the scientific goal of bionics was to acquire specific biological knowledge, then reduce that knowledge to mathematical terms (again with the indispensable computers) that would be meaningful to an engineer, who would then produce what the doctors, or the bionicists, if the term was preferred, requested."
(I happen to know all this since Dr. Steele (now Colonel, retired) is my father-in-law.)
(And a rev iew of "Cyborg" suggests Martin Caidin may be the first user of term cyborg -- from which word of course derives the name of the Star Trek Borg.)
O'Reilly has a good point. To a large degree the current KDE and Gnome efforts, and things like KOffice, AbiWord, etc are attempts to copy Microsoft, with much less focus on doing better than Microsoft (except in terms of code quality), or on focussing on the next generation of applications and standards.
While this (what MS referred to as "chasing taillights") is certainly necessary to capture mindshare and useful in terms of producing better apps and user interfaces for Linux, it's also a limited goal.
How about "embracing and extending" Microsoft apps? Sure, get the functionality down, the ability to read MS Office formats, etc. But take the apps (and the desktop) a few better than that.
Provide function (and not just bells'n'whistles, or feeping creatures) that goes beyond Microsoft's apps. (Themeability in a desktop is nice, but for most folks it's a "nice feature" rather than some critical function they'll learn they can't live without.) Find new app areas (so called "killer apps") that Microsoft hasn't even thought of yet. (Not that this is easy, but this is where the thousands of creative individuals of the bazaar can do better than the rigid structure of the cathedral. The trick is getting it to a point where it's useful before copy artists like MS can embrace and extend the new idea.)
Is this just to bash Microsoft? No. But O'Reilly has a point about what Microsoft, via its own products, is doing to the open protocols of the net. (Go back and re-read Halloween II to refresh your memory about MS targeting protocols.) If we want the net to remain open, if we want our open software to remain useful, we need to ensure that softare that embodies open protocols stays dominant -- which means being better than proprietary software that perverts those open protocols, whether that proprietary software is from Microsoft or anyone else. (It's just that Microsoft is the biggest, and admitted (via the Halloween docs) offender in this regard.)
(And if it means embracing and extending a proprietary protocol/format to do it -- hey, that's the risk you run with proprietary protocols.)
You miss the obvious. Linux the kernel is small enough, and the desktopware (KDE/Gnome, *Office, etc, etc) is optional and all lives in user space. Adding desktopware does not make for a 2 Gb OS, and it only makes for a 2 Gb install if the user wants all that stuff. (Unlike certain other less-than-modular OS's out there.)
This is a good thing. If I just have an old 486 box I want to run as a small volume server, I can put Linux and a few daemons on it. If I have a desktop box I want to do office work (documents, spreadsheets, email, etc) I put Linux and a few different (and bigger) apps on it. And so on. One basic underlying technology -- of proven reliability and flexibility -- so that I don't need to re-learn everything for each box, but different app layers on top customize it for what I want.
So yes, let's see Linux better tuned to the desktop, and with more desktop apps. And lets see it better tuned for server use, for embedded apps, for whatever.
This could be cool, but there are some obvious unanswered questions, like how well does it distinguish those four test words if they're part of continuous speech rather than discrete samples?
If the thing can parse that stuff out of continuous speech, then the key to recognizing a fairly large vocabulary is not scaling it to 50,000 output neurons, each one recognizing a single word, but only to about 40, each one recognizing a single phoneme. Then some backend logic tries to recognize words out of the phoneme stream.
In other words, use something like this as a front end noise filter that inputs to something along the lines of more conventional speech recognition systems.
This (the bit about timing of signals) is the sort of thing my father-in-law (Dr. Jack Steele) has been complaining about folks missing for years. (And he ought to know -- he invented the term "bionics" back about forty years ago.) (Gee, if he's the "father of bionics", does that make me the brother-in-law of bionics?)
I'm a little surprised at how few neurons and links it took, though - and how general purpose (as in different languages) it is. Different human languages contain somewhat different sets of phonemes - what may be two distinct phonemes in one language are considered the same in another. (E.g., Chinese has a sound between the "p" and "b" of English, considered differetn from either. Hence the difficulty anglicizing the name of the city Peking/Beijing.)
So far this fits with the dynamically re-microprogrammable processor I speculated on last week. For "a first instruction set" in the patent, read "microcode", and the patent becomes more legible. In short, I think it's a combo of dynamically changeable microcode with JIT compilation of the interpreted instruction set, although there are a couple of different approaches to that.
Now, the specifics in this case seem to be a provision for cacheing the results of parallel instruction execution and then either voiding or writing that cache depending on whether the instructions cause an exception or not. That in itself is nothing new, but in combination with "just-in-time" compilation of, say, x86 code to Transmeta microcode it might be. Particularly if the Transmeta processor uses horizontal microprogramming (read, "very very very long instruction word") to speed up the processing. (Loosely speaking, with horizontal microcode, each bit in the very long instruction word (could be hundreds of bits) maps to a discrete piece of logic (gate, flip/flop, etc) in the processor. Given an appropriate processor design it might be possible to map several instructions in a more vertical set (x86, PPC, etc) to a single wide microinstruction, effectively executing all of those in parallel, but then you really need some way of flushing everything if it screws up. Which this patent provides.)
(It'll be interesting to see if the active microcode store is loadable from RAM (making it end-user microprogrammable) or just from a fixed set of microprograms on ROM (which may live on the CPU die)).
I've seen some very wrong and some almost right answers posted here. Folks that grew up with a real Unix editor - 'ed' or even 'ex'/'vi' - know that it comes from the editor command 'g/re/p', for globabally search for regular expression and print (where 're' stands for arbitrary regular expression).
Now, if you want obscure name origins, there's 'awk'. (Named for the initials of the three authors).
Seems reasonable. As I mentioned above the idea of reloadable microcode machines goes back a long way, its just that nobody (AFAIK) has done a microprocessor that way. (They've come close -- there was a UCSD P-code chipset that used the same processor as the LSI-11 (PDP-11 architecture) but with a different microcode chip - suppose that microcode chip had been writeable?).
Given a fairly vanilla RISC core and a lot of on-chip writeable memory for the microcode, you're there. Optimizing it, parallelizing it, and coming up with quick ways of swapping microcode (to a different architecture) make it better. Really fast ways of swapping microcode (say on a context switch) and something like just-in-time compiling of new microcode to optimize an application's code make it better yet, and all this is within the realm of current state of the art.
You'd need a smart OS to manage it -- partly like VMware and partly like the way the Linux loader can invoke a JVM to run a Java class file (or the app of your choice to run the program types of your choice if you configure it).
If this isn't what Transmeta is doing, somebody else ought to. It's just too cool.
The multiple personality processor is not a new idea of course, although doing it as a microprocessor may be.
The Burroughs B1700 (as I recall) was one such user-microprogrammable CPU, with standard microprograms to optimize the architecture for running ALGOL programs, or for COBOL programs, and so on. I seem to recall from the same era a nanoprogrammable machine -- the nanocode was horizontal (very wide instruction word) and that reprogrammed the architecture on which the (vertical) microprograms ran (which reprogrammed... etc)).
Doing all this on a microprocessor would be pretty neat (I'm trying to remember if Intel's iAPX 432 Ada chip had some of this capability). Being able to do it on the fly (at a context switch, say) from a micro- or nano-program cache would be doubly so.
Whether applications (or even the kernel) could be compiled down to the microinstruction level would very much depend on the specific memory architecture - microprogram words might be a totally different size from the main memory and transferring data/code between the two different memories could be too much of a bottleneck to run the application that way. But it probably wouldn't be necessary: a really smart compiler will optimize the top level instruction set for the program and generate the appropriate microcode for that instruction set. (Some work was done on this on the micro/nano programmable machines of back in the late 70's - I haven't followed it since then.)
Of course, for any such chip, being able to run native x86/PPC/you-name-it binaries would fall out as a natural given appropriate swappable microcode. Given techniques developed for Java machines like JIT, those binaries could even be recompiled on-the-fly into better microcode for improved performance over what the orginal chip would give. The trick comes in managing all this, which is where someone with operating system expertise comes in.
The problem with high levels of abstraction crop up when the abstract model isn't a good fit for the task or process you're trying to write code for. Bad as coding in C++ may be, it's easier than trying to change the business model. (That said, I've seen more bad C++ code than perhaps any other language -- I've also seen some very good C++ code).
I used to do a lot of development in APL -- now there's a language with a lot of high level abstraction, but it's oriented in a particular direction that is not necessarily a good fit for some of the things I've seen it applied to (email!? business management!?).
It may well be that the applications you're working on could in fact be better developed in ML or Haskell (I'm not familiar with either of those), but in the commercial world that's only one consideration. Other considerations are: who supports the develpment tools, and how big is the available pool of talent to support what gets built. I've beaten my head against that wall, too (I was an early adopter of C++ back in the 'cfront 1.0' days because the OO approach was a much better fit for some of the applications we were developing -- this in a UNIX/C shop that had just barely finished migrating some of their developers from VMS/FORTRAN. C++ has gone downhill since then, in my opinion.)
Slashdot Mirror
The word you're looking for is "extrasolar" - outside the solar system (the planetary system of our sun, Sol). All planets other than Earth are "extraterrestrial", including the local ones like Mercury and Jupiter.
And in response to a different message, Jupiter's surface gravity is about 2.5 G. Yes, Jupiter has way more than 2.5 times Earth's mass, but it has a much larger radius, too; g = (G*m1*m2)/r^2
No, really, he did die in 1964. What you saw on the TV show in 1965 and 1966 was actually an audioanimatron of Disney. Eventually it wore out so in 1966 they staged its death.
On a quick look at that GraphOn patent I was reminded of the technique that the NAPLPS protocol specifies for transmitting coordinate information (both X,Y coordinates and R,G,B coordinates for color info), where the bits for each value are split up and reshuffled into bytes (most significant bits first) such that the receiving app can ignore all the coordinate bytes after it has received the max resolution it can handle. (That is, each byte includes a few bits of each coordinate.)
The NAPLPS specification predates the patent by a good five or six years.
The Fisher-Price site says the program runs under Windows 3.1 (and up), so perhaps it works alright under WINE?
I'd love to see more of the popular kids' educational/entertainment titles for Linux. My daughter has been playing with this stuff on the Mac since she was three, but most of the machines in the house run Linux (x86 mostly). I really should try running some of her stuff (many of the CDs have both Mac & Windows version on them) under WINE.
Meanwhile, interested parents (uncles, aunts) might check out LinuxForKids and Childrens Linux Titles for more. (I haven't checked out these sites very thoroughly, they seem to be fairly new).
What does Motif provide that other window managers and complete enviroments (GNOME etc) don't provide?
Well, Motif is a GUI toolkit, not just a window manager (but includes mwm) or environment (but these days includes CDE).
As for what it provides that GTK or Qt don't: compatibility with the source code of zillions of apps (many for in-house use) originally developed on one of the proprietary unices, and compatibility with the expertise of the zillions of long-time Unix programmers who wrote those apps. And while Motif itself may not be open-source, Lesstif is, and is completely compatible with all the Motif programs I had lying around to try it with (none of which use the more obscure corners of Motif that Lesstif hasn't got to yet).
Back in the earlier GUI toolkit wars (OpenLook vs Motif) I favored OpenLook, but Motif won out and I've used it for years. If I'm developing an app even for Linux I'll use {Mo,Less}tif as first choice because it does the job and I can't be bothered (yet) to learn Qt or GTK.
There's also a hell of a lot more documentation (books, etc.) on the Motif API and Motif style guides, etc, (all applicable of course to Lesstif) than there is for either GTK or Qt.
Qt and GTK have their own advantages, of course, but the "installed base" of {Mo,Less}tif apps and expertise (and adjuncts like GUI builders) is too large for it to be casually dismissed.
And Motif is vital for any enterprise who wants to move their legacy Unix apps to Linux.
The above linked page is pretty sparse on info, bascially saying the ISP seems to have shut down the website "for copyright violation". This isn't exactly legal action (yet). Where's the rest of the story?
Legal offices have a long history of preferring Word Perfect for their document processing. I don't know the specifics of why, other than perhaps conservatism (time was when Word Perfect was the preferred word processor on PCs) and not wanting to convert all their boilerplate. There may also be technical reasons, legal documents have some particular formatting requirements.
And PDF of course is a popular way of distributing docs on the web.
The lack of a Word format copy isn't necessarily a deliberate slight against Microsoft.
With improvements in video projection technology (eg extremely high definition), digital video and increased bandwidth, release of films to theatres on filmstock is going to be obsolete in a few years anyway. The trend to smaller theatres helps, since a smaller screen means less energy output required for the projector (which makes it easier/cheaper to build, etc.)
New (or retrofitted) theatres will have some sort of high-end digital video projection system and the films will be distributed either by a server and high bandwidth feed (possibly a dedicated satellite link) or high capacity digital medium (multiple DVDs?), saving money on the film stock, film duplication process, and shipping costs of those reels.
This also allows for wider simultaneous release, although possible censorship/language/etc issues in other countries may still mean delays in international release.
Movie theatres won't go away, but movies won't be "films" for much longer.
> 6.Solaris' invention of /proc
/dev/kmem.
That came out of Bell Labs, it was (in some form or another) a feature of the Version 8 research kernel (the Labs' internal successor to Version 7, while the commerical side was going with the V7-based System III and System V). I heard Rob Pike give a talk on it at a Usenix back in, oh, 1985 or '86.
I agree on the importance though. Beats hell out of grubbing through
Yep. Grep through /usr/include on commerical Unixen and you may well stumble across the odd Mic rosoft copyright notice, dating back to Xenix days. Certainly was true of OSF/1 a year or so ago (last time I was using a non-free Unix). I think it was in some stuff for reading DOS filesystems.
While it's true in one sense that only the (copyright) owner can relicense code, it is also true that some licenses (e.g. BSD) specifically authorize inclusion in derived works without influencing the license of that derived work.
Under copyright law, a derived work is not the same as the original work(s) from which it was derived, although it may infringe on the original(s) unless such inclusion/derivation is authorized. The change to make it a derived work might be quite trivial, so long as you do something differentiate it.
The BSD allows derivation without restriction. The GPL allows derivation with the restriction that the derived work be GPL'd. Other licenses place even more restrictions on derivation. (Well, strictly speaking, not on derivation but on distribution of derived works.)
Since the BSD license lets you do whatever the heck you like with the code, as long as you retain copyright notices, you can indeed redistribute derived code under the GPL.
You just need to include something like the following in your header: "includes code copyright (c) by [whomever], with permission" (details depend on the BSD license) but the derived work (and the change may be trivial) comes under a new copyright and whatever license you, the new copyright holder, choose to slap on it. If someone you distribute it to doesn't like it, they're free to go back to the original BSD version (if they can find it), but it won't have your changes. If they want your version they have to live with whatever license you've put on it, including the GPL.
(The GPL doesn't have a problem with including BSD code because for the purposes of the GPL, the whole derived work can come under a new license, since the BSD does not prohibit that. Other licenses may prohibit that, and those are "GPL-incompatible".)
proof.
Windows uses BSD code. When was the last time Microsoft gave something back?
This is a first class hack.
Now, how soon before LinuxPPC is ported to it?
A GPL violation is a violation of copyright law, since (for so-licensed works) only the GPL licenses the making of copies. There are a variety of remedies, both civil and criminal, for copyright violation (recall the "FBI Warning" at the beginning of commercial videotapes).
Mind, prosecution of copyright violations against oerations in some places (eg China) has not been widely noted for its effectiveness. Elsewhere however the potential sting of a copyright infringement suit has been enough to cause companies to back off and fix it (somebody mentioned NeXT).
Benyus's book isn't bad, but she needlessly invents a new term, biomimicry, when the perfectly good "bionics" (original meaning) has been around for decades.
(And yes, the less-complete dictionaries only list the definition of bionics popularized by "The Six Million Dollar Man", i.e. machinery replacing/augmenting the organism, but the original definition was the study of biological systems. To quote Martin Caidin's "Cyborg" (which inspired the TV show):
"The term itself, bionics, still found ready understanding within only a limited area. Originally it was coined by Major Jack E. Steele, who had been a research psychiatrist at the Aerospace Research Laboratory in Ohio. . . . He created the word bionics as a combination of the Greek bios, meaning life, and the suffix ics, meaning after the manner of, or resembling. Steele taught his coworkers that the scientific goal of bionics was to acquire specific biological knowledge, then reduce that knowledge to mathematical terms (again with the indispensable computers) that would be meaningful to an engineer, who would then produce what the doctors, or the bionicists, if the term was preferred, requested."
(I happen to know all this since Dr. Steele (now Colonel, retired) is my father-in-law.)
(And a rev iew of "Cyborg" suggests Martin Caidin may be the first user of term cyborg -- from which word of course derives the name of the Star Trek Borg.)
O'Reilly has a good point. To a large degree the current KDE and Gnome efforts, and things like KOffice, AbiWord, etc are attempts to copy Microsoft, with much less focus on doing better than Microsoft (except in terms of code quality), or on focussing on the next generation of applications and standards.
While this (what MS referred to as "chasing taillights") is certainly necessary to capture mindshare and useful in terms of producing better apps and user interfaces for Linux, it's also a limited goal.
How about "embracing and extending" Microsoft apps? Sure, get the functionality down, the ability to read MS Office formats, etc. But take the apps (and the desktop) a few better than that.
Provide function (and not just bells'n'whistles, or feeping creatures) that goes beyond Microsoft's apps. (Themeability in a desktop is nice, but for most folks it's a "nice feature" rather than some critical function they'll learn they can't live without.) Find new app areas (so called "killer apps") that Microsoft hasn't even thought of yet. (Not that this is easy, but this is where the thousands of creative individuals of the bazaar can do better than the rigid structure of the cathedral. The trick is getting it to a point where it's useful before copy artists like MS can embrace and extend the new idea.)
Is this just to bash Microsoft? No. But O'Reilly has a point about what Microsoft, via its own products, is doing to the open protocols of the net. (Go back and re-read Halloween II to refresh your memory about MS targeting protocols.) If we want the net to remain open, if we want our open software to remain useful, we need to ensure that softare that embodies open protocols stays dominant -- which means being better than proprietary software that perverts those open protocols, whether that proprietary software is from Microsoft or anyone else. (It's just that Microsoft is the biggest, and admitted (via the Halloween docs) offender in this regard.)
(And if it means embracing and extending a proprietary protocol/format to do it -- hey, that's the risk you run with proprietary protocols.)
You miss the obvious. Linux the kernel is small enough, and the desktopware (KDE/Gnome, *Office, etc, etc) is optional and all lives in user space. Adding desktopware does not make for a 2 Gb OS, and it only makes for a 2 Gb install if the user wants all that stuff. (Unlike certain other less-than-modular OS's out there.)
This is a good thing. If I just have an old 486 box I want to run as a small volume server, I can put Linux and a few daemons on it. If I have a desktop box I want to do office work (documents, spreadsheets, email, etc) I put Linux and a few different (and bigger) apps on it. And so on. One basic underlying technology -- of proven reliability and flexibility -- so that I don't need to re-learn everything for each box, but different app layers on top customize it for what I want.
So yes, let's see Linux better tuned to the desktop, and with more desktop apps. And lets see it better tuned for server use, for embedded apps, for whatever.
This could be cool, but there are some obvious unanswered questions, like how well does it distinguish those four test words if they're part of continuous speech rather than discrete samples?
If the thing can parse that stuff out of continuous speech, then the key to recognizing a fairly large vocabulary is not scaling it to 50,000 output neurons, each one recognizing a single word, but only to about 40, each one recognizing a single phoneme. Then some backend logic tries to recognize words out of the phoneme stream.
In other words, use something like this as a front end noise filter that inputs to something along the lines of more conventional speech recognition systems.
This (the bit about timing of signals) is the sort of thing my father-in-law (Dr. Jack Steele) has been complaining about folks missing for years. (And he ought to know -- he invented the term "bionics" back about forty years ago.) (Gee, if he's the "father of bionics", does that make me the brother-in-law of bionics?)
I'm a little surprised at how few neurons and links it took, though - and how general purpose (as in different languages) it is. Different human languages contain somewhat different sets of phonemes - what may be two distinct phonemes in one language are considered the same in another. (E.g., Chinese has a sound between the "p" and "b" of English, considered differetn from either. Hence the difficulty anglicizing the name of the city Peking/Beijing.)
So far this fits with the dynamically re-microprogrammable processor I speculated on last week. For "a first instruction set" in the patent, read "microcode", and the patent becomes more legible. In short, I think it's a combo of dynamically changeable microcode with JIT compilation of the interpreted instruction set, although there are a couple of different approaches to that.
Now, the specifics in this case seem to be a provision for cacheing the results of parallel instruction execution and then either voiding or writing that cache depending on whether the instructions cause an exception or not. That in itself is nothing new, but in combination with "just-in-time" compilation of, say, x86 code to Transmeta microcode it might be. Particularly if the Transmeta processor uses horizontal microprogramming (read, "very very very long instruction word") to speed up the processing. (Loosely speaking, with horizontal microcode, each bit in the very long instruction word (could be hundreds of bits) maps to a discrete piece of logic (gate, flip/flop, etc) in the processor. Given an appropriate processor design it might be possible to map several instructions in a more vertical set (x86, PPC, etc) to a single wide microinstruction, effectively executing all of those in parallel, but then you really need some way of flushing everything if it screws up. Which this patent provides.)
(It'll be interesting to see if the active microcode store is loadable from RAM (making it end-user microprogrammable) or just from a fixed set of microprograms on ROM (which may live on the CPU die)).
I've seen some very wrong and some almost right answers posted here. Folks that grew up with a real Unix editor - 'ed' or even 'ex'/'vi' - know that it comes from the editor command 'g/re/p', for globabally search for regular expression and print (where 're' stands for arbitrary regular expression).
Now, if you want obscure name origins, there's 'awk'. (Named for the initials of the three authors).
Seems reasonable. As I mentioned above the idea of reloadable microcode machines goes back a long way, its just that nobody (AFAIK) has done a microprocessor that way. (They've come close -- there was a UCSD P-code chipset that used the same processor as the LSI-11 (PDP-11 architecture) but with a different microcode chip - suppose that microcode chip had been writeable?).
Given a fairly vanilla RISC core and a lot of on-chip writeable memory for the microcode, you're there. Optimizing it, parallelizing it, and coming up with quick ways of swapping microcode (to a different architecture) make it better. Really fast ways of swapping microcode (say on a context switch) and something like just-in-time compiling of new microcode to optimize an application's code make it better yet, and all this is within the realm of current state of the art.
You'd need a smart OS to manage it -- partly like VMware and partly like the way the Linux loader can invoke a JVM to run a Java class file (or the app of your choice to run the program types of your choice if you configure it).
If this isn't what Transmeta is doing, somebody else ought to. It's just too cool.
The multiple personality processor is not a new idea of course, although doing it as a microprocessor may be.
... etc)).
The Burroughs B1700 (as I recall) was one such user-microprogrammable CPU, with standard microprograms to optimize the architecture for running ALGOL programs, or for COBOL programs, and so on. I seem to recall from the same era a nanoprogrammable machine -- the nanocode was horizontal (very wide instruction word) and that reprogrammed the architecture on which the (vertical) microprograms ran (which reprogrammed
Doing all this on a microprocessor would be pretty neat (I'm trying to remember if Intel's iAPX 432 Ada chip had some of this capability). Being able to do it on the fly (at a context switch, say) from a micro- or nano-program cache would be doubly so.
Whether applications (or even the kernel) could be compiled down to the microinstruction level would very much depend on the specific memory architecture - microprogram words might be a totally different size from the main memory and transferring data/code between the two different memories could be too much of a bottleneck to run the application that way. But it probably wouldn't be necessary: a really smart compiler will optimize the top level instruction set for the program and generate the appropriate microcode for that instruction set. (Some work was done on this on the micro/nano programmable machines of back in the late 70's - I haven't followed it since then.)
Of course, for any such chip, being able to run native x86/PPC/you-name-it binaries would fall out as a natural given appropriate swappable microcode. Given techniques developed for Java machines like JIT, those binaries could even be recompiled on-the-fly into better microcode for improved performance over what the orginal chip would give. The trick comes in managing all this, which is where someone with operating system expertise comes in.
The problem with high levels of abstraction crop up when the abstract model isn't a good fit for the task or process you're trying to write code for. Bad as coding in C++ may be, it's easier than trying to change the business model. (That said, I've seen more bad C++ code than perhaps any other language -- I've also seen some very good C++ code).
I used to do a lot of development in APL -- now there's a language with a lot of high level abstraction, but it's oriented in a particular direction that is not necessarily a good fit for some of the things I've seen it applied to (email!? business management!?).
It may well be that the applications you're working on could in fact be better developed in ML or Haskell (I'm not familiar with either of those), but in the commercial world that's only one consideration. Other considerations are: who supports the develpment tools, and how big is the available pool of talent to support what gets built. I've beaten my head against that wall, too (I was an early adopter of C++ back in the 'cfront 1.0' days because the OO approach was a much better fit for some of the applications we were developing -- this in a UNIX/C shop that had just barely finished migrating some of their developers from VMS/FORTRAN. C++ has gone downhill since then, in my opinion.)