Disclaimer: I used to handle transport and build of localized resources at a software company using Mac and Windows.
I've never seen this behavior before on a Mac. The general rule for me was "if I can see it right on screen in TextEdit, it'll reach paper fine."
Here's what I'd do.
If you got UTF-8 text files, open up TextEdit.app and try both auto and UTF-8 selections for the data type. Then hit cmd-P and it should be exactly what you see on screen.
An alternative editor would be BBEdit.app which is more focused as a text editor rather than a basic word processor. Useful if your file turns out to be malformed or some format that TextEdit.app doesn't understand.
You know, you might actually get better service with the 1 bar of 3G rather than the 3+ bars of GSM. The thing is, 3G/UMTS is based off CDMA, which transports data in a way that supports more users in the area and has better reliability.
For the same reason that a call on Verizon/Sprint will sound perfectly clear even at a constant 1 bar, you might be doing pretty well with 1 bar on UMTS. You just might be trained into thinking "1 bar == crap" because of your experience using GSM.
Of course, you'd have to test it to be sure. I'm only speculating. I have both a AT&T phone and a Verizon phone and the AT&T phone just sucks in terms of connection reliability on 2G.
So I went to the University of California, Berkeley as a CS undergrad.
Our CS lab facilities were mainly Sunrays linked to giant Solaris 8 boxes and Windows 2000. The staff seemed to be using a lot of Powerbook G4s, and eventually a smaller lab of G5s were built. And many students had their own Macs, Linux, BSD, and Windows notebooks as expected. I recall there was a Linux lab which some people overflowed to when the Sunrays were all taken up.
The thing is, people flocked to their machines of choice. Most often, it was what was most familiar or what they knew would get the job done best.
Students understood that the G5 lab was replacing one Windows lab for computer graphics classes. So if you were in xyz class and wanted to do OpenGL work but didn't have a sweetass machine at your apt, you went there or the neighboring Windows lab.
If you're in the OS class and wanted to test your threading implementation, the sunrays linked to the 12 processor machine was your best bet.
If you were starting out in CS61a and needed to run Scheme/Lisp, you could go anywhere and instructions were published on the class site for all three major platforms. (Solaris, OSX, Win2k)
In the end, a computer for most people is a tool. The right tool for the job depends on the job, and how much proficiency you have in using it. While I think there's a benefit to FOSS, I don't see its benefits as grandly as you do. I do however highly recommend a diverse ecosystem of platforms available.
Here's why: With respect to education, when it comes down to it, your choice of OS and platform does not matter. You are in school to learn the theory of operation of these machines, not how to use them. You are driven not by a passion for programming, but a passion for learning and the desire to get out of here alive. You recognize that as a student, you have no spare time for open source projects, because your sleep debt will kill you first. Everything that makes your life as a student easier will be more important to you for your 4 years there as an undergrad because, unless you're a total slacker (and wasn't going to graduate anyways), you are devoted to learning your trade and profession with your 18 hour class/study/project days.
We all acknowledge that Linux isn't the easiest OS to use or maintain. Every minute you spend having to deal with the little unexpected quirks of your tools costs you important time. Increasing the possibility that a student will not make their project on time because you suggest they try a new OS takes away from their education about what is ultimately more important at school than FOSS: learning about computer sciences.
Having a lecture talking about FOSS: Good. Promoting Linux as a way to save yourself the cost of an OS: Bad.
With that said, I am so thankful that the Sunray labs were there because outside of the few macs, those things were so damn reliable, and I'm glad that those who primarily used Windows at home could see how little maintenance needed to be done on a properly designed platform.
For the common user, a pre-configured Linux and Windows computer from Best Buy or whatever does "work" out of the box. Since all the drivers are installed and the apps are installed, and fancy icons are available for the user to click on to launch apps. This applies to a Linux distro (say, Ubuntu), as well as a Windows distro (say, WinXP + Sony utilities + Office).
The problem comes when that computer needs to be customized to the user's needs.
The common user acquires software from various sources to augment the computer. I'd assume there's two main options. Download from the net or buy it on a CD from Best Buy.
If I were to download a new piece of software for Ubuntu, there's two options. Package manager (pretty easy if it's there), or source archive. I'm fairly sure most people won't know how to deal with a source archive.
And, there's no way for a software publisher to even make it as a CD. This is because there isn't any sort of standardization as to how to set up a good user experience during an install for an arbitrary distro. There is no easy way to make an executable that you can download that will put the app pieces in the right spot, and add a fancy icon to Gnome/xfce/KDE/blackbox/etoile/whatever. And then give you an option to uninstall. This is why the "install sucks" and "thousands of distros" sucks points are valid.
In Windows, you'd simply double click the exe or insert the CD and stuff will get set up. It doesn't matter who customized it. It could be beigebox, Sony, Dell, Compaq, etc. The fact that this can be done for a driver CD shows why a more solid kernel ABI is important. Even the latest OpenSolaris can take old Solaris x86 drivers.
If there's no way of making a easy way for commercial vendors to distribute apps, there's no way they'll consider making the apps. Want to see how powerful a uniform distribution system is? Just look at the iPhone App Store.
And while I'm at it, X sucks because configuration is a pain, direct rendering is a total hack, and instead of a nicely architected data pipeline, it's some giant tree of modules all centered on a single configuration file. Oh, unlike Windows safe-mode vga, there's no always-functional-vga failback mode.
Actually, I think that the status quo is exactly how everybody essentially seem to want it. (based off priorities)
People who care about stuff working out of the box migrate towards OSX and Windows.
People who care about tinkering migrate towards open source.
People who care about free software and pushing people who don't care about software freedom to use free software, lose out for the proper reason: those who don't care, simply don't care. Those who do care, still care more about effort/functionality.
People who care about widespread use of Linux on the desktop won't ever win because this goal is not the priority of FOSS advocates, nor the priority of those who create the distros, nor the developers working on key pieces of various distros.
I think it depends on how you want to approach it. If you're talking about all computer users, probably well less than 0.1 percent.
If you're talking about Linux-only users, probably a significant number since all the ones who care about stuff working left for Mac OS X, FreeBSD, or OpenSolaris since they at least have stable kernel ABIs.
Keep in mind that the key customer table that you pointed me to is on a page specific to aerospace. If we were to look at this page: http://www.ghs.com/ConsumerProductsCustomers.html then we'd think HP owns them.
Clicking the "about us" link says they were founded in 1982 and were profitable since the beginning. This was well before the Integrity product launched, so I'm sure they had something good going for them for the previous 15 years. It could be military, it could be something else. But I don't see a clear military connection for a company that started it's product line with compilers and logic probes.
My opinion regarding military outsourcing and ownership is that if it's developed internally by the military, it should be shared with taxpayers as long as it's not a national security issue. It's the military. I have to assume that being the military, they'd want to have every advantage possible over any other military. So I would think that for the most important pieces, they'll do the R&D, but for anything that can be cheaply covered by commercial offerings, save the time and money and just buy it. If they decided it was more cost effective to buy it off the shelf or pay somebody else to develop it, then it's not ours. This would be simply because part of that discount in outsourcing is because it either leverages tech already developed or because the outsourced company still owns the tech.
I think should we own a part of NASA's tech and findings. But I don't think Garmin or SiRF owes me any source code just because their entire product lines depends on the military-developed GPS system.
You and the article are talking about Integrity-178B.
I'm saying GHS' web site and product info pages (www.ghs.com) says its a repackage of Integrity. (note, there's no 178B.)
In more detail: Integrity-178B is the same thing as Integrity trimmed down, an avionics added, and then the process of certifying the software suite and the customer's hardware together for DO-178B certification.
Both suites are EAL6+ certified since Integrity is EAL6+ certified. The only code that could possibly be designed specifically for military use would be that avionics library.
I don't know for sure when or what the Integrity kernel was first launched or developed for, but considering we're talking about freakin' old company who developed embedded compilers, libraries, and debuggers back before the Macintosh was available, I see no reason to assume the OS core was built for a military contract.
The actual reason is that when the iPod was created iTunes already existed, and that the purpose of the iPod was supposed to be iTunes on the go and it was supposed to be easy.
Creating playlists on a USB mass storage device.... would not be easy.
Creating playlists on iTunes which centralizes all your personal music is pretty darn easy.
Additional reasons why include: 1) having the entire catalog of songs on an ipod indexed and ready to go makes startup time so much easier and faster. 2) having all the file names be 4 characters makes it smaller and fit into cache better. (remember, it's like, what? a 16 mhz primary CPU on the first ipod?)
There's no crazy conspiracies about lockdown and stuff. The itunes music store was years in the future when these design decisions had to be made. It's just simply better design when your focus is on the experience of using the thing. The proof is that it sold so well when almost nobody had firewire ports and so many mp3 players were usb mass storage devices.
Integrity for Avionics, the product you think you own, is simply a trimmed down version of Integrity, which is used in medical devices, industrial robotics, and other stuff like that.
After reading the product docs, the equivalent of what happened in the linux world would be: IBM starts with Ubuntu, and then the military asks "hey, can you make me a simpler version? I just want the bootloader, the kernel, and bash."
"All it does it make sure that memory from one container does not leak to another."
Doesn't this also mean, no kernel panics caused by application software? Doesn't this also mean, no privilege escalation can take place by hacking any piece of application software?
This sounds pretty darn good to me when it comes to security in embedded devices.
I must say, with the mass storage example, I feel I have to differ.
Yesterday, I downloaded a brand new copy of System Rescue CD from www.sysresccd.org because, well, I needed to pull some data off several drives attached to a machine I wanted to remove Win2k from because win2k was blue screening on startup in a loop.
There's an internal drive, there's a USB drive, and a firewire drive. And the CD I booted from.
Booting into linux was a breeze, and once I logged in as root, I wanted to mount the firewire drive. Except, I couldn't figure out how. lspci says it sees my firewire interface. But no drives/partitions actually showed up at/dev
Point is: In Windows, it'd whine and complain and ask for a driver for my firewire card. Once it has that, it'll whine and complain for a SBP2 driver for the mass storage device I just plugged in. Once it has that, it'll mount the disk if it can. If you fail at any of those points, you know what's next to try to fix.
In a distro of linux designed to access hard drives.... I just happen to know that it knows of my firewire interface. (lspci) But that's about it. If you don't see it in/dev, you're just kinda screwed. Where do I go next? I mean, sure, I could recompile the kernel. I could recompile all the modules. But really, that's like the "when in doubt, reinstall windows" catchall. There's little I can actually do that leads me in the right direction towards fixing this.
It's not the first time these things happen to me. And every time, I just pick another livecd off the net and repeat until I see the drive I want, or disassemble the computer and pull the drive because both of those have had better chances of getting me to my goal than attempts to fix the problem.
With Windows, there's a list of steps that give me insight into what failed. With Linux, I often times hit the catchall "reinstall the OS" instead of getting hints as to what to fix next. This is why I see Linux as less usable than Win XP.
It's relevant only in that not all people know what their jailbreak utility is doing.
Some people may have inadvertently broken their hardware while jailbreaking because it also ran a bad unlock utility. For those people, being rejected warranty service for a broken item is legit even though they don't understand that they themselves broke it.
So funny thing..... in iPhone software 1.1.1 many phones stopped working because the user ran jailbreaking tools that also unlocked their phones improperly.
AnySim unlocked the phone, but did so by corrupting data in a location normally secured by other code.
Apple's software upgraded itself as it was supposed to. However didn't account for corrupt data in an area which isn't normally touched and crashed.
The fault is AnySim no matter how you looked at it since Apple can't QA for unexpected changes in a nonwritable area.
"Nearly equal" is defined as comparing a moped (FW) to a 2-speed bicycle (USB2).
While USB 2.0 sounds pretty similar to Firewire, the reason it's used by people are pretty well defined.
USB 2.0 maxes out at about 25MB/sec while Firewire-400 maxes out around 40MB/sec when you're using the fastest bridges and chipsets for both and hooking up the same hard drive. While in the maxed out state, USB 2.0 takes 10% of a CPU time. While Firewire takes 1%.
USB 2.0 hardware can't guarantee latency. So when you have good audio equipment, all of them will not use USB 2.0 because audio will get out of sync or even drop a few samples, ruining a recording session.
USB 2.0 is master/slave. A USB master can only switch into slave mode if the hardware supports it, and none of the desktop chipsets do. Nor is it expected that they will. Perhaps Apple might push Intel to make a custom USB chipset, but that most likely breaks all the driver stacks too. This means that the target mode feature people are asking for won't come back.
With stuff like that, sure, it might be worth $1000 for people to buy a MBP, but that doesn't change the fact that they're angry for a good reason.
Getting Target Mode to work over USB isn't as simple as writing the software. There's no guarantee that the nForce chipset nor any of Intel's chipsets (which contain the USB2 controller) supports the USB-OTG standard which allows a USB controller to work as both a master and slave.
USB is directional. One end has to be designed to control and negotiate the connection. The other end has to be designed to be controlled. Only some handhelds have chipsets which can switch from being the slave to being the master.
Firewire is peer-to-peer. Control over the conversation is negotiated between any devices that feel like it.
You say: "People go on and on about how Android is Linux based and Open Source, but it's not."
Except, it is. Android IS Linux-based. Android IS Open Source. It annoys me when people say otherwise. I'm not saying there's no problem. I'm saying that if people are going to complain, they have to be right about their complaints first.
Linux-based and Open Source guarantee only that you see the source. It doesn't not have any guarantees about where you can run it.
I gotta ask. Have you bought one? Have you used one? Have you watched the videos of somebody using one?
I watched some of the videos and I was appalled at how bad the software stack is. Then I read some of the comments regarding the state of most of the distros and it sounds like there isn't one that can be reliably used as a phone. There's no way I'd shell out for one of those unless I specifically wanted to work on a phone stack and not apps. If I wanted to develop apps, I'd get Android or iPhone.
I must chime in that I applaud the FSF's effort in this event in that: 1) they did not use guerilla tactics 2) they dealt with SGI on friendly terms 3) and most importantly, did not appear to force the use of the GPL.
In light of the crazy bad ideas that they've attempted recently (like DDOSing Apple stores), I consider this a sign that they're willing to attempt to regain my trust.
Slashdot Mirror
Disclaimer: I used to handle transport and build of localized resources at a software company using Mac and Windows.
I've never seen this behavior before on a Mac. The general rule for me was "if I can see it right on screen in TextEdit, it'll reach paper fine."
Here's what I'd do.
If you got UTF-8 text files, open up TextEdit.app and try both auto and UTF-8 selections for the data type.
Then hit cmd-P and it should be exactly what you see on screen.
An alternative editor would be BBEdit.app which is more focused as a text editor rather than a basic word processor. Useful if your file turns out to be malformed or some format that TextEdit.app doesn't understand.
Seriously though, would that be a bad thing?
It's a new open firmware for a chipset, yet it excludes another open OS from using it? That kinda sucks.
You know, you might actually get better service with the 1 bar of 3G rather than the 3+ bars of GSM.
The thing is, 3G/UMTS is based off CDMA, which transports data in a way that supports more users in the area and has better reliability.
For the same reason that a call on Verizon/Sprint will sound perfectly clear even at a constant 1 bar, you might be doing pretty well with 1 bar on UMTS. You just might be trained into thinking "1 bar == crap" because of your experience using GSM.
Of course, you'd have to test it to be sure. I'm only speculating. I have both a AT&T phone and a Verizon phone and the AT&T phone just sucks in terms of connection reliability on 2G.
So enlighten me. What's the deal with OGG?
I mean, like, what does it get me that 256kbps MP3s don't give me?
Does anybody even make a hardware decoder chip for it?
So I went to the University of California, Berkeley as a CS undergrad.
Our CS lab facilities were mainly Sunrays linked to giant Solaris 8 boxes and Windows 2000. The staff seemed to be using a lot of Powerbook G4s, and eventually a smaller lab of G5s were built. And many students had their own Macs, Linux, BSD, and Windows notebooks as expected. I recall there was a Linux lab which some people overflowed to when the Sunrays were all taken up.
The thing is, people flocked to their machines of choice. Most often, it was what was most familiar or what they knew would get the job done best.
Students understood that the G5 lab was replacing one Windows lab for computer graphics classes. So if you were in xyz class and wanted to do OpenGL work but didn't have a sweetass machine at your apt, you went there or the neighboring Windows lab.
If you're in the OS class and wanted to test your threading implementation, the sunrays linked to the 12 processor machine was your best bet.
If you were starting out in CS61a and needed to run Scheme/Lisp, you could go anywhere and instructions were published on the class site for all three major platforms. (Solaris, OSX, Win2k)
In the end, a computer for most people is a tool. The right tool for the job depends on the job, and how much proficiency you have in using it. While I think there's a benefit to FOSS, I don't see its benefits as grandly as you do. I do however highly recommend a diverse ecosystem of platforms available.
Here's why: With respect to education, when it comes down to it, your choice of OS and platform does not matter. You are in school to learn the theory of operation of these machines, not how to use them. You are driven not by a passion for programming, but a passion for learning and the desire to get out of here alive. You recognize that as a student, you have no spare time for open source projects, because your sleep debt will kill you first. Everything that makes your life as a student easier will be more important to you for your 4 years there as an undergrad because, unless you're a total slacker (and wasn't going to graduate anyways), you are devoted to learning your trade and profession with your 18 hour class/study/project days.
We all acknowledge that Linux isn't the easiest OS to use or maintain. Every minute you spend having to deal with the little unexpected quirks of your tools costs you important time. Increasing the possibility that a student will not make their project on time because you suggest they try a new OS takes away from their education about what is ultimately more important at school than FOSS: learning about computer sciences.
Having a lecture talking about FOSS: Good.
Promoting Linux as a way to save yourself the cost of an OS: Bad.
With that said, I am so thankful that the Sunray labs were there because outside of the few macs, those things were so damn reliable, and I'm glad that those who primarily used Windows at home could see how little maintenance needed to be done on a properly designed platform.
The fact that you can go to a vendor site and download drivers and not have to recompile your kernel totally makes my day.
Just as a counterargument, for any business which depends on widespread external distribution, FOSS/GPL is considered dangerous if used incorrectly.
Just because it's FOSS doesn't mean Google has a good reason to pick it up.
On the other hand, x86? Really? Who in their right mind thought that was a good idea?
In my opinion, the argument is valid.
For the common user, a pre-configured Linux and Windows computer from Best Buy or whatever does "work" out of the box. Since all the drivers are installed and the apps are installed, and fancy icons are available for the user to click on to launch apps. This applies to a Linux distro (say, Ubuntu), as well as a Windows distro (say, WinXP + Sony utilities + Office).
The problem comes when that computer needs to be customized to the user's needs.
The common user acquires software from various sources to augment the computer. I'd assume there's two main options.
Download from the net or buy it on a CD from Best Buy.
If I were to download a new piece of software for Ubuntu, there's two options. Package manager (pretty easy if it's there), or source archive.
I'm fairly sure most people won't know how to deal with a source archive.
And, there's no way for a software publisher to even make it as a CD. This is because there isn't any sort of standardization as to how to set up a good user experience during an install for an arbitrary distro. There is no easy way to make an executable that you can download that will put the app pieces in the right spot, and add a fancy icon to Gnome/xfce/KDE/blackbox/etoile/whatever. And then give you an option to uninstall. This is why the "install sucks" and "thousands of distros" sucks points are valid.
In Windows, you'd simply double click the exe or insert the CD and stuff will get set up. It doesn't matter who customized it. It could be beigebox, Sony, Dell, Compaq, etc. The fact that this can be done for a driver CD shows why a more solid kernel ABI is important. Even the latest OpenSolaris can take old Solaris x86 drivers.
If there's no way of making a easy way for commercial vendors to distribute apps, there's no way they'll consider making the apps. Want to see how powerful a uniform distribution system is? Just look at the iPhone App Store.
And while I'm at it, X sucks because configuration is a pain, direct rendering is a total hack, and instead of a nicely architected data pipeline, it's some giant tree of modules all centered on a single configuration file. Oh, unlike Windows safe-mode vga, there's no always-functional-vga failback mode.
Actually, I think that the status quo is exactly how everybody essentially seem to want it. (based off priorities)
People who care about stuff working out of the box migrate towards OSX and Windows.
People who care about tinkering migrate towards open source.
People who care about free software and pushing people who don't care about software freedom to use free software, lose out for the proper reason: those who don't care, simply don't care. Those who do care, still care more about effort/functionality.
People who care about widespread use of Linux on the desktop won't ever win because this goal is not the priority of FOSS advocates, nor the priority of those who create the distros, nor the developers working on key pieces of various distros.
*coughALSAOSSESDaRtsJACKGStreamerPulseAudioWrappers*
Man, that sounds pretty bad there. Have you seen a doctor?
I think it depends on how you want to approach it. If you're talking about all computer users, probably well less than 0.1 percent.
If you're talking about Linux-only users, probably a significant number since all the ones who care about stuff working left for Mac OS X, FreeBSD, or OpenSolaris since they at least have stable kernel ABIs.
It's unfortunate, but you're right that their use of Halliburton doesn't seem justified to me either.
Additionally, the fact that the war happened in the first place says there's some major corruption issues in the entire gov leadership.
Keep in mind that the key customer table that you pointed me to is on a page specific to aerospace. If we were to look at this page: http://www.ghs.com/ConsumerProductsCustomers.html then we'd think HP owns them.
Clicking the "about us" link says they were founded in 1982 and were profitable since the beginning. This was well before the Integrity product launched, so I'm sure they had something good going for them for the previous 15 years. It could be military, it could be something else. But I don't see a clear military connection for a company that started it's product line with compilers and logic probes.
My opinion regarding military outsourcing and ownership is that if it's developed internally by the military, it should be shared with taxpayers as long as it's not a national security issue. It's the military. I have to assume that being the military, they'd want to have every advantage possible over any other military. So I would think that for the most important pieces, they'll do the R&D, but for anything that can be cheaply covered by commercial offerings, save the time and money and just buy it. If they decided it was more cost effective to buy it off the shelf or pay somebody else to develop it, then it's not ours. This would be simply because part of that discount in outsourcing is because it either leverages tech already developed or because the outsourced company still owns the tech.
I think should we own a part of NASA's tech and findings. But I don't think Garmin or SiRF owes me any source code just because their entire product lines depends on the military-developed GPS system.
You and the article are talking about Integrity-178B.
I'm saying GHS' web site and product info pages (www.ghs.com) says its a repackage of Integrity. (note, there's no 178B.)
In more detail: Integrity-178B is the same thing as Integrity trimmed down, an avionics added, and then the process of certifying the software suite and the customer's hardware together for DO-178B certification.
Both suites are EAL6+ certified since Integrity is EAL6+ certified.
The only code that could possibly be designed specifically for military use would be that avionics library.
I don't know for sure when or what the Integrity kernel was first launched or developed for, but considering we're talking about freakin' old company who developed embedded compilers, libraries, and debuggers back before the Macintosh was available, I see no reason to assume the OS core was built for a military contract.
The actual reason is that when the iPod was created iTunes already existed, and that the purpose of the iPod was supposed to be iTunes on the go and it was supposed to be easy.
Creating playlists on a USB mass storage device.... would not be easy.
Creating playlists on iTunes which centralizes all your personal music is pretty darn easy.
Additional reasons why include:
1) having the entire catalog of songs on an ipod indexed and ready to go makes startup time so much easier and faster.
2) having all the file names be 4 characters makes it smaller and fit into cache better. (remember, it's like, what? a 16 mhz primary CPU on the first ipod?)
There's no crazy conspiracies about lockdown and stuff. The itunes music store was years in the future when these design decisions had to be made. It's just simply better design when your focus is on the experience of using the thing. The proof is that it sold so well when almost nobody had firewire ports and so many mp3 players were usb mass storage devices.
Integrity for Avionics, the product you think you own, is simply a trimmed down version of Integrity, which is used in medical devices, industrial robotics, and other stuff like that.
After reading the product docs, the equivalent of what happened in the linux world would be: IBM starts with Ubuntu, and then the military asks "hey, can you make me a simpler version? I just want the bootloader, the kernel, and bash."
"All it does it make sure that memory from one container does not leak to another."
Doesn't this also mean, no kernel panics caused by application software?
Doesn't this also mean, no privilege escalation can take place by hacking any piece of application software?
This sounds pretty darn good to me when it comes to security in embedded devices.
I must say, with the mass storage example, I feel I have to differ.
Yesterday, I downloaded a brand new copy of System Rescue CD from www.sysresccd.org because, well, I needed to pull some data off several drives attached to a machine I wanted to remove Win2k from because win2k was blue screening on startup in a loop.
There's an internal drive, there's a USB drive, and a firewire drive. And the CD I booted from.
Booting into linux was a breeze, and once I logged in as root, I wanted to mount the firewire drive. /dev
Except, I couldn't figure out how.
lspci says it sees my firewire interface.
But no drives/partitions actually showed up at
Point is:
In Windows, it'd whine and complain and ask for a driver for my firewire card.
Once it has that, it'll whine and complain for a SBP2 driver for the mass storage device I just plugged in.
Once it has that, it'll mount the disk if it can.
If you fail at any of those points, you know what's next to try to fix.
In a distro of linux designed to access hard drives.... /dev, you're just kinda screwed.
I just happen to know that it knows of my firewire interface. (lspci)
But that's about it. If you don't see it in
Where do I go next? I mean, sure, I could recompile the kernel. I could recompile all the modules.
But really, that's like the "when in doubt, reinstall windows" catchall.
There's little I can actually do that leads me in the right direction towards fixing this.
It's not the first time these things happen to me. And every time, I just pick another livecd off the net and repeat until I see the drive I want, or disassemble the computer and pull the drive because both of those have had better chances of getting me to my goal than attempts to fix the problem.
With Windows, there's a list of steps that give me insight into what failed.
With Linux, I often times hit the catchall "reinstall the OS" instead of getting hints as to what to fix next.
This is why I see Linux as less usable than Win XP.
It's relevant only in that not all people know what their jailbreak utility is doing.
Some people may have inadvertently broken their hardware while jailbreaking because it also ran a bad unlock utility.
For those people, being rejected warranty service for a broken item is legit even though they don't understand that they themselves broke it.
So funny thing..... in iPhone software 1.1.1 many phones stopped working because the user ran jailbreaking tools that also unlocked their phones improperly.
AnySim unlocked the phone, but did so by corrupting data in a location normally secured by other code.
Apple's software upgraded itself as it was supposed to. However didn't account for corrupt data in an area which isn't normally touched and crashed.
The fault is AnySim no matter how you looked at it since Apple can't QA for unexpected changes in a nonwritable area.
Who got the flak for the broken phone? Apple did.
Here's the problem. USB 2.0 is only nearly equal.
"Nearly equal" is defined as comparing a moped (FW) to a 2-speed bicycle (USB2).
While USB 2.0 sounds pretty similar to Firewire, the reason it's used by people are pretty well defined.
USB 2.0 maxes out at about 25MB/sec while Firewire-400 maxes out around 40MB/sec when you're using the fastest bridges and chipsets for both and hooking up the same hard drive. While in the maxed out state, USB 2.0 takes 10% of a CPU time. While Firewire takes 1%.
USB 2.0 hardware can't guarantee latency. So when you have good audio equipment, all of them will not use USB 2.0 because audio will get out of sync or even drop a few samples, ruining a recording session.
USB 2.0 is master/slave. A USB master can only switch into slave mode if the hardware supports it, and none of the desktop chipsets do. Nor is it expected that they will. Perhaps Apple might push Intel to make a custom USB chipset, but that most likely breaks all the driver stacks too. This means that the target mode feature people are asking for won't come back.
With stuff like that, sure, it might be worth $1000 for people to buy a MBP, but that doesn't change the fact that they're angry for a good reason.
Actually, Linux wouldn't be that advanced.
Getting Target Mode to work over USB isn't as simple as writing the software. There's no guarantee that the nForce chipset nor any of Intel's chipsets (which contain the USB2 controller) supports the USB-OTG standard which allows a USB controller to work as both a master and slave.
USB is directional. One end has to be designed to control and negotiate the connection. The other end has to be designed to be controlled. Only some handhelds have chipsets which can switch from being the slave to being the master.
Firewire is peer-to-peer. Control over the conversation is negotiated between any devices that feel like it.
See... here's the thing that gets me.
You say: "People go on and on about how Android is Linux based and Open Source, but it's not."
Except, it is. Android IS Linux-based. Android IS Open Source. It annoys me when people say otherwise.
I'm not saying there's no problem. I'm saying that if people are going to complain, they have to be right about their complaints first.
Linux-based and Open Source guarantee only that you see the source. It doesn't not have any guarantees about where you can run it.
I gotta ask. Have you bought one? Have you used one? Have you watched the videos of somebody using one?
I watched some of the videos and I was appalled at how bad the software stack is.
Then I read some of the comments regarding the state of most of the distros and it sounds like there isn't one that can be reliably used as a phone. There's no way I'd shell out for one of those unless I specifically wanted to work on a phone stack and not apps. If I wanted to develop apps, I'd get Android or iPhone.
I must chime in that I applaud the FSF's effort in this event in that:
1) they did not use guerilla tactics
2) they dealt with SGI on friendly terms
3) and most importantly, did not appear to force the use of the GPL.
In light of the crazy bad ideas that they've attempted recently (like DDOSing Apple stores), I consider this a sign that they're willing to attempt to regain my trust.