While WinMo and Palm phones don't see much malware, they do have a bumpy 3rd party app landscape. Even the app resellers like Handango and PocketGear/PalmGear do little to ensure that you're getting a quality, reliable app that plays well with the others you've bought. Currently I have about five licenses for Palm apps, at least two of which made my phone unstable while they were installed. They were all from high-profile developers and were well regarded by the community.
A centralized store that sold apps that were qualified to work properly on their target would go a long way to making people want to shell out for software locked to one vendor's phone. Before someone complains about the fact that the software can't be resold, well, I still have those Palm apps, all of which have license keys locked to my sync ID.
As an example, you could say the same exact thing about all of the people who are buying Blackberries because they're trendy. Most of these folks don't connect them to a corporate BIS. They're probably locked in to a contract and don't get use out of the expensive Blackberry data plans.
A short that causes an arc to form in a conduit carrying high voltage at high currents is enough to cause quite an explosion without any solid or liquid explosives.
Apparently not. The flash array is in the middle of a silicon die and protected with a layer of oxide and epoxy. The pins that come out of the chip packages go directly to some control circuitry and not the flash cells themselves. The flash cells are isolated unless the control circuitry actively tries to read them. So if you were to short all of the pins on the flash chip with the power off the data will still be intact.
If you do put your flash drive through the washer / pool / toilet you should try to soak it in distilled (not deionized or spring) water for a while and then let it dry on a windowsill for a few days. As long as you don't plug it in until it dries it should work just like new. This is the same process used during manufacture of most PC boards with water soluble flux, so it's likely that your drive has already been dunked anyway.
My favorite disk to recover was a Quantum SCSI drive from an old Performa. That model frequently developed congealed oil in the armature bearings. The disk would run for a bit then stop since the heads wouldn't be able to move to a position to receive the servo pulse.
The best way to get the drive going again was to power it up and about 1/2 second later give the edge opposite the connectors a light whack with a mallet. That would unstick the heads long enough to leave park and warm up.
I think it began the same day Slashdot started giving preferential treatment to blogwhores who link to a 2 line treatment on their own site rather than the material being discussed.
Writing an emulation layer is fine if you're Apple. It's not fine if you're a 10k unit/year medical equipment vendor with hundreds of thousands of dollars spent on qualifying your product for clinical use. It's not fine in the low-margin consumer electronics market where you buy most of your software components, often tied to one architecture or another, to save on development costs.
Most CVCS users do work on development or experimental branches for exactly that reason. That way you can follow the 'commit often' rule. You really should only be doing merges to release branches or the trunk.
Right on. Besides, the mobile market is fueled by the further integration of peripherals into SOCs. Performance and power aside: if I were going to design a smartphone, I wouldn't want to go with a three-piece cpu and chipset, not to mention licensing and development for BIOS on a new platform. And that's before including special ASICs for functionality not built into the chipset (3D accel, radio interfaces, LCD & touch panel). And then I'd be stuck with one of the few vendors who make modern embedded x86 chips.
If I go with ARM instead, I get a wide choice of SOCs from which I can pick and choose the built-in features (including the ones mentioned above). Bootloaders are generally included as part of the BSP for any given embedded OS, and if I don't like that there's always redboot or uboot (probably more too, I haven't been in the embedded world in a few years). If I don't want to use vendor A's product on revision 2 of the product, then I choose from one of the many remaining products out there, and my code ports over cleanly.
That's the book that took me from the Radio Shack 200-in-1 springs and wiring diagrams kit to building power supplies, amps, and simple digital circuits as a kid. If Mr. Mims keeps revising it, I'll probably pick up a copy for my son in the next decade.
As for what DMM a beginner should get, I recommend the Radio Shack $20 (is it still $20?) fold-up autoranging model. It's good for voltage, resistance, and continuity, and it's cheap enough that you won't be upset when you lose it.
Last I checked that other company would license their embedded codec with DRM to any manufacturer. Name one player besides Apple's that plays iTMS protected AAC.
Apple sells DRM free tracks. But how many people do you know that buy from iTMS that have a DRM free collection? Even if you bought just one DRMed album, you'd have to keep using Apple's products to maintain that investment.
Don't get me wrong. I have an iPod. But I refuse to buy from iTMS. I'd rather give the same money to Amazon and get my tracks in plain unencumbered MP3.
Most mobile phone applications that need to run in the background are monitoring a network resource. That;s the allure of an always connected portable computer. How do you block on new POP mail on your mail server? How do you block on a new IM arriving in your account? Changes in your RSS feeds? Updates to the local weather? Stocks? Polling and yielding is the best you can do in these cases.
Apple is refusing to allow background tasks simply because they can't trust all developers to write them properly. Hell, most desktop developers can't be bothered to do a sleep(0) when their app is lazily polling for something.
Home Depot and Ikea offer free fluorescent (tube and CFL) recycling. Of course, you still have to handle the bulbs properly during use and recycling, and I'm assuming that recyclers can recover a large portion of the mercury.
Next time I hit "Reply" before noon ask me if I've had my coffee. Now that I think about it, unless you are airheaded (see my OP) there wouldn't be any exploding, right? Someone call Adam Savage!
Slashdot Mirror
While WinMo and Palm phones don't see much malware, they do have a bumpy 3rd party app landscape. Even the app resellers like Handango and PocketGear/PalmGear do little to ensure that you're getting a quality, reliable app that plays well with the others you've bought. Currently I have about five licenses for Palm apps, at least two of which made my phone unstable while they were installed. They were all from high-profile developers and were well regarded by the community.
A centralized store that sold apps that were qualified to work properly on their target would go a long way to making people want to shell out for software locked to one vendor's phone. Before someone complains about the fact that the software can't be resold, well, I still have those Palm apps, all of which have license keys locked to my sync ID.
As an example, you could say the same exact thing about all of the people who are buying Blackberries because they're trendy. Most of these folks don't connect them to a corporate BIS. They're probably locked in to a contract and don't get use out of the expensive Blackberry data plans.
10 page usage/help text with no pager, sent to stderr.
A short that causes an arc to form in a conduit carrying high voltage at high currents is enough to cause quite an explosion without any solid or liquid explosives.
Hopefully an explosion would jostle out the clog that makes their Rails pipes run slowly.
Apparently not. The flash array is in the middle of a silicon die and protected with a layer of oxide and epoxy. The pins that come out of the chip packages go directly to some control circuitry and not the flash cells themselves. The flash cells are isolated unless the control circuitry actively tries to read them. So if you were to short all of the pins on the flash chip with the power off the data will still be intact.
If you do put your flash drive through the washer / pool / toilet you should try to soak it in distilled (not deionized or spring) water for a while and then let it dry on a windowsill for a few days. As long as you don't plug it in until it dries it should work just like new. This is the same process used during manufacture of most PC boards with water soluble flux, so it's likely that your drive has already been dunked anyway.
My favorite disk to recover was a Quantum SCSI drive from an old Performa. That model frequently developed congealed oil in the armature bearings. The disk would run for a bit then stop since the heads wouldn't be able to move to a position to receive the servo pulse.
The best way to get the drive going again was to power it up and about 1/2 second later give the edge opposite the connectors a light whack with a mallet. That would unstick the heads long enough to leave park and warm up.
I think it began the same day Slashdot started giving preferential treatment to blogwhores who link to a 2 line treatment on their own site rather than the material being discussed.
Apple did buy Rosetta, but I was thinking about their 68k-PPC transition for some reason. They wrote that one in-house.
ARM is pretty much the winner in the 32-bit embedded world, though MIPS has a hold in video apps.
Writing an emulation layer is fine if you're Apple. It's not fine if you're a 10k unit/year medical equipment vendor with hundreds of thousands of dollars spent on qualifying your product for clinical use. It's not fine in the low-margin consumer electronics market where you buy most of your software components, often tied to one architecture or another, to save on development costs.
Most CVCS users do work on development or experimental branches for exactly that reason. That way you can follow the 'commit often' rule. You really should only be doing merges to release branches or the trunk.
Right on. Besides, the mobile market is fueled by the further integration of peripherals into SOCs. Performance and power aside: if I were going to design a smartphone, I wouldn't want to go with a three-piece cpu and chipset, not to mention licensing and development for BIOS on a new platform. And that's before including special ASICs for functionality not built into the chipset (3D accel, radio interfaces, LCD & touch panel). And then I'd be stuck with one of the few vendors who make modern embedded x86 chips.
If I go with ARM instead, I get a wide choice of SOCs from which I can pick and choose the built-in features (including the ones mentioned above). Bootloaders are generally included as part of the BSP for any given embedded OS, and if I don't like that there's always redboot or uboot (probably more too, I haven't been in the embedded world in a few years). If I don't want to use vendor A's product on revision 2 of the product, then I choose from one of the many remaining products out there, and my code ports over cleanly.
All the better. If Geoff learns UNIX then he won't be reliant on nine year olds to escape islands with biological experiments gone awry.
That's the book that took me from the Radio Shack 200-in-1 springs and wiring diagrams kit to building power supplies, amps, and simple digital circuits as a kid. If Mr. Mims keeps revising it, I'll probably pick up a copy for my son in the next decade.
As for what DMM a beginner should get, I recommend the Radio Shack $20 (is it still $20?) fold-up autoranging model. It's good for voltage, resistance, and continuity, and it's cheap enough that you won't be upset when you lose it.
Last I checked that other company would license their embedded codec with DRM to any manufacturer. Name one player besides Apple's that plays iTMS protected AAC.
Apple sells DRM free tracks. But how many people do you know that buy from iTMS that have a DRM free collection? Even if you bought just one DRMed album, you'd have to keep using Apple's products to maintain that investment.
Don't get me wrong. I have an iPod. But I refuse to buy from iTMS. I'd rather give the same money to Amazon and get my tracks in plain unencumbered MP3.
Of course. They have to. They certainly don't want to use their own DRM scheme to ensure infrastructure lock-in.
Seriously, can we get a -1 Apologist choice for moderation?
Is there anything in the corner of that towel that's effective against headcrabs?
Most mobile phone applications that need to run in the background are monitoring a network resource. That;s the allure of an always connected portable computer. How do you block on new POP mail on your mail server? How do you block on a new IM arriving in your account? Changes in your RSS feeds? Updates to the local weather? Stocks? Polling and yielding is the best you can do in these cases.
Apple is refusing to allow background tasks simply because they can't trust all developers to write them properly. Hell, most desktop developers can't be bothered to do a sleep(0) when their app is lazily polling for something.
Does playing this game make you near-sighted?
They also deserve to DIE DIE DIE for naming JavaScript.
for sharing.
Home Depot and Ikea offer free fluorescent (tube and CFL) recycling. Of course, you still have to handle the bulbs properly during use and recycling, and I'm assuming that recyclers can recover a large portion of the mercury.
Next time I hit "Reply" before noon ask me if I've had my coffee. Now that I think about it, unless you are airheaded (see my OP) there wouldn't be any exploding, right? Someone call Adam Savage!
I think you meant implode.