Same ideas that have been around for 20+ years, but I have to admit it's a fairly nice implementation of a close-to-the-wire protocol.
They could have gone more flexible and abstract; structs are *bad* for you, and they're missing a fair amount of opportunity to make things dynamic, e.g., growable arrays, hashes, sets, arbitrary nested structures, and even things like canonicalized timestamps, which are a quite important (but often neglected) platform-dependent type (see how often time gets mangled when you go multi-platform...).
As for efficiency, it wouldn't be hard to be better than SOAP. I have some horror stories...
Things would be a lot easier if the darned thing wasn't so bloody complex to emulate. I mean if we were "stuck" with (say) an ARM or even a 68K we'd be able to use virtual machines to dig ourselves out of a similar architectural hole (though with an ARM we'd be unlikely to want to).
The x86 has so many modes of operation (SMM, real/protected, lots of choices for vectorizing instructions, 16/32/64 bit modes) and special cases that it's a pretty big project to get emulation working correctly (much less fast). You're pretty much stuck with a 10x reduction clock-for-clock on a host. Making an emulated environment secure is hard, too; you don't necessarily need specialized hardware here (e.g., specialized MMU mapping modes), but it helps.
And now, with transistor speeds bottoming-out, they want to go multicore and make *more* of the things, which is exactly the opposite direction that I want to go in...:-)
(I loved the first few years of SG1, but then it got pretty random and bad, reminding me more and more of the "Forehead of the Week" clubhouse show: STtNG).
Drivers that worked would be nice. Hardware that didn't freeze would help. Finally, sound cards should be heard and not seen: They should ditch all the extra garbage they install. Look, I bought a stupid little sound card, it's not like that bit of phenolic and silicon is the centerpiece, the very *core* of my PC experience. Yet the bloatware certainly thinks it should be and insists on putting startup junk in my face, installing processes that God only knows what they do, and (I have vague memories of:) calling home to Mom to update itself.
I stopped buying Creative once it was clear they weren't going to support SMP systems anytime soon (heh, hyperthreading *forced* them to, finally), and that any improvements in their stuff was just going to involve shovelware on top of a bunch of creaky drivers that they were never going to fix any bugs in. Meh.
Sure. Company I was writing video games for (Atari) got an arcade version of Pole Position in our group's little area for evaluation. Anyone in the building could wander by and play it.
In the first two weeks after we got the machine, three people totalled their cars on the way home (after having played it for 20+ minutes). One guy flipped his car getting on 101 ("A little too aggressive on that on-ramp, Bob?")
Good ideas: Yup, a group of smart people in one spot can definitely come up with some cool ideas.
Market success: A completely different animal.
Don't confuse the two. (I was in one start-up that had crazy, wonderful technology, and they tanked. Another startup had some of the worst crap I've ever seen, and they're still around, having IPO'd).
"We shall see" about Google. They've got a tough row to hoe once they're out of the search niche, and search is pretty much a fungible technology these days. Give them three bad quarters because something else on the net "got cool" and they'll start shedding engineers, it'll be like Netscape all over again. In the meantime they've got a heavy run-rate, keeping up with salaries and benefits (which aren't all that great, despite what you hear). You'd be surprised how quickly a company that has had nothing but success can burn through a few billion dollars.
Other good texts include Processor Architecture: From Dataflow to Superscalar and Beyond (Silc, Robic, Ungerer) and (my favorite) Modern Processor Design: Fundamentals of Superscalar Processors (Shen and Lipasti). The latter appears to be more in-depth and technical than Inside the Machine (which is pretty, but which concentrates a little too much on implementations for my taste).
[this isn't school, but i've been to school and i know a whole bunch about Reed-Solomon coding, thanks]
I say: Meh. Fifty bucks buys a bunch of DVDs.
Assuming you care about the archival nature of the data you're storing, the FIRST thing you DON'T do is depend on a piece of software that will no longer run under any OS or on any hardware that you can obtain a decade hence.
In general the ECC on DVD is going to prevent you from getting bad data; it's extremely unlikely that you're going to be able to successfully read an ECC block with (say) some bits flipped. The file that is "right" is going to be the one you can read. If all of the copies of that file are damaged, chances are that the failures will be in different locations of the file. If all the files are damaged, well, the data mattered to you, so did you make multiple copies?
In other words, if I want reliability, I'm going to go SIMPLE, not more complex. And the simplest (and unarguably cheapest) way to go is to write multiple copies of a disc, which is what folks making backups have been doing ever since backups were invented.
Okay, so you store redundant (maybe error-correcting) stuff on top of the existing file system (or in otherwise unused sectors), so you can recover your files if the original sectors succumb to bit rot. For fifty bucks.
Why not just store the files twice? It would be a whole lot cheaper...
Who does an OS from scratch? Why on earth would you want to?
(Yes, I can name a few reasons: You want ".NET or Java or Smalltalk or LISP all the way to the metal," or you have some nifty hardware for which no existing kernel or porting layer will work, or you have an embedded system where you need to control every CPU cycle, or you simply want to learn how to write an OS. All valid).
I'll bet that less than 1 percent of/. readers have any code in any OS-level stuff, including device drivers and school projects. Until you've been down near the metal you have no clue about what's going on; talk is cheap.
A new OS means you don't have driver support (unless you leverage existing ones with a compatibility layer -- good luck on that), your development tools probably suck for a long time during bringup, you have to deal with real world issues of badly designed hardware, buggy chipsets and undocumented, murky corners where the people you need to talk to are either sealed-up behind corporate walls or (ahem) have better things to do than talk to whiners.
We definitely need new OS research. Unix essentially killed fundamental OS research for fifteen years in the late 70s and 80s because it was just too easy to do a port of something (yes, I'm aware of MACH and a bunch of other stuff in that time-frame, but so much more could have been done had grad students not been playing rogue all the time:-) ). What the heck happened to decent database integration? (Ans: Unix I/O and file system support sucked for/decades/; this is an area where you really want your OS to provide services to make transactions and messaging really cheap, and it didn't bloody start happening until the late 90s). Don't get me started on zero-copy TCP/IP, timers or prioritized I/O. Man.
Well, the Newton suffered from a bunch of problems, many of which the Palm series "got right" (price, size, easy docking, a very cheap story for application developers).
The Newt was also very difficult to develop for. NewtonScript rocked, as a language, but the tools weren't that great (hint: When you develop a new language, *do the debugger first!* -- you're going to need it anyway...). The GM of Newton actively discouraged developers with a "tax", requiring then to pay Apple a 1% cut (or more?) of a title's gross, and by charging (a LOT) for the development software.
When I was going to job fairs, I was looking for (surprise!) a *job*. One that was interesting, at a company that had its priorities straight.
A gewgaw or crappy pen with your company's logo on it won't help. A poster with a clear statement of the kind of people you're looking for AND someone intelligent at the booth that I can talk technical to is all that I really need. A competent poster says volumes about how your company is organized, a technical lead who asks good questions (and has good answers) is even better.
Once you have my interest, sure, hand me a flashy-buzzy thingy for my cat to tear apart. But it's really not necessary if you have your act together.
This is why whenever I hear the words "architecture" and "web" in the same sentence that I snicker. Unpolite, but OMFG who designed this junk?
Oh, right. Nobody, really. It's amazing it works at all (... and sometimes it doesn't!)
Djikstra's quip, "If programmers build houses they way they built programs, the first woodpecker to come along would topple civilization" was and remains insightful.
You can probably get away with an "oddball" console architecture as long as the development pain is swamped by the reward in the market. When I was writing games (years ago) I used to say, "No one cares how much the developers suffer making a title." And it's true, to a point.
That point is reached when your multi-million-dollar budget is being blown up by a system that is quite, quite difficult to extract performance from. Schedule slips cost money, they always have, but now the slips are *real* money.
For what gain? If the oddball architecture isn't dramatically different from the non-oddball competitors', the oddball one loses out.
I look at the SMP on the 360 and think, "Cool, I can do that." I look at the DMA-driven dwarves and busted-up memory heirarchy of the Cell and think, "Thank God I don't have to program that thing." If you care to throw yourself into that particular meat-grinder then I wish you all the best, you can *have* my lunch there, life is too short to burn yourself out on a broken architecture for what appears to be very little real gain.
Dangerous territory. Feedback could be actionable. This is lawyer territory.
Unfortunately it seems to be the bozos and flatlines and know-nothings who are vindictive. Much safer to give no feedback for someone who's clearly a waste of oxygen.
I've told people who seemed good but weren't good matches, "Look, you'd be better off doing X, Y or Z, rather than what we need at the moment." But the clearly unqualified get a polite letter or phone call and that's it, no matter how much I want to say "If you were flipping burgers, I'd cross the street and eat at Taco Hell."
I'm happy that we're *this close* [holds hooves together a couple millimeters apart] to finally splitting the cow atom. It's been a long road of discovery, from the Heifersburg uncertainty principle (you can have a cow, or a burger, but not both) to the realization that it is possible to cross a cattle grating, with careful quantized footing and a lot of federal funding.
The next big challenge: Sub-atomic cow fusion, and bringing subjugation to the lemur foe! Mooooo!
Of *course* I worked for Atari (on the ST . . . and other things). We had the Flying Tramiel Brothers Invasion Corps and Marching Band and an OS scraped together over a weekend by Digital Research. The Amiga guys had multitasking, blitters, bouncing beachballs, compilers that didn't suck . . . and Kiki Stockhammer. My living God, we were jealous.
Ah, but who went out of business first? [Actually, I couldn't tell you. Don't bother me with facts; my false sense of superiority works best in a vacuum]
Funny how later I ended up working for one of the guys who shipped the first Mac. Silly Valley is small, *way* small: Don't piss anyone off unless it's really worth it. And when you ship, make sure you have a beachball.
"Sell your Agima! Move out of your parent's house!"
seems even more apropos now.
Ahem. Of course, the 25+ year old vintage microcomputers that I'm currently mucking around with (restoring digital tape drives, making MP3s of old audio cassettes, cleaning the muck off 1Kx1 RAM chips...) are not a waste of time, because . . . well, because.:-)
Most of the really good people I've worked with have had either (A) a really good education and have read a lot of good books, or (B) they are self-taught and have read a lot of good books.
It's just like school, really. Read. Do the exercises. There are tons of books (some even good) on how to write video game engines, for instance. (Just avoid the Sams "Learn game programming in 31 milliseconds!" crap). In the absence of helpful literature, well, I didn't know how games worked until I just sat down and wrote a few (a couple years later I had shipped several titles for a company you've definitely heard of).
You could do worse than to join the ACM and take advantage of their online library of journals and proceedings. It's a super way to come up to speed on just about anything in computing.
1. The Atari ST would boot in under two seconds (it's been a while -- definitely less than five seconds, even from hard disk). This was fast enough that, after several years with Macs and PCs, I had a visceral sense of "something is wrong" when I hauled my ST out of the closet. Hit [reset] and SPROING! the GUI is there in front of you a couple of seconds later. Wow.
2. When I joined Apple in 1987, the systems software folks were getting lots of flack about how long it took for a Mac to start up. There was a sign on the top floor of Deanza 6 saying "Time to boot tripled!" (I think this was System 6.0, memory fades). Through public shaming and general introspection boot times got better, but even today they still stink.
3. Visa asked IBM for the source code to the OS of whatever big IBM iron they were using to process credit card transactions. It took many, many minutes to reboot their machines, and *any* off-line time to Visa is pretty serious (thousands of dollars a second, probably). IBM said, "Are you crazy? You'll just break it. No way do you get the sources." Visa talked to the banks, the banks Had A Talk with IBM, and IBM said, "What were we thinking, here you go, need any help?" Visa hacked on the OS and got the boot time down to under a minute.
Many phones have *lots* of storage on them these days. You could imagine a mode that takes voice, compresses it to spare space in the flash file system, then squirts the data up at opportune times (e.g., trickle during a conversation, the tail end of a conversation, etc). This way you wouldn't have to have the radio on all the time (which is easily detectable with $5 dongles). In "VOX" mode I'll bet you could get several days of recording compressed into a few megabytes.
Either technique will have an effect on battery life, however. This is hard to hide, but most people would probably write it off to the general flakiness of batteries.
Anyone remember the flap in the 90s about the software controlled "off hook" LED on ISDN phones? (... didn't think so....)
Slashdot Mirror
The kind man who gave us Explorer Scouts the tour of the IBM Federal Data Center in Gaithersburg, MD (literally acres of machine room floor) said:
"Don't touch that red switch. Really don't. It takes us days to recover."
and
"Well, you actually have to *pull* the knob." (Why he gave half a dozen computer-starved teenagers that knowledge, I have no idea).
On IBM systems, apparently there's a knife of some kind that physically severs the power cables. It's a mess.
"Should I be able to create a book -- ?"
Yes. Absolutely. End of story.
"We know how to fix software really easily."
Hahahahahahahaha. Anyone who thinks that it's easy to patch several tens of millions of machines in customer homes or offices is an idiot.
Same ideas that have been around for 20+ years, but I have to admit it's a fairly nice implementation of a close-to-the-wire protocol.
They could have gone more flexible and abstract; structs are *bad* for you, and they're missing a fair amount of opportunity to make things dynamic, e.g., growable arrays, hashes, sets, arbitrary nested structures, and even things like canonicalized timestamps, which are a quite important (but often neglected) platform-dependent type (see how often time gets mangled when you go multi-platform...).
As for efficiency, it wouldn't be hard to be better than SOAP. I have some horror stories...
Things would be a lot easier if the darned thing wasn't so bloody complex to emulate. I mean if we were "stuck" with (say) an ARM or even a 68K we'd be able to use virtual machines to dig ourselves out of a similar architectural hole (though with an ARM we'd be unlikely to want to).
:-)
The x86 has so many modes of operation (SMM, real/protected, lots of choices for vectorizing instructions, 16/32/64 bit modes) and special cases that it's a pretty big project to get emulation working correctly (much less fast). You're pretty much stuck with a 10x reduction clock-for-clock on a host. Making an emulated environment secure is hard, too; you don't necessarily need specialized hardware here (e.g., specialized MMU mapping modes), but it helps.
And now, with transistor speeds bottoming-out, they want to go multicore and make *more* of the things, which is exactly the opposite direction that I want to go in...
Enough wasting money already. Bring back Firefly.
(I loved the first few years of SG1, but then it got pretty random and bad, reminding me more and more of the "Forehead of the Week" clubhouse show: STtNG).
Drivers that worked would be nice. Hardware that didn't freeze would help. Finally, sound cards should be heard and not seen: They should ditch all the extra garbage they install. Look, I bought a stupid little sound card, it's not like that bit of phenolic and silicon is the centerpiece, the very *core* of my PC experience. Yet the bloatware certainly thinks it should be and insists on putting startup junk in my face, installing processes that God only knows what they do, and (I have vague memories of:) calling home to Mom to update itself.
I stopped buying Creative once it was clear they weren't going to support SMP systems anytime soon (heh, hyperthreading *forced* them to, finally), and that any improvements in their stuff was just going to involve shovelware on top of a bunch of creaky drivers that they were never going to fix any bugs in. Meh.
Sure. Company I was writing video games for (Atari) got an arcade version of Pole Position in our group's little area for evaluation. Anyone in the building could wander by and play it.
In the first two weeks after we got the machine, three people totalled their cars on the way home (after having played it for 20+ minutes). One guy flipped his car getting on 101 ("A little too aggressive on that on-ramp, Bob?")
Good ideas: Yup, a group of smart people in one spot can definitely come up with some cool ideas.
Market success: A completely different animal.
Don't confuse the two. (I was in one start-up that had crazy, wonderful technology, and they tanked. Another startup had some of the worst crap I've ever seen, and they're still around, having IPO'd).
"We shall see" about Google. They've got a tough row to hoe once they're out of the search niche, and search is pretty much a fungible technology these days. Give them three bad quarters because something else on the net "got cool" and they'll start shedding engineers, it'll be like Netscape all over again. In the meantime they've got a heavy run-rate, keeping up with salaries and benefits (which aren't all that great, despite what you hear). You'd be surprised how quickly a company that has had nothing but success can burn through a few billion dollars.
Other good texts include Processor Architecture: From Dataflow to Superscalar and Beyond (Silc, Robic, Ungerer) and (my favorite) Modern Processor Design: Fundamentals of Superscalar Processors (Shen and Lipasti). The latter appears to be more in-depth and technical than Inside the Machine (which is pretty, but which concentrates a little too much on implementations for my taste).
[this isn't school, but i've been to school and i know a whole bunch about Reed-Solomon coding, thanks]
I say: Meh. Fifty bucks buys a bunch of DVDs.
Assuming you care about the archival nature of the data you're storing, the FIRST thing you DON'T do is depend on a piece of software that will no longer run under any OS or on any hardware that you can obtain a decade hence.
In general the ECC on DVD is going to prevent you from getting bad data; it's extremely unlikely that you're going to be able to successfully read an ECC block with (say) some bits flipped. The file that is "right" is going to be the one you can read. If all of the copies of that file are damaged, chances are that the failures will be in different locations of the file. If all the files are damaged, well, the data mattered to you, so did you make multiple copies?
In other words, if I want reliability, I'm going to go SIMPLE, not more complex. And the simplest (and unarguably cheapest) way to go is to write multiple copies of a disc, which is what folks making backups have been doing ever since backups were invented.
Okay, so you store redundant (maybe error-correcting) stuff on top of the existing file system (or in otherwise unused sectors), so you can recover your files if the original sectors succumb to bit rot. For fifty bucks.
Why not just store the files twice? It would be a whole lot cheaper...
Who does an OS from scratch? Why on earth would you want to?
/. readers have any code in any OS-level stuff, including device drivers and school projects. Until you've been down near the metal you have no clue about what's going on; talk is cheap.
:-) ). What the heck happened to decent database integration? (Ans: Unix I/O and file system support sucked for /decades/; this is an area where you really want your OS to provide services to make transactions and messaging really cheap, and it didn't bloody start happening until the late 90s). Don't get me started on zero-copy TCP/IP, timers or prioritized I/O. Man.
(Yes, I can name a few reasons: You want ".NET or Java or Smalltalk or LISP all the way to the metal," or you have some nifty hardware for which no existing kernel or porting layer will work, or you have an embedded system where you need to control every CPU cycle, or you simply want to learn how to write an OS. All valid).
I'll bet that less than 1 percent of
A new OS means you don't have driver support (unless you leverage existing ones with a compatibility layer -- good luck on that), your development tools probably suck for a long time during bringup, you have to deal with real world issues of badly designed hardware, buggy chipsets and undocumented, murky corners where the people you need to talk to are either sealed-up behind corporate walls or (ahem) have better things to do than talk to whiners.
We definitely need new OS research. Unix essentially killed fundamental OS research for fifteen years in the late 70s and 80s because it was just too easy to do a port of something (yes, I'm aware of MACH and a bunch of other stuff in that time-frame, but so much more could have been done had grad students not been playing rogue all the time
Well, the Newton suffered from a bunch of problems, many of which the Palm series "got right" (price, size, easy docking, a very cheap story for application developers).
The Newt was also very difficult to develop for. NewtonScript rocked, as a language, but the tools weren't that great (hint: When you develop a new language, *do the debugger first!* -- you're going to need it anyway...). The GM of Newton actively discouraged developers with a "tax", requiring then to pay Apple a 1% cut (or more?) of a title's gross, and by charging (a LOT) for the development software.
When I was going to job fairs, I was looking for (surprise!) a *job*. One that was interesting, at a company that had its priorities straight.
A gewgaw or crappy pen with your company's logo on it won't help. A poster with a clear statement of the kind of people you're looking for AND someone intelligent at the booth that I can talk technical to is all that I really need. A competent poster says volumes about how your company is organized, a technical lead who asks good questions (and has good answers) is even better.
Once you have my interest, sure, hand me a flashy-buzzy thingy for my cat to tear apart. But it's really not necessary if you have your act together.
It probably gets out of line when you mash up a Columbine-type game with Remote Control Hunting.
I'm just sayin'.
This is why whenever I hear the words "architecture" and "web" in the same sentence that I snicker. Unpolite, but OMFG who designed this junk?
Oh, right. Nobody, really. It's amazing it works at all (... and sometimes it doesn't!)
Djikstra's quip, "If programmers build houses they way they built programs, the first woodpecker to come along would topple civilization" was and remains insightful.
You can probably get away with an "oddball" console architecture as long as the development pain is swamped by the reward in the market. When I was writing games (years ago) I used to say, "No one cares how much the developers suffer making a title." And it's true, to a point.
That point is reached when your multi-million-dollar budget is being blown up by a system that is quite, quite difficult to extract performance from. Schedule slips cost money, they always have, but now the slips are *real* money.
For what gain? If the oddball architecture isn't dramatically different from the non-oddball competitors', the oddball one loses out.
I look at the SMP on the 360 and think, "Cool, I can do that." I look at the DMA-driven dwarves and busted-up memory heirarchy of the Cell and think, "Thank God I don't have to program that thing." If you care to throw yourself into that particular meat-grinder then I wish you all the best, you can *have* my lunch there, life is too short to burn yourself out on a broken architecture for what appears to be very little real gain.
Dangerous territory. Feedback could be actionable. This is lawyer territory.
Unfortunately it seems to be the bozos and flatlines and know-nothings who are vindictive. Much safer to give no feedback for someone who's clearly a waste of oxygen.
I've told people who seemed good but weren't good matches, "Look, you'd be better off doing X, Y or Z, rather than what we need at the moment." But the clearly unqualified get a polite letter or phone call and that's it, no matter how much I want to say "If you were flipping burgers, I'd cross the street and eat at Taco Hell."
I'm happy that we're *this close* [holds hooves together a couple millimeters apart] to finally splitting the cow atom. It's been a long road of discovery, from the Heifersburg uncertainty principle (you can have a cow, or a burger, but not both) to the realization that it is possible to cross a cattle grating, with careful quantized footing and a lot of federal funding.
The next big challenge: Sub-atomic cow fusion, and bringing subjugation to the lemur foe! Mooooo!
Of *course* I worked for Atari (on the ST . . . and other things). We had the Flying Tramiel Brothers Invasion Corps and Marching Band and an OS scraped together over a weekend by Digital Research. The Amiga guys had multitasking, blitters, bouncing beachballs, compilers that didn't suck . . . and Kiki Stockhammer. My living God, we were jealous.
Ah, but who went out of business first? [Actually, I couldn't tell you. Don't bother me with facts; my false sense of superiority works best in a vacuum]
Funny how later I ended up working for one of the guys who shipped the first Mac. Silly Valley is small, *way* small: Don't piss anyone off unless it's really worth it. And when you ship, make sure you have a beachball.
My refrain from 15 years ago:
:-)
"Sell your Agima! Move out of your parent's house!"
seems even more apropos now.
Ahem. Of course, the 25+ year old vintage microcomputers that I'm currently mucking around with (restoring digital tape drives, making MP3s of old audio cassettes, cleaning the muck off 1Kx1 RAM chips...) are not a waste of time, because . . . well, because.
Most of the really good people I've worked with have had either (A) a really good education and have read a lot of good books, or (B) they are self-taught and have read a lot of good books.
It's just like school, really. Read. Do the exercises. There are tons of books (some even good) on how to write video game engines, for instance. (Just avoid the Sams "Learn game programming in 31 milliseconds!" crap). In the absence of helpful literature, well, I didn't know how games worked until I just sat down and wrote a few (a couple years later I had shipped several titles for a company you've definitely heard of).
You could do worse than to join the ACM and take advantage of their online library of journals and proceedings. It's a super way to come up to speed on just about anything in computing.
Three quick stories:
1. The Atari ST would boot in under two seconds (it's been a while -- definitely less than five seconds, even from hard disk). This was fast enough that, after several years with Macs and PCs, I had a visceral sense of "something is wrong" when I hauled my ST out of the closet. Hit [reset] and SPROING! the GUI is there in front of you a couple of seconds later. Wow.
2. When I joined Apple in 1987, the systems software folks were getting lots of flack about how long it took for a Mac to start up. There was a sign on the top floor of Deanza 6 saying "Time to boot tripled!" (I think this was System 6.0, memory fades). Through public shaming and general introspection boot times got better, but even today they still stink.
3. Visa asked IBM for the source code to the OS of whatever big IBM iron they were using to process credit card transactions. It took many, many minutes to reboot their machines, and *any* off-line time to Visa is pretty serious (thousands of dollars a second, probably). IBM said, "Are you crazy? You'll just break it. No way do you get the sources." Visa talked to the banks, the banks Had A Talk with IBM, and IBM said, "What were we thinking, here you go, need any help?" Visa hacked on the OS and got the boot time down to under a minute.
Many phones have *lots* of storage on them these days. You could imagine a mode that takes voice, compresses it to spare space in the flash file system, then squirts the data up at opportune times (e.g., trickle during a conversation, the tail end of a conversation, etc). This way you wouldn't have to have the radio on all the time (which is easily detectable with $5 dongles). In "VOX" mode I'll bet you could get several days of recording compressed into a few megabytes.
Either technique will have an effect on battery life, however. This is hard to hide, but most people would probably write it off to the general flakiness of batteries.
Anyone remember the flap in the 90s about the software controlled "off hook" LED on ISDN phones? (... didn't think so....)