As anybody who spends 10 full minutes fiddling with adapters to get their macbook connected to a projector *should* look stupid. As should anybody, not just mac users. Your argument that mac users look retarded for having an adapter is just ridiculous. I've always been taught to view those with adapters as "especially prepared". Now, show me someone that doesn't have an adapter, and I'll show you someone that looks stupid when they fail to get the job done.

Cell Phone carriers (such as AT&T, Verizon, et. al) should write phone firmware that indicates to the network when it is traveling at a high rate of speed (faster than can be humanly achieved... indicating that the user is either operating a vehicle or a passenger in a bus, train, plain, car, etc.).

Sure... being a passenger might suck... so they should have an option like... "Dial #MV on your phone to change the settings... permanently disable or disable for 24 hours".

People that don't own a car and are perpetually passengers in vehicles they don't operate will likely opt-out. However, people that own cars and operate speedy vehicles on a regular basis would likely prefer the feature... opting to have the carrier "hold my calls or texts while I'm driving".

Of course, the system wouldn't be fool-proof... for example, if you're sitting in traffic and traveling pretty slow, a flood of texts that have been held for you might dump on your phone... or incoming calls will be patched through rather than being held.

To solve that... maybe carriers should partner up with car makers... when the phone detects your Bluetooth car (such as a Prius)... the phone just locally holds your calls/texts... then when you get 20 feet away from your car... ALERT! 5 missed calls, 12 texts! If a smart phone... it could even do something like reply to the caller/texter... "Your friend is driving right now... please try again later" (either in that annoying automated voice, or in the form of a reply-text).

There just seems to be so much more that we can do about this rather than relying on some law that will ultimately be unaffective. Honestly now... how on Earth is a judge supposed to accurately determine (other than the cop's word against yours... unless perhaps there's another witness involved) that you WERE or WEREN'T texting/talking on your phone. After-all... were it me, I'd just say "I wasn't texting... I was just checking the time". Now, extenuating circumstances aside... such as if the police person was behind you watching you fiddle with your iPhone-in-hand for 60+ seconds... I really see these laws as silly. Either put a full ban on using a phone while driving period, or don't make legislation on the topic... out-lawing, say... texting, but not checking the weather, or calling but not e-mailing makes no sense. Even the hands-free paradigm doesn't work because "Hands-Free" doesn't mean "Eyes-Free". I can see a crash occur with a Hands-Free option if the user is required to look at the screen for longer than 3 seconds.

I think that the problem also extends further than just phones. My buddy just crashed into a parked car last week (and rolled his car, totaling it) because he was staring at his in-dash touch-screen trying to select a song to play. There's a reason that factory in-dash stereos are minimalist, people! It's so that you don't have to stare at the thing while driving!

Some cars with factory in-dash LCD screens are designed to turn off the display while driving, or have a minimalist display with large features so that you can interpret the data they display "at a glance".

