A variation was sold in Germany for many years (starting in the early 20s I believe) by Märklin, known more for model trains.
I got the largest one when I was like 4 or 5, and bought all expansions when I turned 21:-). I still have it and on occasion use it now, over 40 years later.
Meanwhile, does anyone remember the IAPX 432? It was a flop for several reasons: ADA flopped, its performance was bad, it was a real departure from the architectures of the day. But it had some real innovations - every function ran in its own protected space, using message passing for communication, and your program could protect itself from itself. Is it time to revisit that sort of architecture?
Very possibly... before the iAPX432 came out (I still own the original architecture manual), there was the Burrough x700 mainframe architecture. It had 48-bit words, each with a 3-bit tag... one of the tag values was reserved for executable code. It also used an indirect base+displacement pointer architecture which allowed hardware bounds checking.
I did quite a lot of kernel hacking on that as we had the full source code. Unless you did something stupid with the process dispatcher, it was impossible to overwrite memory or hang the system.
Elliott Organick wrote an excellent book on the architecture. I think with some modifications this would make an excellent (and fast!) Java machine...
The press release says "Kleopatra's interior arrangement of solid metal fragments and loose metallic rubble, and the geometry of fractures within any solid components, are unknown."
Note also that no actual photos are available - just computer reconstructions of radar echoes.
Suspending disbelief for a moment, this could as well be a generation-type starship... drive at one end, cargo/living space at the other end, a narrower structure holding both apart. And, of course, this would show up on radar as hollow spaces, smaller metallic "fragments", a metallic skin, and patterns which would be misinterpreted as "fractured" by anyone convinced that this must be a naturally-formed object.
I wrote: at least some basic facts should be checked before posting something like this... And you asked: Why?
For two reasons: 1) the joke's easier to understand if not cluttered up by factually wrong details, and 2) the point's less dependent of secondary jokes like the "running Onion" thing.
Tastes differ regarding to what's funny, but at least some basic facts should be checked before posting something like this...
RIO DE JANIERO It's "Rio de Janeiro". Brazilians speak Portuguese, not Spanish, although a recent poll showed that 60% of Americans are unaware of this.
Luis Sanchez, overlord of a drug cartel that stretches from the Cape Horn to the Bering Strait... "Sanchez" is a Spanish name - see above. And, aren't you thinking of Bolivia...?
...by a federal judge. Judge Roberto Gonzalez carried out the sentence at a Starbuck's coffee house... "Gonzalez" is again Spanish. You'll find "federal judges" in Brasília, the capital, not in Rio... they moved decades ago. Then again, 30% of Americans still think the capital is Buenos Aires:-) And, Starbucks in Brazil...? Now that is hilarious!
I suppose the rest of the names and statements might make sense to an American...
I generally like your post, but I'm not sure I agree with your logic on this part. It's trivially easy to find mechanical devices where you move something down to move something else up. If the widget you describe didn't survive, I suspect it was because it bet on the wrong horse, not that it violated any natural principle.
My point here was that in a situation where, to move something up, you can move a "handle" either down or up, moving the handle in the same direction will probably seem more "intuitive" to most people. In mechanical devices (think of a bow's rudder) often you see a direct linkage which helps you understand the relative movements. On-screen you don't have that sort of aid.
Also, of course, people can get used to anything - even to a command line:-). We're trying to find out how people who've never seen a particular widget before are likely to try to use it the first time. I agree there are many cases where there might not be any huge advantage one way or the other, but anything helps.
Two points... if I repeat myself, please bear with me.
Firstly, "intuitive" is a slippery word. There's "intuitive for power users", "intuitive for somewhat experienced users", and "intuitive for newbies". Some would say the last category is the empty set.
Metaphors are the key. Read John Lawler's 1987 lecture "Metaphors we compute by" for a quick intro on metaphor and metaphors in computing. The situation has unfortunately changed very little in the last 13 years. George Lakoff's book "Philosophy in the Flesh" shows how metaphors actually are the basic working units of the mind, and that all basic metaphors are based on sensory-motor concepts - in fact, sensory-motor neurons very probably do double duty as metaphor processors.
So, as long as one bases GUI metaphors on basic sensory-motor stuff - things like "time is space-like" (progress bars), "nearer means on top" (overlapping windows), and so forth - you have some chance of being more newbie-intuitive. I've used a prototype ancient GUI where scrollbars worked the other way around; the thumb moved down to scroll up for some reason the designer considered compelling, and it was pure hell to use. Needless to say it didn't survive.
Now, something I've noticed in most (thankfully not all) replies here is a restricted understanding of what a GUI should do. Yes, having icons represent files is useful; installing by running a single program and marking off some options is useful; using menus is often useful. But that's only a small part.
I've released an application for the Mac OS recently. As long as one uses the standard system calls, one gets the expected GUI functionality for basic items - that is, menus work like a Mac user thinks they should, windows drag, roll up, close and whatever. But I spent very little time on that - thanks to a neat C++ framework called PowerPlant - and spent much time making sure other things worked as Mac users are used to.
For instance, placement of the exact hot spot in cursors is important. Shift-click selection of long sections of text is important. Exact timing and graphical progression of drag-and-drop is important. Wording, defaults and back-out options in dialog boxes, sound cues, selection behavior - the list is very long. And the extra time spent on subtleties was rewarded by a five-star review where the reviewer said "I love using this program, but it's often hard to say why unless I watch very closely".
When I'm using CAD software I'm often forced to use Windows NT, and frankly, it's terrible. People argument there are Microsoft UI guidelines, but it seems most people either don't know them or think they're unimportant. For instance, in the PCB layout program I'm using right now, if you select a library component to place on the layout, you select the component from a list - OK, the cursor changes to a translucent image of the component - also OK, but if you want to click on the scroll bar to place the component somewhere else, the component is placed _under_ the scroll bar with no visual indication that the scroll bars are inactive! If you click on a tool palette the component is placed under the palette! If people don't think this sort of flagrant misbehavior is important, are they likely to worry about more subtle things? No way...
So, what the original article says about "skins" being just skin deep is very accurate. Most Linux programmers seem naturally disdainful of graphic interfaces and therefore are slapdash in implementing one. And reaching consensus among a large group about any particular GUI feature is nearly impossible. This is definitely a field where the "absolute dictator" method is the only one which may work - granted it may also fail spectacularly.
Well, I scored 70%, and it called me a, erh, ummh, "Jon Katz Wannabe".
Not that I've got anything against J.K. (I may be in a minority here), but it gave me pause...
In fact, I tried to shoot for "Microserf" but just didn't make it. Then again, knowing my karma points without going to my info page should have scored me a plus instead of a minus - right?
And I DID preview this at least 4 times! Yes!! So what?
BTW I had to post my score because I promised to do so on the test...
I'm sure few people have ever worked on a mainframe for any length of time, and many may even have a false concept of a mainframe as a huge, obsolete piece of equipment which obviously should be substituted by a Beowulf cluster or a multiple-CPU desktop (or near-desktop).
Well, it just isn't so. Granted that clusters and desktops may even equal a mainframe's raw processing power, but a mainframe's real strength lies in its massive I/O capacity... you can connect huge arrays (even RAID arrays) of high-speed disk drives and have them work near rated transfer speed. No desktop comes even close to that.
Over 25 years ago I worked on a Burroughs B6700 mainframe. We had full source (at zero cost) to the OS, compilers, utilities and so forth, and had a great time mucking around with these, fine-tuning stuff, fixing bugs and even implementing new Algol constructs. For some weird reason Burroughs rarely used our fixes, though:-). BTW we also had full hardware schematics - not that these were of much use...
Why does it matter whether unrelated projects use the same API or not? You choose the GUI and API that you fid most pleasant, or that best suits your application.
That's all right for the individual programmer/student, but not for someone trying to put a product on the market...
Jeez. I use emacs. The guy next to me is using VIM. What do I care? I can still read and write each other's files, right?
Jeez, that sounds so 20th-century:-)
Can you drag a range of text from an emacs window and drop-insert it into a vi window? Or can you drop a JPEG file from the desktop into your text? Or when you get some new application, do you have to learn all new command-keys and shortcuts, or recalibrate your muscle memory for the way the menus work and so forth?
Ugh, no. No standards on GUI, please. The great thing about using Linux is that there isn't just one way to do something. If we start forcing GUI standards on people, we'll get bloated window managers that don't serve the needs of particular people.
The worst thing about Linux is that there are too many ways to do something, and everybody and his aunt feels free to reinvent the wheel in his own way.
Well, that's not really the _worst_ thing, but it sure holds up people that wish to port some GUI-based application to Linux... if there's no commonly accepted API to call, you either have to include the whole GUI in your app - making it bloated and crash-prone - or you have to tie up to Gnome or KDE or whatever and pray that it either becomes the standard in the future, or at least survives long enough for your purposes.
Notice I'm not talking about visual appearances, but at least standard ways to set up menus, windows, and drag&drop...
The Palm IIIc's new Motorola 68VZ328 supports up to 640x512 screens, so this is simply a matter of messing with the case and display. Epson has a new line of glass-backed, ultrathin, 640x480 LCDs coming out... who knows?
The new CPU also has a second UART, and support for 2 banks of 32MB SDRAM... so we can also look forward to more memory.
If you don't have to run over copper, you can already get good gig-ethernet cards for under $300!! Do a search for the netgear ga620
I searched and found this quoted for $609.97, $649.95, and $512... None under $500. But I wouldn't be too surprised, as running over fiber obviates the need for the expensive interface chip and transformer.
Read the datasheet... this is just the physical interface transceiver, that is, the chip which interfaces the MAC chip (which implements the Ethernet protocol itself) with the line transformers.
To put things into perspective, National's own DP83843 chip, which does the same thing for 10/100 Ethernet, costs $5.50 in small quantities. A 10/100 MAC chip cost around $10, so we'll probably see $150-200 prices quoted for gigabit MACs... I doubt we'll see gigabit Ethernet cards under $500 this year.
On the other hand, previous transceivers cost over $250, so things are getting better... just look at 10/100, where a year ago you would pay $500 for a 10/100 8-port hub, today you can find a 10/100 _switch_ for under $150... probably next year gigabit prices will be at nearly this level.
Reading the review I was struck by the common fallacy that predetermination somehow demonstratesthe abscence of free will.
Another serious, and similar, fallacy is shown by Katz' words "is there really free will, or are conscience and consciousness merely byproducts of electricity, impulses, genes and molecules?".
The answer (of course;-)) is yes, there is "free will" - although what this exactly means is quite different from what the average person, or even the average philosophers, thinks it means - and yes, predetermination of a sort exists, and consciousness _is_ a byproduct of "electricity, impulses, genes and molecules".
Taking this in reverse order, I take exception with the word "merely". The fact that consciousness can emerge from these low-order (but neither trivial nor to be despised) material phenomena is something inherently marvelous and consciousness is all the more precious and remarkable because of it. Postulating some sort of "mental plane", "etheric impulse" or other undifferentiated dei ex machina just trivializes and demeans this issue... any two-bit deity can whip up some sort of consciousness with second-hand spiritual goo, but making it emerge from quantum physics is _real_ skill.
Predetermination here seems to mean that it's somehow demeaning (also in the sense of "losing all meaning") to "lack a common or universal goal beyond our pre-determined biological nature". I disagree. The universe is self-consistent, as its mere existence proves. No abstract goals are necessary; any concrete goals are by definition built-in to the hardware platform.
Regarding free will, the definite argument is given by Raymond Smullyan's "The Tao is Silent", which I recommend to all and sundry... he shows that God, if he exists at all, must necessarily be identical to the universe itself; that God, whether he exists or not, is a Taoist; and that "Free Will" (which Smullyan calls "Free Won't") _is_ necessary but is not what one thinks.
Well, I don't believe this is non-obvious. Over 15 years ago, in the first real-time embedded system I ever put on the market, I implemented a similar scheme: there was a kernel which gave priority to realtime interrupts (in fact the system spent 2/3 of its time in the interrupt routines) and the "idle" realtime task actually ran a simple GUI, which was essentially just an old-fashioned command-line system which executed one command for each button, and changed the display accordingly.
I've used variations of this on nearly all embedded systems I've done since. So I'm not sure this is patentable... not that I care enough to contest it. It's a good and workable idea which I'm sure has been rediscovered time and again by many people.
Unfortunately, today even the vast majority of ISPs have never heard of Usenet. In the more than 10 years I've been on the net, the only time I've been able to get reliable (and free) Usenet service outside of the USA was when I had my own ISP, and even then only for a short time, since even finding a reasonable upstream provider was nearly impossible.
Today I try to use one of the web-based newsgroup portals, but they're _slow_ and unreliable... as for web-based forums, unfortunately only/. and its offspring are useable. The others nearly all insist in doing that kinky Java/JavaScript stuff, which I prefer to leave permanently off.
Regarding signal-to-noise ratios, isn't there a law of applied thermodynamics which states "The sum of the IQs of Internet users is a constant"?:-)
Re:Why not just use the Crusoe as a G4?
on
Darwin on Crusoe?
·
· Score: 3
The Crusoe might well be a good emulator for the generic PowerPC architecture, but I doubt that it will be able to get any comparable performance emulating an AltiVec unit... and much of the G3/G4's non-AltiVec performance is due to the excellent backside cache implementation. I don't have Crusoe's specs handy at this moment, but their cache architecture will necessarily be less potent because of power constraints.
Now, a Crusoe implementation of PowerPC for a hand-held - a Color Palm running some subset of Mac OS X - that might be both feasible and interesting. Regarding other achitectures, porting has always been done at Apple for internal projects - starting with the defunct "StarTrek" port of System 7 to the x86 - but there's been talk for years about this or that port, with no product emerging. Now they're talking about a a modified AMD chip; but remember, there's a very heavy investment in PowerPC binaries, and PowerPC-optimizing compilers. Even if it's just a simple recompile (which it never is), you're talking about major manpower involvement...
MacOSRumors always makes for interesting reading, but it's just rumors, don't forget.
I've been an embedded developer for 15 years. For all of that, I've written my own small-scale RTOS and hacked a commercial (non-embedded) compiler/IDE to generate code for EPROM burning or downloading to the target machine - later ones did have a GUI, but this wasn't related to development. So that's my definition of "embedded".
I'm late in starting a new project which will use the ARM Thumb-based AT91F40416, a 32-bit chip with 2MB of embedded flash memory. One of the sticking points is the expense of specialized development systems - I've had quotes between $4K and $10K, which are over my limit at this time.
I've looked at several open-source options, like RTLinux, eCOS, ucLinux and so forth, but user-friendliness (in the strict sense) isn't a feature... most of them seem to assume that you're developing for the x86 architecture, or necessarily want to use a Linux or BSD machine as a development system (which I definitely don't).
Look at the Palm development system based on CodeWarrior: you get a standard IDE, debugger, and a Palm simulator box to run things in. The linker grabs the PalmOS as a library, or if one had the source to that, one could build stuff directly into the PalmOS. This is the ideal way to write an embedded system, IMHO. Until somebody develops a similar way for me to write my own stuff to, say RTLinux' API, but will all the facilites I'm used to, and then just compile/link the kernel with that into a ROM image, I won't be a convert to embedded Linux. Sorry...
What I've noticed is that most of the data we're accumulating is quickly becoming useless. 10 year old schoolwork isn't something so worthy of archiving.
Amen to that. I've recently had occasion to look over my accumulation of old data. Item: - a 6-foot stack of source code, punch cards, old Algol and FORTRAN programs. Unreadable by current hardware. Value:zero/sentimental. - one 1200-foot, 9-track, 1200-dpi, magnetic tape. Content:More Algol programs, complete database for printing out a 6-by-9 ft. Playboy poster on a Burroughs high-speed line printer. Unreadable by current hardware. Value:zero. - a stack of Apple ][ disk with "all Apple ][ software ever written". Unreadable by current hardware. Value:near-zero. - A couple of thousand 400K diskettes containing Mac System 1.0, Microsoft Word 1.0, Adobe Photoshop 1.0 and similar stuff. Unreadable by current hardware. Value:who knows? - several Syquest 44MB cartridges and drive, incompatible containing "important backups". Incompatible with current hardware/software. Value:zero. - several Ricoh optical cartridges and drive, ditto, ditto. - several dozen DAT DDS-II backup tapes and drive, containing "backups of everything!". Can still be read on occasion, but it's been over a year since I _had_ to. Value:who knows?
All the important stuff is constantly migrating from hard drive to hard drive, anyway. Granted, I'm an individual programmer - a company or institution will view things differently, but I don't worry...
The first ever consulting call (for a microcomputer, that is) which I got was for one of these Pets. The guy, a rich flying-saucer enthusiast, led me to a UFO replica constructed in his backyard - stuffed full with parabolic antennas, state-of-the-art audio/video equipment, and the Pet - the first Commodore I'd ever seen. I had just bought an Apple ][ at the time... this was in '78 or '79, IIRC.
His complaint was that the computer crashed at inappropriate moments. I asked him to try to reproduce the error. He loaded a program from cassette tape and ran it - and it indeed crashed. I listed the program and as near as I can recall, it: - defined a huge array of characters - cleared it to blanks - printed "O divine ETs, send me a message" - scanned the character array for a reply - looped until a message was found.
:-)
I ran some other test programs and they crashed too, so my guess was that it was a hardware problem - probably interference from the UFO's warp drive - which was beyond my skills at the time. I waived my fee and got the hell out of there before the UFO took off.
Regarding specs - I looked at the other articles from 1978, and was nostalgic for the time when the Playmates weren't overclocked, productized, and siliconized. What a pity... today my wife has a subscription to Playboy, and we _both_ read it for the articles:-(
...such advances usually follow an S-shaped curve.
At first progress is slow while basic research is done and understanding of the whole thing grows slowly - almost linearly. Then when a certain critical mass is reached, suddenly the pieces start coming together, interaction with other fields opens up zillions of new insights and applications, and adoption of the technology grows almost exponentially. Finally, either market saturation or some other fundamental limitation starts making its effects felt and the growth tends to become horizontal again.
There've been many "new technology" news items posted on/., and it seems there are 4 main opinion groups - "Yeeha! Where can I buy this?", "Cool, if it were possible, which it ain't", "(yawn) Been there, done that - see URL", and as always the "petrified Beowulf cluster of Natalie Portmans" contingent (if I got this right:-)). But I'd like to ask people who actually are connected to serious nanotech research to post something about what level in the S-cruve they're really in at this time...
It's called the Sapir-Whorf hypothesis (although there's some debate as to whether either Sapir of Whorf had anything to do about it) and is not widely held to be true among linguists.
In its original, somewhat radical form, Sapir-Whorf is obsolete, but from my linguist friends (I'm only an amateur, myself) I hear a weakened concept of it survives. I speak four Indo-European languages (and understand a few more), and there are many concepts which aren't easily translatable from one to the other; or at least can't be expressed without a lengthy explanation. So any given language doesn't necessarily limit what and how you can think, but it channels what you try to communicate into its own well-worn grooves.
Regarding programming languages, I'd say Sapir-Whorf is applicable in many circumstances. Once you learn, say, C++ templates, you can use them to solve certain classes of problems very easily, and this leads you to visualize a complex system in a different way. For several years I programmed a Burroughs 6700-series mainframe in a modified Algol, which had very powerful string find, search and replace commands - which actually mapped directly to the hardware - and this actually led me to work in a wholly different way from the way I did things before.
So a programming language channels your thinking and often even leads to the well-known syndrome of "To he who owns a hammer, the whole world looks like a nail". Yes, you could write a compiler in Object COBOL (known to its victims as "POST INCREMENT COBOL BY ONE"), but please don't ask me to...
If the next generation of languages allows me to abstract these differences and use one language with different toolkits (in principle I suppose this is possible with today's languages), I'm all for it.
Historically all such attempts have either failed outright, or not been popular - witness the Ada language, which tried to be all things to all people. As long as we're limited to writing programs, or parts of programs, in text form I doubt we're going to see this. And 100% visual languages (like ProGraph) won't see wide acceptance until we get better gestural input devices.
Quite a good article in fact. I've never programmed in UnrealScript and little in Java, but I agree with the author's conclusions about C++. I've not had the time to analyze his "virtual class" concept thoroughly, but I'd like to point out that very similar mechanisms have already existed two decades ago in SmallTalk - and are in daily use in Objective C, which is in several respects just SmallTalk with C syntax.
When I started out in programming 31 years ago [mumbled the old geezer;-)] I bought Jean Sammet's classic book "Programmi ng Languages:History and Fundamentals", a two-inch thick thing with not overly detailed descriptions of nearly a hundred programming languages. I've actually managed to work in over a dozen of those, as well as several modern ones, and about 20 assembly "languages" - it's been a while since I counted those separately, as nowadays one thinks of a single Assembly language with trivial variations for each CPU or MPU. Nearly all of those languages are extinct, I suppose. Remember, for instance, the Algol 68 disaster? An evolutionary dead-end which advanced compiler theory a lot, but has no descendants today... I could go on for a couple of pages, but will spare you.
That said, I think the author's conclusions are valid for his chosen field - games for desktop computers. In embedded systems, C++ or even C is a perfectly valid way to go, since one usually has either the whole source avaliable and compiling/linking together, or one has reasonably static library components. And in the smaller MPU/MCU universe, one is back in the olden days of 8K code space, 128 bytes of RAM, and bit-twiddling to save space or time...
Regarding the non-games desktop arena, I definitely think that some evolution of NeXTstep (aka Apple's Cocoa) will point the way for the next 10 years. I'm starting to learn that now, the learning curve is a little steep, but it's very powerful stuff.
Slashdot Mirror
Even better coverage of anything whatsoever:
"The worlds most powerful metadisclaimer"
I got the largest one when I was like 4 or 5, and bought all expansions when I turned 21 :-). I still have it and on occasion use it now, over 40 years later.
Unfortunately they apparently stopped making them. There are some photos at http://home.t-online.de/home/HGFinke/metall/engl.h tml.
Very possibly... before the iAPX432 came out (I still own the original architecture manual), there was the Burrough x700 mainframe architecture. It had 48-bit words, each with a 3-bit tag... one of the tag values was reserved for executable code. It also used an indirect base+displacement pointer architecture which allowed hardware bounds checking.
I did quite a lot of kernel hacking on that as we had the full source code. Unless you did something stupid with the process dispatcher, it was impossible to overwrite memory or hang the system.
Elliott Organick wrote an excellent book on the architecture. I think with some modifications this would make an excellent (and fast!) Java machine...
Note also that no actual photos are available - just computer reconstructions of radar echoes.
Suspending disbelief for a moment, this could as well be a generation-type starship... drive at one end, cargo/living space at the other end, a narrower structure holding both apart. And, of course, this would show up on radar as hollow spaces, smaller metallic "fragments", a metallic skin, and patterns which would be misinterpreted as "fractured" by anyone convinced that this must be a naturally-formed object.
at least some basic facts should be checked before posting something like this...
And you asked:
Why?
For two reasons:
1) the joke's easier to understand if not cluttered up by factually wrong details, and
2) the point's less dependent of secondary jokes like the "running Onion" thing.
Here's some advice: It's a joke. Lighten up. :-)
Hey, I said "NITS", didn't I...? ;-)
RIO DE JANIERO
It's "Rio de Janeiro". Brazilians speak Portuguese, not Spanish, although a recent poll showed that 60% of Americans are unaware of this.
Luis Sanchez, overlord of a drug cartel that stretches from the Cape Horn to the Bering Strait...
"Sanchez" is a Spanish name - see above. And, aren't you thinking of Bolivia...?
"Gonzalez" is again Spanish. You'll find "federal judges" in Brasília, the capital, not in Rio... they moved decades ago. Then again, 30% of Americans still think the capital is Buenos Aires
And, Starbucks in Brazil...? Now that is hilarious!
I suppose the rest of the names and statements might make sense to an American...
My point here was that in a situation where, to move something up, you can move a "handle" either down or up, moving the handle in the same direction will probably seem more "intuitive" to most people. In mechanical devices (think of a bow's rudder) often you see a direct linkage which helps you understand the relative movements. On-screen you don't have that sort of aid.
Also, of course, people can get used to anything - even to a command line :-). We're trying to find out how people who've never seen a particular widget before are likely to try to use it the first time. I agree there are many cases where there might not be any huge advantage one way or the other, but anything helps.
Firstly, "intuitive" is a slippery word. There's "intuitive for power users", "intuitive for somewhat experienced users", and "intuitive for newbies". Some would say the last category is the empty set.
Metaphors are the key. Read John Lawler's 1987 lecture "Metaphors we compute by" for a quick intro on metaphor and metaphors in computing. The situation has unfortunately changed very little in the last 13 years. George Lakoff's book "Philosophy in the Flesh" shows how metaphors actually are the basic working units of the mind, and that all basic metaphors are based on sensory-motor concepts - in fact, sensory-motor neurons very probably do double duty as metaphor processors.
So, as long as one bases GUI metaphors on basic sensory-motor stuff - things like "time is space-like" (progress bars), "nearer means on top" (overlapping windows), and so forth - you have some chance of being more newbie-intuitive. I've used a prototype ancient GUI where scrollbars worked the other way around; the thumb moved down to scroll up for some reason the designer considered compelling, and it was pure hell to use. Needless to say it didn't survive.
Now, something I've noticed in most (thankfully not all) replies here is a restricted understanding of what a GUI should do. Yes, having icons represent files is useful; installing by running a single program and marking off some options is useful; using menus is often useful. But that's only a small part.
I've released an application for the Mac OS recently. As long as one uses the standard system calls, one gets the expected GUI functionality for basic items - that is, menus work like a Mac user thinks they should, windows drag, roll up, close and whatever. But I spent very little time on that - thanks to a neat C++ framework called PowerPlant - and spent much time making sure other things worked as Mac users are used to.
For instance, placement of the exact hot spot in cursors is important. Shift-click selection of long sections of text is important. Exact timing and graphical progression of drag-and-drop is important. Wording, defaults and back-out options in dialog boxes, sound cues, selection behavior - the list is very long. And the extra time spent on subtleties was rewarded by a five-star review where the reviewer said "I love using this program, but it's often hard to say why unless I watch very closely".
When I'm using CAD software I'm often forced to use Windows NT, and frankly, it's terrible. People argument there are Microsoft UI guidelines, but it seems most people either don't know them or think they're unimportant. For instance, in the PCB layout program I'm using right now, if you select a library component to place on the layout, you select the component from a list - OK, the cursor changes to a translucent image of the component - also OK, but if you want to click on the scroll bar to place the component somewhere else, the component is placed _under_ the scroll bar with no visual indication that the scroll bars are inactive! If you click on a tool palette the component is placed under the palette! If people don't think this sort of flagrant misbehavior is important, are they likely to worry about more subtle things? No way...
So, what the original article says about "skins" being just skin deep is very accurate. Most Linux programmers seem naturally disdainful of graphic interfaces and therefore are slapdash in implementing one. And reaching consensus among a large group about any particular GUI feature is nearly impossible. This is definitely a field where the "absolute dictator" method is the only one which may work - granted it may also fail spectacularly.
Not that I've got anything against J.K. (I may be in a minority here), but it gave me pause...
In fact, I tried to shoot for "Microserf" but just didn't make it. Then again, knowing my karma points without going to my info page should have scored me a plus instead of a minus - right?
And I DID preview this at least 4 times! Yes!! So what?
BTW I had to post my score because I promised to do so on the test...
Well, it just isn't so. Granted that clusters and desktops may even equal a mainframe's raw processing power, but a mainframe's real strength lies in its massive I/O capacity... you can connect huge arrays (even RAID arrays) of high-speed disk drives and have them work near rated transfer speed. No desktop comes even close to that.
Over 25 years ago I worked on a Burroughs B6700 mainframe. We had full source (at zero cost) to the OS, compilers, utilities and so forth, and had a great time mucking around with these, fine-tuning stuff, fixing bugs and even implementing new Algol constructs. For some weird reason Burroughs rarely used our fixes, though :-). BTW we also had full hardware schematics - not that these were of much use...
You choose the GUI and API that you fid most pleasant, or that best suits your application.
That's all right for the individual programmer/student, but not for someone trying to put a product on the market...
Jeez. I use emacs. The guy next to me is using VIM. What do I care? I can still read and write each other's files, right?
Jeez, that sounds so 20th-century :-)
Can you drag a range of text from an emacs window and drop-insert it into a vi window? Or can you drop a JPEG file from the desktop into your text? Or when you get some new application, do you have to learn all new command-keys and shortcuts, or recalibrate your muscle memory for the way the menus work and so forth?
That's what a standard GUI API is for...
The worst thing about Linux is that there are too many ways to do something, and everybody and his aunt feels free to reinvent the wheel in his own way.
Well, that's not really the _worst_ thing, but it sure holds up people that wish to port some GUI-based application to Linux... if there's no commonly accepted API to call, you either have to include the whole GUI in your app - making it bloated and crash-prone - or you have to tie up to Gnome or KDE or whatever and pray that it either becomes the standard in the future, or at least survives long enough for your purposes.
Notice I'm not talking about visual appearances, but at least standard ways to set up menus, windows, and drag&drop...
The new CPU also has a second UART, and support for 2 banks of 32MB SDRAM... so we can also look forward to more memory.
Do a search for the netgear ga620
I searched and found this quoted for $609.97, $649.95, and $512... None under $500. But I wouldn't be too surprised, as running over fiber obviates the need for the expensive interface chip and transformer.
To put things into perspective, National's own DP83843 chip, which does the same thing for 10/100 Ethernet, costs $5.50 in small quantities. A 10/100 MAC chip cost around $10, so we'll probably see $150-200 prices quoted for gigabit MACs... I doubt we'll see gigabit Ethernet cards under $500 this year.
On the other hand, previous transceivers cost over $250, so things are getting better... just look at 10/100, where a year ago you would pay $500 for a 10/100 8-port hub, today you can find a 10/100 _switch_ for under $150... probably next year gigabit prices will be at nearly this level.
Another serious, and similar, fallacy is shown by Katz' words "is there really free will, or are conscience and consciousness merely byproducts of electricity, impulses, genes and molecules?".
The answer (of course ;-)) is yes, there is "free will" - although what this exactly means is quite different from what the average person, or even the average philosophers, thinks it means - and yes, predetermination of a sort exists, and consciousness _is_ a byproduct of "electricity, impulses, genes and molecules".
Taking this in reverse order, I take exception with the word "merely". The fact that consciousness can emerge from these low-order (but neither trivial nor to be despised) material phenomena is something inherently marvelous and consciousness is all the more precious and remarkable because of it. Postulating some sort of "mental plane", "etheric impulse" or other undifferentiated dei ex machina just trivializes and demeans this issue... any two-bit deity can whip up some sort of consciousness with second-hand spiritual goo, but making it emerge from quantum physics is _real_ skill.
Predetermination here seems to mean that it's somehow demeaning (also in the sense of "losing all meaning") to "lack a common or universal goal beyond our pre-determined biological nature". I disagree. The universe is self-consistent, as its mere existence proves. No abstract goals are necessary; any concrete goals are by definition built-in to the hardware platform.
Regarding free will, the definite argument is given by Raymond Smullyan's "The Tao is Silent", which I recommend to all and sundry... he shows that God, if he exists at all, must necessarily be identical to the universe itself; that God, whether he exists or not, is a Taoist; and that "Free Will" (which Smullyan calls "Free Won't") _is_ necessary but is not what one thinks.
I've used variations of this on nearly all embedded systems I've done since. So I'm not sure this is patentable... not that I care enough to contest it. It's a good and workable idea which I'm sure has been rediscovered time and again by many people.
Today I try to use one of the web-based newsgroup portals, but they're _slow_ and unreliable... as for web-based forums, unfortunately only /. and its offspring are useable. The others nearly all insist in doing that kinky Java/JavaScript stuff, which I prefer to leave permanently off.
Regarding signal-to-noise ratios, isn't there a law of applied thermodynamics which states "The sum of the IQs of Internet users is a constant"? :-)
Now, a Crusoe implementation of PowerPC for a hand-held - a Color Palm running some subset of Mac OS X - that might be both feasible and interesting. Regarding other achitectures, porting has always been done at Apple for internal projects - starting with the defunct "StarTrek" port of System 7 to the x86 - but there's been talk for years about this or that port, with no product emerging. Now they're talking about a a modified AMD chip; but remember, there's a very heavy investment in PowerPC binaries, and PowerPC-optimizing compilers. Even if it's just a simple recompile (which it never is), you're talking about major manpower involvement...
MacOSRumors always makes for interesting reading, but it's just rumors, don't forget.
I'm late in starting a new project which will use the ARM Thumb-based AT91F40416, a 32-bit chip with 2MB of embedded flash memory. One of the sticking points is the expense of specialized development systems - I've had quotes between $4K and $10K, which are over my limit at this time.
I've looked at several open-source options, like RTLinux, eCOS, ucLinux and so forth, but user-friendliness (in the strict sense) isn't a feature... most of them seem to assume that you're developing for the x86 architecture, or necessarily want to use a Linux or BSD machine as a development system (which I definitely don't).
Look at the Palm development system based on CodeWarrior: you get a standard IDE, debugger, and a Palm simulator box to run things in. The linker grabs the PalmOS as a library, or if one had the source to that, one could build stuff directly into the PalmOS. This is the ideal way to write an embedded system, IMHO. Until somebody develops a similar way for me to write my own stuff to, say RTLinux' API, but will all the facilites I'm used to, and then just compile/link the kernel with that into a ROM image, I won't be a convert to embedded Linux. Sorry...
Amen to that. I've recently had occasion to look over my accumulation of old data. Item:
- a 6-foot stack of source code, punch cards, old Algol and FORTRAN programs. Unreadable by current hardware. Value:zero/sentimental.
- one 1200-foot, 9-track, 1200-dpi, magnetic tape. Content:More Algol programs, complete database for printing out a 6-by-9 ft. Playboy poster on a Burroughs high-speed line printer. Unreadable by current hardware. Value:zero.
- a stack of Apple ][ disk with "all Apple ][ software ever written". Unreadable by current hardware. Value:near-zero.
- A couple of thousand 400K diskettes containing Mac System 1.0, Microsoft Word 1.0, Adobe Photoshop 1.0 and similar stuff. Unreadable by current hardware. Value:who knows?
- several Syquest 44MB cartridges and drive, incompatible containing "important backups". Incompatible with current hardware/software. Value:zero.
- several Ricoh optical cartridges and drive, ditto, ditto.
- several dozen DAT DDS-II backup tapes and drive, containing "backups of everything!". Can still be read on occasion, but it's been over a year since I _had_ to. Value:who knows?
All the important stuff is constantly migrating from hard drive to hard drive, anyway. Granted, I'm an individual programmer - a company or institution will view things differently, but I don't worry...
His complaint was that the computer crashed at inappropriate moments. I asked him to try to reproduce the error. He loaded a program from cassette tape and ran it - and it indeed crashed. I listed the program and as near as I can recall, it:
- defined a huge array of characters
- cleared it to blanks
- printed "O divine ETs, send me a message"
- scanned the character array for a reply
- looped until a message was found.
:-)
I ran some other test programs and they crashed too, so my guess was that it was a hardware problem - probably interference from the UFO's warp drive - which was beyond my skills at the time. I waived my fee and got the hell out of there before the UFO took off.
Regarding specs - I looked at the other articles from 1978, and was nostalgic for the time when the Playmates weren't overclocked, productized, and siliconized. What a pity... today my wife has a subscription to Playboy, and we _both_ read it for the articles :-(
At first progress is slow while basic research is done and understanding of the whole thing grows slowly - almost linearly. Then when a certain critical mass is reached, suddenly the pieces start coming together, interaction with other fields opens up zillions of new insights and applications, and adoption of the technology grows almost exponentially. Finally, either market saturation or some other fundamental limitation starts making its effects felt and the growth tends to become horizontal again.
There've been many "new technology" news items posted on /., and it seems there are 4 main opinion groups - "Yeeha! Where can I buy this?", "Cool, if it were possible, which it ain't", "(yawn) Been there, done that - see URL", and as always the "petrified Beowulf cluster of Natalie Portmans" contingent (if I got this right :-)). But I'd like to ask people who actually are connected to serious nanotech research to post something about what level in the S-cruve they're really in at this time...
In its original, somewhat radical form, Sapir-Whorf is obsolete, but from my linguist friends (I'm only an amateur, myself) I hear a weakened concept of it survives. I speak four Indo-European languages (and understand a few more), and there are many concepts which aren't easily translatable from one to the other; or at least can't be expressed without a lengthy explanation. So any given language doesn't necessarily limit what and how you can think, but it channels what you try to communicate into its own well-worn grooves.
Regarding programming languages, I'd say Sapir-Whorf is applicable in many circumstances. Once you learn, say, C++ templates, you can use them to solve certain classes of problems very easily, and this leads you to visualize a complex system in a different way. For several years I programmed a Burroughs 6700-series mainframe in a modified Algol, which had very powerful string find, search and replace commands - which actually mapped directly to the hardware - and this actually led me to work in a wholly different way from the way I did things before.
So a programming language channels your thinking and often even leads to the well-known syndrome of "To he who owns a hammer, the whole world looks like a nail". Yes, you could write a compiler in Object COBOL (known to its victims as "POST INCREMENT COBOL BY ONE"), but please don't ask me to...
If the next generation of languages allows me to abstract these differences and use one language with different toolkits (in principle I suppose this is possible with today's languages), I'm all for it.
Historically all such attempts have either failed outright, or not been popular - witness the Ada language, which tried to be all things to all people. As long as we're limited to writing programs, or parts of programs, in text form I doubt we're going to see this. And 100% visual languages (like ProGraph) won't see wide acceptance until we get better gestural input devices.
When I started out in programming 31 years ago [mumbled the old geezer ;-)] I bought Jean Sammet's classic book "Programmi ng Languages:History and Fundamentals", a two-inch thick thing with not overly detailed descriptions of nearly a hundred programming languages. I've actually managed to work in over a dozen of those, as well as several modern ones, and about 20 assembly "languages" - it's been a while since I counted those separately, as nowadays one thinks of a single Assembly language with trivial variations for each CPU or MPU. Nearly all of those languages are extinct, I suppose. Remember, for instance, the Algol 68 disaster? An evolutionary dead-end which advanced compiler theory a lot, but has no descendants today... I could go on for a couple of pages, but will spare you.
That said, I think the author's conclusions are valid for his chosen field - games for desktop computers. In embedded systems, C++ or even C is a perfectly valid way to go, since one usually has either the whole source avaliable and compiling/linking together, or one has reasonably static library components. And in the smaller MPU/MCU universe, one is back in the olden days of 8K code space, 128 bytes of RAM, and bit-twiddling to save space or time...
Regarding the non-games desktop arena, I definitely think that some evolution of NeXTstep (aka Apple's Cocoa) will point the way for the next 10 years. I'm starting to learn that now, the learning curve is a little steep, but it's very powerful stuff.