The age old slogan of "never underestimate the bandwidth of a van full of backup tapes" holds true today. However, "just" a MicroSD memory card of 32 gigs can hold a LOT of useful information. Said card can be easily put in a dead drop, just like the old fashioned spying using microfilm.
My worry is that businesses will spend their time protecting (or trying to) protect against remote threats that they won't keep an eye out for the obvious.
This is how Windows Mobile 6 and newer protect the contents on the memory card. It creates a key (and I forgot what exact file it uses under \Windows), and when writing to files on the SD card, uses that key with AES-128. When reading files, it checks the file against the list of keys stored to see if it can decrypt it. If it can, it will transparently decrypt it.
Hard reset the WM device either by a remote wipe, too many wrong PINs, or physically, and that keyfile is wiped and recreated with a new random key.
Blackberries go one step further and offer to ask for a passphrase, use device encryption, or both.
iPhone encryption is present, but articles have been around stating that it needs some work.
Android's weakness is that it has -no- encryption mechanism. And this is ironic because this would be trivial to set up under Linux. Device-based encryption can use LUKS, file based could use a variant of EncFS. Android by itself doesn't have any facility for remote wiping, but there are a number of third party apps (WaveSecure), as well as phone maker software (MotoBlur) which allow for remote wipe capability.
Ideally, phones should have security on par with a Blackberry. They should support:
Remote wipe (obviously). Wipe if SIM card is changed, card is not on an authorized list. Wipe if the phone has not been on the network in X amount of time. Wipe if the phone has had too many bad passwords entered. File encryption, as well as encryption by device, so the memory card would be completely unreadable to an attacker who couldn't even guess file sizes or names. Backups, with some form of encryption, be it a passphrase or other ways. Secure storage of private keys (client Web certificates, PGP/gpg keys) where not just any app can read the private key material, but have to go through an API which prompts the user, and optionally asks for a PIN.
One app I use to mitigate this is Droidwall. It is an app for rooted phones which uses ipchains to allow or deny apps access to the network. Even if an app demands Internet access, it won't be able to send packets in or out unless Droidwall is configured to allow it.
Of course, if an app is installed and nobody checks permissions, it can send/receive using SMS or MMS, but that is a different story altogether.
This is the same battle as DRM fights. Who has control of the host can dump memory images of the VMs at will.
Not like this can't be done, where the VMs are protected from the host. Look how well the PS3 has kept its security without a solid breach, and when it was breached, it was fixed by a ROM update in record time.
I will give a concrete example of this: Motorola's CLIQ. It has fastboot disabled, and its initial root was done by a RAMDLD exploit. About a month later, it had an OTA radio ROM update. What happened is, if you had a custom ROM on your Cliq and that update went through, you would end up with an inoperable device until you flashed a factory stock.SHX file onto your phone. Of course, guess what? The RAMDLD exploit was fixed, and the phone was made unrootable. Source: modmymoto.com's CLIQ forums.
Unrootable, until an European carrier had their version of the CLIQ ROM which happened to ship with ro.secure set to 0. This meant you could flash a custom recovery module via adb, then reflash a custom ROM as part of the root process.
Even HTC has had reports of this (IIRC). Some of their models, if you go to xda-developers, the ROM makers have noticed that some of the filesystems cannot be remounted read-write, even with root.
This is what we don't want. We don't want supposedly open devices which in reality are locked down in subtle ways. This is why that my next phone is going to be a phone that doesn't use hidden signatures, disabled fastboot ROM, or other items to prevent rooting or modding with custom ROMS.
The problem is that "something different" may not be good.
Obligatory car analogy: It would be like trading in your 10 year old car for a new one that looks cool and is comfortable, but is completely autopiloted, and only lets you out at certain stops. Businesses have to apply to the car maker so the car would stop at their brick and mortar store. And without warning, this can be taken away, so if someone used to stop at a Target, they wouldn't have that option tomorrow and only get Wal-Marts. Continuing the analogy, someone patches the ECM with a steering wheel to allow manual control, but the next year's cars always come with protection against that.
People trading their computers in for what are effectively game consoles means that they are trading their freedom to run what they want, when they want for an environment locked down and managed by someone else who can do anything they please.
My question is: Do we want to go this route of sacrificing openness for ease of use? Yes, viruses and Trojans are a nuisance, but do we want to trade our relatively open computers for what would essentially be terminals, locked to some for-profit corporation's motives and future? For me, it is a no-brainer. I will keep my computer, and my phone will be on an open platform. If Android phones become unrootable or impossible to put custom ROMs on, I'll move to the Nokia N900 and encourage others to follow.
Do we want all our computers to be like PS3s where at any time, functionality can disappear at a moment's notice like the "other OS", and there would not be a single thing we can do about it? I'm sure the usual antagonists of open computing would love a wholesale move to a locked down platform, but is that where we want to take computing as we know it? Do we want to move to a computing model where what we buy, we are only permitted access to whatever the company allows on a whim? Yes, PS3s have no virus or spyware problems, but we are trading freedom for security here, and in the end, we will end up with neither.
Just some will. T-Mobile is arguably the best about this, because people either have bought their phone outright, or have to pay an ETF.
Other providers might not let you unlock your phones. I do not know if Sprint or Verizon will allow someone to do this, nor do I know if either provider would let someone have a unit on their CDMA network without their branding. They might with their "world" phones (the ones that have both CDMA and a GSM radio.)
Another advantage of one standard for phones: No need to have so many radio bands allocated. GSM has one band. AT&T'3 3G has another, T-Mobile's has another, CDMA has theirs. WiMax has one, same with LTE, and iDen. Having one standard means that a lot of the bands can be freed up for other uses.
You also have the ability for companies to share towers. This is what T-Mobile and AT&T did, pre-3G. This way, each phone company didn't have to have their own tower in each space for coverage, but could just lease from another provider.
There is one thing the Nexus One has that very few phones don't -- rootability. Want to root a Nexus One:
Fire up adb, fastboot the phone, enter in "fastboot oem unlock", then flash whatever image you want.
Other phones have a lot of roadblocks to custom ROMs, or even rooting it. For example, read-only partitions under Linux that stay read-only even when rooted. Or having fastboot disabled and everything else signed so trying to get root access is a job in itself.
My first choice with a phone is rootability. And I'm hoping if there is a Nexus Two, it will be as easily rootable as the N1. I'm also hoping Google has an ADP3 that has a modern (1GHz or so) CPU, preferably with a slider keyboard.
Two years max? I was content with my Windows Mobile phone (a HTC Wizard) for its lifetime of over four years. It wasn't handled with kid gloves either (although it wasn't spilled on, dropped, or roughly handled.)
There is a good reason to spend that much on a phone these days. For me, a phone can do a good amount of functions a laptop can. It also serves as a functional equivalent [1] of: a MP3 player, a PDA, a GPS receiver, a SecurID keyfob, and even random stuff, such as a compass, an XM radio player, a VT100 terminal, a SSH client, a so-so camera, a video camera, a Game Boy, and a wireless router with tethering. Having all these discrete devices would easily amount to this cost. For what a decent smartphone does these days, it is a comparative bargain compared to just what a PDA sold for just 3-4 years ago, where an iPaq sold for $600 or higher.
So, for a device that lasts 4 years that offers a lot of functionality, and the fact that it is something I use daily, so the ratio for money spent for time used is very good.
[1]: Well, not really a 100% functional equivalent. I'd say 50%-90% of the features, but better than nothing. For example, Android's MP3 player is pretty Spartan when it comes to features, but it does the job. Or the GPS directions require an app with a monthly subscription.
Both automatic transmissions and manual transmissions (well, mainstream ones. I'm not meaning the Justy's ECVT or others), both use friction surfaces that eventually wear out. Manual transmissions have clutch plates. Automatic transmissions use brake bands actuated by fluid pressures and planetary gear systems.
Brake bands wear out eventually, thus causing slipping, and eventually will need to be replaced (thus a rebuild.)
I don't know the details, but I've seen the NuVinci end up on cruiser bikes. I never see it specced for much else outside of that type.
The Rohloff is a masterwork of engineering, IMHO. I wish it would show up on more mountain bikes, because it completely gets rid of a ton of issues. It is expensive, but XT and XTR components are about the same price. And weight-wise, it is competitive to standard derailleur systems for mountain bikes. The biggest advantage this gives is the reliability. The chain maintains the same path and doesn't get twisted (side loads are what help contribute to wearing bike chains out), there is no low hanging derailleur to get smacked by rocks, and you can change gears while stopped. Only real hub maintaining is doing oil changes.
Actually, any professional grade UPS is set up this way. Online systems have the data center power always coming off the batteries 24/7. Only if there is a complete battery failure does power get switched to the utility company. This is opposed to standby UPSes that have power going from the utility, and try to switch over to battery. This also provides very clean power, so brownouts or spikes do not affect the equipment.
Any serious data center has an online UPS like this where someone can flip off the utility power, and the DC will not skip a beat until the batteries croak. However, by then, the diesel generator should be on and working.
I wonder how "3.5G" networks such as T-Mobile's HSPA+ will compare to this. T-Mobile is supposed to have this rolled out at the end of this year, and because it isn't as big a hardware change, towers can be converted faster as compared to a completely new wireless technology.
I've heard people in Philadelphia say that T-Mobile has the edge compared to Clear WiMax, but it has been stated that T-Mobile has a 5 GB limit per month, so that makes it useless for a primary Internet connection.
When will someone get the Evo rooted and able to have custom ROMs. This is my biggest decision maker on what phone I select. If the phone has hidden obstacles (partitions that can't be mounted rw even with root, fastboot issues, etc.), or have other gotchas (such as the radio ROM upgrade on the Cliq), then I'll pass, even if it has a fast Internet connection.
I can think of a lot of very useful things that could be useful with a device offering a fast connection and with a custom ROM. A quick and dirty failover connection on a LAN, to plugging into a server and running some firewall/VPN software on the Android level for a fast remote access ability, to load balancing (if someone has a slow, but low latency DSL connection, the packets for games go through that, while the video streaming and such will go through the high bandwidth, high latency 4g connection).
Of course, I wonder how well this will perform if not on a Clear/4G network. How well will it failover to 3G gracefully if I'm in the sticks and able to get a "generic" CDMA signal?
I've seen people do the same thing but with hostnames. And because the in-house apps had the names hard-coded, it was well nigh impossible to change them. At least adding proper names in DNS helped mitigate that a bit once I convinced the PHBs that naming the DNS servers "dns1" and "dns2" instead of zwerty and azerty (not using the real hostnames) were not going to have any impact to the security of the institution.
Eek.... 3.2.5.x? That should have been killed off with a flaming chainsaw a decade ago. Heck, even an old 220 with the abacus in the back would run 4.x without issue, much less a vintage H50 still in the rack.
Here is what I'd do (assuming a perfect world):
In the hardware department, I'd see if the old AIX machines can't be upgraded (I've seen some embedded applications that depended on a hardware/OS stack which could not be upgraded without a complete retool of a lot of physical robotic hardware, so even though they were running an ancient version of an OS, it stayed.) If they can be upgraded, I'd just yank the H50s out, drop in some modern iron, and carve out LPARs. I'm sure that even a small chunk from a modern POWER6/POWER7 box would do the job.
In the process department, I'd drill into people's heads that doing a job is half the battle. The second half is documenting what was done. This can be leaving proper comments in code if in a development house, or a decent changelog if in IT.
There is one thing I have encountered though which may be a hard political battle, regardless of if you are in the public sector, academia, or the private sector: Programmers who deliberate obfuscate code and go as far as to leave misleading comments in order for them to have job security. This used to work in the past, but these days, PHBs will just ask the friendly offshoring firm to either fix that for a relative pittance, or just have the module recoded, new bugs and all. I have seen some companies pay for a total rewrite of core code just so they can be free of someone who does this.
There is one thing forgotten. For the most part, US government "GS" jobs have job security. Unless someone commits a felony on the job, they know that their badge and CAC will work the next day. Private industry has higher salaries, but there is always the chance of being pitched out like last night's garbage if a PHB decides to swallow outsourcing/offshoring Kool-Aide.
And people know this. Government jobs have a lot more competition going for them than private jobs in a lot of places, from what I've seen.
Don't forget benefits. A $60k/year job may not be as alluring when one realizes that they have to spend $15k a year after taxes for health insurance for them and their family.
I'm cynical. If energy producing items such as fossil fuels started running out, resources are what a lot of wars end up being fought over. You wouldn't find a culture becoming energy sustaining if energy producing resources ran out. Instead you would find a culture teetering on the edge of survival at best due to so many wars. Even if there were usable resources, before a country would be overrun, they would be destroyed. A good example of this is how Saddam set fire to every oil well in Kuwait before he was pushed out.
Numerous examples of this exist. One of the reasons that the Mayans went into decline is because they required such high temperatures for their cement that they ran out of trees, which caused drought conditions similar to the Dust Bowl.
When resources get scarce, countries go to war. If push came to shove, I'm sure even nuclear powers would rather see an enemy have all oil wells destroyed and all mineral mines nuked, the classic, "if I can't have it, nobody can".
For a car analogy, NoSQL reminds me of people who take a reciprocating saw to a car, removing all airbags and safety systems, all but one disk for brakes, cutting the roof, trunk, and doors off, then saying that their vehicle is far faster than anything else on the track, comparing their vehicle to factory stock models with all their safety systems intact.
There is a reason why SQL-based RDBMS servers are slower than NoSQL. And that is because they ensure that the data is consistent and not lost/corrupted if two things access an entry at the same time.
Eventual consistency is a nice concept. However, it assumes that a tablespace will quiesce sometime. And a lot of these databases are hit 24/7, so there is never a time that the entries (can't call them transactions) that are in flight actually are assured that they are written to disk. Of course, a failure or unexpected shutdown can happen anytime, and entries in flight that can't be considered completed, or be able to be rolled back are corrupt entries which require time to find and fix, assuming they can be detected.
If I value the integrity of data stored in a database, I'm going to use an RDBMS that is designed and built from the ground up on tried and true concepts (ACID mainly). Even if it means that it would cost more than a NoSQL solution.
That may not be a good wish. Once their products are completely locked down, the copyright war would turn into a patent war. F/OSS products will get pounded on with patent lawsuits, legit or trollish. Or they would bundle DRM into every document [1], so ACTA/DMCA provisions come into play if someone wants to make an application that can read/write/convert their files. Soon, the organizations would be hunting down individuals for patent infringement because they happen to run some utility and hitting them with multi-million dollar verdicts.
[1]: Even if the DRM something as simple as encrypting the document and storing the key semi-obfuscated in the file, it would tout as DRM bypassing and get the program to be ripped off download servers without ever seeing a court.
Cloud computing is just like dumb terminals, only on the application layer.
First, there were the dumb terminals which were connected via a serial port. Then the X stations were pushed, which are one "level" up because they had a network stack to communicate with a server. Then the JavaStations which have an OS, but updates and all applications were handled by a server. Cloud computing is just the next step up. The clients provide the network stack, OS, and Web browsing app.
What makes cloud computing so insane is that it was marketed to solve all problems. Impotency? Cloud computing can fix it. Hemorrhoids? A cloud computing provider provides faster relief than Preparation H. The bad thing is that a lot of companies put so much money on this, that cloud computing turned into a bubble and are fearing the burst.
If we blow the puffery, smoke, mirrors, and hype, cloud computing does provide some solutions:
1: Archiving. At the simplest, you can archive stuff by dumping the files to be archived in a directory, running PGP and using either passphrases or PGP keys. You can even store the private keys on smart cards so compromise of a computer won't mean possible compromise of what is stored on the cloud. You can also store TrueCrypt volumes that have a month's worth of contents and have the keyfiles stored somewhere safely, even on smart cards. More complex cloud based archive systems would require someone to make an encryption front end, either software of hardware.
2: Backups. Mozy and Carbonite are good second-line solutions, if people know the security implications [1]. I say last ditch because even though the backups are stored securely, restoring through an Internet is a lot slower than restoring from an external hard disk and Time Machine (for example.) If combined with a first line solution (external HDD, backup server on LAN), they should provide adequate protection. Encryption is a must.
3: Virtual machines. For non security sensitive tasks, these might be useful. For example, carving out a temporary VM as a download mirror or to load balance Web static/dynamic content. The problem is that there are not many VM tasks (other than load balancing downloads of files or Web pages) that one would do that wouldn't have confidential data present.
Cloud computing has too many security issues to be used blindly. In reality, if businesses need capacity, they are going to have to hit IBM, HP, or Cisco [2], and own their own iron.
[1]: Make sure if you specify a manual keyfile to make sure the file is stored somewhere securely. I personally would recommend at the minimum storing it encrypted on a USB flash drive in a safe place like a safe deposit box. Another place would be in a tiny TrueCrypt volume and stored as an E-mail attachment on Gmail.
[2]: Cisco sells decent rackable PCs. The UCS C-series may actually be a bargain if a shop has a high Cisco investment.
Lets say someone comes out with a 100% secure DRM. A theory could be that ACTA mandates a Fritz/Clipper like chip in every computer sold that locks software to machines, or the main OS of all computers is put under a hypervisor like the non-updated PS3s with the "Other OS" feature, with a remote kill switch that frys the machine if it thinks there there is any tampering.
What will happen? One of five things:
People would find substitutes. Developers will work on an open source solution en masse, and the software battle would shift from licensing and DRM to patent enforcement. Here, bigger companies might get behind a product so it isn't this easy one-way battle companies have with no opposition that they do with copyrights. For example, GIMP would get donations and developers. Patent enforcement is harder to enforce than copyrights, and the whack-a-mole war would begin with a program that gets slightly modified and renamed. A utility that is a clone of a commercial product may get sued out of oblivion, but if it were open source, each fork of it would have to be sued, and all it would take would be one single developer to perform a fork and call it a different name. And even though copyright infringement may be sued for millions of dollars, there are no cases of a patent violation for noncommercial use being sued into oblivion. So we would see programs spring up that are functionally identical to the commercial applications.
People will do without. If music programs got so expensive that average musicians couldn't afford them, people would go back to hardware mixers and discrete devices. People would write apps for Android and the iPad so the device can do basic music functions (loops, sampling, etc.)
The company turns into a niche vendor. The commercial product might still sell for unpurchasable prices, but only a few people in a narrow market would buy it. Yes, this would be lucrative for some businesses (AutoDesk is a good example), but there are other products which cannot thrive just on a narrow market segment. Adobe for example. If Acrobat was both rendered unpiratable and too expensive, then businesses would move wholesale to Microsoft's XPS, and print shops either install XPS to PDF converters, or they would lose out to the shops that do.
Of course, the worst thing is that this would do is create a digital divide. People who know how to use the commercial programs and who don't. In IT, this used to be common when Solaris was commercial. You would get people with Linux experience, but without the experience of Solaris/AIX/IRIX/HP-UX directly, they were always on the bottom of the list compared to someone who managed to get in a high end rendering lab and learn the basics of these operating systems.
The extreme worst case is that the commercial products be considered as premium/luxury brands, and are bought for status. If someone has a copy of a full version of a commercial application, it is considered far more stylish than any competition.
History has already shown us examples of what happens when too much DRM happens. Competitors who don't do copy-protection start coming in and grabbing large pieces of the pie. Lotus 1-2-3 got bit by this. Novell also got hit by this when people could install Windows NT, set up their domains and filesharing without having to worry about the hair-pulling license keys that Netware 3.x and 4.x had. Need more users to share files in NT Server? Just increment the number, but make sure to have a filed receipt of the CALs used, so when the BSA comes for an audit, you can show that you are authorized to use the amount of licenses.
Of course the exception to this are games, but its because people are used to games being locked down. Console DRM is almost bulletproof (XBox 360s are moddable, but get kicked off XBL left and right, PS3s are effectively uncrackable (yes, they got cracked for a little bit of time but Sony didn't just patch the crack out, but also locked
I'm pretty sure most/. readers could design a decent database architecture for this.
You have the main database replicated to several geographic regions, with a few replicas made to be synced, cut off, backed up offline, and resynced for sake of disaster recovery. Another replica runs a real time backup program and those backups get saved to other locations. The key is making sure the database is consistent for a long period of time.
You then replicate the tablespaces which concern each airline (Delta in general doesn't need to see the tables of Continental's ticket holders. I'm sure there are exceptions such as people transferring though.) By this, each airline has a subset of queries they need to make. This gives a performance boost, as they only need to query tables that concern them.
At most places, one would use a view with SHA-256 hashes instead of the names, passport IDs, and identifying information. This lessens the chance of a nosy person from trying to just do a quick SELECT * FROM TERRORIST_LASTNAMES to see if anyone they know is on it. Instead, they could grab a list of hashes and try running a guessing program, but that takes a lot more work (and can get them caught faster) than just a simple SELECT statement being executed.
I'd definitely go big-ass (DB/2, Oracle, or even MS SQL Server). A normal-ass database might not have the following features:
1: Real time backups (since this database is critical, a backup system should be catching all writes and socking them away, perhaps to a D2D2T configuration.) You don't want to lose even 5-10 minutes worth of new information, so you either backup all writes, or you make sure the archive log files are well kept. Since this is a 24/7/365 database, there is no time to quiesce the tables for a solid offline backup.
2: Distributed replication. There are a lot of read queries on this thing, and not as many writes relatively, so there should be at least mirrors distributed geographically because the airlines have to check every person boarding the plane.
3: Performance and reliability. Just due to the sheer number of queries (essentially one per person per time he or she hops on a plane, goes past security, or gets a ticket), a big-ass database for scalability is almost required. If the database can't handle the queries, airlines and airports grind to a halt, and since their money is in getting people across the skies at the appointed times, they start hemorrhaging losses if this database is down.
4: Expertise. If a glitch happens, you want the product to be well known so you can get top talent and top talent fast.
Of all the items listed above, just because this database is so crucial to an industry, I'd stick with big-ass and avoid medium-ass, even though the size of the DB is probably not that big. The reason for this is that the name list entries may not take that much room on the SAN, but because you can't cache the lookups (if you cache for 2-24 hours, you might miss someone added to the list 5 min ago), so have to do a full query every time for every person at the gate, going through the metal scanner, getting a boarding pass, or buying a ticket.
Slashdot Mirror
The age old slogan of "never underestimate the bandwidth of a van full of backup tapes" holds true today. However, "just" a MicroSD memory card of 32 gigs can hold a LOT of useful information. Said card can be easily put in a dead drop, just like the old fashioned spying using microfilm.
My worry is that businesses will spend their time protecting (or trying to) protect against remote threats that they won't keep an eye out for the obvious.
This is how Windows Mobile 6 and newer protect the contents on the memory card. It creates a key (and I forgot what exact file it uses under \Windows), and when writing to files on the SD card, uses that key with AES-128. When reading files, it checks the file against the list of keys stored to see if it can decrypt it. If it can, it will transparently decrypt it.
Hard reset the WM device either by a remote wipe, too many wrong PINs, or physically, and that keyfile is wiped and recreated with a new random key.
Blackberries go one step further and offer to ask for a passphrase, use device encryption, or both.
iPhone encryption is present, but articles have been around stating that it needs some work.
Android's weakness is that it has -no- encryption mechanism. And this is ironic because this would be trivial to set up under Linux. Device-based encryption can use LUKS, file based could use a variant of EncFS. Android by itself doesn't have any facility for remote wiping, but there are a number of third party apps (WaveSecure), as well as phone maker software (MotoBlur) which allow for remote wipe capability.
Ideally, phones should have security on par with a Blackberry. They should support:
Remote wipe (obviously).
Wipe if SIM card is changed, card is not on an authorized list.
Wipe if the phone has not been on the network in X amount of time.
Wipe if the phone has had too many bad passwords entered.
File encryption, as well as encryption by device, so the memory card would be completely unreadable to an attacker who couldn't even guess file sizes or names.
Backups, with some form of encryption, be it a passphrase or other ways.
Secure storage of private keys (client Web certificates, PGP/gpg keys) where not just any app can read the private key material, but have to go through an API which prompts the user, and optionally asks for a PIN.
One app I use to mitigate this is Droidwall. It is an app for rooted phones which uses ipchains to allow or deny apps access to the network. Even if an app demands Internet access, it won't be able to send packets in or out unless Droidwall is configured to allow it.
Of course, if an app is installed and nobody checks permissions, it can send/receive using SMS or MMS, but that is a different story altogether.
This is the same battle as DRM fights. Who has control of the host can dump memory images of the VMs at will.
Not like this can't be done, where the VMs are protected from the host. Look how well the PS3 has kept its security without a solid breach, and when it was breached, it was fixed by a ROM update in record time.
I will give a concrete example of this: Motorola's CLIQ. It has fastboot disabled, and its initial root was done by a RAMDLD exploit. About a month later, it had an OTA radio ROM update. What happened is, if you had a custom ROM on your Cliq and that update went through, you would end up with an inoperable device until you flashed a factory stock .SHX file onto your phone. Of course, guess what? The RAMDLD exploit was fixed, and the phone was made unrootable. Source: modmymoto.com's CLIQ forums.
Unrootable, until an European carrier had their version of the CLIQ ROM which happened to ship with ro.secure set to 0. This meant you could flash a custom recovery module via adb, then reflash a custom ROM as part of the root process.
Even HTC has had reports of this (IIRC). Some of their models, if you go to xda-developers, the ROM makers have noticed that some of the filesystems cannot be remounted read-write, even with root.
The Milestone from Motorola also appears unflashable with a custom ROM: http://androidforums.com/motorola-milestone/44177-motorola-locks-milestone.html
This is what we don't want. We don't want supposedly open devices which in reality are locked down in subtle ways. This is why that my next phone is going to be a phone that doesn't use hidden signatures, disabled fastboot ROM, or other items to prevent rooting or modding with custom ROMS.
The problem is that "something different" may not be good.
Obligatory car analogy: It would be like trading in your 10 year old car for a new one that looks cool and is comfortable, but is completely autopiloted, and only lets you out at certain stops. Businesses have to apply to the car maker so the car would stop at their brick and mortar store. And without warning, this can be taken away, so if someone used to stop at a Target, they wouldn't have that option tomorrow and only get Wal-Marts. Continuing the analogy, someone patches the ECM with a steering wheel to allow manual control, but the next year's cars always come with protection against that.
People trading their computers in for what are effectively game consoles means that they are trading their freedom to run what they want, when they want for an environment locked down and managed by someone else who can do anything they please.
My question is: Do we want to go this route of sacrificing openness for ease of use? Yes, viruses and Trojans are a nuisance, but do we want to trade our relatively open computers for what would essentially be terminals, locked to some for-profit corporation's motives and future? For me, it is a no-brainer. I will keep my computer, and my phone will be on an open platform. If Android phones become unrootable or impossible to put custom ROMs on, I'll move to the Nokia N900 and encourage others to follow.
Do we want all our computers to be like PS3s where at any time, functionality can disappear at a moment's notice like the "other OS", and there would not be a single thing we can do about it? I'm sure the usual antagonists of open computing would love a wholesale move to a locked down platform, but is that where we want to take computing as we know it? Do we want to move to a computing model where what we buy, we are only permitted access to whatever the company allows on a whim? Yes, PS3s have no virus or spyware problems, but we are trading freedom for security here, and in the end, we will end up with neither.
Just some will. T-Mobile is arguably the best about this, because people either have bought their phone outright, or have to pay an ETF.
Other providers might not let you unlock your phones. I do not know if Sprint or Verizon will allow someone to do this, nor do I know if either provider would let someone have a unit on their CDMA network without their branding. They might with their "world" phones (the ones that have both CDMA and a GSM radio.)
Another advantage of one standard for phones: No need to have so many radio bands allocated. GSM has one band. AT&T'3 3G has another, T-Mobile's has another, CDMA has theirs. WiMax has one, same with LTE, and iDen. Having one standard means that a lot of the bands can be freed up for other uses.
You also have the ability for companies to share towers. This is what T-Mobile and AT&T did, pre-3G. This way, each phone company didn't have to have their own tower in each space for coverage, but could just lease from another provider.
There is one thing the Nexus One has that very few phones don't -- rootability. Want to root a Nexus One:
Fire up adb, fastboot the phone, enter in "fastboot oem unlock", then flash whatever image you want.
Other phones have a lot of roadblocks to custom ROMs, or even rooting it. For example, read-only partitions under Linux that stay read-only even when rooted. Or having fastboot disabled and everything else signed so trying to get root access is a job in itself.
My first choice with a phone is rootability. And I'm hoping if there is a Nexus Two, it will be as easily rootable as the N1. I'm also hoping Google has an ADP3 that has a modern (1GHz or so) CPU, preferably with a slider keyboard.
Two years max? I was content with my Windows Mobile phone (a HTC Wizard) for its lifetime of over four years. It wasn't handled with kid gloves either (although it wasn't spilled on, dropped, or roughly handled.)
There is a good reason to spend that much on a phone these days. For me, a phone can do a good amount of functions a laptop can. It also serves as a functional equivalent [1] of: a MP3 player, a PDA, a GPS receiver, a SecurID keyfob, and even random stuff, such as a compass, an XM radio player, a VT100 terminal, a SSH client, a so-so camera, a video camera, a Game Boy, and a wireless router with tethering. Having all these discrete devices would easily amount to this cost. For what a decent smartphone does these days, it is a comparative bargain compared to just what a PDA sold for just 3-4 years ago, where an iPaq sold for $600 or higher.
So, for a device that lasts 4 years that offers a lot of functionality, and the fact that it is something I use daily, so the ratio for money spent for time used is very good.
[1]: Well, not really a 100% functional equivalent. I'd say 50%-90% of the features, but better than nothing. For example, Android's MP3 player is pretty Spartan when it comes to features, but it does the job. Or the GPS directions require an app with a monthly subscription.
Both automatic transmissions and manual transmissions (well, mainstream ones. I'm not meaning the Justy's ECVT or others), both use friction surfaces that eventually wear out. Manual transmissions have clutch plates. Automatic transmissions use brake bands actuated by fluid pressures and planetary gear systems.
Brake bands wear out eventually, thus causing slipping, and eventually will need to be replaced (thus a rebuild.)
I don't know the details, but I've seen the NuVinci end up on cruiser bikes. I never see it specced for much else outside of that type.
The Rohloff is a masterwork of engineering, IMHO. I wish it would show up on more mountain bikes, because it completely gets rid of a ton of issues. It is expensive, but XT and XTR components are about the same price. And weight-wise, it is competitive to standard derailleur systems for mountain bikes. The biggest advantage this gives is the reliability. The chain maintains the same path and doesn't get twisted (side loads are what help contribute to wearing bike chains out), there is no low hanging derailleur to get smacked by rocks, and you can change gears while stopped. Only real hub maintaining is doing oil changes.
Actually, any professional grade UPS is set up this way. Online systems have the data center power always coming off the batteries 24/7. Only if there is a complete battery failure does power get switched to the utility company. This is opposed to standby UPSes that have power going from the utility, and try to switch over to battery. This also provides very clean power, so brownouts or spikes do not affect the equipment.
Any serious data center has an online UPS like this where someone can flip off the utility power, and the DC will not skip a beat until the batteries croak. However, by then, the diesel generator should be on and working.
I wonder how "3.5G" networks such as T-Mobile's HSPA+ will compare to this. T-Mobile is supposed to have this rolled out at the end of this year, and because it isn't as big a hardware change, towers can be converted faster as compared to a completely new wireless technology.
I've heard people in Philadelphia say that T-Mobile has the edge compared to Clear WiMax, but it has been stated that T-Mobile has a 5 GB limit per month, so that makes it useless for a primary Internet connection.
When will someone get the Evo rooted and able to have custom ROMs. This is my biggest decision maker on what phone I select. If the phone has hidden obstacles (partitions that can't be mounted rw even with root, fastboot issues, etc.), or have other gotchas (such as the radio ROM upgrade on the Cliq), then I'll pass, even if it has a fast Internet connection.
I can think of a lot of very useful things that could be useful with a device offering a fast connection and with a custom ROM. A quick and dirty failover connection on a LAN, to plugging into a server and running some firewall/VPN software on the Android level for a fast remote access ability, to load balancing (if someone has a slow, but low latency DSL connection, the packets for games go through that, while the video streaming and such will go through the high bandwidth, high latency 4g connection).
Of course, I wonder how well this will perform if not on a Clear/4G network. How well will it failover to 3G gracefully if I'm in the sticks and able to get a "generic" CDMA signal?
I've seen people do the same thing but with hostnames. And because the in-house apps had the names hard-coded, it was well nigh impossible to change them. At least adding proper names in DNS helped mitigate that a bit once I convinced the PHBs that naming the DNS servers "dns1" and "dns2" instead of zwerty and azerty (not using the real hostnames) were not going to have any impact to the security of the institution.
Eek.... 3.2.5.x? That should have been killed off with a flaming chainsaw a decade ago. Heck, even an old 220 with the abacus in the back would run 4.x without issue, much less a vintage H50 still in the rack.
Here is what I'd do (assuming a perfect world):
In the hardware department, I'd see if the old AIX machines can't be upgraded (I've seen some embedded applications that depended on a hardware/OS stack which could not be upgraded without a complete retool of a lot of physical robotic hardware, so even though they were running an ancient version of an OS, it stayed.) If they can be upgraded, I'd just yank the H50s out, drop in some modern iron, and carve out LPARs. I'm sure that even a small chunk from a modern POWER6/POWER7 box would do the job.
In the process department, I'd drill into people's heads that doing a job is half the battle. The second half is documenting what was done. This can be leaving proper comments in code if in a development house, or a decent changelog if in IT.
There is one thing I have encountered though which may be a hard political battle, regardless of if you are in the public sector, academia, or the private sector: Programmers who deliberate obfuscate code and go as far as to leave misleading comments in order for them to have job security. This used to work in the past, but these days, PHBs will just ask the friendly offshoring firm to either fix that for a relative pittance, or just have the module recoded, new bugs and all. I have seen some companies pay for a total rewrite of core code just so they can be free of someone who does this.
There is one thing forgotten. For the most part, US government "GS" jobs have job security. Unless someone commits a felony on the job, they know that their badge and CAC will work the next day. Private industry has higher salaries, but there is always the chance of being pitched out like last night's garbage if a PHB decides to swallow outsourcing/offshoring Kool-Aide.
And people know this. Government jobs have a lot more competition going for them than private jobs in a lot of places, from what I've seen.
Don't forget benefits. A $60k/year job may not be as alluring when one realizes that they have to spend $15k a year after taxes for health insurance for them and their family.
I'm cynical. If energy producing items such as fossil fuels started running out, resources are what a lot of wars end up being fought over. You wouldn't find a culture becoming energy sustaining if energy producing resources ran out. Instead you would find a culture teetering on the edge of survival at best due to so many wars. Even if there were usable resources, before a country would be overrun, they would be destroyed. A good example of this is how Saddam set fire to every oil well in Kuwait before he was pushed out.
Numerous examples of this exist. One of the reasons that the Mayans went into decline is because they required such high temperatures for their cement that they ran out of trees, which caused drought conditions similar to the Dust Bowl.
When resources get scarce, countries go to war. If push came to shove, I'm sure even nuclear powers would rather see an enemy have all oil wells destroyed and all mineral mines nuked, the classic, "if I can't have it, nobody can".
For a car analogy, NoSQL reminds me of people who take a reciprocating saw to a car, removing all airbags and safety systems, all but one disk for brakes, cutting the roof, trunk, and doors off, then saying that their vehicle is far faster than anything else on the track, comparing their vehicle to factory stock models with all their safety systems intact.
There is a reason why SQL-based RDBMS servers are slower than NoSQL. And that is because they ensure that the data is consistent and not lost/corrupted if two things access an entry at the same time.
Eventual consistency is a nice concept. However, it assumes that a tablespace will quiesce sometime. And a lot of these databases are hit 24/7, so there is never a time that the entries (can't call them transactions) that are in flight actually are assured that they are written to disk. Of course, a failure or unexpected shutdown can happen anytime, and entries in flight that can't be considered completed, or be able to be rolled back are corrupt entries which require time to find and fix, assuming they can be detected.
If I value the integrity of data stored in a database, I'm going to use an RDBMS that is designed and built from the ground up on tried and true concepts (ACID mainly). Even if it means that it would cost more than a NoSQL solution.
That may not be a good wish. Once their products are completely locked down, the copyright war would turn into a patent war. F/OSS products will get pounded on with patent lawsuits, legit or trollish. Or they would bundle DRM into every document [1], so ACTA/DMCA provisions come into play if someone wants to make an application that can read/write/convert their files. Soon, the organizations would be hunting down individuals for patent infringement because they happen to run some utility and hitting them with multi-million dollar verdicts.
[1]: Even if the DRM something as simple as encrypting the document and storing the key semi-obfuscated in the file, it would tout as DRM bypassing and get the program to be ripped off download servers without ever seeing a court.
Cloud computing is just like dumb terminals, only on the application layer.
First, there were the dumb terminals which were connected via a serial port.
Then the X stations were pushed, which are one "level" up because they had a network stack to communicate with a server.
Then the JavaStations which have an OS, but updates and all applications were handled by a server.
Cloud computing is just the next step up. The clients provide the network stack, OS, and Web browsing app.
What makes cloud computing so insane is that it was marketed to solve all problems. Impotency? Cloud computing can fix it. Hemorrhoids? A cloud computing provider provides faster relief than Preparation H. The bad thing is that a lot of companies put so much money on this, that cloud computing turned into a bubble and are fearing the burst.
If we blow the puffery, smoke, mirrors, and hype, cloud computing does provide some solutions:
1: Archiving. At the simplest, you can archive stuff by dumping the files to be archived in a directory, running PGP and using either passphrases or PGP keys. You can even store the private keys on smart cards so compromise of a computer won't mean possible compromise of what is stored on the cloud. You can also store TrueCrypt volumes that have a month's worth of contents and have the keyfiles stored somewhere safely, even on smart cards. More complex cloud based archive systems would require someone to make an encryption front end, either software of hardware.
2: Backups. Mozy and Carbonite are good second-line solutions, if people know the security implications [1]. I say last ditch because even though the backups are stored securely, restoring through an Internet is a lot slower than restoring from an external hard disk and Time Machine (for example.) If combined with a first line solution (external HDD, backup server on LAN), they should provide adequate protection. Encryption is a must.
3: Virtual machines. For non security sensitive tasks, these might be useful. For example, carving out a temporary VM as a download mirror or to load balance Web static/dynamic content. The problem is that there are not many VM tasks (other than load balancing downloads of files or Web pages) that one would do that wouldn't have confidential data present.
Cloud computing has too many security issues to be used blindly. In reality, if businesses need capacity, they are going to have to hit IBM, HP, or Cisco [2], and own their own iron.
[1]: Make sure if you specify a manual keyfile to make sure the file is stored somewhere securely. I personally would recommend at the minimum storing it encrypted on a USB flash drive in a safe place like a safe deposit box. Another place would be in a tiny TrueCrypt volume and stored as an E-mail attachment on Gmail.
[2]: Cisco sells decent rackable PCs. The UCS C-series may actually be a bargain if a shop has a high Cisco investment.
I am going to be a devil's advocate here:
Lets say someone comes out with a 100% secure DRM. A theory could be that ACTA mandates a Fritz/Clipper like chip in every computer sold that locks software to machines, or the main OS of all computers is put under a hypervisor like the non-updated PS3s with the "Other OS" feature, with a remote kill switch that frys the machine if it thinks there there is any tampering.
What will happen? One of five things:
People would find substitutes. Developers will work on an open source solution en masse, and the software battle would shift from licensing and DRM to patent enforcement. Here, bigger companies might get behind a product so it isn't this easy one-way battle companies have with no opposition that they do with copyrights. For example, GIMP would get donations and developers. Patent enforcement is harder to enforce than copyrights, and the whack-a-mole war would begin with a program that gets slightly modified and renamed. A utility that is a clone of a commercial product may get sued out of oblivion, but if it were open source, each fork of it would have to be sued, and all it would take would be one single developer to perform a fork and call it a different name. And even though copyright infringement may be sued for millions of dollars, there are no cases of a patent violation for noncommercial use being sued into oblivion. So we would see programs spring up that are functionally identical to the commercial applications.
People will do without. If music programs got so expensive that average musicians couldn't afford them, people would go back to hardware mixers and discrete devices. People would write apps for Android and the iPad so the device can do basic music functions (loops, sampling, etc.)
The company turns into a niche vendor. The commercial product might still sell for unpurchasable prices, but only a few people in a narrow market would buy it. Yes, this would be lucrative for some businesses (AutoDesk is a good example), but there are other products which cannot thrive just on a narrow market segment. Adobe for example. If Acrobat was both rendered unpiratable and too expensive, then businesses would move wholesale to Microsoft's XPS, and print shops either install XPS to PDF converters, or they would lose out to the shops that do.
Of course, the worst thing is that this would do is create a digital divide. People who know how to use the commercial programs and who don't. In IT, this used to be common when Solaris was commercial. You would get people with Linux experience, but without the experience of Solaris/AIX/IRIX/HP-UX directly, they were always on the bottom of the list compared to someone who managed to get in a high end rendering lab and learn the basics of these operating systems.
The extreme worst case is that the commercial products be considered as premium/luxury brands, and are bought for status. If someone has a copy of a full version of a commercial application, it is considered far more stylish than any competition.
History has already shown us examples of what happens when too much DRM happens. Competitors who don't do copy-protection start coming in and grabbing large pieces of the pie. Lotus 1-2-3 got bit by this. Novell also got hit by this when people could install Windows NT, set up their domains and filesharing without having to worry about the hair-pulling license keys that Netware 3.x and 4.x had. Need more users to share files in NT Server? Just increment the number, but make sure to have a filed receipt of the CALs used, so when the BSA comes for an audit, you can show that you are authorized to use the amount of licenses.
Of course the exception to this are games, but its because people are used to games being locked down. Console DRM is almost bulletproof (XBox 360s are moddable, but get kicked off XBL left and right, PS3s are effectively uncrackable (yes, they got cracked for a little bit of time but Sony didn't just patch the crack out, but also locked
I'm pretty sure most /. readers could design a decent database architecture for this.
You have the main database replicated to several geographic regions, with a few replicas made to be synced, cut off, backed up offline, and resynced for sake of disaster recovery. Another replica runs a real time backup program and those backups get saved to other locations. The key is making sure the database is consistent for a long period of time.
You then replicate the tablespaces which concern each airline (Delta in general doesn't need to see the tables of Continental's ticket holders. I'm sure there are exceptions such as people transferring though.) By this, each airline has a subset of queries they need to make. This gives a performance boost, as they only need to query tables that concern them.
At most places, one would use a view with SHA-256 hashes instead of the names, passport IDs, and identifying information. This lessens the chance of a nosy person from trying to just do a quick SELECT * FROM TERRORIST_LASTNAMES to see if anyone they know is on it. Instead, they could grab a list of hashes and try running a guessing program, but that takes a lot more work (and can get them caught faster) than just a simple SELECT statement being executed.
I'd definitely go big-ass (DB/2, Oracle, or even MS SQL Server). A normal-ass database might not have the following features:
1: Real time backups (since this database is critical, a backup system should be catching all writes and socking them away, perhaps to a D2D2T configuration.) You don't want to lose even 5-10 minutes worth of new information, so you either backup all writes, or you make sure the archive log files are well kept. Since this is a 24/7/365 database, there is no time to quiesce the tables for a solid offline backup.
2: Distributed replication. There are a lot of read queries on this thing, and not as many writes relatively, so there should be at least mirrors distributed geographically because the airlines have to check every person boarding the plane.
3: Performance and reliability. Just due to the sheer number of queries (essentially one per person per time he or she hops on a plane, goes past security, or gets a ticket), a big-ass database for scalability is almost required. If the database can't handle the queries, airlines and airports grind to a halt, and since their money is in getting people across the skies at the appointed times, they start hemorrhaging losses if this database is down.
4: Expertise. If a glitch happens, you want the product to be well known so you can get top talent and top talent fast.
Of all the items listed above, just because this database is so crucial to an industry, I'd stick with big-ass and avoid medium-ass, even though the size of the DB is probably not that big. The reason for this is that the name list entries may not take that much room on the SAN, but because you can't cache the lookups (if you cache for 2-24 hours, you might miss someone added to the list 5 min ago), so have to do a full query every time for every person at the gate, going through the metal scanner, getting a boarding pass, or buying a ticket.