What's the perfect name for the robot following the Aibo?
The Bibo, of course!
Then of course they'll make the Cibo. Followed by the Cibo++ when they decide it needs to be able to take out the garbage and have inheritence. Of course it will be very slow at taking out the garbage and will eventually be rivaled by the Jibo, which will be touted as 'Bite' compatible with every home in the world.
And of course, the Cibo and Cibo++ will stick around for like 20 years. And people will be afraid to switch to other electronic pets because of the long history of the Cibo/Cibo++. For example, pets like the electronic Python (c'mon guys, this is a tough metaphor...) will be able to take out the garbage better than the Cibo++ and look much cleaner.... Now I'm getting pretty far out there.;-) But they say history repeats itself....
Billy: Sorry teacher... The RIAA confescated my PC.
Teacher: That's the stupidest excuse I have ever heard, report to the principals office!!
Billy: But.. Damn, I should have just said my dog ate it.
This article finally got me off my butt to check out all this mozilla stuff, and though this post will likely be buried under hundreds of other posts since it's a late comer, here's my $0.02 anyway.
My first impression was not good. After unpacking the binary tarball and trying to start it, I was greeted by a bazillion debug messages on the xterm that opened it, and it took longer than gimp on a 486 to start, and I have a P3-500 w/256M of RAM. That had me worried. Then the interface.... No comment here, but I have a custom theme I built in FVWM2, and needless to say, it doesn't exactly match. Though if I want to take the time, I can change it, so I guess I can live with that. So I try and fire up slashdot... All the while debug messages spewing forth on my xterm... I type in slashdot.org and press enter... and BAM! Instant webpage. I have to say, the rendering engine is *FAST* compared to the netscape I'm used to, and that's the stock w/ Slackware 7.0. So I thought, OK, try some buttons, and after a lot of wandering I got no where but frustrated with all the extra CRAP that seems to be included. I can do email. Pine. I can do news. Tin. I can do IRC. BitchX or xchat. And they all do it better.
So I thought, well, I remember seeing some things on freshmeat that are interfaces to the gecko engine. Well that would do it, only a web engice and NO crap, so off to freshmeat I went, eventually to sourceforge, and downloaded 3 different packages that are supposed to support the gecko engine. None worked. Why? Because they all want a million gnome libs, and Slack has never really embraced gnome, nor have I, I run FVWM2 as noted earlier. Now if someone could just get that gecko engine in a motif wrapper, I'd be happy.
So I guess I'm back at stage 1, dissappointed as ever. I'm either going to have to just live with Netscape or take the plunge in to overgrown gnome lib land. Not pretty either way.
I see a lot of talk about 'You need binaries for every kernel' and while that is a swaying argument, why not make a mini-module architecture that is kernel independant, or allow linking a binary object to some code to make a module for the current kernel. That's probably why they can release windows drivers and keep them updated, becuase even if they support all windows platforms, they only need 3 or 4 different drivers, compliled once. I think it's too much to ask a company to compile 50 different versions of a module just because you use linux. I understand that lots of companys don't want to open source their drivers because of technical concerns, but with a system in place for modules that work independant of kernel version, they would have a way to write the driver and keep one version maintained and release a better driver if they choose to keep it closed source, and I'd rather have good closed source drivers than open ones missing functionality.
Now I'm no ASM junkie, and I did do a little back in the DOS 3.x days, but everyone seems hell bent on saying C won't work because it's too bloated. But that's not what C is about, that's the CRT that get's bloated, and it can be rewritten to be smaller for a particular platform. I mean, I don't think people will be able to use glibc on anything with 32k, so why complain about it's CRT bloat in the linking stage? It includes stuff that's important on a desktop machine like std io routines and stuff, but for a micro, you'd need a different development library. After all, you don't need terminal support if there is NO terminal. I programmed in C on a TRS-80 CC2 a long time ago on OS/9. Now my computer only had 32K of ram, and things worked there, and compiled binaries were no where near the size of what they are now, but it was a different architecture with a different CRT that suited the environment and created executables from C that were reasonable. If C programming is desired, and it probably will be as faster development is always a cost saver, then someone will develop a lib with a comparable CRT for that platform that will create executables that are good enough to get the job done. That means a CRT that only sets up an environment suitable for the micro and not bloated by all the POSIX and everything else. You'd have to do the same thing in assembly anyway.
Look at the palm pilot, people wanted to write programs for it and it has a CRT that is small enough that even bare applications are only 2K or smaller even. And most of that is probably setting up the hooks for recieving PalmOS evens and using the hardware correctly like the touch screen and everything else. And that's with gcc, different CRT and now MUCH smaller executables. Now I'm not saying ASM has no place, but I am saying that just because you're some 37337 ASM coder that you should say "Go away C coders, you can't hack it here" that's just stupid. If there is a demand, it will be done.
And about the no terminal thing, I also see people hollaring about "What about the hax0rs beating at my toasters door!!" and that's crap. Like I said, being as small as they are, they probably won't be able to support a terminal of any sort, so no one will be telnetting in to your toaster and setting your house ablaze. Most likely, any connected appliance will have little interaction with the real world short of sending outgoing messages. I mean a toaster has no reason to accept external commands if you're not there anyway. And there are also few homes, in the homes connected vs homes not, that are on the net all the time AND wired for ethernet so that they could put their toaster on the net. But then if someone does that, they'd have to be a geek anyway and they probably know what could go wrong. Just like setting up a fulltime connected anything. For example, most anwering machines allow you to remotely change the message and check messages, so if being connected is so bad for normal people, why don't more people have problems with kiddies changing their messages all the time? It's because people are familiar enough with that technology to reasonably secure it themselves. And when connected embedded appliances become a reality, before the mass population will accept them they will have to be comfortable with them, and with that comes responsibility to correctly use them. So by the time your grandma's toaster IS online, so will everyone else's, and when that happens everyone will probably know how to secure their toaster with RSA so that they can only SSH in to it. Just my $0.02. Please apply appropriate international rate conversions if you are not in the US.
All I see is "crack it!" up and down the comment board here, but how easy could that really be? After all, I'd assume that after the DeCSS fiasco they would have learned something and fixed there mistakes, and if I'm not mistaken, no one cracked the DVD encryption, someone got lucky and found an unencrypted key that allowed them to break the encryption. Without the key, DeCSS would be as useless as all those badly burned CD's on my coffee table. And with software viewers, couldn't the industry use one time license keys or keysets for a digital production, so that by compromising one, they wouldn't all be compromised. And another thing about software players is that they can be upgraded, so say someone does create a monolithic crack for any movie out there, couldn't they just release a new viewer program? After all, a couple hour download is not even close to as painful as having to do a hardware upgrade.
Slashdot Mirror
The Bibo, of course!
Then of course they'll make the Cibo. Followed by the Cibo++ when they decide it needs to be able to take out the garbage and have inheritence. Of course it will be very slow at taking out the garbage and will eventually be rivaled by the Jibo, which will be touted as 'Bite' compatible with every home in the world.
And of course, the Cibo and Cibo++ will stick around for like 20 years. And people will be afraid to switch to other electronic pets because of the long history of the Cibo/Cibo++. For example, pets like the electronic Python (c'mon guys, this is a tough metaphor...) will be able to take out the garbage better than the Cibo++ and look much cleaner.... Now I'm getting pretty far out there. ;-) But they say history repeats itself....
Billy: Sorry teacher... The RIAA confescated my PC. Teacher: That's the stupidest excuse I have ever heard, report to the principals office!! Billy: But.. Damn, I should have just said my dog ate it.
This article finally got me off my butt to check out all this mozilla stuff, and though this post will likely be buried under hundreds of other posts since it's a late comer, here's my $0.02 anyway.
My first impression was not good. After unpacking the binary tarball and trying to start it, I was greeted by a bazillion debug messages on the xterm that opened it, and it took longer than gimp on a 486 to start, and I have a P3-500 w/256M of RAM. That had me worried. Then the interface.... No comment here, but I have a custom theme I built in FVWM2, and needless to say, it doesn't exactly match. Though if I want to take the time, I can change it, so I guess I can live with that. So I try and fire up slashdot... All the while debug messages spewing forth on my xterm... I type in slashdot.org and press enter... and BAM! Instant webpage. I have to say, the rendering engine is *FAST* compared to the netscape I'm used to, and that's the stock w/ Slackware 7.0. So I thought, OK, try some buttons, and after a lot of wandering I got no where but frustrated with all the extra CRAP that seems to be included. I can do email. Pine. I can do news. Tin. I can do IRC. BitchX or xchat. And they all do it better.
So I thought, well, I remember seeing some things on freshmeat that are interfaces to the gecko engine. Well that would do it, only a web engice and NO crap, so off to freshmeat I went, eventually to sourceforge, and downloaded 3 different packages that are supposed to support the gecko engine. None worked. Why? Because they all want a million gnome libs, and Slack has never really embraced gnome, nor have I, I run FVWM2 as noted earlier. Now if someone could just get that gecko engine in a motif wrapper, I'd be happy.
So I guess I'm back at stage 1, dissappointed as ever. I'm either going to have to just live with Netscape or take the plunge in to overgrown gnome lib land. Not pretty either way.
I see a lot of talk about 'You need binaries for every kernel' and while that is a swaying argument, why not make a mini-module architecture that is kernel independant, or allow linking a binary object to some code to make a module for the current kernel. That's probably why they can release windows drivers and keep them updated, becuase even if they support all windows platforms, they only need 3 or 4 different drivers, compliled once. I think it's too much to ask a company to compile 50 different versions of a module just because you use linux. I understand that lots of companys don't want to open source their drivers because of technical concerns, but with a system in place for modules that work independant of kernel version, they would have a way to write the driver and keep one version maintained and release a better driver if they choose to keep it closed source, and I'd rather have good closed source drivers than open ones missing functionality.
Now I'm no ASM junkie, and I did do a little back in the DOS 3.x days, but everyone seems hell bent on saying C won't work because it's too bloated. But that's not what C is about, that's the CRT that get's bloated, and it can be rewritten to be smaller for a particular platform. I mean, I don't think people will be able to use glibc on anything with 32k, so why complain about it's CRT bloat in the linking stage? It includes stuff that's important on a desktop machine like std io routines and stuff, but for a micro, you'd need a different development library. After all, you don't need terminal support if there is NO terminal. I programmed in C on a TRS-80 CC2 a long time ago on OS/9. Now my computer only had 32K of ram, and things worked there, and compiled binaries were no where near the size of what they are now, but it was a different architecture with a different CRT that suited the environment and created executables from C that were reasonable. If C programming is desired, and it probably will be as faster development is always a cost saver, then someone will develop a lib with a comparable CRT for that platform that will create executables that are good enough to get the job done. That means a CRT that only sets up an environment suitable for the micro and not bloated by all the POSIX and everything else. You'd have to do the same thing in assembly anyway.
Look at the palm pilot, people wanted to write programs for it and it has a CRT that is small enough that even bare applications are only 2K or smaller even. And most of that is probably setting up the hooks for recieving PalmOS evens and using the hardware correctly like the touch screen and everything else. And that's with gcc, different CRT and now MUCH smaller executables. Now I'm not saying ASM has no place, but I am saying that just because you're some 37337 ASM coder that you should say "Go away C coders, you can't hack it here" that's just stupid. If there is a demand, it will be done.
And about the no terminal thing, I also see people hollaring about "What about the hax0rs beating at my toasters door!!" and that's crap. Like I said, being as small as they are, they probably won't be able to support a terminal of any sort, so no one will be telnetting in to your toaster and setting your house ablaze. Most likely, any connected appliance will have little interaction with the real world short of sending outgoing messages. I mean a toaster has no reason to accept external commands if you're not there anyway. And there are also few homes, in the homes connected vs homes not, that are on the net all the time AND wired for ethernet so that they could put their toaster on the net. But then if someone does that, they'd have to be a geek anyway and they probably know what could go wrong. Just like setting up a fulltime connected anything. For example, most anwering machines allow you to remotely change the message and check messages, so if being connected is so bad for normal people, why don't more people have problems with kiddies changing their messages all the time? It's because people are familiar enough with that technology to reasonably secure it themselves. And when connected embedded appliances become a reality, before the mass population will accept them they will have to be comfortable with them, and with that comes responsibility to correctly use them. So by the time your grandma's toaster IS online, so will everyone else's, and when that happens everyone will probably know how to secure their toaster with RSA so that they can only SSH in to it. Just my $0.02. Please apply appropriate international rate conversions if you are not in the US.
All I see is "crack it!" up and down the comment board here, but how easy could that really be? After all, I'd assume that after the DeCSS fiasco they would have learned something and fixed there mistakes, and if I'm not mistaken, no one cracked the DVD encryption, someone got lucky and found an unencrypted key that allowed them to break the encryption. Without the key, DeCSS would be as useless as all those badly burned CD's on my coffee table. And with software viewers, couldn't the industry use one time license keys or keysets for a digital production, so that by compromising one, they wouldn't all be compromised. And another thing about software players is that they can be upgraded, so say someone does create a monolithic crack for any movie out there, couldn't they just release a new viewer program? After all, a couple hour download is not even close to as painful as having to do a hardware upgrade.