Screw rebooting, there're other advantages
on
No More Rebooting?
·
· Score: 4, Insightful
I see the reboot issue as minor, compared to the other potential advantages of this technology. I will expect to be rebooting, for one reason or another, for years to come and am not too bothered.
The article glosses over what I consider the important advantages:
- [assumedly] great power savings. Great for portables and remote embedded systems.
- No moving parts! If this tech can really replace and even surpass in speed, Hard Disk Drives, reliability and performance should make a gain of at least an order of magnitude.
I've been waiting for years for computers to become eletronic-only devices. I've harped before that CRT's (vaccum tubes, for God's sake!) and HDD's need to join the Dodo in oblivion. This new tech, in the common mass storage area (HDD's, CD'c, floppies), along with flat panel technology, would put us right on the verge of that ideal. The last hurdle would be cooling without moving parts.
I chose to get married and it *has enhanced* my life. I was not providing a commentary on how marriage and family have ruined my life, it was a commentary on how changes in my life have changed the things that I enjoy most. Playing with my 2 year old *is* fun and much more important to me than re-hashing an experience that ceased to be a challenge years ago.
I wasn't bitching about how I can't have fun anymore, I was saying that building a PC from parts at home is becoming "a pain in the ass" to me and not worth the trouble or money saved.
Eeye.com has often posted the proof-of-concept exploits as a part of their advisories... is the author of the guest editoral saying eeye.com is doing wrong?
Back when the original Code Red was stirring up a ruckus, I posted its disassembled code (from eeye) to alt.comp.virus.source, and an short discussion of several weird aspects (poor coding) of the code ensued. I don't think I did anything wrong by posting it. If some weasel used that post (or other such sources) to create CRII, so be it. IMO, by that time any servers that were still vulnerable to CR/CRII deserved to be hit and, better yet, TOS'd by there ISP.
I just don't subcribe to the idea that suppressing potentially dangerous source code will do good in the long run. Having the source available and widely distributed has several advantages:
- promotes understanding of exploit mechanisms in order avoid making the same mistakes in the futre
- promotes rapid deployment of fixes. There is no pressure greater than knowing every little script kiddy's got the code
- raises awareness of code weaknesses/failure modes/common pitfalls (maybe *someday* CS courses will teach future coders to prevent buffer overflows!)
I firmly believe that being open about software/network/OS weaknesses will gradually drive the state of the art in secure software to a much higher level. The "keep quiet", "head-in-the-sand" approach that M$ is promoting these days will only hinder such advances. I'll make a loose analogy to the old outlaws & guns argument: "If you outlaw virus source code, only outlaws will have virus source code."
In fact, I think it is *imperative* that malicious source code NOT be suppressed. How else can we arm the next generations of app and OS coders to develop resistance code?
Careful there, the other day I inadvertently dissed C++ and OOP in general and must have trod on someones religion in the process.
But I think you've got a good point about FORTRAN, but I'd make a slightly different point on C++. FORTRAN is passe' not because it's old, but because what made it special (FORmula TRANslation) isn't all that special or unique anymore. C++ and OOP in general can be great, but a programmer really needs to know the difference between OOP and non-OOP and why you would want to use one method/language over the other. Applying OOP methologies where unnecessary can *add* to code complexity and obfuscation. Never use OOP because it's cool, only when it's the better way.
From the article: "In software engineering there is no theory,"
I don't buy that... at least not completely. I would say something more like, "In software engineering, theory is extremely underutilized."
I believe there are many instances of engineered software, but not necessarily high-profile stuff. A lot of DoD conscripted code may never the the civilian light of day, but there are procedures and documentation requirements that, flawed or not, enforce certain practices. Can we call that "theory"? Anyhow, defense suppliers can afford the extra development time, 'cause the government is forking over big bucks for the code to right.
For the mainstream (read desktop) apps, where all the money is, the time to market and feature pressures will continue to suppress even the best "unified theory" of software development.
Ouch, that hurt. Actually, my daily job involves system integration, software and (sometimes) hardware development, so I kinda get my fill of it at work. Getting married... well that changed things a lot. Way back when (while single), I spent a week of evenings hacking an 8 channel [radio] scanner from Radio Trash. Interfaced the PLL tuner IC to the parallel port on my PC and wrote a C [DOS] program to control the tuning. Wound up with a 400 channel scanner when under PC control. Me very busy now; all I can do is look back on that stuff as "the Good ol' Days"
Since about 1987, I have always built my own boxes, but recently I've wavered... and it's purely on account of the cost issue. Now my time is becoming more and more valuable (higher pay, family) and PC prices [have been] getting lower and lower. It's getting harder for me to justify (especially to my wife) the time it takes to roll my own when the difference between parts and off-the-shelf is only a 100 to 200 bucks (or perhaps even less).
Used to be, I'd do it just for the love of it (and to save some dough). Now, it's usually just a pain in the ass. And I don't believe hardware prices are going to increase to point where I'll change my mind.
I'm beginning to see the light. 'til now, I'd only seen a very few (or recognized as such) real Java desktop apps. Poking around at Swing Sightings, I was surprised to find quite a few Java/GUI apps that look like fairly heavy hitters. I still have some reservations about the throughput of a busy Swing desktop application, but now I'm going to shut up until I've tried out a few more (IDEA looks good).
I think the whole "ThinkFree Office" product is just a tag to lure you to their "CyberDrive" product. Their "20-megabyte Web file-storage service" is free for one year, then $30 anually thereafter should you continue to use it. And I think it's a product (web-based storage) that, in one form or another, has been tried and failed earn a profit (think X-drive). I very dubious about web storage as a product for a couple of reasons:
. security. Let someone else store my (potentially private) files and trust them to keep grubby cracker fingers out of it?
. I've got a 120 GB drive in my desktop at work, 80 GB at home and 30 GB in my notebook, what would I need 20 MB for?
I wish them luck, but a $50 productivity suite and a $30/yr 20MB storage service? I'm afraid they'll need to sell a shitload of each to do well.
"Javascript really has very little to do with Java" That pretty well shows the limit of my knowledge of Javascript:|
I have to agree with you on the "buggy" issue; I didn't mean to imply that Java code was inherently more buggy. One feature I really admire, is the portability of code... Sun has done a great job of keeping that feature in line.
Another poster said that GUI's are probably the slowest part of a desktop Java app. I've seen things that may support that position. If true, wouldn't that be the fault of the Java Runtime Engine?
"Less than glowing" review is right. To paraphrase the reviewer, it's buggy and slow.
My experience with Java, the language this app was written in, is limited to a little experimentation, web-based javascripts and using Limewire (the Gnutella client). Limewire is also an app that I would describe as buggy and slow, with emphasis on slow.
Does anyone else have an opinion on the suitability of Java in medium (Limewire) to large (thinkFree's product) desktop applications?
"We can finally find out how to implement their PigeonRank system..."
They already described the machanisms fairly well on their site. What you might not have access to is the programming language that's optimized to the task: HP-PGL (High Performance Pigeon Goading Language).
To quote my own post (above): "I wonder if they have a [business] plan for this feature..."
The more I think about it, the less I think this is going to be a "free" feature. It seems to encourage "automated queries" and that doesn't fit with any business model I've thought of (for Google) and, as you've pointed out, it's against their TOS.
I'm guessing that, if this feature comes to fruition and stays, its usage will come under some sort of paid model. -
I wonder as well. I've used my own C/GUI front end for Google searches, mainly to automate finding and downloading PDF, gz and other binaries. But I use that much less frequently than I do normal browser based searches so I don't make the slightest spike on their BadBoy meter.
I wonder if they have a [business] plan for this feature or if it's just the brain child of their gurus in the back room. Actually, I'm quite intriqued by the possibilities, so I'm going to keep on eye on it...
Gee, I think someone missed my point about bloat; perhaps I wasn't clear in my prior post. Basically I have developed a poor opinion of applications trying to perform every [semi-related] function under one umbrella because of the apps' ungainly size, load time and usability.
My recommendation to counteract bloat is to:
. cut down on the unnecessary GUI gee-gaws (skins, etc)
. find the right balance of critical functions and only a few "wouldn't it be nice" elements
. remove smaller functions from the main app, then let the app call them. Allows the smaller sub-functions to be focused to the task and developed more independently (hopefully encouraging efficiency).
Maybe my previous post contained too many exclamation marks for the moderator...
Thanks much for the link. It provide a *tad* bit more info. Esp. the reference to wanting to ship 20M units in the next year. With production runs like that (and in that short a period) it makes sense to trim unit costs in any way reasonable.
I agree on several of your points:
. less real estate
. reliability
. "...disadvantage that this was not done already." and 1 additional minor manufacturing point: ease of test
However, in the economics of mass production, their new design must be MUCH less expensive or seriously advantagous in some other way, in order to justify the cost of retooling for new production. The production costs for their existing product must have already hit bottom, so why reinvent and retool? They must have a reason and I would like to know more!
By the way, my experience in PCB design and manufacture is limited to small design, small runs ( 300 components, 500 board lots) and I realize the economics of scale must change motivations. On the point of "possible vias," I was told by me PCB manufacturer that number of vias/holes had very little to do with the end cost, especially compared to board size and production quantities. Part placement and test is a seperate issue and some real savings can be achieved by reducing component count, but is that the only reason Sony wants to do this? -
How lame is this? Our wonderful "story" is merely a reference to a post on gamefu which, itself, points to no credible source.
Slashdot: "Sony says... cause Gamefu says that Nikkei Microdevice says that Sony says..."
Good, God. I don't really doubt it's happened, but where's the interview? Where's the real scoop? I'd rather know a bit more than this. I'd like to know what else might get integrated; I don't consider squeezing 2 chips into 1 is going redefine the marketplace, or even Sony's bottomline.
Mod as you will, and let's hope someone on Slashdot can post a link with more info...
"Touchscreens are sensitive to touch though, not pressure"
Depends on the technology used for the touchscreen.
1) Capacitive: Senses the change in capacitance within a grid. Sensitive to bare hands/fingers. Not sensitive to gloved finders, pointers or styluses. Is sensitive to your fingers lying on it, so it's not a good choice for a buttonless/clickless mouse.
2) Acoustic wave: Senses interference by an object to a generated acoustic (ultrasonic?) wave along the surface of the touchscreen. Also not good for a buttonless mouse.
3) Resistive: Senses pressure as a change is resistance within a grid. Sensitive to fingers gloved or ungloved, also sensitive to pens, styluses, etc. A great candidate for a clickless mouse.
There are other types as well, but stick with my #3 for the clickless mouse.
The GUI email clients I've used of late are all over-bloated already, and getting worse with each revision! There's a lot to be said for a GUI client vs a command line (text) client, but there are trade-offs, and severe bloat comes with every cute little "wish-list" items that gets added. That said, I'm never going to give up my GUI email client, but TRIM THE BLOAT!
I think the main causes of bloat are these:
1) Developers just "throwing shit together" in an attempt to keep ahead (or catch up with) of the competition.
2) GUI bloat. GUI's make for bigger apps anyway, but add on 3rd pary libraries that distance the programmer from the API, then throw a bunch of "Gee, whiz!" gooie trash (skins, a plethora of icons, smilies, etc) on top...
3) Poor object oriented programming methods. Woo, I'll prolly get flamed for this, but OOP doesn't automatically make your app better or even help you (the programmer) do a better job. The only thing that I can guarantee is your code will ALWAYS compile slower, USUALLY run slower, USUALLY bloat up like a dead pup. Not all the "fault" of OOP, but of some programming practices it may engender. OOP (C++ esp) is *great* but, as with any language, you've got to know what you're doing with it! IMO, C++ in the hands of a neophyte or run-of-the-mill CS grad is bloat and inefficiency looking for a place to happen.
Back to email clients & such: I think the best approach to (a) adding any/every cool idea possible, and (b) preventing bloat would be to partition the app into smaller chunks.
Like all the myriad utilities from the Un*x world, keep all the little features in seperate programs that could work with the main app thru an API and shared libraries. When I say "little features" I mean *make them little!*
Ah, crap. I'm gonna have to stop, cause my Rant-O-meter just pegged. I really do have a problem with code/app bloat and wish the major developers would do *something* to combat the issue, but I'm afraid it must be a non-issue to the hordes of Joe Schmoes who just got their PC a WalMart.
The embedded systems I've worked on range from (smallest) a 68HC11 based black box with no OS and a 511 byte program to (largest) an x86 based SBC with ROMDOS and a 400K byte program. To me, embedded is the computer in your microwave oven; you can't afford to make one of those with enough memory, etc to support even the most stripped-down version of Linux.
I realize that the term "embedded" cuts a pretty big swath, but I do believe that the majority of embedded systems are teeny-tiny; many of them with no UI at all and the entire OS (if any) & app in an OTPROM, EEPROM or Flash. The bulk of commercial embedded OSes go into things like stand alone data aquisition units, traffic light controllers, toll booth controllers, satellites, remote weather & geological telemetry devices, etc. In most of those cases, Linux and other Unices are *way* overkill.
So, maybe Lineo really was trying to go for the PDA market, but IMO, that's not embedded, PDA's are just small computers.
Try Limewire. With its new "swarmed downloads" I've downloaded a single file from 6 hosts simultaneously. Really filled my pipe! Also, the Ultra Peer feature lowers the crap search bandwidth usage for most users.
OTOH, Limewire comes with its own crapware, adware and spyware; but, with a little effort, you can rid yourself of most of it (even the ads, but that's more difficult).
Slashdot Mirror
I see the reboot issue as minor, compared to the other potential advantages of this technology. I will expect to be rebooting, for one reason or another, for years to come and am not too bothered.
The article glosses over what I consider the important advantages:
- [assumedly] great power savings. Great for portables and remote embedded systems.
- No moving parts! If this tech can really replace and even surpass in speed, Hard Disk Drives, reliability and performance should make a gain of at least an order of magnitude.
I've been waiting for years for computers to become eletronic-only devices. I've harped before that CRT's (vaccum tubes, for God's sake!) and HDD's need to join the Dodo in oblivion. This new tech, in the common mass storage area (HDD's, CD'c, floppies), along with flat panel technology, would put us right on the verge of that ideal. The last hurdle would be cooling without moving parts.
I chose to get married and it *has enhanced* my life. I was not providing a commentary on how marriage and family have ruined my life, it was a commentary on how changes in my life have changed the things that I enjoy most. Playing with my 2 year old *is* fun and much more important to me than re-hashing an experience that ceased to be a challenge years ago.
I wasn't bitching about how I can't have fun anymore, I was saying that building a PC from parts at home is becoming "a pain in the ass" to me and not worth the trouble or money saved.
Posting, distributing or making available source code to viruses should be illegal? You mean, like this?
CodeRed.zip at Eeye.com
and
CodeRedII.zip at Eeye.com
Eeye.com has often posted the proof-of-concept exploits as a part of their advisories... is the author of the guest editoral saying eeye.com is doing wrong?
Back when the original Code Red was stirring up a ruckus, I posted its disassembled code (from eeye) to alt.comp.virus.source, and an short discussion of several weird aspects (poor coding) of the code ensued. I don't think I did anything wrong by posting it. If some weasel used that post (or other such sources) to create CRII, so be it. IMO, by that time any servers that were still vulnerable to CR/CRII deserved to be hit and, better yet, TOS'd by there ISP.
I just don't subcribe to the idea that suppressing potentially dangerous source code will do good in the long run. Having the source available and widely distributed has several advantages:
- promotes understanding of exploit mechanisms in order avoid making the same mistakes in the futre
- promotes rapid deployment of fixes. There is no pressure greater than knowing every little script kiddy's got the code
- raises awareness of code weaknesses/failure modes/common pitfalls (maybe *someday* CS courses will teach future coders to prevent buffer overflows!)
I firmly believe that being open about software/network/OS weaknesses will gradually drive the state of the art in secure software to a much higher level. The "keep quiet", "head-in-the-sand" approach that M$ is promoting these days will only hinder such advances. I'll make a loose analogy to the old outlaws & guns argument: "If you outlaw virus source code, only outlaws will have virus source code."
In fact, I think it is *imperative* that malicious source code NOT be suppressed. How else can we arm the next generations of app and OS coders to develop resistance code?
Though I'm not sure which part of my comment you're refering to, be my guest.
Careful there, the other day I inadvertently dissed C++ and OOP in general and must have trod on someones religion in the process.
But I think you've got a good point about FORTRAN, but I'd make a slightly different point on C++. FORTRAN is passe' not because it's old, but because what made it special (FORmula TRANslation) isn't all that special or unique anymore. C++ and OOP in general can be great, but a programmer really needs to know the difference between OOP and non-OOP and why you would want to use one method/language over the other. Applying OOP methologies where unnecessary can *add* to code complexity and obfuscation. Never use OOP because it's cool, only when it's the better way.
From the article:
"In software engineering there is no theory,"
I don't buy that... at least not completely. I would say something more like, "In software engineering, theory is extremely underutilized."
I believe there are many instances of engineered software, but not necessarily high-profile stuff. A lot of DoD conscripted code may never the the civilian light of day, but there are procedures and documentation requirements that, flawed or not, enforce certain practices. Can we call that "theory"? Anyhow, defense suppliers can afford the extra development time, 'cause the government is forking over big bucks for the code to right.
For the mainstream (read desktop) apps, where all the money is, the time to market and feature pressures will continue to suppress even the best "unified theory" of software development.
I'm the CEO of my household, and the chairman of the board and majority stockholder is my wife and she don't put up with no shit :~/
Some people call it 'whipped, but it's really just married.
Oh, and the VP of R&D is a 2 year old.
"You're no longer a hacker."
Ouch, that hurt. Actually, my daily job involves system integration, software and (sometimes) hardware development, so I kinda get my fill of it at work. Getting married... well that changed things a lot. Way back when (while single), I spent a week of evenings hacking an 8 channel [radio] scanner from Radio Trash. Interfaced the PLL tuner IC to the parallel port on my PC and wrote a C [DOS] program to control the tuning. Wound up with a 400 channel scanner when under PC control. Me very busy now; all I can do is look back on that stuff as "the Good ol' Days"
Since about 1987, I have always built my own boxes, but recently I've wavered... and it's purely on account of the cost issue. Now my time is becoming more and more valuable (higher pay, family) and PC prices [have been] getting lower and lower. It's getting harder for me to justify (especially to my wife) the time it takes to roll my own when the difference between parts and off-the-shelf is only a 100 to 200 bucks (or perhaps even less).
Used to be, I'd do it just for the love of it (and to save some dough). Now, it's usually just a pain in the ass. And I don't believe hardware prices are going to increase to point where I'll change my mind.
I'm beginning to see the light. 'til now, I'd only seen a very few (or recognized as such) real Java desktop apps. Poking around at Swing Sightings, I was surprised to find quite a few Java/GUI apps that look like fairly heavy hitters. I still have some reservations about the throughput of a busy Swing desktop application, but now I'm going to shut up until I've tried out a few more (IDEA looks good).
I think the whole "ThinkFree Office" product is just a tag to lure you to their "CyberDrive" product. Their "20-megabyte Web file-storage service" is free for one year, then $30 anually thereafter should you continue to use it. And I think it's a product (web-based storage) that, in one form or another, has been tried and failed earn a profit (think X-drive). I very dubious about web storage as a product for a couple of reasons:
. security. Let someone else store my (potentially private) files and trust them to keep grubby cracker fingers out of it?
. I've got a 120 GB drive in my desktop at work, 80 GB at home and 30 GB in my notebook, what would I need 20 MB for?
I wish them luck, but a $50 productivity suite and a $30/yr 20MB storage service? I'm afraid they'll need to sell a shitload of each to do well.
"Javascript really has very little to do with Java" That pretty well shows the limit of my knowledge of Javascript :|
I have to agree with you on the "buggy" issue; I didn't mean to imply that Java code was inherently more buggy. One feature I really admire, is the portability of code... Sun has done a great job of keeping that feature in line.
Another poster said that GUI's are probably the slowest part of a desktop Java app. I've seen things that may support that position. If true, wouldn't that be the fault of the Java Runtime Engine?
"Less than glowing" review is right. To paraphrase the reviewer, it's buggy and slow.
My experience with Java, the language this app was written in, is limited to a little experimentation, web-based javascripts and using Limewire (the Gnutella client). Limewire is also an app that I would describe as buggy and slow, with emphasis on slow.
Does anyone else have an opinion on the suitability of Java in medium (Limewire) to large (thinkFree's product) desktop applications?
"We can finally find out how to implement their PigeonRank system..."
They already described the machanisms fairly well on their site. What you might not have access to is the programming language that's optimized to the task: HP-PGL (High Performance Pigeon Goading Language).
-
To quote my own post (above):
"I wonder if they have a [business] plan for this feature..."
The more I think about it, the less I think this is going to be a "free" feature. It seems to encourage "automated queries" and that doesn't fit with any business model I've thought of (for Google) and, as you've pointed out, it's against their TOS.
I'm guessing that, if this feature comes to fruition and stays, its usage will come under some sort of paid model.
-
I wonder as well. I've used my own C/GUI front end for Google searches, mainly to automate finding and downloading PDF, gz and other binaries. But I use that much less frequently than I do normal browser based searches so I don't make the slightest spike on their BadBoy meter.
I wonder if they have a [business] plan for this feature or if it's just the brain child of their gurus in the back room. Actually, I'm quite intriqued by the possibilities, so I'm going to keep on eye on it...
-
Gee, I think someone missed my point about bloat; perhaps I wasn't clear in my prior post. Basically I have developed a poor opinion of applications trying to perform every [semi-related] function under one umbrella because of the apps' ungainly size, load time and usability.
My recommendation to counteract bloat is to:
. cut down on the unnecessary GUI gee-gaws (skins, etc)
. find the right balance of critical functions and only a few "wouldn't it be nice" elements
. remove smaller functions from the main app, then let the app call them. Allows the smaller sub-functions to be focused to the task and developed more independently (hopefully encouraging efficiency).
Maybe my previous post contained too many exclamation marks for the moderator...
Thanks much for the link. It provide a *tad* bit more info. Esp. the reference to wanting to ship 20M units in the next year. With production runs like that (and in that short a period) it makes sense to trim unit costs in any way reasonable.
-
I agree on several of your points:
. less real estate
. reliability
. "...disadvantage that this was not done already."
and 1 additional minor manufacturing point: ease of test
However, in the economics of mass production, their new design must be MUCH less expensive or seriously advantagous in some other way, in order to justify the cost of retooling for new production. The production costs for their existing product must have already hit bottom, so why reinvent and retool? They must have a reason and I would like to know more!
By the way, my experience in PCB design and manufacture is limited to small design, small runs ( 300 components, 500 board lots) and I realize the economics of scale must change motivations. On the point of "possible vias," I was told by me PCB manufacturer that number of vias/holes had very little to do with the end cost, especially compared to board size and production quantities. Part placement and test is a seperate issue and some real savings can be achieved by reducing component count, but is that the only reason Sony wants to do this?
-
How lame is this? Our wonderful "story" is merely a reference to a post on gamefu which, itself, points to no credible source.
Slashdot: "Sony says... cause Gamefu says that Nikkei Microdevice says that Sony says..."
Good, God. I don't really doubt it's happened, but where's the interview? Where's the real scoop? I'd rather know a bit more than this. I'd like to know what else might get integrated; I don't consider squeezing 2 chips into 1 is going redefine the marketplace, or even Sony's bottomline.
Mod as you will, and let's hope someone on Slashdot can post a link with more info...
-
"Touchscreens are sensitive to touch though, not pressure"
Depends on the technology used for the touchscreen.
1) Capacitive: Senses the change in capacitance within a grid. Sensitive to bare hands/fingers. Not sensitive to gloved finders, pointers or styluses. Is sensitive to your fingers lying on it, so it's not a good choice for a buttonless/clickless mouse.
2) Acoustic wave: Senses interference by an object to a generated acoustic (ultrasonic?) wave along the surface of the touchscreen. Also not good for a buttonless mouse.
3) Resistive: Senses pressure as a change is resistance within a grid. Sensitive to fingers gloved or ungloved, also sensitive to pens, styluses, etc. A great candidate for a clickless mouse.
There are other types as well, but stick with my #3 for the clickless mouse.
-
Hear, hear!
The GUI email clients I've used of late are all over-bloated already, and getting worse with each revision! There's a lot to be said for a GUI client vs a command line (text) client, but there are trade-offs, and severe bloat comes with every cute little "wish-list" items that gets added. That said, I'm never going to give up my GUI email client, but TRIM THE BLOAT!
I think the main causes of bloat are these:
1) Developers just "throwing shit together" in an attempt to keep ahead (or catch up with) of the competition.
2) GUI bloat. GUI's make for bigger apps anyway, but add on 3rd pary libraries that distance the programmer from the API, then throw a bunch of "Gee, whiz!" gooie trash (skins, a plethora of icons, smilies, etc) on top...
3) Poor object oriented programming methods. Woo, I'll prolly get flamed for this, but OOP doesn't automatically make your app better or even help you (the programmer) do a better job. The only thing that I can guarantee is your code will ALWAYS compile slower, USUALLY run slower, USUALLY bloat up like a dead pup. Not all the "fault" of OOP, but of some programming practices it may engender. OOP (C++ esp) is *great* but, as with any language, you've got to know what you're doing with it! IMO, C++ in the hands of a neophyte or run-of-the-mill CS grad is bloat and inefficiency looking for a place to happen.
Back to email clients & such: I think the best approach to (a) adding any/every cool idea possible, and (b) preventing bloat would be to partition the app into smaller chunks.
Like all the myriad utilities from the Un*x world, keep all the little features in seperate programs that could work with the main app thru an API and shared libraries. When I say "little features" I mean *make them little!*
Ah, crap. I'm gonna have to stop, cause my Rant-O-meter just pegged. I really do have a problem with code/app bloat and wish the major developers would do *something* to combat the issue, but I'm afraid it must be a non-issue to the hordes of Joe Schmoes who just got their PC a WalMart.
-
The embedded systems I've worked on range from (smallest) a 68HC11 based black box with no OS and a 511 byte program to (largest) an x86 based SBC with ROMDOS and a 400K byte program. To me, embedded is the computer in your microwave oven; you can't afford to make one of those with enough memory, etc to support even the most stripped-down version of Linux.
I realize that the term "embedded" cuts a pretty big swath, but I do believe that the majority of embedded systems are teeny-tiny; many of them with no UI at all and the entire OS (if any) & app in an OTPROM, EEPROM or Flash. The bulk of commercial embedded OSes go into things like stand alone data aquisition units, traffic light controllers, toll booth controllers, satellites, remote weather & geological telemetry devices, etc. In most of those cases, Linux and other Unices are *way* overkill.
So, maybe Lineo really was trying to go for the PDA market, but IMO, that's not embedded, PDA's are just small computers.
-
Try Limewire. With its new "swarmed downloads" I've downloaded a single file from 6 hosts simultaneously. Really filled my pipe! Also, the Ultra Peer feature lowers the crap search bandwidth usage for most users.
OTOH, Limewire comes with its own crapware, adware and spyware; but, with a little effort, you can rid yourself of most of it (even the ads, but that's more difficult).
-
Do a search on petswarehouse on google. After the first hit, it ain't pretty.
-