In other words... in this day and age... there's no excuse why technology can't solve this problem. Technology started the problem... technology can solve it (because apparently, people are too stupid to know that when you're operating 2000+ pounds of steel with hundred(s) of kilograms of force/power behind it... you need to pay attention to what you're doing on not stare down at the shiny thing 3 inches from your face! but rather the destruction you're going to cause by not watching where you're going or what's going on around you).

There should be a mandate to stop selling technology that allows people to grossly endanger others and start selling technology that caters to the million-plus nimrods.
--
Devin

I actually got System 7.6.1 shoe-horned into a Mac Classic with 50MB hard disk and 4MB RAM (originally came with 2MB). It took me a week of splitting up the Finder and various other elements across multiple 3.5" floppies and piecing them back-together again. Lol, I had that little Mac Classic singing tunes it thought it'd NEVER sing (I was a big resedit junkie and programmed AppleScript... as in actually programmed the aslt raw resources for implementing new dictionaries and such; you can even find some of my aete resources and tips on resexcellence from the early 90's).

I meant to say that you don't have to go to the store and buy it to get that warm-safe-fuzzy feeling (knowing that your copy is legit and not a back-doored/trojan'd piece of work like the "Black Edition" that's recently surfaced on BitTorrent), that there are other avenues. For example, if you happen to have an MSDN subscription and get them that way (as in, not through the retail chain).

There's no GUI element to the ZFS support in 10.6 non-Server. 10.6 Server has GUI elements for managing ZFS volumes... but rest-assured 10.6 client does indeed support ZFS (albeit if you have to do some leg-work yourself at the command-line; kernel support is there). Apple has promised that 10.7.x client later-on will have the necessary bits to manage ZFS volumes, but 10.6 does support fully using ZFS volumes that are created/managed on a 10.6 server. I think I want to say that kernel-level support in 10.6 client is read-only at the moment, with promises to make it read-write in 10.6.1 (the first update).

You, sir, are an argumentative idiot.

The reasoning stands... Microsoft, Mac, Linux, whatever, operating systems to not "spontaneously bloat-up and slow-down"... there is an impetus, a root-cause... the USER! Let's dismantle your silly argument line-by-line:

"The more you use your OS- the slower it gets." False... this may be the case when you use your computer, but it's not the case when I use my computer... hence, again, the problem is YOU.

"Browser histories get bigger"... well let's see... might that be because you allow it to? Don't you clear your history? Haven't you gone into gpedit.msc to modify the Group Policy settings, disabling the browser's history? User negligence does not equal self-bloat (aka spontaneous bloating).

"and take longer to open"... bloat is not the same thing as disk-sector fragmentation. Seek times will naturally degrade in minute quantities as your hard disk approaches capacity (and no, the decrease in seek time is not a factor of bloat, it's a factor of the level of entropy in respect to block contiguousness).

"Search bar suggestions take longer to load"... again, the USER's fault for allowing a search bar to be installed (for example, when you install Sun's Java JRE or JDK, it offers to install the google toolbar). Not to mention that this is not considered bloat as (a) the USER has to choose to install the option and (b) once installed the feature does not grow in perpetuity. Sorry, wrong again.

"My computer gets slower with every drive you add"... your computer does... not mine. Again, see gpedit.msc to disable automatic statistical analysis/tracking of internal disks.

"Sometimes programs install themselves to context menus" ... solution: don't use said programs (I make it a point to not use programs that install unwanted/non-optional components... for example, any program that installs a Browser-Helper Object or BHO without my permission gets mercilessly killed immediately after install). Go to sysinternals.com (now owned and operated by Microsoft) and get yourself a copy of these four utilities: ProcessExplorer, AutoRuns, NTFileMon, and TCPView. These four utilities will help you to uninstall anything that is undesired and find any malware. Again, claiming that your computer spontaneously self-bloats without your interaction is both naive and a clear attempt at denying the user's negligence. Might you be referring to the WinRar context menu? You are allowed to uncheck the box for context menu items during install (which you probably neglected to look into, therefore YOU were the root-cause of any perceived bloat).

"How about programs that have background processes always running" ... like I said... the operating system does not spontaneously bloat-up... it takes YOU to help it. Either you surfed some pr0n that you shouldn't have, allowing security exploits in your browser to install malware and make your system part of a bot-net (a zombie that does the bidding of a remote hacker on some IRC channel). It's not Microsofts fault that you love you some dirty hairy pr0n, so much so that you're willing to visit websites infected with malware. Oh, and you were too busy with that pr0n to take some responsibility for the ensuing bloat (which you yourself caused) by installing some Anti-Malware software (which can't be considered as bloat either, because you installed it because you needed protection from the dirty pr0n-sites). Oh, were you referring to legitimate software that runs background tasks? Well, presumably you clicked the button to install said software too, so once again, we're back to YOU as the problem. Java did not install itself. You had a hand in it's install, even if you didn't explicitly install Java (that is, you installed product XYZ that required Java, so you indirectly installed Java).

