No joke: aside from the more advanced support for DirectX and the like, an old Fujitsu laptop I've got with an ATI Radeon chipset has better performance with Compiz than an MSI Wind PC with i9x0 graphics (Atom). The old Fujitsu clocks at 500MHz; it's a Celeron.
I don't think the problem is the Intel GMA 950. I have a MSI Wind and graphics performance was horrible with Compiz, yet fine with OS X or Vista.
1. OS X is certified Unix. I don't care if you disagree. You can disagree with gravity too if you want, but it will still keep your feet on the ground.
This is meaningless today. Most Unixlike systems today are not certified Unix systems. OS X has some significant differences from traditional Unixlike systems and Linux - not necessarily disadvantages:
OS X has a Mach-based microkernel (XNU) and a completely different driver model (I/O Kit)
OS X's VM (virtual memory) system performs poorly, and swapping cannot be safely disabled. If you do disable swap, the OS acts poorly when it thinks it's run out of memory - it grinds to a halt. Linux by default will kill the process using the most memory if it runs out - this is configurable. Also, since Linux's VM system is configurable enough that you can control just how much is swapped and how much is cached, you can set Linux so that swap is only touched when it is really needed.
OS X is huge - it's much larger than a minimal installation of a server Linux distribution. The GUI is not an optional component.
3. There is increased functionality above a "regular linux server". Take xgrid for instance. Many of the tasks it does it can do work only with mac software.
You can certainly add grid computing software to other operating systems. OS X is missing some functionality that a "regular linux server" may have. Even when considering third-party software, there are many things that can be done in Linux but not in OS X.
OS X is somewhat lacking clustering ir high availability fatures. For example, a "regular linux server" running CentOS has DRBD, for distributed block devices, and GFS, a cluster file system. It doesn't have application failover of the type provided by Windows's built-in clustering or by Linux-HA; OS X only has IP failover.
OS X has few server virtualization options - just Parallels. VMware ESX supports Windows, Linux, and Solaris. Commercial Xen distributions support Windows and Linux; paravirtualized versions of BSDs and OpenSolaris are available too. Solaris, FreeBSD, and addons to Linux provide effective kernel virtualization. Microsoft's Hyper-V runs Windows and can even run SUSE (and eventually RHEL.)
OS X has no built-in or even officially supported iSCSI initiator. There is one free closed-source initiator, but commerical support is not offered - making it not very suitable for server use. Microsoft has a supported iSCSI initiator that works with Windows 2000 and up, and it's included in 2008 and Vista. iSCSI initiation is supported by many Linux distributions, including Red Hat and Suse.
Mac updates are not all or nothing. What in the world do you even mean by that? They have point updates, but so does linux. This doesn't mean they don't have updates for individual OS components too. There was a security update just the other day that wasn't "all or nothing."
Mac OS X security updates certainly are "all or nothing" - you have to install all of the patches included in the package or install none of them. Each package includes many fixes, and sometimes they break things. The updates are not available as individual pkacages. You cannot select which updates are applied to the system.
RHEL/CentOS has point releases, but there are plenty of individual package updates in between (to fix bugs, compatibility, and security issues.) Individual package updates are released when they are ready, not as part of a large security update bundle or a monthly schedule.
I pay for a phone so I can talk with family and friends, all of which understand that they may not call me without their number displaying on the caller ID. Is your "right" to contact me against my wishes more important than MY RIGHT to have a phone, especially when considering that I PAY for that phone service?
I never said that anyone had the right to call you without properly providing caller ID information.
Subscribing to telephone service is not a right; it is a service you pay for. One of the features of most telephone services is that anyone who knows the number can call it and the line will ring.
You have the right to enter into a contract to recieve telephone service if you choose. You also have the right not to enter into such a contract if you do not like the terms. If you don't like your current telephone service, you're free to use another that meets your needs.
If you are going to call my house, you are making something happen inside my home, probably without my permission. If you are going to do that, I have a RIGHT to know who you are and where you are calling from.
Don't want me to know who you are? Fine, don't call me.
If you subscribe to a telephone service, you are paying for a service that is known to cause your phones to ring when your telephone number is dialed. You have the RIGHT to disable the ringer or not subscribe to the service.
Don't want to be interrupted? Disable your ringers or disconnect your phone line.
Remember, the EV1 got over 140 miles per charge on the NiMH batteries in the late 90s or very early 2001 period. GM is hardly getting 40 miles per charge of expensive lithium batteries today and nobody is using NiMH for mostly electric or all electric vehicles. It's not because the tech can't handle it. Ask any of the few Rav 4 EV owners out there.
By volume, the Volt has 1/3 as much battery as the EV1 (even less by weight). (source)
The EV1 was also designed to be as efficient as possible - it was a two-seater with the lowest drag coefficient of any production vehicle. I can't find any definitive sources, but it seems that the Volt is about 500 lbs heavier as well.
What Google has just done is to license PPP from Microsoft. Nice job.
Don't believe me? Read this. [handhelds.org]
All the "Activesync Protocol" is, is good old PPP.
No. Google licensed Exchange ActiveSync, a protocol runs on top of http(s) to provide calendar and contacts synchronization and push email for mobile devices. It only requires an internet connection - unlike BlackBerry, which requires special network support.
On the client side, Exchange ActiveSync is implemented by the iPhone (since firmware 2.0), Windows Mobile devices, and some Sony Ericsson and Nokia devices. Microsoft Exchange is the most popular server, but other closed- (Zimbra) and open-source (Z-Push) implementations exist.
Is the encryption even going to work? Where I work we found out that the whole-disk encryption works fine when people shut their computers off and then boot them back up. But when you just suspend/hibernate a laptop it resumes exactly where it was, with the encryption software decrypting the disk exactly as normal, without prompting for any passphrase.
What software did you use? Every whole-disk encryption application I've used requires authentication to resume from hibernation; if the key is stored in the hibernation image, it's encrypted along with everything else. There isn't very much they can do for standby, however. (Remember that in standby mode, the CPU shuts off while RAM continues to be powered.) Control passes directly back to the OS, so there's no opportunity for encryption software to prompt for authentication.
When the system is in standby or powered on, security depends on how much you can trust the operating system's lock screen...do you enforce the option to require a password after resuming from standby/hibernate/screen saver?
We also found that the encryption made disk recovery impossible. One of our developers had his laptop fail. Motherboard problem, the disk was completely fine but the laptop itself had to be replaced. We didn't have any of that model of laptop (not made anymore), we couldn't use that drive as the boot disk for the new laptop and it wasn't possible to enter the boot-time password for it using an external USB disk adapter. So, complete loss of all data on the disk, even though the disk was completely intact and functional, because there wasn't any way for the authorized user to decrypt it to get the data back off.
Every whole-disk encryption application I've used has at least one recovery method. Sometimes, the disk can be attached directly to another system with the software installed, and the user's pre-boot credentials provided. Sometimes, there is a recovery disk that will decrypt the drive. Some systems also have a mechanism to print or save a recovery key before starting the encryption process.
If you didn't actually test how the product's recovery features worked before deploying it, it's no surprise that you ran into problems.
And many of the problems can be avoided completely. For instance, I use RDP to get into my office desktop from home or a laptop using a VPN and an RDP client (built into Windows XP, or rdesktop on Linux).
Unless you've disabled (or encrypted) swap space and disabled any file-backed cache your RDP client might use, there is still the (remote) possibility that information could be sitting unencrypted on the hard drive.
Complete remote access isn't an option for many. It's not a pleasant option for those who might be using high-latency cellular connections or are far away from the host. It's also not an option for those who do not have access to the network at the times they need to do work.
I agree that there could be a "Developer" variant of a distro that would offer you install-time options for various databases, web servers, IDEs, and so on, on top of the basic "Desktop" variant's offerings.
I would also like to not install some of the stuff that Ubuntu installs by default. Evolution comes to mind - why not let me pick which email client I want to use. There's also all the games, which I never play.
Before the current live-CD trend, distributions asked what package sets the user wanted to install. This is still the case for CentOS/RHEL when installed from a full DVD or over the network. A default "desktop" install would include either KDE or Gnome, a mail client, a web browser, etc. There were options for "development", "web server", etc. Now, live CD based distributions just copy whatever's on the live CD.
If you don't like what Ubuntu installs by default, use an installation method that doesn't simply copy the contents of the live CD. Ubuntu's text installer might do this.
Yes; any modern x86 OS should run on Xen in HVM mode, provided Xen emulates compatible hardware.
Windows I/O performance seems weak when compared to Linux guests, even when using the open-source paravirtualized drivers. With paravirtualized drivers, I get no more than ~30 MB/sec over the network to a Windows guest (CentOS 5.2 x86_64 host). Linux guest I/O is usually limited by hardware - ~70 MB/sec from a single SATA drive is no problem.
With Microsoft's Hyper-V (architecurally similar to Xen), Windows guests' I/O performance is also limited by hardware. Hyper-V supports Windows and SLES; they provide paravirtualized drivers for SLES 10 that happen to work in RHEL 5 as well. I ran a CentOS guest with the paravirtualized drivers and got decent I/O performance - at least 40 MB/sec. However, the host can't signal the CentOS guest to shut down and the guest locks up after resuming if I have the host suspend the VM then reboot.
Actually a multi terrabyte RAID 5 drive is a nice bit of the backup solution.
RAID 5 gets increasingly dangerous as drive size increases. Going strictly by published unrecoverable read error rates (1 per 10^14 bits read on recent Seagate desktop drives), the chance of data loss during a rebuild can be very high - 48%, assuming a five-drive array of 1.5 TB drives with this failure rate. Of course, these figures don't mean that 10^-14 of all bits read will result in a failure. It also doesn't mean that an error will manifest as a flipped bit - instead, one or more sectors will be unreadable (512 bytes each).
The risks of large capacity RAID5 arrays can be mitigated by using more reliable drives or a system that can handle more failures. WD's desktop drives have a failure rate of 1 in 10^15; enterprise drives from all manufacturers usually have a failure rate of 1 in 10^16. And RAID6 can sustain two failures of any drive. Using six 1.5 TB drives with a 10^-15 bit error rate and RAID6 has a failure rate during rebuild under 1%.
Well, based on my experiences, I would strongly suggest that you purchase some non-Western Digital hard drives for your backups. That is, unless you like being on a first name basis with their technical support agents.
I had a WD desktop drive show signs of failure a few months ago (SMART showed offline unreadable sectors.) I was able to get a replacement just by filling out a few forms on the web. Seagate's the same way, but they charge a nonrefundable fee for advance replacement (where they send you a replacement drive first.)
Not quite. The merchant agreement typically states that the merchant cannot use ID to validate the identity ONLY for card purchases. If they check ID for check purchases, too, they'd typically be free to do so. It's essentially "you cannot do anything that makes it more inconvenient to the customer to purchase via our card than via other methods".
Same applies for cash, too, which isn't quite the same as writing a check.
How many people would present identification for a cash purchase that wasn't age restricted?
Maybe if you update the kernel; not using it much, I can only extrapolate from my linux experience, where updates almost never require a boot cycle.
For the past few weeks, I've been ignoring a "Digital Camera Raw Compatibility Update" that requires a reboot. Past QuickTime updates have also required system reboots.
(Why are you making comments about stuff you don't have experience with?)
I've heard that argued (mainly by CDMA technology vendors). The biggest claim I've heard is that you can cram more calls into a smaller airspace than with GSM. I suppose the absence of that famous GSM speaker buzz is also a factor.
CDMA is clearly technologically superior; this is why the current TDMA-based GSM systems are being overlaid with UMTS/WCDMA networks. CDMA has less latency in data services, faster data rates (in the latest revisions), much cleaner handoffs, and no 20-mile distance limits. CDMA2000 1xRTT (which was deployed around the same time as GPRS and EDGE) isn't quite as fast as EDGE, but has about half the latency.
Modern UMTS/WCDMA have all the technical advantages with the user-friendly features of GSM.
Also, when you compare CDMA and GSM, you should really look at the baseline, not the recent bells and whistles. My first phone (2000) was CDMA, and my biggest disappointment was that there was no SMS. Texting has been big with GSM from day one. In many third world countries, the cell networks get more income from texting than they do from calls. I heard an interview with one Philippines politico who was disconcerted to find that his children could text faster than he could type!
The situation from 9 years ago doesn't matter. SMS was introduced by CDMA carriers around 2000-2001.
Are you saying that there's nothing particularly special about GSM versus CDMA devices? If so, why aren't there any inexpensive GSM/CDMA phones?
No. There's nothing special about US CDMA phones for different carriers and US GSM phones for different carriers. Verizon, Sprint, and ex-Alltel phones don't use special hardware exclusive to one carrier. Until the implementation of 3G, T-Mobile and AT&T phones didn't use special hardware either.
If I'm reading the Google article you linked correctly (possibly not) LTE will be implemented on top of GSM and CDMA, much as TCP/IP is currently implemented on top of diverse network layers. That doesn't remove the compatibility issue at the bottom of the stack.
The article clearly states that LTE is an air interface, not something to be implemented on top of GSM or CDMA. A signalling & authentication system would be implemented on top of LTE - something that might be implemented in sofwtare.
In fact, development of the next generation of CDMA2000, UMB, was discontinued in favor of LTE.
I'll say it again: T-mobile USA has an unlimited data plan (HSDPA/edge/gprs) for 24.99 a month. 9.00 a month more to get exchange access. I got it working in linux and blogged on it at http://adjix.com/if6u [adjix.com] It's really not that expensive compared to the other carriers.
They charge $9.00 extra for Exchange access? Or $9.00 extra for BlackBerry connectivity to Exchange?
Exchange ActiveSync support (with a compatible phone) only requires access to the Exchange server via http or https. Compatible devices include all recent Windows Mobile deivces, the iPhone, some Palm OS devices, and newer Nokia Series 60 devices. I think there are a few Sony Ericsson non-smartphones that support it as well.
It works with consumer PDA and non-PDA plans on AT&T.
Cell providers also routinely filter data traffic, because they want to charge extra for mobile Internet and fax plans. Verizon definitely does this, and T-mobile kills fax but not dialup users. How this is not a violation of the Sherman act is a mystery to me.
I have yet to see any internet filtering on AT&T (after four and a half years) - even on their consumer plans.
What do you mean by saying that Verizon and T-Mobile block dialup and fax use? CSD is an extra feature that actually requires modems to be installed somewhere. And it's slow.
The Centro was also CDMA-only at first. (The initial partner was Sprint, if I remember correctly.) This is the only way you can introduce a new smart phone that's intended for the U.S. market, where CDMA is far and away the leading technology. Unless you have money to burn (which Palm certainly does not!) you introduce the phone for one kind of network and start production on the next version later.
CDMA (as in cdmaOne and CDMA2000 with 1xRTT) is technologically superior than GSM/GPRS/EDGE. It took a long time for UMTS to catch up. The US's biggest GSM carrier didn't even start deploying it until the past 3 years, and as a result the CDMA carriers had a 2-4 year head start on 3G services. Unfortunately CDMA as implemented by US carriers is lacking user friendly features (namely SIMs). From what I understand, the signalling protocols on top of the air interface are much closer to the old U.S. analog AMPS system - of which Verizon had tons of until the FCC permitted carriers to shut off analog service last year.
CDMA's market share in the US isn't nearly as big as you suggest. There are at least 107 million customers using GSM/UMTS networks (AT&T and T-Mobile) and there are probably somewhere around 130-150 million customers using CDMA (I can't find any good numbers; Sprint Nextel has 50.1 million customers, but some of these are on the old Nextel network.)
There's no special network-specific implementation needed for devices on Verizon and Sprint's CDMA networks as of now. New mobile communication bands have been opened up (AWS and 700 MHz). I believe T-Mobile is the only nationwide carrier who has launched service in one of these new bands.
The exception is phones that are designed for one particular network and never have versions for other networks. I could be mistaken, but I think most phones actually are designed that way.
You are mistaken. Many phones are released on the different US CDMA carriers with different firmware. GSM (non-UMTS) phones are treated the same way.
Handset design differences are minimal when differences in frequencies do come up (among CDMA networks or among GSM/UMTS networks); usually a handset for a market will differ in the version of the chipset inside and perhaps the antennas. The software will be different as well.
This is a natural result of the fact that the U.S. chose not to standardize on a single cellular technology, unlike most of the rest of the planet, which uses GSM. (Some Slashdotters will remember attempt at CDMA imperialism just before the U.S. invaded Iraq.) This is a bone of contention in many corners.
GSM and UMTS is all that's used in most of Europe and has the majority of the entire world market. But CDMA has significant deployment in Asia, incuding China. Japan and Korea used/use networks in compatible with those elsewhere (some CDMA based), although both countries now have UMTS on the 2100 MHz band like Europe.
Qualcomm is the owner of many patents on WCDMA, which is used by UMTS. They also make many of the baseband chips going into WCDMA phones. So, in a way, everyone is now using American (W)CDMA technology.
Just about all the carriers will be moving over to the same technology when they start using LTE.
And of course Palm would save big bucks if they didn't have to create multiple versions of each new phone.
They don't have to. They could choose to exclude 2/3 of the US market, like Apple did. The iPhone 3G works in nearly every country, including China and South Korea.
There's no exFAT specification or documentation that I can find, but it's supposed to be close to FAT32 with design improvements.
I couldn't find any conclusive information on exFAT ACL support; however, ACLs for exFAT aren't implemented in Windows Vista. It might be for Windows CE use only, like the transaction feature, and could be implemented as one of the extensions that exFAT is supposed to make it easy to implement.
exFAT is a simple filesystem that will work with large files and volumes - in this case, intended for use on removable storage devices like USB/SD drives and in embedded devices like digital cameras and MP3 players.
Filesystems like ext2 are more complex than FAT32, with more features like permissions and ACLs. Things could easily get messy with permissions when moving volumes between systems.
ext4 (and any other journaling filesystems) are not optimal for flash devices because of the limited write cycles.
Ideally, there would be a simple filesystem suitable for large removable volumes and large files with an open specification. FAT32 and ext2 are probably the closest, but FAT32 is a bad choice on volumes above 32GB and ext2 is more complex.
Given that ZFS has been optimized for flash, why bother with FAT?
Because ZFS is a filesystem with lots of features that are useless in systems in which SD cards are normally used. ZFS's goals are completely different than those of exFAT.
Sorry, but open standards is the correct priority. The problem is that closed source software never supports open standards...at least not reliably. One version may, but then after the next patch update it won't, and you upgraded without noticing.
So even though open standards is the correct priority, they require open source software to be ensured.
Fallacious. Some closed source software vendors do not implement open standards (in full or in part), but this has nothing to do with that software being closed source. These vendors ignore open standards as a business decision.
Some open standards don't even have complete open source implementations. How many fully complete ISO 32000-1 implementations (more commonly known as PDF 1.7) are there? How many are open source?
I am writing this on a closed-source browser (Opera), which aims for standards compliance.
Slashdot Mirror
I don't think the problem is the Intel GMA 950. I have a MSI Wind and graphics performance was horrible with Compiz, yet fine with OS X or Vista.
This is meaningless today. Most Unixlike systems today are not certified Unix systems.
OS X has some significant differences from traditional Unixlike systems and Linux - not necessarily disadvantages:
You can certainly add grid computing software to other operating systems. OS X is missing some functionality that a "regular linux server" may have. Even when considering third-party software, there are many things that can be done in Linux but not in OS X.
Mac OS X security updates certainly are "all or nothing" - you have to install all of the patches included in the package or install none of them. Each package includes many fixes, and sometimes they break things. The updates are not available as individual pkacages. You cannot select which updates are applied to the system.
RHEL/CentOS has point releases, but there are plenty of individual package updates in between (to fix bugs, compatibility, and security issues.) Individual package updates are released when they are ready, not as part of a large security update bundle or a monthly schedule.
I never said that anyone had the right to call you without properly providing caller ID information.
Subscribing to telephone service is not a right; it is a service you pay for. One of the features of most telephone services is that anyone who knows the number can call it and the line will ring.
You have the right to enter into a contract to recieve telephone service if you choose. You also have the right not to enter into such a contract if you do not like the terms. If you don't like your current telephone service, you're free to use another that meets your needs.
If you subscribe to a telephone service, you are paying for a service that is known to cause your phones to ring when your telephone number is dialed. You have the RIGHT to disable the ringer or not subscribe to the service.
Don't want to be interrupted? Disable your ringers or disconnect your phone line.
By volume, the Volt has 1/3 as much battery as the EV1 (even less by weight). (source)
The EV1 was also designed to be as efficient as possible - it was a two-seater with the lowest drag coefficient of any production vehicle. I can't find any definitive sources, but it seems that the Volt is about 500 lbs heavier as well.
Although the main Zimbra product is open-source, the connector for ActiveSync is not. It requires an additional license.
It syncs contacts and should eventually support true push email, unless Google decides for some odd reason not to implement it.
No. Google licensed Exchange ActiveSync, a protocol runs on top of http(s) to provide calendar and contacts synchronization and push email for mobile devices. It only requires an internet connection - unlike BlackBerry, which requires special network support.
On the client side, Exchange ActiveSync is implemented by the iPhone (since firmware 2.0), Windows Mobile devices, and some Sony Ericsson and Nokia devices. Microsoft Exchange is the most popular server, but other closed- (Zimbra) and open-source (Z-Push) implementations exist.
What software did you use? Every whole-disk encryption application I've used requires authentication to resume from hibernation; if the key is stored in the hibernation image, it's encrypted along with everything else. There isn't very much they can do for standby, however. (Remember that in standby mode, the CPU shuts off while RAM continues to be powered.) Control passes directly back to the OS, so there's no opportunity for encryption software to prompt for authentication.
When the system is in standby or powered on, security depends on how much you can trust the operating system's lock screen...do you enforce the option to require a password after resuming from standby/hibernate/screen saver?
Every whole-disk encryption application I've used has at least one recovery method. Sometimes, the disk can be attached directly to another system with the software installed, and the user's pre-boot credentials provided. Sometimes, there is a recovery disk that will decrypt the drive. Some systems also have a mechanism to print or save a recovery key before starting the encryption process.
If you didn't actually test how the product's recovery features worked before deploying it, it's no surprise that you ran into problems.
Unless you've disabled (or encrypted) swap space and disabled any file-backed cache your RDP client might use, there is still the (remote) possibility that information could be sitting unencrypted on the hard drive.
Complete remote access isn't an option for many. It's not a pleasant option for those who might be using high-latency cellular connections or are far away from the host. It's also not an option for those who do not have access to the network at the times they need to do work.
Before the current live-CD trend, distributions asked what package sets the user wanted to install. This is still the case for CentOS/RHEL when installed from a full DVD or over the network. A default "desktop" install would include either KDE or Gnome, a mail client, a web browser, etc. There were options for "development", "web server", etc. Now, live CD based distributions just copy whatever's on the live CD.
If you don't like what Ubuntu installs by default, use an installation method that doesn't simply copy the contents of the live CD. Ubuntu's text installer might do this.
Yes; any modern x86 OS should run on Xen in HVM mode, provided Xen emulates compatible hardware.
Windows I/O performance seems weak when compared to Linux guests, even when using the open-source paravirtualized drivers. With paravirtualized drivers, I get no more than ~30 MB/sec over the network to a Windows guest (CentOS 5.2 x86_64 host). Linux guest I/O is usually limited by hardware - ~70 MB/sec from a single SATA drive is no problem.
With Microsoft's Hyper-V (architecurally similar to Xen), Windows guests' I/O performance is also limited by hardware. Hyper-V supports Windows and SLES; they provide paravirtualized drivers for SLES 10 that happen to work in RHEL 5 as well. I ran a CentOS guest with the paravirtualized drivers and got decent I/O performance - at least 40 MB/sec. However, the host can't signal the CentOS guest to shut down and the guest locks up after resuming if I have the host suspend the VM then reboot.
RAID 5 gets increasingly dangerous as drive size increases. Going strictly by published unrecoverable read error rates (1 per 10^14 bits read on recent Seagate desktop drives), the chance of data loss during a rebuild can be very high - 48%, assuming a five-drive array of 1.5 TB drives with this failure rate.
Of course, these figures don't mean that 10^-14 of all bits read will result in a failure. It also doesn't mean that an error will manifest as a flipped bit - instead, one or more sectors will be unreadable (512 bytes each).
The risks of large capacity RAID5 arrays can be mitigated by using more reliable drives or a system that can handle more failures. WD's desktop drives have a failure rate of 1 in 10^15; enterprise drives from all manufacturers usually have a failure rate of 1 in 10^16. And RAID6 can sustain two failures of any drive. Using six 1.5 TB drives with a 10^-15 bit error rate and RAID6 has a failure rate during rebuild under 1%.
I had a WD desktop drive show signs of failure a few months ago (SMART showed offline unreadable sectors.) I was able to get a replacement just by filling out a few forms on the web.
Seagate's the same way, but they charge a nonrefundable fee for advance replacement (where they send you a replacement drive first.)
Same applies for cash, too, which isn't quite the same as writing a check.
How many people would present identification for a cash purchase that wasn't age restricted?
For the past few weeks, I've been ignoring a "Digital Camera Raw Compatibility Update" that requires a reboot. Past QuickTime updates have also required system reboots.
(Why are you making comments about stuff you don't have experience with?)
Digital cameras and many other portable devices don't have to deal with annoying things like:
my EFI system (Intel Mac) takes just as long to start loading as any other recent PC I've used, regardless of the OS being loaded.
CDMA is clearly technologically superior; this is why the current TDMA-based GSM systems are being overlaid with UMTS/WCDMA networks. CDMA has less latency in data services, faster data rates (in the latest revisions), much cleaner handoffs, and no 20-mile distance limits. CDMA2000 1xRTT (which was deployed around the same time as GPRS and EDGE) isn't quite as fast as EDGE, but has about half the latency.
Modern UMTS/WCDMA have all the technical advantages with the user-friendly features of GSM.
The situation from 9 years ago doesn't matter. SMS was introduced by CDMA carriers around 2000-2001.
No. There's nothing special about US CDMA phones for different carriers and US GSM phones for different carriers. Verizon, Sprint, and ex-Alltel phones don't use special hardware exclusive to one carrier. Until the implementation of 3G, T-Mobile and AT&T phones didn't use special hardware either.
The article clearly states that LTE is an air interface, not something to be implemented on top of GSM or CDMA. A signalling & authentication system would be implemented on top of LTE - something that might be implemented in sofwtare.
In fact, development of the next generation of CDMA2000, UMB, was discontinued in favor of LTE.
They charge $9.00 extra for Exchange access? Or $9.00 extra for BlackBerry connectivity to Exchange?
Exchange ActiveSync support (with a compatible phone) only requires access to the Exchange server via http or https. Compatible devices include all recent Windows Mobile deivces, the iPhone, some Palm OS devices, and newer Nokia Series 60 devices. I think there are a few Sony Ericsson non-smartphones that support it as well.
It works with consumer PDA and non-PDA plans on AT&T.
I have yet to see any internet filtering on AT&T (after four and a half years) - even on their consumer plans.
What do you mean by saying that Verizon and T-Mobile block dialup and fax use? CSD is an extra feature that actually requires modems to be installed somewhere. And it's slow.
CDMA (as in cdmaOne and CDMA2000 with 1xRTT) is technologically superior than GSM/GPRS/EDGE. It took a long time for UMTS to catch up. The US's biggest GSM carrier didn't even start deploying it until the past 3 years, and as a result the CDMA carriers had a 2-4 year head start on 3G services.
Unfortunately CDMA as implemented by US carriers is lacking user friendly features (namely SIMs). From what I understand, the signalling protocols on top of the air interface are much closer to the old U.S. analog AMPS system - of which Verizon had tons of until the FCC permitted carriers to shut off analog service last year.
CDMA's market share in the US isn't nearly as big as you suggest. There are at least 107 million customers using GSM/UMTS networks (AT&T and T-Mobile) and there are probably somewhere around 130-150 million customers using CDMA (I can't find any good numbers; Sprint Nextel has 50.1 million customers, but some of these are on the old Nextel network.)
There's no special network-specific implementation needed for devices on Verizon and Sprint's CDMA networks as of now. New mobile communication bands have been opened up (AWS and 700 MHz). I believe T-Mobile is the only nationwide carrier who has launched service in one of these new bands.
You are mistaken. Many phones are released on the different US CDMA carriers with different firmware. GSM (non-UMTS) phones are treated the same way.
Handset design differences are minimal when differences in frequencies do come up (among CDMA networks or among GSM/UMTS networks); usually a handset for a market will differ in the version of the chipset inside and perhaps the antennas. The software will be different as well.
GSM and UMTS is all that's used in most of Europe and has the majority of the entire world market. But CDMA has significant deployment in Asia, incuding China. Japan and Korea used/use networks in compatible with those elsewhere (some CDMA based), although both countries now have UMTS on the 2100 MHz band like Europe.
Qualcomm is the owner of many patents on WCDMA, which is used by UMTS. They also make many of the baseband chips going into WCDMA phones. So, in a way, everyone is now using American (W)CDMA technology.
Just about all the carriers will be moving over to the same technology when they start using LTE.
They don't have to. They could choose to exclude 2/3 of the US market, like Apple did. The iPhone 3G works in nearly every country, including China and South Korea.
There's no exFAT specification or documentation that I can find, but it's supposed to be close to FAT32 with design improvements.
I couldn't find any conclusive information on exFAT ACL support; however, ACLs for exFAT aren't implemented in Windows Vista. It might be for Windows CE use only, like the transaction feature, and could be implemented as one of the extensions that exFAT is supposed to make it easy to implement.
exFAT is a simple filesystem that will work with large files and volumes - in this case, intended for use on removable storage devices like USB/SD drives and in embedded devices like digital cameras and MP3 players.
Filesystems like ext2 are more complex than FAT32, with more features like permissions and ACLs. Things could easily get messy with permissions when moving volumes between systems.
ext4 (and any other journaling filesystems) are not optimal for flash devices because of the limited write cycles.
Ideally, there would be a simple filesystem suitable for large removable volumes and large files with an open specification.
FAT32 and ext2 are probably the closest, but FAT32 is a bad choice on volumes above 32GB and ext2 is more complex.
Because ZFS is a filesystem with lots of features that are useless in systems in which SD cards are normally used. ZFS's goals are completely different than those of exFAT.
Fallacious. Some closed source software vendors do not implement open standards (in full or in part), but this has nothing to do with that software being closed source. These vendors ignore open standards as a business decision.
Some open standards don't even have complete open source implementations. How many fully complete ISO 32000-1 implementations (more commonly known as PDF 1.7) are there? How many are open source?
I am writing this on a closed-source browser (Opera), which aims for standards compliance.