You underestimate the problem. The OLPC is quite slow, has very large screen (1200x900) and no hardware acceleration to speak about, so it isn't even fast enough to do fullscreen refreshes at good framerates, let alone draw anything half complex while doing so.
If it's really that bad then it seems they chose a poor place to cut a few dollars out of the cost. You'd think that things like video (educational, video conferencing), games (educational, fun), animations would be exactly the sort of thing the target usage would call for, never mind the anticipated requirements of the UI.
OTOH a zooming interface doesn't even need to run at 30fps to look good - you just want it to be highly responsive to the controls, and show something clearly recognizable (but not necessarily full resolution) while zooming. I remember real-time arcade games like asteroids, space invaders and sideways-scroller games playing quite happily on the old c.1980 8-bit systems with 1MHz closk speeds and zero display acceleration, so I still maintain that you can do a very acceptible version of zooming on low powered hardware.
Note also that a zooming interface doesn't need to do full-screeen refreshes - you just need to clear-to-background any parts that you arn't about to overwrite at the new zoom level. If zooming IN there's probably nothing to be erased. With a sparse sceene like Sugar's "neigborhood view" (more background than foreground) this type of optimization vs full-screen updates would be a massive speed-up.
I'd have to guess that most planes lost in Vietnam weren't due to SAMs firing at targets that were only visible to radar. Most losses were more likely up-close and personal - dogfights and AA fire aimed at clearly visible planes on low-level bombing runs.
I don't think a zooming interface needs a lot of CPU if done right - Qt's QGraphicsView widget supports zooming on a massive hierarchy (millions of sub-widgets) very efficiently. The display code (in this case the Qt library) just needs to be smart so that it doesn't actually draw things that are too small to be seen or are obscured by other objects. The Qt widgets sit atop a VERY effifient Qt drawing library with multiple backends... Qt's own raster engine is much faster than many native drawing APIs and always available, but they also support OpenGL and recently OpenVL (a 2-D accelerated API for low-powered things like smart phones). If you download the free version of Qt there's a precompiled demo of it you can try.
To me the issue is just that this is a flashy but not very usable interface. It would work as a "discovery" interface if I want to see what Sugar users are located in some village in another country (rather like Google earth - zoom out, move, then zoom back in), but it's hardly the best way to select between a small number of other users that you may actually be interacting with on a daily basis. An clickable set of photos of those users (maybe with online indication shown too), displayed on a single page regardless of their physical location, would be much nicer and more productive to use.
The intial interface showing what I assume is the "neighborhood" view of other Sugar users/machines (arranged in cum-by-ya campfire circles) is cute, but seems more designed for a Movie than for actual use (cf Jurassic Park's "Oh, it's Unix! I know that!" interface where they zoom down from a building view to an individual computer).
One you get past this odd and confusing initial user interface it seems you're using traditional apps like the Editor/Word Processor they show.
Maybe there are other elements of Sugar that are better designed or more innovative, but the demo doesn't seem too compelling.
Audio on Linux has been bad for 10 years, its not getting any better and ALSA is more the problem than the solution, as are all the hacks like pulse, esd, arts, gstreamer, etc.
GStreamer isn't an audio API. It's the Linux version of DirectShow - i.e. a multi-media framework for building decoding/encoding graphs/pipelines.
e.g. Say you want to play a DVD. Your GStreamer-based player invokes GStreamer to build a decoding pipeline that reads the DVD, demuxes it into video and audio streams, decodes each stream in parallel, maybe applies some filters, then outputs them the the chosen sink. In the case of the audio stream the sink (for a player app) would be an audio API.
I expect the "explicitometer" is just the same exact same none/moderate/strict classification that both Google and Bing's "Safe Search" preferences offer.
This change by Bing isn't some big brother restriction on your porn viewing... it's just coming closer** to honoring your wishes by not allowing you to view porn sites that you, yourself, have already chosen to block via Open DNS, Net Nanny or whatever!
** Of course, you can still see Microsoft hosted thumbnails (incl. videos) from sites that you've chosen to block but Microsoft hasn't classified as explicit, and Google does no better with their image thumbnails.
I don't expect that the image or video results you get with Bing vs Google at any preferred level of "safe search" filtering are much different, and that's not going to change with this announcement.
All the Bing change does, rather belatedly, is stop overriding parental controls (Open DNS, Net Nanny, etc) that would block porn domains. What happens up until now is that Bing self-hosts all it's image/video thumbnails from it's own servers - porn included - and starts to play these thumbnail videos automatically - direct from Microsoft's servers - when you mouseover them. Since the videos are coming from a Microsoft domain rather than a porn domain, parental porn filters are bypassed.
All the Bing change does is to move Microsoft's porn video reviews from bing.com to microsofts-hard-core-porn-server.bing.com so that Open DNS, Net Nanny, etc can once again be used to block this stuff.
But the Twitter guy wasn't the one to get his C64 on the internet - that was a given. He just plugged a C64 ethernet adapter into his C64 (MMC replay expansion box with RR-net ethernet daughtercard), and installed an OS (Contiki) on his C64 that already had a working TCP/IP stack and a ethernet driver. He didn't use 6502 assembler either - he used the CC65 'C' cross-compiler.
So, basically the guy wrote a Twitter client in C, on a fairly full-featured OS that includes TCP/IP support.
Let's note too that the guy himself was totally open about all this in TFA, and even noted:
Although primarely [sic] programmed for the C64 BREADBOX64 should compile for other systems using Contiki. The only C64 specific code relates to the little bird at the top of the screen, which is actually a sprite.
So, I'd have to agree with the parent - not a hack, just implementing a Twitter client in C.
Writing a Twitter client is also not a hack - they have a public API (XML based):
There's obviously a lot of truth to the ease of programming using high level tools, and standing on other's shoulders, but back in the day we made do with what we had. I used to work for Acorn Computers (UK) back in 1982, and was one half of the team that implemented ISO Pascal for the 6502-based BBC Micro...
The project was divided into two halves (shipped on two 16K EPROMS), one half being a stack-based virtual instruction set for the compiler to target (to get reasonable code density), Pascal run-time libraries (I/O, floating point, heap, etc), a decent screen editor including regex search/replace etc, a command line interpreter... this all written in 6502 assembler developed on a BBC micro using it's own BBC BASIC inline assember... and the other half being the Pascal compiler which was written in Pascal and self-compiled. We did bootstrap the compiler using an existing one on another (equally slow!) system, but as soon as it could self-compile we moved all development to the BBC micro.
It's really not so bad to bootstrap yourself up from assembler to decent development tools. Write a very minimal C/whatever compiler in assembler, then write a better one in that language/etc, and repeat!
Actually, if you RTFA, he didn't develop the TCP/IP interface.
This project uses an "MMC replay" C64 expansion box with an RR-net ethernet daughterboard installed. He wrote the Twitter client to run on the Contiki OS, which comes with a built-in TCP/IP stack and a driver for the RR-card. Credit for Contiki and it's uIP TCP/IP stack go primarily to Adam Dunkels:
The accomplishment of the C64 Twitter client's author is really more about writing a Twitter client with one hand tied behind your back rather than really being C64 specific. He wrote it in C (CC65 6502 compiler) on Contiki, so the fact that it happens to be running on a C64 as opposed to any other environment that supports Contiki is somewhat irrelevant.
Whether it scores any points for complexity really depends on your level of experience. Given that the./ readership has become less and less hard core over the years, I think there are many people here who should be avoiding this guy's front lawn. At least, if you've never written any networking code in your life, how about firing up Linux, or installing MinGW (maybe roughly comparable to installing Contiki and CC65 on a C64), then writing your own Twitter client... It certainly won't be a waste of time if you learn how to do socket programming as a result.
Right, and someone blocking your view of the screen (or the screen's view of you) isn't normally a problem when you're playing games. You can just keep on playing while they are blocking you, eh?
IMO universities should be teaching core principles and methods, not attempting to impart up-to-date job skills.
If you are going to teach FORTRAN because it's of use in the real world, then why stop there? Why not also (god forbid) teach.NET. JavaScript, C#, etc. May as well teach them Excel macros and how to interact with Microsoft Clippy while you're at it.
No!
Teaching programming should be done in a langauge that imparts the principles easily and teaches good habits. You could do a lot worse than Pascal which was often used in this role, or maybe today just C++. I'd argue against Java and scripting languages as the core language since they are too high level to learn all the basics. You could throw in Perl, Python or any modern scripting langauge as a secondary, and for a Computer Science (vs. Physics, Engineering, etc) it's appropriate to teach a couple of other styles of programming - e.g. assembler, and functional programming.
I think "animatronic toy" is being a bit dismissive, even if it didn't live up to the hype.
It's really an autonomous robot that learns and reacts to the environment - it's not just a robot with a remote or a canned set of moves.
That said, the degree of learning and autonomy it displays seems to be rather limited, although the promise was for this to be imporoved in subsequent software releases.
The reason you, as a Slashdot denizen, should care, is:
1) As an autonomous robot - with vision and hearing - it is pretty cool.
2) It's eminently hackable, and really an excellent value as a chunk of mechanics and electronics.
But battery consumption is not good. It will work for 2.5 hours on one charge.
That's amazingly bad! I thought Freescale = ARM (= low power), but maybe not.
Yesterday's article about the range of ARM based netbooks at Computex mentioned battery life of 8-12 hours, so this isn't even remotely in the ballpark.
It'd be interesting if RiscOS gave some benefit that the other ARM OS options don't, but given that these ARM based netbooks also support the latest Ubuntu, Android, Windows CE (these latter two could also be considered as written for the ARM - that's what most smart phones/handhelds use), it's hard to see what RiscOS brings to the table. Let's not forget that the ARM also powers the BSD/Unix powered iPhone quite happily. It's a powerful little beast - ARM sells over 4 BILLION ARM cores a year!
Problem is, they think they want to make a "Linux" app, but they really want to make a Gnome app or a KDE app.
Exactly, or even more so.... There's no such thing as a Linux app, because there's no such thing as a Linux API.
There's no point whining about it - you just make your choice and go with it. Qt or GTK+. For audio you may as well write to ALSA in the knowledge that it can be routed through any of the myriad alternatives if anyone wants to.
Xlib... and then what for widgets? If not Qt or GTK (and I assume you're not advocating Xt/Motif), then I suppose you're suggesting they introduce even more Linux GUI/HIG/theming incompatability and write their own UI/widget library? (as they did for Android!)
Well, we're talking tens if not ultimately hundreds of billions here, which makes a big difference.
That said, if we're only talking billions, how about the $6 billion Microsoft spent developing Vista. Heck, Microsoft spend about $1.5 billion a year just in advertizing!
I vaguely remember one RCA1802 board that may be the PE one your talking about - it had a plastic "bubble" covering the CPU, which I think was to protect it since it was CMOS. There was a video board/processor for it too as I recall.
I've certainly never heard of the UC1800!
Yeah - good times - the challenge of accomplishing anything with such meagre resources was always fun, as well as being so intimately familiar with the hardware as you needed to be.
Acoustic couplers weren't meant for browsing web site - they are from the era when the internet was the ARPAnet and HTTP and the web hadn't even been invented. Back then the "internet" was about archie/gopher/e-mail, etc - all text - which is why 300/1200 baud, was tolerable.
The oldest thing I still use is a DECtalk speech synthesizer dating to 1984.
It's a huge VCR-size box with a 68000 (a giant 3" long DIP chip) based board inside that converts text coming in on a serial port (DB-25) to speech. It also supports phoneme input and is flexible enough that it can do a passable job of singing. It can also connect to a phone and answer calls, response to DTMF touch tones, etc, if you want it to - you can use it to create touch tone driven voice response systems.
This was one of the first commercial speech synthesizers, and was based on years of research done at MIT.
Unlike most modern speech synthesizers that basically concatenate small human speech snippets to create their output, the DECtalk is what is called a formant synthesizer - it simulates the human speech generation process whereby the sound produced by the vocal chords is shaped by the resonant frequencies (aka formants) of the mouth. It's a much more flexible approach - seeing as your controlling the speech generation process, you can programatically create new voice, create your own intonation, make it sing, etc.
I've also got a couple of c. 1977 Processor Technology Sol-20 computers (an old S-100 bus 8080-based computer, with wooden side panels!), complete with their 8" floppy drive subsystem, at home collecting dust - not sure if they still work or not.
Of course this guy is just poking fun at creationists, but mislabelling dogs as species would really help. For that matter it wouldn't help if they really were separate species.
1) Dog breeds may be a recent thing but nobody say them evolve either - it happended over a time longer than a human lifetime. If you're of a mind to deny these things then "I didn't see it with my own eyes" argument applies just as well here. Maybe God created Chihuahas and Great Danes. I slighty smarter creationist might complain that the selection pressure on most breeds was artificial.
2) Much more to the point, there are genuine species all around us at every conceivable stage of speciation. Heading towards branching, during branching, immediately after branching, long after branching, etc.
The best answer to a creationist who says "if it's true, why don't we see it?" is to ask "what is it you'd expect to see that isn't in fact all around you right now?!!". Anyone expecting to see Tigers bifuracte into furbys and unicorns in their own lifetime isn't worth trying to argue with, but anyone who realizes the timescale of evolution should realize that's not the case. The length of a human lifetime is so ridiculously short compared to the evolutionary timescales that we're essentially looking at snapshot of a movie.
Think of it this way: earth is 4.5 x 10^9 years old. If you had a feature length 2 hr movie of the whole of earth's history shot at 60 frames per second, then the movie would have 432,000 frames, and each frame would still encompass over 10,000 years of history! (4.5 billion / 432,000). And yet these creationists are expecting to see a whole movie playing in their 100 year lifetime...
So, realizing that our brief lifetime has doomed us to only be observing a snapshot of anything happening on an evolutionary timescale, the real question isn't why arn't we seeing it happen (trivial answer: your lifetime is too short, but rather if this is the movie of evolution we're caught in a still frame of, then what would you expect to see in this still frame? The answer of course is that you'd expect to see species caught at every stage of branching/speciation, which is exactly what we do see.
1) Species accumulating genetic change, living in subpolulations, apparently heading for branching: too many to list, but including things like forest/plains elephants, dogs(!), humans (assuming the races don't in the future start interbreeding indiscriminately). Even things like lions/tigers can still interbreed so (whatever arbitrary labels you want to slap on them) are really pre-branch rather than post-branch, even if we understand the amount of interbreeding in the wild to be close to zero (although it does occur).
2) Species that are essentially at the point of branching right now. A classic example might be horses/donkeys, which can still kind of interbreed, but not quite (their offspring, a mule, is sterile). Given that branching is more of a process than event (it's something that happens to populations, not individuals) there are many more less spectacular examples - I'd probably include some of those (technically) pre-brancing examples in this class.
3) Species that are post-branch (can no longer interbreed, but are still genetically very close) : any species withing the same biological genus, familiy, etc. One's that branched more long ago are more genetically different corresponding to biological order, class, etc. For a specific example, how about oursellves and chimps still with 98% shared DNA and only a few million years after having branched from a common ancestor.
So the still frame we're living in sure fits the bill - we see everying around us that we'd expect to see if species are created by branching from each other. OTOH if the creationists are right, and species are created by God then the number of species that exist along every conceivable degree of genetic difference (as opposed to isolated individual creations) is rather embarassing!
Slashdot Mirror
You underestimate the problem. The OLPC is quite slow, has very large screen (1200x900) and no hardware acceleration to speak about, so it isn't even fast enough to do fullscreen refreshes at good framerates, let alone draw anything half complex while doing so.
If it's really that bad then it seems they chose a poor place to cut a few dollars out of the cost. You'd think that things like video (educational, video conferencing), games (educational, fun), animations would be exactly the sort of thing the target usage would call for, never mind the anticipated requirements of the UI.
OTOH a zooming interface doesn't even need to run at 30fps to look good - you just want it to be highly responsive to the controls, and show something clearly recognizable (but not necessarily full resolution) while zooming. I remember real-time arcade games like asteroids, space invaders and sideways-scroller games playing quite happily on the old c.1980 8-bit systems with 1MHz closk speeds and zero display acceleration, so I still maintain that you can do a very acceptible version of zooming on low powered hardware.
Note also that a zooming interface doesn't need to do full-screeen refreshes - you just need to clear-to-background any parts that you arn't about to overwrite at the new zoom level. If zooming IN there's probably nothing to be erased. With a sparse sceene like Sugar's "neigborhood view" (more background than foreground) this type of optimization vs full-screen updates would be a massive speed-up.
I'd have to guess that most planes lost in Vietnam weren't due to SAMs firing at targets that were only visible to radar. Most losses were more likely up-close and personal - dogfights and AA fire aimed at clearly visible planes on low-level bombing runs.
I don't think a zooming interface needs a lot of CPU if done right - Qt's QGraphicsView widget supports zooming on a massive hierarchy (millions of sub-widgets) very efficiently. The display code (in this case the Qt library) just needs to be smart so that it doesn't actually draw things that are too small to be seen or are obscured by other objects. The Qt widgets sit atop a VERY effifient Qt drawing library with multiple backends... Qt's own raster engine is much faster than many native drawing APIs and always available, but they also support OpenGL and recently OpenVL (a 2-D accelerated API for low-powered things like smart phones). If you download the free version of Qt there's a precompiled demo of it you can try.
To me the issue is just that this is a flashy but not very usable interface. It would work as a "discovery" interface if I want to see what Sugar users are located in some village in another country (rather like Google earth - zoom out, move, then zoom back in), but it's hardly the best way to select between a small number of other users that you may actually be interacting with on a daily basis. An clickable set of photos of those users (maybe with online indication shown too), displayed on a single page regardless of their physical location, would be much nicer and more productive to use.
From the demo video, I've got to wonder what the they were thinking. This doesn't seem like a kid-friendly UI.
http://www.sugarlabs.org/index.php?template=gallery&page=media_01
The intial interface showing what I assume is the "neighborhood" view of other Sugar users/machines (arranged in cum-by-ya campfire circles) is cute, but seems more designed for a Movie than for actual use (cf Jurassic Park's "Oh, it's Unix! I know that!" interface where they zoom down from a building view to an individual computer).
One you get past this odd and confusing initial user interface it seems you're using traditional apps like the Editor/Word Processor they show.
Maybe there are other elements of Sugar that are better designed or more innovative, but the demo doesn't seem too compelling.
Audio on Linux has been bad for 10 years, its not getting any better and ALSA is more the problem than the solution, as are all the hacks like pulse, esd, arts, gstreamer, etc.
GStreamer isn't an audio API. It's the Linux version of DirectShow - i.e. a multi-media framework for building decoding/encoding graphs/pipelines.
e.g.
Say you want to play a DVD. Your GStreamer-based player invokes GStreamer to build a decoding pipeline that reads the DVD, demuxes it into video and audio streams, decodes each stream in parallel, maybe applies some filters, then outputs them the the chosen sink. In the case of the audio stream the sink (for a player app) would be an audio API.
I expect the "explicitometer" is just the same exact same none/moderate/strict classification that both Google and Bing's "Safe Search" preferences offer.
This change by Bing isn't some big brother restriction on your porn viewing... it's just coming closer** to honoring your wishes by not allowing you to view porn sites that you, yourself, have already chosen to block via Open DNS, Net Nanny or whatever!
** Of course, you can still see Microsoft hosted thumbnails (incl. videos) from sites that you've chosen to block but Microsoft hasn't classified as explicit, and Google does no better with their image thumbnails.
Yep - this is just the thumbnails on the Bing search results page.
This Bing change won't help with that.
I don't expect that the image or video results you get with Bing vs Google at any preferred level of "safe search" filtering are much different, and that's not going to change with this announcement.
All the Bing change does, rather belatedly, is stop overriding parental controls (Open DNS, Net Nanny, etc) that would block porn domains. What happens up until now is that Bing self-hosts all it's image/video thumbnails from it's own servers - porn included - and starts to play these thumbnail videos automatically - direct from Microsoft's servers - when you mouseover them. Since the videos are coming from a Microsoft domain rather than a porn domain, parental porn filters are bypassed.
All the Bing change does is to move Microsoft's porn video reviews from bing.com to microsofts-hard-core-porn-server.bing.com so that Open DNS, Net Nanny, etc can once again be used to block this stuff.
But the Twitter guy wasn't the one to get his C64 on the internet - that was a given. He just plugged a C64 ethernet adapter into his C64 (MMC replay expansion box with RR-net ethernet daughtercard), and installed an OS (Contiki) on his C64 that already had a working TCP/IP stack and a ethernet driver. He didn't use 6502 assembler either - he used the CC65 'C' cross-compiler.
So, basically the guy wrote a Twitter client in C, on a fairly full-featured OS that includes TCP/IP support.
Let's note too that the guy himself was totally open about all this in TFA, and even noted:
Although primarely [sic] programmed for the C64 BREADBOX64 should compile for other systems using Contiki. The only C64 specific code relates to the little bird at the top of the screen, which is actually a sprite.
So, I'd have to agree with the parent - not a hack, just implementing a Twitter client in C.
Writing a Twitter client is also not a hack - they have a public API (XML based):
http://apiwiki.twitter.com/Twitter-API-Documentation
And everyman and his dog has already implemented this in every language under the sun:
http://apiwiki.twitter.com/Libraries
So, really: Dude wrote a Twitter client. Story at 11.
That said, don't knock it unless you're capable of doing it yourself.
There's obviously a lot of truth to the ease of programming using high level tools, and standing on other's shoulders, but back in the day we made do with what we had. I used to work for Acorn Computers (UK) back in 1982, and was one half of the team that implemented ISO Pascal for the 6502-based BBC Micro...
The project was divided into two halves (shipped on two 16K EPROMS), one half being a stack-based virtual instruction set for the compiler to target (to get reasonable code density), Pascal run-time libraries (I/O, floating point, heap, etc), a decent screen editor including regex search/replace etc, a command line interpreter... this all written in 6502 assembler developed on a BBC micro using it's own BBC BASIC inline assember... and the other half being the Pascal compiler which was written in Pascal and self-compiled. We did bootstrap the compiler using an existing one on another (equally slow!) system, but as soon as it could self-compile we moved all development to the BBC micro.
It's really not so bad to bootstrap yourself up from assembler to decent development tools. Write a very minimal C/whatever compiler in assembler, then write a better one in that language/etc, and repeat!
Actually, if you RTFA, he didn't develop the TCP/IP interface.
This project uses an "MMC replay" C64 expansion box with an RR-net ethernet daughterboard installed. He wrote the Twitter client to run on the Contiki OS, which comes with a built-in TCP/IP stack and a driver for the RR-card. Credit for Contiki and it's uIP TCP/IP stack go primarily to Adam Dunkels:
http://www.sics.se/~adam/
The accomplishment of the C64 Twitter client's author is really more about writing a Twitter client with one hand tied behind your back rather than really being C64 specific. He wrote it in C (CC65 6502 compiler) on Contiki, so the fact that it happens to be running on a C64 as opposed to any other environment that supports Contiki is somewhat irrelevant.
Whether it scores any points for complexity really depends on your level of experience. Given that the ./ readership has become less and less hard core over the years, I think there are many people here who should be avoiding this guy's front lawn. At least, if you've never written any networking code in your life, how about firing up Linux, or installing MinGW (maybe roughly comparable to installing Contiki and CC65 on a C64), then writing your own Twitter client... It certainly won't be a waste of time if you learn how to do socket programming as a result.
Right, and someone blocking your view of the screen (or the screen's view of you) isn't normally a problem when you're playing games. You can just keep on playing while they are blocking you, eh?
How on earth did this crap get modded up?! :-(
IMO universities should be teaching core principles and methods, not attempting to impart up-to-date job skills.
If you are going to teach FORTRAN because it's of use in the real world, then why stop there? Why not also (god forbid) teach .NET. JavaScript, C#, etc. May as well teach them Excel macros and how to interact with Microsoft Clippy while you're at it.
No!
Teaching programming should be done in a langauge that imparts the principles easily and teaches good habits. You could do a lot worse than Pascal which was often used in this role, or maybe today just C++. I'd argue against Java and scripting languages as the core language since they are too high level to learn all the basics. You could throw in Perl, Python or any modern scripting langauge as a secondary, and for a Computer Science (vs. Physics, Engineering, etc) it's appropriate to teach a couple of other styles of programming - e.g. assembler, and functional programming.
I think "animatronic toy" is being a bit dismissive, even if it didn't live up to the hype.
It's really an autonomous robot that learns and reacts to the environment - it's not just a robot with a remote or a canned set of moves.
That said, the degree of learning and autonomy it displays seems to be rather limited, although the promise was for this to be imporoved in subsequent software releases.
The reason you, as a Slashdot denizen, should care, is:
1) As an autonomous robot - with vision and hearing - it is pretty cool.
2) It's eminently hackable, and really an excellent value as a chunk of mechanics and electronics.
But battery consumption is not good. It will work for 2.5 hours on one charge.
That's amazingly bad! I thought Freescale = ARM (= low power), but maybe not.
Yesterday's article about the range of ARM based netbooks at Computex mentioned battery life of 8-12 hours, so this isn't even remotely in the ballpark.
It'd be interesting if RiscOS gave some benefit that the other ARM OS options don't, but given that these ARM based netbooks also support the latest Ubuntu, Android, Windows CE (these latter two could also be considered as written for the ARM - that's what most smart phones/handhelds use), it's hard to see what RiscOS brings to the table. Let's not forget that the ARM also powers the BSD/Unix powered iPhone quite happily. It's a powerful little beast - ARM sells over 4 BILLION ARM cores a year!
Problem is, they think they want to make a "Linux" app, but they really want to make a Gnome app or a KDE app.
Exactly, or even more so.... There's no such thing as a Linux app, because there's no such thing as a Linux API.
There's no point whining about it - you just make your choice and go with it. Qt or GTK+. For audio you may as well write to ALSA in the knowledge that it can be routed through any of the myriad alternatives if anyone wants to.
Xlib... and then what for widgets? If not Qt or GTK (and I assume you're not advocating Xt/Motif), then I suppose you're suggesting they introduce even more Linux GUI/HIG/theming incompatability and write their own UI/widget library? (as they did for Android!)
Well, we're talking tens if not ultimately hundreds of billions here, which makes a big difference.
That said, if we're only talking billions, how about the $6 billion Microsoft spent developing Vista. Heck, Microsoft spend about $1.5 billion a year just in advertizing!
I vaguely remember one RCA1802 board that may be the PE one your talking about - it had a plastic "bubble" covering the CPU, which I think was to protect it since it was CMOS. There was a video board/processor for it too as I recall.
I've certainly never heard of the UC1800!
Yeah - good times - the challenge of accomplishing anything with such meagre resources was always fun, as well as being so intimately familiar with the hardware as you needed to be.
Acoustic couplers weren't meant for browsing web site - they are from the era when the internet was the ARPAnet and HTTP and the web hadn't even been invented. Back then the "internet" was about archie/gopher/e-mail, etc - all text - which is why 300/1200 baud, was tolerable.
Too bad that most of the kiddies here probably don't even know what a teletype was!
The ASR33 was certainly a classic!
My first home computer was similar vintage/capability to your AIM-65 - it was a NASCOM-1 (Z-80) kit I assembled in 1978.
The oldest thing I still use is a DECtalk speech synthesizer dating to 1984.
It's a huge VCR-size box with a 68000 (a giant 3" long DIP chip) based board inside that converts text coming in on a serial port (DB-25) to speech. It also supports phoneme input and is flexible enough that it can do a passable job of singing. It can also connect to a phone and answer calls, response to DTMF touch tones, etc, if you want it to - you can use it to create touch tone driven voice response systems.
This was one of the first commercial speech synthesizers, and was based on years of research done at MIT.
Unlike most modern speech synthesizers that basically concatenate small human speech snippets to create their output, the DECtalk is what is called a formant synthesizer - it simulates the human speech generation process whereby the sound produced by the vocal chords is shaped by the resonant frequencies (aka formants) of the mouth. It's a much more flexible approach - seeing as your controlling the speech generation process, you can programatically create new voice, create your own intonation, make it sing, etc.
I've also got a couple of c. 1977 Processor Technology Sol-20 computers (an old S-100 bus 8080-based computer, with wooden side panels!), complete with their 8" floppy drive subsystem, at home collecting dust - not sure if they still work or not.
Except there isn't one shred of evidence to prove that
You mean aside from the actual DNA sequences and the fossil record, eh?!
Gotta wonder what else you expect to see? Maybe a 5 million yr old guy saying "dude! I just saw the most amazing thing! ..."
Of course this guy is just poking fun at creationists, but mislabelling dogs as species would really help. For that matter it wouldn't help if they really were separate species.
1) Dog breeds may be a recent thing but nobody say them evolve either - it happended over a time longer than a human lifetime. If you're of a mind to deny these things then "I didn't see it with my own eyes" argument applies just as well here. Maybe God created Chihuahas and Great Danes. I slighty smarter creationist might complain that the selection pressure on most breeds was artificial.
2) Much more to the point, there are genuine species all around us at every conceivable stage of speciation. Heading towards branching, during branching, immediately after branching, long after branching, etc.
The best answer to a creationist who says "if it's true, why don't we see it?" is to ask "what is it you'd expect to see that isn't in fact all around you right now?!!". Anyone expecting to see Tigers bifuracte into furbys and unicorns in their own lifetime isn't worth trying to argue with, but anyone who realizes the timescale of evolution should realize that's not the case. The length of a human lifetime is so ridiculously short compared to the evolutionary timescales that we're essentially looking at snapshot of a movie.
Think of it this way: earth is 4.5 x 10^9 years old. If you had a feature length 2 hr movie of the whole of earth's history shot at 60 frames per second, then the movie would have 432,000 frames, and each frame would still encompass over 10,000 years of history! (4.5 billion / 432,000). And yet these creationists are expecting to see a whole movie playing in their 100 year lifetime...
So, realizing that our brief lifetime has doomed us to only be observing a snapshot of anything happening on an evolutionary timescale, the real question isn't why arn't we seeing it happen (trivial answer: your lifetime is too short, but rather if this is the movie of evolution we're caught in a still frame of, then what would you expect to see in this still frame? The answer of course is that you'd expect to see species caught at every stage of branching/speciation, which is exactly what we do see.
1) Species accumulating genetic change, living in subpolulations, apparently heading for branching: too many to list, but including things like forest/plains elephants, dogs(!), humans (assuming the races don't in the future start interbreeding indiscriminately). Even things like lions/tigers can still interbreed so (whatever arbitrary labels you want to slap on them) are really pre-branch rather than post-branch, even if we understand the amount of interbreeding in the wild to be close to zero (although it does occur).
2) Species that are essentially at the point of branching right now. A classic example might be horses/donkeys, which can still kind of interbreed, but not quite (their offspring, a mule, is sterile). Given that branching is more of a process than event (it's something that happens to populations, not individuals) there are many more less spectacular examples - I'd probably include some of those (technically) pre-brancing examples in this class.
3) Species that are post-branch (can no longer interbreed, but are still genetically very close) : any species withing the same biological genus, familiy, etc. One's that branched more long ago are more genetically different corresponding to biological order, class, etc. For a specific example, how about oursellves and chimps still with 98% shared DNA and only a few million years after having branched from a common ancestor.
So the still frame we're living in sure fits the bill - we see everying around us that we'd expect to see if species are created by branching from each other. OTOH if the creationists are right, and species are created by God then the number of species that exist along every conceivable degree of genetic difference (as opposed to isolated individual creations) is rather embarassing!
Of course these discussions are endl