"And why can't more registry items slow down windows?" I know you're being sarcastic, so I'll answer as such. Again, things don't get added to the registry spontaneously. Do this exercise... install Windows on a machine with a battery-backed power-supply, then put said workstation into a physical bank-vault (not connected to the Internet)... come back in a few hours... did the system spontaneously fill up the registry and hard disk? NO, because, sir, YOU ARE THE IDIOT! Systems don't spontaneously decide to get slower and more bloated... they need YOUR HELP FOR THAT!

"Searching takes..."
"Storing it in memory takes..." ... blah blah blah

We've moved away from the realm of "self-bloat" and are now talking about raw memory operations and binary search heuristics? Bloat, in it's most canonical form, implies "data that increases in size". I neither see how memory operations or searching for binary data has anything to do with data growth. You clearly have no idea what you're talking about.

"*drops the mic*" ... because you are a first-year CIS student trying to argue with a post-doctoral professional (of whom you just called an idiot) that can run circles around you in practically any topic.

Let's see... you can read the release notes to see what's new, or you can be lazy and ask the Slashdot Fanboys (btw, I'm a FreeBSD fanboy... which undoubtedly means I like Mac since it's based on BSD, but I do have a love for all Operating Systems; currently I recommend checking out MenuetOS which could give the old BeOS a run for it's money as "best realtime OS").

There's support for ZFS which I think is pretty amazing. What is it? It's kind of like software RAID, on steroids. Imagine being able to create a Logical Disk consisting of multiple variable-sized cheap disks, and being able to grow it on-the-fly. Definitely cool for anybody that needs a lot of contiguous disk-space but doesn't have a whole lot of money to spend all-at-once.

No, it happens because you (a) pirate the OS despite knowing full-well that somebody that goes through the arduous task of hacking the OS is also skilled enough to do anything else (back-door) he/she wants to put into your potential install and (b) you surf too much pr0n that leads to heaping piles of malware on disk and in your Registry. If you go to the store and pay actual $$$ for a retail copy (or get a release from a reputable supplier where you can be certain that it is an un-modified, non-back-doored copy), and practice proper security/safety measures, your system will not "get bloated" and "slow down"... that is a complete myth and falsification. Just about any OS you run, if you simply (a) install it (b) secure it and (c) maintain it in a secure state (if you even know what that means), then ANY OS will reasonably continue to operate in the same manner. It is when you go trolling for pr0n and start clicking "accept" on all the requests to Install/Run this-or-that is when your system starts slowing down. If you can reliably say that you have NEVER clicked "OK" or "Accept" on a dialog-box without reading it, then perhaps you ARE smart enough to understand why your computer has slowed down. Otherwise, let me spell it out for you... YOU ARE THE PROBLEM!

"Steal an idea from Microsoft" ... excuse me? I think you may be referring to the infamous "Registry" which, were you dealing with uninstalling an application on Windows, you would have a MUCH more difficult time of tracking down your user preferences and deleting them. And, I'm sorry to inform you, but Apple did no such thing. The standard practice of storing a file with configuration options within the User's configured directory hierarchy actually dates back to the late 1960's from Bell Labs on UNIX System V when the precursor to BSD-style user-account processing was introduced (which pre-dates Microsoft Windoze *AND* Mac OS). You might as well get your facts right... they BOTH stole from UNIX (which probably stole from VAX, which probably stole from... ad nauseum). And if anybody is going to be called out as the black-sheep for doing things nonsensically, it's going to be Microsoft with the, again, the infamous "Registry" (which I believe to be the most counter-productive waste of cycles ever conceived; with perhaps goatse.cx running a close second).

Except that it's not a Service Pack. If you really want to equate Microsoft Windows (commonly associated with the "Service Pack" jargon), then Snow Leopard is to Windows 7 what Leopard is to Vista. The fact is that Snow Leopard brings in new features (such as support for Sun Microsystem's Zetta File-System [ZFS]) and more in addition to refining the Operating System. A "service pack" is, well, a pack of updates to a service (that or a pack that performs a service, but that doesn't sound nearly as canonical). It doesn't matter what meaning you assign to "service pack," Snow Leopard does not qualify under this title.

My favorite publisher of all-time is Que. They come in a variety of flavors... including the "Complete Idiot's Guide to (insert topic here)", "Special Edition using (topic)", and "Platinum Edition using (topic)". I've at least found that the "Complete Idiot's Guides" go much further in-depth than one might think (at least more-so than IDG's "For Dummies" series which seem to often be good for nothing-more-than writing "Hello World" applications). I've always been impressed with the level of quality, depthness, and even humor contained in all the Que-published titles. O'Reilly actually earns second-place behind Que in my book, while being utterly invaluable for the fact that they (O'Reilly) publish on topics that nobody else does.

I commented on this a while ago. Copy-paste from my blog:

Improving CAPTCHA and Hand-Writing Analysis (Friday, January 02, 2009):

For anybody who has used a Tablet PC, drawing stylus, smart phone or any other device that translates hand-written text into computer text, you may have noticed that hand-writing analysis needs work. When I used to work at Dell, we used to demo the PDAs with this technology. Depending on the quality of hand-writing, each person had a different experience. Accuracy of the translation varied from poor-to-moderate.

I have an idea that just might help.

In an alternate paradigm, programmers in the online-services industry are continually trying to obfuscate text for the purpose of verifying that a human is behind the keyboard. You might recognize this when signing up for digital services, such as e-mail, at a site like Hotmail. Often, during the sign-up process at one of these sites, you will be shown an image containing altered text and be required to verify the meaning of said-text. This image is commonly known as a CAPTCHA (a contrived acronym that could be said to stand for "Completely Automated Public Turing test to tell Computers and Humans Apart."). What the CAPTCHA folks are doing can be viewed as similar to what the hand-writing analysis folks are doing (though diametrically opposed).

There is a way that we can marry the two paradigms in a single concerted effort to make improvements for both. The process of effectively implementing CAPTCHA on a site is not very significant when trying to relate CAPTCHA to the process of efficiently analyzing hand-written text. Rather, it is the mere existence of CAPTCHA that could very well lead to advances in hand-writing analysis.

The sole-purpose of CAPTCHA is to verify that the entity supplying information to a website is indeed a person and not a computer. That is to say, the reason-for-being for CAPTCHA is to prevent automated abuse of an online-service by computer(s). For example, CAPTCHA can be instrumental in preventing hackers from using computers to further proliferate spam (an already staggering problem in online communities).

The only reason that CAPTCHA is able to tell the difference between man-and-machine is due solely to the assumption that it is difficult for a computer to interpret obfuscated text in an image. That is to say, that human-beings are particularly adept at reliably determining alphabetic letters in an image despite many factors such as angle, skew, noise, color, rotation, and simple distortion. To a certain degree, this assumption is basically correct. However, computers are only lacking in this ability because humans have not yet programmed them to be adept in this area. However...

Hackers have devised ways to reliably translate the distorted text or at least reduce the number of odds. Today, it has become common to see in the news that occasionally a particular site's CAPTCHA algorithm will be broken. In fact, a friend of mine (who shall remain nameless) is quite adept in breaking CAPTCHA and was likely the first to achieve reliable results. He published his work in 2003.

As hackers build better programs to defeat CAPTCHA, it should become more obvious that CAPTCHA will never last. In fact, some websites now use Audio-based CAPTCHA where digital-noise, distortion and other obfuscation technique may be added. Unfortunately, this new form of CAPTCHA has also been broken. It's unfortunate that CAPTCHA developers must increasingly make their system more complex but there is an upside. With each new revision of CAPTCHA, we are actually making computers smarter (by way of challenging the hackers to overcome deficiencies). Each new version attempts to find tasks which are simple to a human but difficult for a computer, meanwhile hackers look to defeat each new revision and close the gap.

Naturally, should CAPTCHA systems start making use of hand-written samples rather than purposefully computer-distorted images, hackers will eventually crack that system too (and, unknowingly, help advancements in computer-based hand-writing analysis and translation).

Unfortunately, there's one little problem in this plan. There is little doubt that hackers will eventually find a solution to interpreting hand-written CAPTCHAs, but as to whether the work will be released and/or published is anybodies guess.
--
Devin