Originally posted by: Nothinman
You can thoroughly customize XP and Server 2003 installations with preinstalled apps, drivers, and configuration settings.
I know, but that doesn't take away from the fact that the only way to load storage drivers during the interactive install is via a f'ing floppy. And most people aren't going to through that hassle even though just about every install needs to use a floppy now that so many people are installing onto SATA drives.
Again, the "so many people installing onto SATA drives" to which you refer are roughly 1% of the Windows user base. The rest of the SATA users (who probably don't even know they're SATA users, like my parents and their new Dell), don't ever install a system using Windows Setup. At worst, they would utilize the WinPE image-based recovery method provided by their OEM
if they needed to reinstall. System builders are considered savvy enough to utilize the floppy drive. And again, I think we recognize many of setup's problems, and should be improving the situation dramatically with Longhorn. Now if we can only ship the darn... (oops, did I say that out loud?)
The only place I can think of off the top of my head that Linux lacks good support in right now is wifi and that's because the manufacturers require binary-only firmware to be uploaded upon device init and just generally aren't playing nice with the Linux kernel devs.
That's an over-simplistic summary, wouldn't you agree? Loading device functionality as firmare at driver initialization is an increasingly popular driver implementation for obvious reasons. It cuts hardware development time and permits hardware 'firmware' fixes via driver updates. The fact that device vendors do not wish to give out their firmware code to open source developers should come as no surprise to anyone who has worked at that level of device development before. And this is not just wifi: there are new generations of audio devices, video devices, and even traditional imaging (printer/scanner) devices moving this way.
Luckily the Intel developers are working with lkml to get whatever chipsets are used in the Centrino stuff working even though it still requires a binary-only firmware to be uploaded to the device.
Isn't that sort of like treating the symptom rather than treating the problem? Last time I checked, the vast majority of laptops out there were not Centrino-based. And with laptops now comprising more than 50% of all system sales, this headache will only get worse for linux until a better solution is found.
The Linux community should embrace closed-source drivers in a big way. There is way too much argument about this from the kernel guys. There are still people out there adamant about forcing driver vendors to give out their code. This makes device vendors nervous, and it ain't gonna happen.
ACPI will be a major hurdle though since so many manufacturers don't test on anything other than Windows and don't follow the standard as they should, for example ACPI works but it always says it's (dis)charging at a rate of 0. Is there a way to get that info in Windows? I poked around a bit and couldn't find it in the OS nor could I find any 3rd party tools.
You can use
WMI to get just about everything that ACPI exposes. If no tool exists, you can write a VBScript command shell script to get it in about 10 lines of code. But I'm not sure exactly what ACPI quantity you're referring to.
Yes there is, it's just not included in the Linus kernel.
Ah, I didn't know about it. Linus was always so adamantly opposed to kernel debuggers that I never thought it would happen... I don't know much about it (and I'm prohibited from playing with it now)... what kind of host/target setups does it support? Is it fully aware of the kernel data structures? And does it support live kernel debugging (single-system)?
But even without it the lkml devs seem to do just fine with the normal oops backtrace because they know how the kernel works and since the source is there it's easy for anyone to determine what's going on and where the breakage is.
Nah, I don't buy that. That's like telling people writing regular user-mode apps, "You don't need a debugger: you have your source code!" After all, the point of a kernel debugger is not to help write the kernel: it's to help driver vendors write device drivers... Linus used to call a kernel debugger an "unnecessary crutch", but that's exactly why people use debuggers: to help them solve tricky problems.
And people still don't do it well, ironic eh?
It is, indeed. Some of the mistakes I've seen would astound you. From major vendors, no less. But using the international crash dump data from OCA has helped tremendously. We've helped many vendors locate and fix lots of bugs in their drivers that millions of Windows users hit daily.
And all without forcing device vendors to open source anything.
Facebook
Twitter