As opposed to the Windows paging system? Has the author used a Windows OS lately? Swapping is a *bleeping* killer! Especially when you have more than enough memory not to swap.:-/
No OS performs well while swapping heavily, but OS X seems to swap too often. I'm at 4.65 GB of swap used right now on a system with 4 GB of RAM, 3.94 GB of it used. The sum of real memory allocated by all processes is less than 3 GB. In my experience, this is worse than Windows or Linux. It's not rare for applications or the entire system to respond slowly for seconds at a time.
Windows lets you disable or limit swap easily, and Linux gives you lots of control over how much swap you have and how it is used.
Macs support CIFS/SMB pretty darn well these days. I keep hoping that someone will come up with a better replacement, but CIFS/SMB will continue to work until that day comes.
I disagree. Compared to other non-Microsoft SMB/CIFS client implementations, the OS X SMB client is deficient.
It does not support DFS, which basically amounts to having symlinks from one CIFS share to another (so a hierarchy of directories spread across many servers can be accessed via one namespace.) But Linux's cifs client driver can use it and Samba can host it. Closed-source DAVE supports DFS on OS X.
By default, the OS X SMB client puts desktop folders and dotfiles on remote SMB shares.
It's not like Apple is a struggling company who can't afford to improve their SMB/CIFS client. It's not like the required protocols are so difficult to implement that no one can figure it out. It's not like Microsoft is suing anyone who dares implement certain features.
It's not like they're ignoring the SMB client altogether. In Leopard, they finally introduced SMB packet signing (which other non-Microsoft clients have supported for longer, including Samba's userspace smbclient.) And performance seems to have improved; in unscientific testing with no attempt to improve performance on the Samba server or client, I went from 45 mbytes/sec SMB performance in Tiger in any condition to performance very close to the maximum possible given the disks involved - about 70 mbytes/sec.
Re:WTF? If AMD64 can't do it with a full x86 core.
on
Ubuntu Ports To ARM
·
· Score: 2, Informative
We are having problems moving to AMD64, and those processors include a full speed x86 compatibility mode. Until there is an ARM7 core that has a full x86 mode I don't think it is going to go anywhere on eliminating the "software advantage" of x86.
You might have problems running x86 software on x86-64 operating systems on x86-64 CPUs. But many issues are specific to certain operating systems. Missing 64-bit browser plug-ins can be solved by running a 32-bit browser and 32-bit plugins. It's also possible to support 64-bit software on a 32-bit kernel (which could have prevented driver availability issues for those who insist on using 64-bit software when they don't need to use more than ~3 GB of RAM), but only OS X Leopard takes this approach.
Some operating systems don't have x86-64 implementations that make this easy. I like the approach used in Solaris and OS X; there are no separate x86-64 and x86 versions of either operating system. Solaris includes the x86 and x86-64 kernels and OS X Leopard uses a 32-bit kernel which can run 64-bit processes. They ship with 32- and 64-bit libraries, but most of the userland executables are 32-bit.
Yes. Windows NT was originally developed with portability in mind. It has been ported to (at least) MIPS, Alpha, PowerPC, x86, x86-64, and Itanium. However, only x86, x86-64, and Itanium versions have been released since Windows 2000. The Alpha port was planned/developed for Windows 2000 but never released, and I've read rumors of Xbox 360 demos/development running on PowerPC chips running some port of Windows NT.
Microsoft already has compilers for (at least) x86, x86_64, Itanium, MIPS, ARM, PPC, SH3, although some of those are for Windows CE or Xbox development.
Microsoft didn't start offering Windows NT as the consumer "desktop" version until XP was released in 2001, but they've since released x86, x86_64, and Itanium versions of Windows NT.
I'm still skeptical about Android for the same reason, Java-only for 3rd party development. Since it's open source someone could technically "fork" it to a platform that allows native coding, but that'd be it's own thing and not have the industry backing. So far "just fork it" hasn't worked in creating a mass market force for OSS systems on the workstations, and it won't be any different on smartphones.
You *are* using the same APIs on the BlackBerry and Android.
Apple doesn't "let" you write native code with the same APIs they use -- you have to if you want to follow their rules (and run your own software on unhacked devices.) This is the same for BlackBerry and Android; it just happens that the language you have to use is Java. In some ways, iPhone software is more limited than BlackBerry software.
On the other hand, Windows Mobile, Symbian, and PalmOS all support languages other than the one they were developed in. There are JVMs for all platforms to run J2ME software. Windows Mobile supports.NET. I believe there's Python interpreters for Windows Mobile and Symbian.
Because far too often at least one of the parties doesn't really want to be there. And is 'consenting' to something out of financial desperation/outright fear. That isn't how business transactions are supposed to be conducted.
A long time ago, people worked in factories for long hours in unsafe conditions out of financial desparation. Did we outlaw factories? Did we outlaw buying products made in factories? Did we make it illegal to work in a factory?
Mac OS X doesn't have to accommodate variances in the hardware it is running on in the same way that Linux or Windows has to do. Therefore, it can exploit the hardware better. It's the same principle that applied to game developers targeting the XBox rather than a standard PC. Standard PCs might be more powerful, but the XBox is a non-moving target, so you don't need to write to the lowest common denominator, and can exploit the particular strengths of the hardware better. So, it's unreasonable to expect an OS that is written to work on multiple platforms to compete in this fashion.
The Xbox was always sold with the same chipset. There was no need to have interchangable drivers.
OS X Intel has been sold (so far, and at least) on systems with Intel 945GM, 945PM, GM965, GMS965, PM965, 5000X, 5400 and nVidia 9400M system chipsets. That's two (plus one low-power variation) Intel mobile chipsets with Intel integrated graphics, two Intel mobile chipsets with PCI Express x16 graphics, two Intel server/workstation chipsets, and one nVidia integrated mobile chipset. It supports two generations of Intel GPUs (GMA 950 and X3100), at least three generations of GeForce GPUs (7, 8, and 9-series), and at least four generations of Radeon GPUs (X1k, HD2k, HD3k, and HD4k). There aren't a whole lot of hardware-specific assumptions or optimizations that can be made without making things only work on on that hardware... which is why hardware-specific code is in interchangeable drivers.
Apple can't even assume that every Intel Mac has a 64-bit dual core CPU; the first Intel Macs had Core Solo or Core Duo CPUs. Apple can assume that every Intel CPU will have SSE2 and SSE3, though, so many floating-point operations are performed using SSE instructions instead of the x87 FPU. But software can be compiled to use SSE on any other operating system as well. (SSE3 is featured on nearly all Intel and CPUs.)
They could write code/compiler optimizations that result in faster execution on some CPUs, but they're already supporting the P6 microarchitecture (the original Core Duo was close in design to the Pentium M) and the Core microarchitecture, and Nehalem will be here soon.
Did both machines have two DIMMs inserted? I've noticed a significant different in Aero on Intel GPUs when the machine only had one DIMM (that is, 1x1GB DIMM was noticeably slower than 2x512MB DIMMs.)
You can't remap a sector if an entire drive fails. By the time you have put in your spare and your RAID controller has finished rebuilding the arrays, there's a not insignificant chance that the stress of constant reading has killed one of the remaining good drives. This chance goes up as the time to write an entire drive (capacity divided by transfer rate) goes up. See Art S. Kagel's article that strongly recommends RAID 10 over RAID 5 [miracleas.com].
This argument is essentially: RAID 5 is more likely to fail during rebuild than RAID 10, so use RAID 10. But why not consider something else?
Consider an array of 1TB drives with a published failure rate (BER) of 1e-15 (one in every 10^-15 bits read will fail.) Assume that one drive fails. If there is a single mirror, there is a.11% chance that the mirror will have a read error while rebuilding. In a three-drive RAID5, there is a.21% chance that one of the remaining drives will have a read error while rebuilding. In a four-drive RAID6, the chanche of having read errors twice while rebuilding (essentially three drives failing) is less than.01%.
I suppose 5400RPM is slow in terms of transfer and seek time, and being a software RAID5 set managed in software via mdadm likely also reduces the speed of the array.
Actually, it should be faster than the speed of a single drive.
On my five drive RAID5 running on CentOS 5.2 with the default kernel, no tuning, and the ext3 file system with default mount options, I'm getting write speeds of 109 mbytes/sec. It is possible to get faster speeds; there are paramaters and configuration choices that affect performance, and I haven't tuned them since installing this operating system. When things are set up correctly, the maximum read speed should be close to 250 mbytes/sec.
Instead, I bought a Toyota for $13,500, brand new, and I haven't had a single problem (except for a flat tire) since then. That was almost 4 years ago. I have a warranty, I know all the problems with my car (no shady history), and I keep a good record of all the mechanical work I do on my car (get regular oil changes, etc). I will *never* buy a used car ever again.
Buying a used Toyota in good condition would have a similar effect... I've had a 2001 for three years. Besides having the alignment fixed when I got new tires installed, just about every expense has been something that was expected - new tires, battery, brakes, etc.
Re:This is a huge amount of work
on
Linux 2.6.27 Out
·
· Score: 1
It does happen. It's just that the Windows kernel doesn't update vary often, so you get a binary driver instead of kernel source (the Linux version has binaries too if you have the right kernel), but it does add drivers for Network and others to your windows install.
Not quite. The Windows kernel has changed quite a bit between Windows 5.0 (2000) and Windows 6.0 (Vista and Server 2008), but there are drivers that will work on all versions of the OS (that is, many 2000/XP drivers will work on Vista/2008.) This doesn't mean that the Windows driver interfaces never change. It means that changes or replacements to driver interfaces usually don't break the old interfaces without a good reason. Using older drivers may mean that you may not be able to use features that are only supported by the new driver models.
OTOH, Linux's ABI/API isn't very stable between versions. There is no attempt to make binary drivers that work across new kernels. Drivers & filesystems that aren't part of the kernel are often distributed as a patch for a specific version of Linux; the patches may or may not apply to older or newer versions.
Other OSes manage to have a stable driver ABI: FreeBSD and OS X keep the driver API/ABI stable across minor versions (at least). Solaris's driver ABI goes back even further, perhaps even as far back as Solaris 7.
I've never seen a Windows laptop do that. I usually have a working wireless connection in less than 8-10 seconds too. That took at least 30 seconds on the last Windows laptop I tried (same base station).
I use PCs and Macs btw, but this is one of those things that Macs just seem to do way better, probably due to Apple's ability to control the hardware. Windows has to deal with whatever random collection of chips you have on your motherboard, etc.
Takes about 2 seconds for me on a PC Intel ICH7M/945GML laptop running Windows. This is the same chipset used by the first Intel Mac laptops. The Intel mobile chipsets in most Macs are the most popular PC laptop chipsets as well.
Wireless takes 5-15 seconds to come back up, depending on the last time I authenticated to the network (WPA2 PEAP or TLS).
I had a buddy of mine claim up and down that comcast did not compress the OTA HD channels. so I pulled a firewire stream into my PC from my tuner box and had him do the same at the same time from his cable box.
My OTA recording of the TS had far fewer artifacts and overall looked better on his TV set. If I had mpeg2TS analysis tools I'd bet that mine had a higher bitrate oming from OTA.
Not all systems reduce the bitrate of OTA channels. Your local Comcast system might, but this doesn't mean that other Comcast systems do.
From what I've heard, they don't, because it's against the law. It sounds like you did a good test, but I suspect something else is going on. They do compress the hell out of non-OTA channels (scifi, etc), which I hear look much better on analog.
There is no such law. Cable companies might or might not reduce the bitrate of OTA channels.
What this gets to you is ZFS and RAID-Z and RAID-Z2. When you get used to the fact that your filesystems has end to end quarantee of data integrity by hashing (even cryptographic hashing if you want, you feel uncomfortable with any other filesystem.
Hashing does not guarantee data integrity. It only detects it. RAID-Z/2 or mirroring plus hashing can detect & recover from corrupted data automatically, but it doesn't prevent corruption from happening in the first place.
It's certainly a nice feature that's worth using when available, but it's no substitute for adeuqate backups and reliable hardware. If you have data corruption due to a factor that affects more than one element of the array (like a bad storage controller or driver), RAID-Z/2 might not help.
Symbian/WinMobile smart phones have tools to lock the handset remotely or in case of new Kaspersky antivirus/security or other 3rd solutions, you can remotely instruct phone to delete all personal data irrecoverably and lock itself. I am almost sure Blackberry, being an enterprise focused device must have similar option.
Remote wipe is a feature of BlackBerry/BES and Windows Mobile/Exchange. No third-party software is needed, unless your phone isn't connected to a BES/Exchange server. When the phone receives the wipe signal, all data stored on the device will be wiped.
The iPhone has remote wipe, but I don't think it has encryption of any of the content stored on the device.
BlackBerry has content encryption and the latest Windows Mobile (6.1) has encryption for the entire user-writable storage area. The key is stored on the device, encrypted with a password. BlackBerry overwrites the key in RAM when the device is locked (that is, when the device is inactive for a certain amount of time or when it is placed in its holster); since WM's encryption operates at a lower level, the key does stay in memory while the device is powered on. Either way, cutting power to the RAM will erase the decrypted copy of the key. Both support encryption of storage cards as well.
As long as the device is set to automatically lock itself out and there is no way to bypass the lock screen, there's not a whole lot you can do to a fully encrypted WM6.1 device without resorting to a RAM attack or finding a weakness in the implementation. Since the BlackBerry will erase the unencrypted copy of the key when the device is not active, it's secure against searching for the key in RAM, too.
However, since infecting a server is lower profile than infecting 1000 home computers, people looking for notoriety won't be doing it. I imagine that if someone finds a linux server exploit, they will exploit it as widely as possible without letting anyone know. Until very recently, hacking windows was something you did because you could, and letting people know they had a virus wasn't an issue. With linux, I imagine it's a different game entirely, and the tipping point is already there.
You speak as if this doesn't already happen. I remember fixing a server that was set up with Red Hat 9, about six months after the release (2003). No updates were installed. It got rooted after a few days, using an exploit that was known; patched binaries were available from Red Hat. I think it was discovered because it was scanning other hosts.
If you've got a vulnerable server in an IP range known to host servers, it might get exploited... If you've got a vulnerable system in a residental IP range, it might be infected by an automated scanner... but will anyone be manually scanning residential IP ranges for vulnerable Linux machines anytime soon? Unlikely.
Only when it forgets where drives are, or wipes configuration during upgrades, or the fact that it's slower than software raid setups in FreeBSD or even Mac OS X.
md doesn't forget where drives are: if md is configured properly and there are enough connected devices to start the array, it will work. md arrays shouldn't be configured by describing the individual members; I set up my arrays by specifying the UUID.
md does not have a configuration tool that modifies the configuration file; any configuration is done by hand or by some other tool. It's more likely that your package manager or distribution's own scripts are deleting the md configuration file, possibly due to your own (in)action while upgrading.
I've been using AT&T 3G since November 2006 (about a month after the coverage was turned on in this market); coverage was spotty at first, but things got better within a few months. Dropped calls weren't uncommon on 3G back then and the phone would often switch between 3G and GSM unnecessarily. I don't remember the last time I had a dropped call or had the phone switch between 3G and GSM excessively.
When I have a problem with 3G, the call/data session should gets handed off to GSM no problem.
Slashdot Mirror
I like Eclipse with PyDev.
No OS performs well while swapping heavily, but OS X seems to swap too often. I'm at 4.65 GB of swap used right now on a system with 4 GB of RAM, 3.94 GB of it used. The sum of real memory allocated by all processes is less than 3 GB. In my experience, this is worse than Windows or Linux. It's not rare for applications or the entire system to respond slowly for seconds at a time.
Windows lets you disable or limit swap easily, and Linux gives you lots of control over how much swap you have and how it is used.
I disagree. Compared to other non-Microsoft SMB/CIFS client implementations, the OS X SMB client is deficient.
It's not like Apple is a struggling company who can't afford to improve their SMB/CIFS client. It's not like the required protocols are so difficult to implement that no one can figure it out. It's not like Microsoft is suing anyone who dares implement certain features.
It's not like they're ignoring the SMB client altogether. In Leopard, they finally introduced SMB packet signing (which other non-Microsoft clients have supported for longer, including Samba's userspace smbclient.) And performance seems to have improved; in unscientific testing with no attempt to improve performance on the Samba server or client, I went from 45 mbytes/sec SMB performance in Tiger in any condition to performance very close to the maximum possible given the disks involved - about 70 mbytes/sec.
You might have problems running x86 software on x86-64 operating systems on x86-64 CPUs. But many issues are specific to certain operating systems. Missing 64-bit browser plug-ins can be solved by running a 32-bit browser and 32-bit plugins. It's also possible to support 64-bit software on a 32-bit kernel (which could have prevented driver availability issues for those who insist on using 64-bit software when they don't need to use more than ~3 GB of RAM), but only OS X Leopard takes this approach.
Some operating systems don't have x86-64 implementations that make this easy. I like the approach used in Solaris and OS X; there are no separate x86-64 and x86 versions of either operating system. Solaris includes the x86 and x86-64 kernels and OS X Leopard uses a 32-bit kernel which can run 64-bit processes. They ship with 32- and 64-bit libraries, but most of the userland executables are 32-bit.
Yes. Windows NT was originally developed with portability in mind. It has been ported to (at least) MIPS, Alpha, PowerPC, x86, x86-64, and Itanium. However, only x86, x86-64, and Itanium versions have been released since Windows 2000. The Alpha port was planned/developed for Windows 2000 but never released, and I've read rumors of Xbox 360 demos/development running on PowerPC chips running some port of Windows NT.
Microsoft already has compilers for (at least) x86, x86_64, Itanium, MIPS, ARM, PPC, SH3, although some of those are for Windows CE or Xbox development.
Microsoft didn't start offering Windows NT as the consumer "desktop" version until XP was released in 2001, but they've since released x86, x86_64, and Itanium versions of Windows NT.
You *are* using the same APIs on the BlackBerry and Android.
Apple doesn't "let" you write native code with the same APIs they use -- you have to if you want to follow their rules (and run your own software on unhacked devices.) This is the same for BlackBerry and Android; it just happens that the language you have to use is Java. In some ways, iPhone software is more limited than BlackBerry software.
On the other hand, Windows Mobile, Symbian, and PalmOS all support languages other than the one they were developed in. There are JVMs for all platforms to run J2ME software. Windows Mobile supports .NET. I believe there's Python interpreters for Windows Mobile and Symbian.
Offshore manufacturing is a recent event. Labor laws are not.
A long time ago, people worked in factories for long hours in unsafe conditions out of financial desparation. Did we outlaw factories? Did we outlaw buying products made in factories? Did we make it illegal to work in a factory?
The Xbox was always sold with the same chipset. There was no need to have interchangable drivers.
OS X Intel has been sold (so far, and at least) on systems with Intel 945GM, 945PM, GM965, GMS965, PM965, 5000X, 5400 and nVidia 9400M system chipsets. That's two (plus one low-power variation) Intel mobile chipsets with Intel integrated graphics, two Intel mobile chipsets with PCI Express x16 graphics, two Intel server/workstation chipsets, and one nVidia integrated mobile chipset. It supports two generations of Intel GPUs (GMA 950 and X3100), at least three generations of GeForce GPUs (7, 8, and 9-series), and at least four generations of Radeon GPUs (X1k, HD2k, HD3k, and HD4k).
There aren't a whole lot of hardware-specific assumptions or optimizations that can be made without making things only work on on that hardware... which is why hardware-specific code is in interchangeable drivers.
Apple can't even assume that every Intel Mac has a 64-bit dual core CPU; the first Intel Macs had Core Solo or Core Duo CPUs. Apple can assume that every Intel CPU will have SSE2 and SSE3, though, so many floating-point operations are performed using SSE instructions instead of the x87 FPU. But software can be compiled to use SSE on any other operating system as well. (SSE3 is featured on nearly all Intel and CPUs.)
They could write code/compiler optimizations that result in faster execution on some CPUs, but they're already supporting the P6 microarchitecture (the original Core Duo was close in design to the Pentium M) and the Core microarchitecture, and Nehalem will be here soon.
Did both machines have two DIMMs inserted? I've noticed a significant different in Aero on Intel GPUs when the machine only had one DIMM (that is, 1x1GB DIMM was noticeably slower than 2x512MB DIMMs.)
Tada was the shutdown sound in Windows 95 (as well as the startup sound in Windows 3.1), so it's not *that* bad.
For me, blockdev --report alone shows all block devices... using blockdev (util-linux 2.13-pre7) from CentOS 5.2.
This argument is essentially: RAID 5 is more likely to fail during rebuild than RAID 10, so use RAID 10. But why not consider something else?
Consider an array of 1TB drives with a published failure rate (BER) of 1e-15 (one in every 10^-15 bits read will fail.) Assume that one drive fails. If there is a single mirror, there is a .11% chance that the mirror will have a read error while rebuilding. In a three-drive RAID5, there is a .21% chance that one of the remaining drives will have a read error while rebuilding. In a four-drive RAID6, the chanche of having read errors twice while rebuilding (essentially three drives failing) is less than .01%.
Actually, it should be faster than the speed of a single drive.
On my five drive RAID5 running on CentOS 5.2 with the default kernel, no tuning, and the ext3 file system with default mount options, I'm getting write speeds of 109 mbytes/sec. It is possible to get faster speeds; there are paramaters and configuration choices that affect performance, and I haven't tuned them since installing this operating system. When things are set up correctly, the maximum read speed should be close to 250 mbytes/sec.
Buying a used Toyota in good condition would have a similar effect... I've had a 2001 for three years. Besides having the alignment fixed when I got new tires installed, just about every expense has been something that was expected - new tires, battery, brakes, etc.
Not quite. The Windows kernel has changed quite a bit between Windows 5.0 (2000) and Windows 6.0 (Vista and Server 2008), but there are drivers that will work on all versions of the OS (that is, many 2000/XP drivers will work on Vista/2008.) This doesn't mean that the Windows driver interfaces never change. It means that changes or replacements to driver interfaces usually don't break the old interfaces without a good reason. Using older drivers may mean that you may not be able to use features that are only supported by the new driver models.
OTOH, Linux's ABI/API isn't very stable between versions. There is no attempt to make binary drivers that work across new kernels. Drivers & filesystems that aren't part of the kernel are often distributed as a patch for a specific version of Linux; the patches may or may not apply to older or newer versions.
Other OSes manage to have a stable driver ABI: FreeBSD and OS X keep the driver API/ABI stable across minor versions (at least). Solaris's driver ABI goes back even further, perhaps even as far back as Solaris 7.
XP.
It's worked fine for some time. I suspect that most people don't have the laptop set to standby when they close the lid or don't know that they can.
Takes about 2 seconds for me on a PC Intel ICH7M/945GML laptop running Windows. This is the same chipset used by the first Intel Mac laptops. The Intel mobile chipsets in most Macs are the most popular PC laptop chipsets as well.
Wireless takes 5-15 seconds to come back up, depending on the last time I authenticated to the network (WPA2 PEAP or TLS).
Cable operators are not required to have an "unencrypted QAM Teir". They transmit OTA digital channels unencrypted, but that's it.
Not all systems reduce the bitrate of OTA channels. Your local Comcast system might, but this doesn't mean that other Comcast systems do.
There is no such law. Cable companies might or might not reduce the bitrate of OTA channels.
Hashing does not guarantee data integrity. It only detects it. RAID-Z/2 or mirroring plus hashing can detect & recover from corrupted data automatically, but it doesn't prevent corruption from happening in the first place.
It's certainly a nice feature that's worth using when available, but it's no substitute for adeuqate backups and reliable hardware. If you have data corruption due to a factor that affects more than one element of the array (like a bad storage controller or driver), RAID-Z/2 might not help.
Remote wipe is a feature of BlackBerry/BES and Windows Mobile/Exchange. No third-party software is needed, unless your phone isn't connected to a BES/Exchange server. When the phone receives the wipe signal, all data stored on the device will be wiped.
The iPhone has remote wipe, but I don't think it has encryption of any of the content stored on the device.
BlackBerry has content encryption and the latest Windows Mobile (6.1) has encryption for the entire user-writable storage area. The key is stored on the device, encrypted with a password. BlackBerry overwrites the key in RAM when the device is locked (that is, when the device is inactive for a certain amount of time or when it is placed in its holster); since WM's encryption operates at a lower level, the key does stay in memory while the device is powered on. Either way, cutting power to the RAM will erase the decrypted copy of the key. Both support encryption of storage cards as well.
As long as the device is set to automatically lock itself out and there is no way to bypass the lock screen, there's not a whole lot you can do to a fully encrypted WM6.1 device without resorting to a RAM attack or finding a weakness in the implementation. Since the BlackBerry will erase the unencrypted copy of the key when the device is not active, it's secure against searching for the key in RAM, too.
You speak as if this doesn't already happen. I remember fixing a server that was set up with Red Hat 9, about six months after the release (2003). No updates were installed. It got rooted after a few days, using an exploit that was known; patched binaries were available from Red Hat. I think it was discovered because it was scanning other hosts.
If you've got a vulnerable server in an IP range known to host servers, it might get exploited... If you've got a vulnerable system in a residental IP range, it might be infected by an automated scanner... but will anyone be manually scanning residential IP ranges for vulnerable Linux machines anytime soon? Unlikely.
md doesn't forget where drives are: if md is configured properly and there are enough connected devices to start the array, it will work. md arrays shouldn't be configured by describing the individual members; I set up my arrays by specifying the UUID.
md does not have a configuration tool that modifies the configuration file; any configuration is done by hand or by some other tool. It's more likely that your package manager or distribution's own scripts are deleting the md configuration file, possibly due to your own (in)action while upgrading.
I've been using AT&T 3G since November 2006 (about a month after the coverage was turned on in this market); coverage was spotty at first, but things got better within a few months. Dropped calls weren't uncommon on 3G back then and the phone would often switch between 3G and GSM unnecessarily. I don't remember the last time I had a dropped call or had the phone switch between 3G and GSM excessively.
When I have a problem with 3G, the call/data session should gets handed off to GSM no problem.