Swallow that anti-Microsoft sentiment and get the god damned thing working.
It's far easier and technically the Right Thing to write a new ACPI layer from scratch and deal with the compatibility headaches, rather than to reverse-engineer Microsoft's ACPI code and try to emulate it, notwithstanding the legal issues involved. Why emulate a buggy closed-source competitor when the whole idea is to do it better?
It is worthless to support a standard that nobody implements.
You're out of your mind. Using your logic, there is no value in supporting any new standard, because at that point nobody has implemented it yet.
ACPI is a usable and solid platform; unfortunately it just so happens that the only vendor who embraced it from the very beginning has done a bang-up job of, well, banging it up. Netscape did a great job pissing all over HTML in the old days, and Microsoft followed them by pissing all over DOM and CSS. Does this mean that nobody should bother doing things the right way? How is progress made if everyone just follows the leader?
The linux ACPI project needs to figure out how Windows manages to work reliably and emulate that
<sarcasm>Sure, because reverse engineering a binary-only operating system is obviously the most efficient way for people interested in ACPI to spend their time.</sarcasm>
Anyway, this isn't an issue of "reliability". With few exceptions, the ACPI code works fine if your machine isn't broken. I run at least 10 desktop systems in ACPI mode and never have any ACPI-related trouble.
It's not as simple as that. A "standard interface" for drivers involves abstraction, which affects performance negatively. It also involves development and maintenance for a feature which no kernel developer will care about or use, sucking up time which could be used for more generally useful things. It constrains new developments because the stable interfaces must be maintained in order to be useful. Furthermore, as you mentioned, it goes against the preferences of the folks who are actually writing the code.
Implementing such a feature would be a pretty rotten bargain for their part, don't you think?
You're not trolling, but your last few words show a lack of understanding of the situation.
ACPI is an open standard, but unfortunately, vendors' closed source BIOS implementations for the last few years are written against the Microsoft ACPI parser, bugs and all. Consequently, many machines fail to work at all with the Linux implementation (written against the standard) unless kludges or more relaxed syntax checking are used. This is not a failing of the Linux ACPI implementation or the ACPI specification. It is a Windows interoperability issue.
It is unknown how many machines have bugs in their ACPI BIOS code. The only way the ACPI developers find these and special-case them is when users mail in their bug reports and DSDT (check here), because the developers don't have access to every machine on earth to perform testing on. Even when a bug is found, it can only be worked around, because most system BIOS in the field are no longer supported by the respective vendors. So you'll see messages from the ACPI layer regarding syntax errors or known bugs in a particular BIOS, which the developers are helpless to fix in any way other than a special-casing.
Even worse is that many ACPI BIOSes return different values depending on which OS the vendor's ACPI code thinks you're running. Most of the time, any BIOS code path other than for an OS which calls itself "WindowsNT" is broken, so AFAIK, all ACPI layers simply spoof themselves as "WindowsNT" to the BIOS to avoid problems. Rather sad, isn't it?
As a final note, some vendors like Tyan, HP, Intel, etc are extremely active on the ACPI and LinuxBIOS mailing lists. HP has fixed ACPI-related bugs in their system BIOSes due to the Linux ACPI code rooting them out.
So the moral of the story is, don't assume poor ACPI operation on a specific machine is the fault of the Linux ACPI project. More often than not, it's the fault of the BIOS vendor not caring to implement the standard correctly beyond what it takes to get Windows up and running on the machine, which doesn't correspond 1:1 to whether or not they've implemented the standard correctly.
Personally, I think Linux should allow binary drivers. Most hardware is useless in a few years anyway, so what good is having the source? Compare that to the OS, where it can live on for decades.
Linux still runs on hardware which is older than Linux. There is nothing inherent in the hardware which causes it to be "useless" after a few years. It is only useless when it is impossible for the individual user to support its use, and this typically happens when the manufacturer loses interest in your platform or when the new (and sometimes improved) generation of hardware shows up.
Unfortunately, the new generations of hardware are not always improved from the end user's standpoint. Modems, network devices, low-end sound, and keyboards are a few examples where manufacturers cripple newer products in order to sell for a lower price and gain volume.
A common tactic is to move hardware functionality into software to save engineering costs and material costs. Frequently, this inconveniences the user even while the product is being supported by the manufacturer (I don't know of anyone who hasn't complained about a Winmodem at some point or another), but thanks to trade secrets and braindead software copyright law, as soon as the manufacturer disappears, the hardware that the user paid money for becomes useless. Not because it's obsolete, or defective, or incapable of performing to specification. It's because the manufacturer didn't care enough to give others the necessary tools to fill in for them, once they decided supporting their products (or staying in business at all) was too expensive for them.
That's not really a fair bargain for individual users who don't throw their single PC away and buy a new one every three years, which is why we would like to discourage the practice of maintaining binary-only drivers in favor of open-source ones. Having to change hardware because the manufacturer's business plans changed *after the date of purchase* is not something that leaves a good taste in my mouth.
You're welcome to disagree, but the vast majority of kernel hackers are taking the opposite position, and they're the ones writing the code.
Regarding software copyrights, I think software authors should be entitled to copyright on their binary code only if they place the corresponding source code in escrow with the Library of Congress. That way, when the company dissolves or the copyright expires (heh), the public actually gets something useful in return, as opposed to rights to an indeterminate binary blob with piles of unfixed bugs and design issues that has to run in a legacy emulation environment or on suboptimal hardware.
Yes, especially when Microsoft walked off the OpenGL ARB after securing SGI's OpenGL-related patent portfolio. What to do next was a very good question at that point.
Hmmm... now I'm thinking of Lindows. Why didn't that make a difference?
Now you're hitting on it: it's because the cards were stacked to begin with. Reveal Microsoft's secret file formats, APIs, and network protocols, and release the OEM stranglehold for preinstalls, and you might see some competition in the OS market.
P.S. It's the same reason BeOS didn't make a difference. No install base, and no way to achieve one.
(i.e. hassle people at work and cop 'superior' cuz you're running ewe-nicks).
I hassle people at work because inferior operating systems waste hours of my time every day. Why is it zealotry to suggest that something else might be better? Maybe the person doesn't even know they have a choice in the matter before I mention it.
And incidentally, Linux (but Linux isn't plug n play....hack around...text configuration files....modprobe drivers....cryptic....CLI...difficult)
Try discover+hotplug. Works fine for me. Only things it doesn't pick up are ISA cards without PNP. Unfortunately there's no "add new hardware" detection wizard for Linux, but that's okay because this hardware is increasingly hard to find these days.
Realtek network cards are great, cost as little as $2.00 each. They never break.
They also have atrocious busmaster performance due to broken design. Use RTL8139C+ or else get a Tulip instead.
Ditto the $10 internal modems,
Winmodems -- real useful.
$7.50 sound cards,
Sure, if you consider a 90dB S/N ratio good, or don't mind your CPU doing PCM streams mixing instead of other work.
Hard drives - different story. Quality control is slipping amongst all the manufacturers, but Maxtor by far is the worst.
My Western Dig and Seagates still run like champs.
Maxtor - We've found some bad blocks. Please backup all your data and RMA the drive. WDC - ka-click, ka-click, ka-click, ka-click....
Ribbing aside, anyone who intentionally buys a hard drive with a 1yr warranty from a mfg who also offers drives with a 3yr or 5yr warranty should have their head examined. You get what you pay for with respect to hard disk longevity.
WTF are you talking about? Name the last time the syscall interface changed. I believe it was in the 1.x days. That's the only place binary compatibility has broken with respect to Linux.
With gcc 3.x, C++ linkage was changed from 2.x to comply with the standard C++ name mangling. The benefit is that GCC-compiled object code can interoperate with object code from other vendors. The drawback is that binary compatibility was broken and required all C++ shared libraries to be updated. This is not a problem with Linux, this is a problem with the GNU toolchain which also affects *BSD, etc. But everyone got on the bandwagon and called it a Linux problem for some reason, propagating an incorrect assertion.
Guess what? Many of the machines D-I supports don't even have a framebuffer console. A text-based setup is the lowest common denominator for all the machines that the Debian can run on. There are install images with PGI for i386 only, if you just have to have that eye candy.
Linux has to have a desktop that is intuitively written and not too different from the Windows menu system.
Oh, it "has to", eh? Pray tell, why? Is it because Windows is the be-all end-all of graphical user interfaces? Is it because Windows has some kind of technical advantage over GNOME and KDE? Or is it simply because armchair software designers like yourself believe that their unfounded opinions are somehow supposed to be convincing to people who actually have a background in human-computer interaction and software engineering?
In other words, if you have arguments as to why an emulation of Windows is the best approach for someone designing a new desktop environment GUI, please present them in a coherent matter-of-fact manner. Otherwise, don't be surprised when nobody pays you any attention.
This is just a simple bug -- but its been around sice I first used mozilla, over 2 years ago. So shut up about stupid IE not being perfect, K?
Yes, and I suppose it would take too much effort on your part to file a bug report. Wait, then you wouldn't have things to bitch pointlessly about on slashdot.
Of course Debian users will argue "well, just do an apt-get install foo", and Gentoo people will tell you to use emerge, but the point for Joe User is not to have to use the command line.
Well, maybe you'd best try Knoppix and lay those fears to rest. It's not your fault that Red Hat doesn't produce working code, but it makes for an unconvincing argument when you generalize based on a single experience.
It pisses me off to no end when people proclaim Debian to be the most stable (in reference to the stable branch) and most up-to-date (in reference to unstable). It's the most stable OR the most up-to-date, not both.
This is a false dichotomy if you are aware of the existence of the 'testing' distribution.
Many older PC memory controllers don't cache more than 64MB of system RAM. In the case that you want more than 64MB of RAM, the net result will usually be a slowdown in overall performance due to the kernel running out of uncached memory (it is loaded at the top of memory).
The solution is the slram MTD driver. Pass mem=64M to the kernel to force it to load within the cached region, and then use slram to allocate the rest of system memory. This gives you a block device which you can use as a scratchpad, tmpfs, or even better, a swap area! Swapping to RAM (even uncached RAM) is much faster than swapping to disk in any case. I did this on my Toshiba Tecra 500CDT. The system has 144MB RAM but only 64MB is cacheable. It runs like a champ, and I don't need a swap partition on disk this way.
The first time I described this idea to someone, he thought I was crazy. I realized why the reaction was such. Just think if you told someone that the magic secret to speeding up your system is to "put your swapfile on a RAM disk"...
Some LDs contain Dolby Digital or DTS sound. DTS sound is available on the standard optical digitial audio out but DD sound comes from an RF modulated connection that you can't just stuff into a digital input. You will need an RF demodulator which then provides standard digital audio.
An additional bit of trivia is that there are 4 audio tracks on a typical laserdisc. Two of these are analog tracks and two are digital. The analog tracks are provided as a fallback in case a player doesn't support digital audio tracks.
On a DTS laserdisc, the digital tracks are used for DTS encoded audio. So if you have a player which supports digital audio but no DTS decoder, you are stuck listening to analog tracks.
On a AC-3 laserdisc, the digital stream is RF modulated into the right analog track. So if you have a digital player but no AC-3 decoder, you can at least get Dolby Surround from the digital tracks, but no Dolby Digital. If you have a player which is analog only, you get only a mono analog track. Worse, if you have a player which not only doesn't read digital tracks but isn't even AC-3 aware, you get the one analog track on the left side, and a hideous screeching on the right side.
I don't remember if any actually existed, but it would be possible to have a LD with both AC-3 and DTS audio. The problem is that if you don't have a DD or DTS decoder, instead of falling back to Dolby Surround, or even to stereo analog, at best you get one analog channel, and at worst you might have to deal with screeching.
Any wonder why LD was rejected by consumers? Besides the inconvenient size of the media, short lifespan due to oxidation of the reflective layer of many mass-produced discs, composite video, and complex equipment which had high production costs. Oh, and having to flip/change discs multiple times in the middle of a movie, though some high-end players would omit the flipping stage by reading both sides. Some LD players doubled as 5-disc CD changers though, like the one I have (Pioneer CLD-Mxxx series); that's rather convenient in terms of rack space, but still nothing like the storage density of a DVD. Too bad my DVD collection has begun to rot with oxidation too:-(
I don't understand why you are whining about helping out the poor guys (software industry that cannot fight ms)
Where did I whine about that? Gates broke the law to make his billions. Plain and simple fact. Does the law not apply to charitable men?
and at the same time frown on helping some "backward nation" (FYI that term is often considered derogatory)
It's not our fault that their people refuse to overthrow dictatorships or to prevent them from being installed in the first place. It's not like we wouldn't help them if they tried. Why should we prop up a system which is inevitably doomed? Feeding the hungry foreign nationals only ensures that they will be comfortable with their current miserable situation for that much longer instead of organizing a revolt.
On another note, I may be a sniveling gates worshipper but rest assured, with your level of compassion for your fellow man, noone will ever worship you.
You're just whining and promoting a double standard. If I made as much money as Gates, I'd be investing it into wiser things than buying loyalty. My money would go towards research to increase the standard of living, and to education institutions worldwide. His money just buys him boot-lickers, both from people who are in tough situations in other countries, and people like you who assign to them none of the blame for their situation. They're just poor helpless victims! We _owe_ them our support, and the largest Microsoft shareholder is supporting them, ergo we should be proud to give our money to Microsoft. Give me a break.
I'm not cold and heartless. I just expect people to beg for their handouts if they really want them. None of this Robin Hood crap. It just fosters a cycle of dependence which continues into the next generation, instead of motivating people to fix the underlying problems in their societies.
Slashdot Mirror
ACPI is a usable and solid platform; unfortunately it just so happens that the only vendor who embraced it from the very beginning has done a bang-up job of, well, banging it up. Netscape did a great job pissing all over HTML in the old days, and Microsoft followed them by pissing all over DOM and CSS. Does this mean that nobody should bother doing things the right way? How is progress made if everyone just follows the leader?
<sarcasm>Sure, because reverse engineering a binary-only operating system is obviously the most efficient way for people interested in ACPI to spend their time.</sarcasm>Anyway, this isn't an issue of "reliability". With few exceptions, the ACPI code works fine if your machine isn't broken. I run at least 10 desktop systems in ACPI mode and never have any ACPI-related trouble.
Implementing such a feature would be a pretty rotten bargain for their part, don't you think?
ACPI is an open standard, but unfortunately, vendors' closed source BIOS implementations for the last few years are written against the Microsoft ACPI parser, bugs and all. Consequently, many machines fail to work at all with the Linux implementation (written against the standard) unless kludges or more relaxed syntax checking are used. This is not a failing of the Linux ACPI implementation or the ACPI specification. It is a Windows interoperability issue.
It is unknown how many machines have bugs in their ACPI BIOS code. The only way the ACPI developers find these and special-case them is when users mail in their bug reports and DSDT (check here), because the developers don't have access to every machine on earth to perform testing on. Even when a bug is found, it can only be worked around, because most system BIOS in the field are no longer supported by the respective vendors. So you'll see messages from the ACPI layer regarding syntax errors or known bugs in a particular BIOS, which the developers are helpless to fix in any way other than a special-casing.
Even worse is that many ACPI BIOSes return different values depending on which OS the vendor's ACPI code thinks you're running. Most of the time, any BIOS code path other than for an OS which calls itself "WindowsNT" is broken, so AFAIK, all ACPI layers simply spoof themselves as "WindowsNT" to the BIOS to avoid problems. Rather sad, isn't it?
As a final note, some vendors like Tyan, HP, Intel, etc are extremely active on the ACPI and LinuxBIOS mailing lists. HP has fixed ACPI-related bugs in their system BIOSes due to the Linux ACPI code rooting them out.
So the moral of the story is, don't assume poor ACPI operation on a specific machine is the fault of the Linux ACPI project. More often than not, it's the fault of the BIOS vendor not caring to implement the standard correctly beyond what it takes to get Windows up and running on the machine, which doesn't correspond 1:1 to whether or not they've implemented the standard correctly.
Unfortunately, the new generations of hardware are not always improved from the end user's standpoint. Modems, network devices, low-end sound, and keyboards are a few examples where manufacturers cripple newer products in order to sell for a lower price and gain volume.
A common tactic is to move hardware functionality into software to save engineering costs and material costs. Frequently, this inconveniences the user even while the product is being supported by the manufacturer (I don't know of anyone who hasn't complained about a Winmodem at some point or another), but thanks to trade secrets and braindead software copyright law, as soon as the manufacturer disappears, the hardware that the user paid money for becomes useless. Not because it's obsolete, or defective, or incapable of performing to specification. It's because the manufacturer didn't care enough to give others the necessary tools to fill in for them, once they decided supporting their products (or staying in business at all) was too expensive for them.
That's not really a fair bargain for individual users who don't throw their single PC away and buy a new one every three years, which is why we would like to discourage the practice of maintaining binary-only drivers in favor of open-source ones. Having to change hardware because the manufacturer's business plans changed *after the date of purchase* is not something that leaves a good taste in my mouth.
You're welcome to disagree, but the vast majority of kernel hackers are taking the opposite position, and they're the ones writing the code.
Regarding software copyrights, I think software authors should be entitled to copyright on their binary code only if they place the corresponding source code in escrow with the Library of Congress. That way, when the company dissolves or the copyright expires (heh), the public actually gets something useful in return, as opposed to rights to an indeterminate binary blob with piles of unfixed bugs and design issues that has to run in a legacy emulation environment or on suboptimal hardware.
P.S. It's the same reason BeOS didn't make a difference. No install base, and no way to achieve one.
WDC - ka-click, ka-click, ka-click, ka-click
Ribbing aside, anyone who intentionally buys a hard drive with a 1yr warranty from a mfg who also offers drives with a 3yr or 5yr warranty should have their head examined. You get what you pay for with respect to hard disk longevity.
With gcc 3.x, C++ linkage was changed from 2.x to comply with the standard C++ name mangling. The benefit is that GCC-compiled object code can interoperate with object code from other vendors. The drawback is that binary compatibility was broken and required all C++ shared libraries to be updated. This is not a problem with Linux, this is a problem with the GNU toolchain which also affects *BSD, etc. But everyone got on the bandwagon and called it a Linux problem for some reason, propagating an incorrect assertion.
In other words, if you have arguments as to why an emulation of Windows is the best approach for someone designing a new desktop environment GUI, please present them in a coherent matter-of-fact manner. Otherwise, don't be surprised when nobody pays you any attention.
The solution is the slram MTD driver. Pass mem=64M to the kernel to force it to load within the cached region, and then use slram to allocate the rest of system memory. This gives you a block device which you can use as a scratchpad, tmpfs, or even better, a swap area! Swapping to RAM (even uncached RAM) is much faster than swapping to disk in any case. I did this on my Toshiba Tecra 500CDT. The system has 144MB RAM but only 64MB is cacheable. It runs like a champ, and I don't need a swap partition on disk this way.
The first time I described this idea to someone, he thought I was crazy. I realized why the reaction was such. Just think if you told someone that the magic secret to speeding up your system is to "put your swapfile on a RAM disk"...
On a DTS laserdisc, the digital tracks are used for DTS encoded audio. So if you have a player which supports digital audio but no DTS decoder, you are stuck listening to analog tracks.
On a AC-3 laserdisc, the digital stream is RF modulated into the right analog track. So if you have a digital player but no AC-3 decoder, you can at least get Dolby Surround from the digital tracks, but no Dolby Digital. If you have a player which is analog only, you get only a mono analog track. Worse, if you have a player which not only doesn't read digital tracks but isn't even AC-3 aware, you get the one analog track on the left side, and a hideous screeching on the right side.
I don't remember if any actually existed, but it would be possible to have a LD with both AC-3 and DTS audio. The problem is that if you don't have a DD or DTS decoder, instead of falling back to Dolby Surround, or even to stereo analog, at best you get one analog channel, and at worst you might have to deal with screeching.
Any wonder why LD was rejected by consumers? Besides the inconvenient size of the media, short lifespan due to oxidation of the reflective layer of many mass-produced discs, composite video, and complex equipment which had high production costs. Oh, and having to flip/change discs multiple times in the middle of a movie, though some high-end players would omit the flipping stage by reading both sides. Some LD players doubled as 5-disc CD changers though, like the one I have (Pioneer CLD-Mxxx series); that's rather convenient in terms of rack space, but still nothing like the storage density of a DVD. Too bad my DVD collection has begun to rot with oxidation too :-(
I'm not cold and heartless. I just expect people to beg for their handouts if they really want them. None of this Robin Hood crap. It just fosters a cycle of dependence which continues into the next generation, instead of motivating people to fix the underlying problems in their societies.