I'm not exactly the most vocal contributor here, but as you can probably see, I've been around for a while, and believe-you-me your presence will be missed.

Thanks for /.

-- Nathan

How do you know that he did this, out of curiosity?

-- Nathan

You misspelled "now."

Ah. Sorry. I misread the beginning of that second sentence as you offering a second point in favor of the Nexus S (as in, "they're the most dev friendly, AND they're supported pretty well, too").

Nexus S is Samsung, not HTC.

'nuff said.

(...alright, troll: I'll bite...)

Microsoft wrote OS/2 1.x, yes. Calling anything above 2.x a recompile is pretty silly, though. I'm sure that there is still Microsoft code that exists in IBM-branded versions of OS/2 after their "breakup" (most likely at lower levels, in the kernel or filesystem layers), but MS had absolutely no hand in IBM SOM or the Workplace Shell. WPS came to be after Microsoft decided to wash their hands of IBM.

-- Nathan

This is a non-story, at least how it is written.

As part of iPhoneOS (now iOS) 3.0, in June *2009*, Apple announced that hardware manufacturers would be able to have their hardware directly interface with their iPhoneOS applications, either through the dock connector OR through bluetooth. They have an official set of APIs built into the OS specifically to facilitate this.

I think it was cool that they did this over a YEAR AGO, but hey, that story doesn't make for as sexy a headline as "OMG Apple suddenly loosening their Death Grip on their iPhone hardware?!?!?!"

-- Nathan

P.S. -- No Apple apologist here; in fact, I'm generally very critical of the locked-down nature of the iDevices. But come on...let's strive for accuracy here.

First, I don't think it's about BES (at least exclusively). If BES doesn't also go through RIM's servers (As in: your provider's Exchange server BES gateway Blackberry servers Blackberry phone), then why do all of the articles about this India scuffle to-date talk about "RIM's network"? (Yes, I read TFA.)

Second, if it was about BES and BES worked the way you imply it does, then it seems to me that RIM still shouldn't need to get involved. Sure, the communication over-the-air is all encrypted, but since BES (according to you) is simply a gateway to your corporate Exchange/Notes/Groupwise server, why not simply ask the owner of the server for direct access to its contents rather than dragging RIM into this? Or are you trying to tell me that IMAP4+SSL users or encrypted Exchange users on other phones that don't need to be tied down to a proprietary network will give the Indian government the same kinds of headaches?

-- Nathan

See, this is exactly why device manufacturers shouldn't be making devices that are entirely reliant upon an external "cloud" service that is also controlled by the device manufacturer. If Blackberry was merely making devices that could be configured to talk to any server(s) using industry-standard protocols, they wouldn't get themselves into the kind of situation where 1 million deployed devices could have been turned into doorstops overnight. (Maybe my understanding of the way that Blackberries work is misinformed, and so my rant here could be completely groundless -- and just for the record, I'm open to correction -- but I am under the impression that Blackberries need to be in constant communication with the BIS servers that Blackberry themselves run in order to function.)

This is also why the whole push notification system that Apple came up with for the iPhone is stupid. If something goes wrong with servers that Apple controls, then suddenly that feature across every single phone that has shipped to-date is dead. Device features should not be wholly reliant upon a service that the device manufacturer controls...all you are doing is making a single point-of-failure when you do that.

-- Nathan

So, I see all of the posts coming to the defense of CSIRO, and I get them. I truly do.

However, there is still one thing I do not get: Why is CSIRO going (and why have they been allowed to go) after the companies selling the final piece of complete, end-user hardware in a shrink-wrap box, rather than the chipset manufacturers themselves? Isn't it Broadcom, Atheros, Intel, Ralink, Realtek, etc., who failed to license the technology? It seems to me that the company who takes the chipset and slaps their name on the front of a plastic box that contains it has become an unwitting victim in all of this. Most of these companies don't even really have their own designs. The original Broadcom reference design was tweaked by Gemtek and then rebranded by Linksys, Buffalo, and many, many others, for example...most of these companies buy their stuff from an ODM and barely do any of their own actual engineering and are just sales and marketing warehouses.

So why are all the actual chipset manufacturers getting off scott-free?

-- Nathan

Okay, so it's not ideal, but here's what you can do that doesn't require running a virtual machine on your primary PC, or a dual-boot-into-Windows to run the scanner/authenticator software every once in a while scenario:

Get yourself a cheap-ass PC. Throw two ethernet NICs in it. Install a new copy of Windows XP, and any software that your campus IT staff require to be installed on there. Then run Windows XP Internet Connection Sharing (ICS) on the unused ethernet adapter. (ICS is a small DHCP server + NAT engine built into Windows.) Plug that into a switch along with your main computer or computers, and use the XP box running ICS as your router.

Then from the university's perspective, you have a single Windows XP box hooked up which is clean and conforms to their standards for network access. Unless the software that you need to install prohibits ICS from functioning, and there is no way around the artificial restriction, they won't know about the PC or PCs you have running behind the ICS machine.

On my iPhone, I use a free app from the App Store called FStream which can stream MP3, OGG, ASX, and WMA formats over HTTP or MMS. It actually works great over 3G/HSDPA and even EDGE in many cases as well (I drove 300 miles once along Hwy 26 in Washington with EDGE service most of the way, and listened to a 128kbps Shoutcast radio stream most of the time...worked great).

You can create a "favorites" list that you can scroll through and select the station of your choice to "tune in" to by simply tapping the selection, so it works fairly well in the car while driving. It even ties into the main Shoutcast Directory server where I can browse all of the advertised streams on there and connect to any one of them.

Not affiliated with the author, just a fan, etc.

-- Nathan

You have absolutely no need or cause for apology. My curiosity often gets the better of me and I end up asking questions the answers to which I have absolutely no entitlement.

If you happen to somehow manage to read over your docs and then furthermore have time to flesh out your answer to me in more detail, I'll consider that a bonus. You pretty much confirmed what I guessed about the different names being internal codenames for entire series, so I guess the more interesting information at this point would be what makes a drive that takes CC firmware different from one that takes SD firmware (especially since it would seem that there are at least some distinct differences between the two branches of firmware revs, considering that although one bug was shared between the two -- the stuttering -- the other so-called "bricking" bug never crossed over between firmware branches).

Thanks again,

-- Nathan

Hey Maxtorman,

I personally have not been affected by any of the recent firmware issues on Seagate drives, but I have long been a Seagate fan and have been reading your posts with interest. First, I just wanted to say that the great deal of transparency that you personally and your company as a whole have both shown through these recent ordeals is more likely than not going to counter any possible fear that might have resulted in me leaving the brand for another. So, kudos.

Mostly I'm just curious about some of the more technical details behind-the-scenes. You keep referring to the BRINKS and MOOSE model of drives; elsewhere, when I Google those terms, I also have caught wind of a GARBO model as well. Nowhere do you explain in your posts what the differences actually ARE between these different models. Is it just a matter of assembly, or are they different revisions of the same drive, or are they completely different top-to-bottom but just happen to bare the same customer-facing model #? (It _drives me up a wall_ when companies do that...) Are the differences between these drive models related to the differences in the firmware series (CC## vs. SD##), or is that a different thing entirely? Is all of this perhaps somehow related to the split-branding between Seagate and Maxtor (same silicon and platters, subtle differences in the firmware to account for that branding distinction)? Do the differences in these drive models (BRINKS vs. MOOSE vs. GARBO) or the differences in the drives that accept different firmware series (those that take "CC" vs. "SD" firmwares) somehow come down to performance differences, or MTBF/QC differences at all? Is one line of drives preferable to another?

Unless it would cause you to risk your job or reveal any kind of trade secrets, please don't feel the need to spare any details...I absolutely love this kind of "trivia." :)

Also, can we assume from your username that you were brought into the Seagate fold from the merger? If so, I'd love to ask you about that (how you viewed that coming into the fold, what your perceptions are/were of Maxtor and now of Seagate, etc.), but I've already asked you enough. :P

Please, only answer as your time and conscience allows. Feel free to contact me by e-mail, if you *really* feel like it. :P

And thanks for being here on /.

-- Nathan