Free/Open Source Software Hardware Requirements? 228
Bender asks: "Most on Slashdot seem to be concerned with getting Free/Open Source software to be compatible with hardware (firmware, register sets, etc). My question is from the other side of the table: I'm in the hardware business and I'm wondering if there are any central guidelines to better guarantee compatibility with Linux/*BSD. As an example, to guarantee that our hardware runs Microsoft Windows, we have to conform to the Windows Logo Program Requirements. These requirements dictate (among other things) firmware interfaces, debug ports, and DRM. Some of these requirements, if not implemented carefully, could trigger incompatibilities with non-Microsoft operating systems. Is there a Linux/*BSD equivalent to the Microsoft requirements to allow hardware designers to build OS agnostic systems?"
This is no problem.. (Score:5, Informative)
Re:This is no problem.. (Score:5, Insightful)
If you release complete documentation of said hardware ...
True. The trend seems to be that many F/OSS projects prefer to develop the drivers themselves (as it assures them a known level quality from reliable developers). That is not to say they don't trust the developers in many hardware companies. But let's face it, a EE sometimes makes a crappy programmer (and I have pleny of EE-wielding friends that work for hardware companies and end up getting pressed into service writing drivers for hardware when they would rather be designing the next batch of hardware).
Failing that, as long as the F/OSS people can QA the stuff and suggest modifications it will eventually make it in. This can be seen in the all the back-and-forth between the Linux kernel developers and SGI over getting support for XFS into the kernel, which ultimately resulted the XFS patches getting accepted into Linus' tree.
Perhaps release a F/OSS reference driver (Score:2, Insightful)
Your company almost certainly doesn't want to provide support for the driver itself (for each of the OS's, etc) - but just putting out the reference driver with the conditions that it works (i.e. "this was only tested on the 2.0 kernel running Caldera Linux") can help people with the clues they need
It also helps... (Score:5, Insightful)
It's not enough to release your own closed-source driver for one architecture (like nvidia and ati do) because this locks out people on other architectures and later kernel versions.
Re:This is no problem.. (Score:5, Insightful)
Way to sidestep the question. It sounds as if the original author wants his system to just drop in and work. You suggesting that he document and let others fix a problem that shouldn't have occured in the first place.
Re:This is no problem.. (Score:3, Insightful)
You have to recognize, though, that it can be difficult for hardware producers to write drivers that run on every conceivable version of *n*x; there are so many different combinations of hardware and kernel options that it quickly gets messy. It's much better for hardware manufacturers to release specifications for their hardware--publish what the chip does when it receives signal x on pins 20-25, and what the significance of the output of pins 30-39 is. Then, let the driver writers for the various operatin
I doubt that is the question. Much less the answer (Score:5, Insightful)
I think he wants to know how to select parts that will work with Linux and BSD not how to build parts that will work with them.
If so it is a very good question. How would a hardware integrator know what Video, SATA card, Raid controllers, and motherboards to use?
Interface Documentation (Score:5, Insightful)
Re:Interface Documentation (Score:4, Informative)
And if you're looking for something to feed your marketing department, check out the applications for certification on major distro vendor's sites.
Mandrake: http://www.linux-mandrake.com/en/hardware.php3
(
RedHat:
http://bugzilla.redhat.com/hwcert/
(a
Those processes will probably get you a shiny logo for your product's box.
Re:Interface Documentation (Score:2)
That having been said, it's better to have potentially usable software than no software at all.
Well... (Score:5, Insightful)
Complete and freely available documentation.
If your product is really wanted, people will adapt (look at how hard people try to do this with things like reverse-engineered open-source drivers). If you freely provided complete documentation on your hardware, it would make it several orders of magnitude easier for developers to write software for your hardware.
Re:Well... (Score:4, Interesting)
Documentation available under NDA is useless for open source (publishing the source itself will likely break the NDA).
Re:Well... (Score:5, Insightful)
It is, however, not preferred.
The preference is that the necessary documentation be freely available, and even, redistributable, so that it can accompany the source if it would be beneficial.
Re:Well... (Score:2, Insightful)
Not really.
Not unless the SOURCE for the drivers can be distributed under a F/OSS license. (and if an NDA it went that far you may as well rename it a DA"Disclosure Agreement")
Re:Well... (Score:2)
I guess distributing binary drivers make so little sense to me I totally ignored the idea.
Re:Well... (Score:4, Interesting)
Here's how I see it, NDA is bad, nothing done under an NDA is worth using. Because if you have work done under the NDA and you stop working on it, noone else has the documentation you signed an NDA for and therefore cannot maintain the code.
NDA work being released is almost as bad as a binary.
Only if noone else can sign the NDA... (Score:2)
Of course, well commented source code and NDAs are almost a contradiction in terms. Even if you strip all comments, you could still trace each function and variable to what it does with the hardware. Any obfuscation of those would be a breach of the GPL, I believe.
Kjella
Re:Only if noone else can sign the NDA... (Score:2)
But then, this isn't about the GPL, it's about code and the NDA. If you don't have the documentation for the hardware you cannot be sure what you do to the code is right.
Re:Only if noone else can sign the NDA... (Score:3, Insightful)
Depends on how you look at it. Sure, if you work with the obfuscated code in the normal course of development then that's fine. But developing it "normally" and then obfuscating it for release is technically a violation. The source code is defined as "the preferred form of the work for making modifications to it." If you're releasing anything as "source code" other than what you work with, then that's not the "preferred" form.
Re:Well... (Score:2)
It can be made to be workable, if there is a need for it on the hardware vendor's side of things. (Some people do have contractual obligations that complicate this!)
Re:Well... (Score:4, Insightful)
You're kidding right? Basically every component of my computer has crashed windows at one point in time.
Faulty 3d drivers, crash the thing going from a D3d game to desktop.
Faulty hauppage drivers lock up the tv viewer and can make the machine unstable
Faulty cpu drivers [I kid you not] from via for the AMD64 make it crash on bootup [don't have my exact mobo model off the top of my head but it's an ASUS K8V I think].
Granted things work [for the most part] more smoothly in windows but that is ONLY because they write drivers for it. If they spent event a quarter of their time/money on Linux/BSD drivers we wouldn't be having this conversation.
Tom
Re:Well... (Score:2)
Dude, whoever built and looks after your computer is doing a really shitty job of it
Re:Well... (Score:2)
Though I readily admit I'm incapable of using windows for long periods of time. Outside of nix/linux I get a strong hate of all mankind cuz the OS is just so damn crippled...
In anycase I'm running a Gentoo AMD64 box [in 64-bit mode no less] using all the hardware I had running in windows with ZERO problems. I have yet to actually crash my box.
Can't say that for Windows.
tom
Re:Well... (Score:4, Insightful)
Dude, whoever built and looks after your computer is doing a really shitty job of it :-)
I can't comment on his computer, but something causes Windows to crash, and I have one computer that doesn't want to run it. The machine is a K6 without anything fancy - fairly vanilla stuff with an ATI Rage 128 card. It won't (actively) run Windows 98 (that was the last time I tried) for more than 30 minutes without crashing. However, it has run every version of Mandrake Linux from 7.2 to 10.1 without problems.
When using Windows, it would run for hours as long as you didn't actually do anything like open a program or use the mouse. When I did try to use Windows, it would crash at seemingly random times, and not a BSOD either - it would freeze solid or give a black screen. One person suggested the power supply was marginal and just wasn't enough to support Windows, but I find that a bit hard to believe. In any case, I can vouch for the fact that Windows has problems with certain hardware when Linux doesn't.
Re:Well... (Score:2)
Sure it "works" in winxp
Tom
Re:Well... (Score:3, Insightful)
Sure it "works" in winxp
Let me guess.. you click through the "these drivers have not been signed" warnings, don't you?
That warning means that the drivers haven't been through Microsoft's WHQL driver testing procedures. Which means that you deserve whatever you get.
Re:Well... (Score:2)
Let you in on a little hint buddy, even nvidias drivers have that warning...
It shouldn't be upto a little logo to say whether it's tested or not... That's my whole friggin point.
Just do a good job at writing the drivers and making the hardware. Quality can often speak for itself [e.g. ATI is usually faster but yet people still buy nvidia... imagine that].
Tom
Re:Well... (Score:3, Insightful)
No they don't.
http://www.nvidia.com/object/winxp_2k_71.
"Version: 71.84
Release Date: March 11, 2005
WHQL Certified"
Know what that last line - WHQL Certified - means?
Well, for starters, it means you're talking through your hat.
Re:Well... (Score:2)
2005.03.21 : YES
2004.11.09 : YES*
2004.07.27 : NO
2004.04.01 : YES
2004.03.15 : YES*
(*) Not certified for all GPUs
You just got amazingly lucky that this discussion came up at exactly the right time to point that out. Some of us have to update our video drivers slightly more often than that to resolve bugs and other issues. I
To make it work with linux... (Score:5, Interesting)
Re:To make it work with linux... (Score:2)
Re:To make it work with linux... (Score:5, Funny)
Re:To make it work with linux... (Score:2)
Legacy, Ick (Score:2, Insightful)
Microsoft tries to commoditise the hardware (Score:2)
Software compatability. If a customer buys and application it will run on the device. This is partially a customer thing, but is also an MS thing since it encourages lock-in to MS.
Make the hardware all the same: Makes life easier for MS to write/maintain their code as well as allowing MS a leash on how they're steering the indus
Re:Legacy, Ick (Score:4, Interesting)
I fail to see why office or home applications should dictate a particular architecture. Gaming and lab work are probably the only things which may be picky, due to bus speeds. The AMD64 is a nice start, but when can we exepct some of the other housecleaning of PC design? All I've got on my desk at home is very souped up PC-XT. Meanwhile some really good architecture has died along the way as everyone fought to support quite possibly the most exasperating legacy beast, just like everyone else. Moo.
tricky questions.. (Score:2, Funny)
After all, this seems like there will be a 'right' answer to this question, and where's the fun in that?
Follow published standards (Score:5, Informative)
just make documentation available (Score:5, Insightful)
The real key is to make documentation available to OS developers, preferably without an NDA. Pretty much everything else can be worked around--a lot of the main OS developers are pretty bright.
One other thing to consider is that there is a lot of 64-bit hardware running on free OSs. It's nice when PCI devices can DMA to the full address space.
Use the distributions (Score:2, Insightful)
Re:Use the distributions (Score:2)
Open Hardware Certification (Score:5, Informative)
Hardware-compatible software (Score:5, Insightful)
Of course (as some posts already mentioned), this can only be achieved if the hardware in question is properly documented so that developers know how to write drivers for it, without having to resort to dirty (and sometimes illegal) tricks like reverse engineering.
Re:Hardware-compatible software (Score:2, Insightful)
Uhh, no. Given an operating system with 98% market share and an in-design piece of hardware, doesn't a hardware standard make more sense than building whatever comes to mind and hoping that Microsoft will release a service pack to make your product usable? As a hardware designer, which would you prefer?
Re:Hardware-compatible software (Score:5, Insightful)
Re:Hardware-compatible software (Score:2)
What the hell does this mean and why is it considered insightful?
Software is the most flexible artifact in history. It can be patched. Hardware, basically, can't.
Re:Hardware-compatible software (Score:2)
Re:Hardware-compatible software (Score:2)
Logo? (Score:5, Informative)
You said:
From the "MS Logo" link:
So is it really a question of ensuring that your hardware "works", or is it a marketing issue in which you need to show the colourful Windows flag on your product's packagaing?
I'll admit that I didn't devle too deep into that MS document, though, so it may encompass far more than the logo, despite what the title suggests.
Re:Logo? (Score:4, Interesting)
I do not do the work, but I have had products I'm working on impacted by some pretty low-level technical changes on the product required to meet WHQL from other groups.
Re:Logo? (Score:2)
I can say that the Logo certification requires a significant amount of technical work, not just some buy off.
I imagine it does, but I was simply asking whether it had to meet MS Logo cert in order to work, or if it had to meet MS Logo cert in order to display the "for use with Windows" logo as the MS blurb suggests. I had interpreted the poster's statement of "...to guarantee that our hardware runs Microsoft Windows..." to mean that the software would (somehow) not operate unless it met certain specs.
Re:Logo? (Score:5, Informative)
Hardware incompatabilities (Score:2)
By demanding that hardware manufacturers get a certified driver, MS can say for anyone else that "It's not certified by us, we never made it, so it's not our fault"
Certainly given the craploads of issues I've had with some manufacturers' products (*cough* ATI *cough*), I'd happily pin a large portion of the blame on their buggy drivers rather than an issue with the OS itself.
GNU (Score:2, Interesting)
Linux doesn't have the muscle.... (Score:4, Insightful)
So the *nix crowd has always been followers.
If the harware guys want to play OS here's the game plan:
1. exactly follow existing spes (where posable)
2. clearly and loudly publish interface details
3. release *Linux drivers with the hardware
[#3 is cheaper than you think!]
Re:Linux doesn't have the muscle.... (Score:2)
Getting drivers in the Linux kernel is much better than just "releasing" drivers with your hardware; it ensures that they're likely to remain available, and be upgraded to be compatible when kernel interfaces change. And your users won't have to install seperate drivers most of the time -- things will just work.
A vote for bloat.... (Score:2, Insightful)
Anyway, this is much harder for a small manufacturer to acomplish.
Placing drivers in the Internet Archive and etching the URL on the hardware is the minimium they should do.
If it's open source... (Score:5, Insightful)
If you are prepared to put paid developers at the whim of the community then you are already on the right track to wide acceptance. You have to realize it isn't your baby anymore and if you've just released a horrible monster it will get tamed and put into other projects that have nothing to do with you.
Going open source is easy - anyone will tell you what is good and bad to do. Closed source, proprietary software tends to lean towards groupthink and suddenly a bad project is worse. There is no reason to keep discussions and ideas behind closed doors in the open source world so you can benefit from wider feedback.
In a year you'll be discussing you're release on Slashdot, and we'll be saying *BSD is dying. But that will be some of the best marketing and market research you can do, and it will all pay off.
I'm in a weird mood..
I just want to say... (Score:4, Insightful)
Re:I just want to say... (Score:2)
I kindof wish you would include what company you work for so that I could perhaps see if I need any of your hardware.
Just a coincidence move along now. (Score:4, Funny)
<Microsoft>Thats not a bug its a feature</Microsoft>
One rule (Score:5, Insightful)
Remember that documenting your interface does not mean revealing the secrets of what's going on under the hood! What do the signal lines do? What commands are accepted? What are the timing characteristics? What format of text/image/video flows along the lines? etc
Hardware Status (Score:2, Informative)
Serious or Tongue-In-Cheek? (Score:2)
Make all registers readable! Write-only registers are a pain in the #$@#$%^!
I know a little about assembly language at the processor level, but next to nothing about e.g. PCI-bus negotiation.
Is there such a thing as e.g. "write-only" memory when you're dealing with device drivers? Maybe when you're doing DMA stuff to upload data to RAM?
Or was your post intended to be tongue-in-cheek?
Re:Serious or Tongue-In-Cheek? (Score:2, Informative)
What this means is that you write some control values to the registers, which causes the hardware to do something.
If you later wish to use those values, you can't just read them back from the registers. You have to have "shadow" registers which cache the last value written to the real hardware registers.
-- Andyvan
Yikes! (Score:2)
If you later wish to use those values, you can't just read them back from the registers. You have to have "shadow" registers which cache the last value written to the real hardware registers.
That does sound like an incredible pain in the ass.
Is this just bad design, or are there economic reasons for doing this? Perhaps e.g. "R/W register memory" is vastly more expensive than "Write-Only register memory"?
Re:Yikes! (Score:2)
It is microscopically cheaper to not provide a read path in hardware (both FPGA and ASIC) so there can be justification for that at times, but I have yet to see one that outweighs the debugging nightmares caused by it.
Open Source is Like Terrorism (note: ironic subj.) (Score:3, Insightful)
Likewise, you can not design "for F/OSS" because F/OSS is a means. Linux and the like may be most associated with F/OSS, so you might legitimately ask "how to I do hardware so that it is compatible with most linux distributions", but NOT (generally) with F/OSS. Consider the (unlikely) case where MS open source'd XP source code today - there you have it .. F/OSS software, and you see that your question loses its correctness.
And now for the part that will receive real flames from the unthoughtful: F/OSS came of age with linux. But, likewise, the fundamentally good idea is handicapped by its association with it. F/OSS is too important an idea and reality to be associated with a unix clone with generally poor usability (despite its stability) and the blindered hobbyists who dance around it.
Re:Open Source is Like Terrorism (note: ironic sub (Score:2)
"Today Open Source advocate mumblestheclown admitted Open Source is Like Terrorism. We must destroy this evil before it spreads! Think of the children! Do we want our kids growing up in a world where source code is open can be examined by anyone?"
There's a few things you can do to help (Score:5, Informative)
If you are doing anything that is truly groundbreaking, for your company, but has been done in other places, at other times, the experienced OS developers in the free software community can sometimes provide invaluable feedback on what is wrong with your design.
For example, as I understand it, the AMD64 architecture did not have an IOMMU until rather late. The Linux developers working with AMD on providing support for this architecture pointed out that it was useful and a huge performance win to have one, so AMD reworked that into the architecture. That kind of feedback is invaluable, and something a company like MicroSoft simply can't give, because they lack the necessary cross-platform experience to care. I believe the major Linux distributors are open to consulting arrangements of this type - approach them and ask them for assistance!
If the hardware you have needs firmware to be loaded into it, consider what license the firmware is distributed under, and how that interacts with the licenses of the free software you are trying to work with. At the very least, make sure other people can redistribute the firmware, unmodified, so the users are not dependent on a download from your site.
So, document the hardware interfaces. Answer questions on the hardware, and involve those more knowledgeable than your company early and often to give a better design.
Re:There's a few things you can do to help (Score:2)
Microsoft lack cross-platform experience?
Strange, last I looked their OS have run on Alpha, MIPS (not sure about this one) for a long time and they are distributing a development kit for their next-gen X-Box console on
I don't like Microsoft either but the truth is that they have cross-platform experience.
Note that Linux works usua
Re:There's a few things you can do to help (Score:2)
The depth of knowledge of what hardware is good and what hardware is annoying and hard to deal with is massively different.
Intel is trying.... (Score:5, Informative)
http/news.com.com/Intel+more+active+in+desktop+Li
a comment (Score:3, Insightful)
Re:a comment (Score:2)
I'd love to use all open-source; but it has to be useable for my needs, first. That's why I've always appreciated Linus's perspective on the BitKeeper flamefest.
Thoughts from the tastier end of the food chain... (Score:2, Insightful)
So, yeah - if you're going open, go all the way.
Great Idea!11 Nerds will hate it. (Score:3, Funny)
Been Down This Road... (Score:3, Insightful)
I've gone around this block a few times and I have a few comments that you might find useful.
First off, you didn't say what is your market space. Are you shooting for home, office, workstation or server? I think you'll probably find it easiest to be compatible in the office desktop or server spaces where the configurations are quite generic and not apt to be modified by the end user. Secondly, you didn't say what you did. Are you a full system designer, motherboard designer or configurator? Are you looking to design components that are *nix compatible or are you looking to put together off the shelf components into a system that is *nix compatible? How you answer these questions will affect how you approach the problem.
If I were in your position, I would suggest that you look at the "PC/99" Specification put out by Microsoft/Intel and see what you can do to be compatible with this specification instead of the more Windows (and DRM) specific later specifications and try to get/design hardware that meets this specification; it should be very *nix compatible although it will not encompass the latest audio and video specifications (which is why I suggested office desktop and (preferably 1U) server products.
The problem with this approach will be specifying chipsets that can handle the latest processors and memory. You should be able to mix and match to end up with a motherboard that will run the latest processors with the most appropriate memory and access EIDE and SCSI storage and should be very *nix friendly.
Good luck and let us know how you make out,
myke
A few pointers (Score:5, Informative)
First of all, I must commend you and your company for caring about these things - it's definitely nice to see that there are companies who actually care about their customers. ^_~ That being said, here are a few things to get you started:
Hope this helps!
Re:one point (Score:2)
To add some minor nitpicking, you can add GPL'ed code to a *BSD system, too; you just cannot distribute the whole thing under a BSD license then. It would be perfectly possible, however, to fork a BSD-licensed project (*BSD or something else) and distribute the fork under the GPL, as
F/OSS Works Differently (Score:5, Informative)
In Windoze land, Microsoft publishes a list of requirements, and offers testing services to ensure compliance. You code to these requirements and get the thing tested and validated. Once done, Microsoft awards you the right to put "Windows-certified" on your box, and you can consider your product "done" (modulo bug fixes/patches).
In F/OSS circles, no such certification program exists. There is no list of requirements; there is no explicit testing service. Instead, what there is is the complete kernel source code (so that you can determine precise requirements yourself), hundreds of existing drivers (to get you started writing your own), and hundreds of thousands of users who will beat up on your hardware/driver and liberally shower you with bug reports (of highly variable quality).
This may seem like a recipe for complete disaster but, depending on what you want to do, it's really not. Linux's device driver model is almost pathetically simple compared to the byzantine mess that Windows uses. So getting a driver with basic functionality is a fairly simple affair. Depending on your device, you'll probably be able to leverage off of existing infrastructure to handle bookkeeping details (for example, I2C bus devices already have an API layer that handles reference counts and locking; coding to it is dead-simple).
Conversely, there are some areas of Linux driver land that are still evolving. One of the big areas is power management. There are three major competing power management mechanisms for Linux (APM, ACPI, and the lesser-known DPM). None of them really address all power management needs and, while some sleep/suspend modes sorta kinda work, Linux's solution is far from complete. You'll be working with a moving target.
As other posters have already mentioned, publicly-available, complete hardware documentation (register maps, theory of operation, strapping options, clock diagrams, etc.) is absolutely essential . In case you get bored with your product or, heaven forfend, your company dies, the F/OSS community will be able to take up the slack. They'll also be able to add features or enhance kernel compatibility when and where it's needed. (Some lawyers or senior execs will try to veto a documentation release, citing imaginary fears such as "loss" of proprietary information and trade secrets. You are encouraged to nut-punch these knuckleheads until their opinion is changed.)
F/OSS is not as strictly regimented as the Windows camp, so strictly regimented project planning isn't as easy. There's a lot of chaos out there. This is, on balance, widely regarded as a good thing. You may be surprised at how well your engineers cope in such an environment. (Conversely, it will also help you identify more quickly exactly which features your users actually value.)
Schwab
P.S: If you have the ability, tell Microsoft to take their copy protection ("DRM") requirements and cram them.
Re:F/OSS Works Differently (Score:2)
Actualy there's quite a few. Red Hat, SuSE and most of the major business distros have hardware certification programs.
For example... [redhat.com]
Our Requirements (Score:4, Informative)
Even if you have "proprietary" behavior you need to hide behind some proprietary software, just provide us an object file for that *tiny* portion of code, and we can manage the rest. We might grumble a little bit, but we'll still accept it.
What we don't want is for you to act as if you own the hardware. Don't lock us in to your driver. That's just rude.
Re: (Score:2)
He's not MAKING hardware, he's assembling!! (Score:5, Informative)
Meaning, he buys hardware from a distributor, and with a $4 screwdriver, assembles said hardware and pitches it a customer.
I've been there, and done that. Trying to make one that's WINDOWS compatable is a royal pain in the arse, let alone OSS.
When I ran a store, we had a few lines of hardware that seemed to be more or less compatable with each other. We had to continually buy hardware of all kinds and test them to see how they did together.
It was always shocking to me how much of the hardware just didn't pass our testing. Our testing was pretty extensive, and consequently, the hardware lines we stocked were fairly limited.
Also, it was commonplace to have hardware revisions that would change without any notice whatsoever, ruining compatability.
At the time (ending Spring of 2000) one of the *WORST* offenders was Asus. On the other hand, a few relatively unknown brands (DFI and A-trend) scored rather well in our testing, and were cheaper to boot!
My best advice would be to simply test some hardware before you sell it, and see how compatable it is with your favorite distro.
Good luck.
You might do what we did in software (Score:2)
Back in the 80's we published a security package that included DES as one of its encryption options. The NSA didn't want us to export the software because DES was considered a munition. Nevermind that the programmer who wrote the software lived on the Isle of Wight off the coast of England and was using a book that documented how to implement DES and the book he was u
People RTFQ!! (Score:2, Insightful)
It seems to me like the guys is looking at some kind of guide to writing drivers for the different *nix flavours. Telling him to write open drivers with open documentation and specs isn't helping him.
As far as Linux is concerned, a good place to start is here [kernelnewbies.org]. *BSDs probably have a similar way of working: almost all the communication between the kernel/driver developers is done by email on mailing lists. IRC channels
open source specs for hardware (Score:2)
Yes! Here they are:
1. Design whatever the hell crazy cool hardware you want.
2. Document the interface thoroughly.
3. Openly publish the documentation without restriction or encumberance.
4. (optional) give a couple test systems to folks who volunteer to write drivers and have demonstrated a history of doing so successfully.
That's it! Open source operating systems can and will adapt to an
Re:Follow the windows guide, (Score:2, Interesting)
Insightful, this? People, the o.p. asked a sensible question which shows they are serious about adding support for Linux, and all you can poke out of your ass is a dig at Microsoft. If you can't help, then leave alone!
Re:Follow the windows guide, (Score:3, Insightful)
Re:Follow the windows guide, (Score:2)
Keep the DRM part (Score:3, Insightful)
Personally, I *want* Linux to be able to used the good parts of Trusted Computing (palladium).
DRM is a technology - not unlike encryption - that has it's uses and places in the Linux world. Surely you wouldn't claim that Linux would be better off without SSL support. Some uses of DRM technology are a valuable and logical extention to help improve secure commerce. I want Linux to have a place in those solutions.
... so what? (Score:2)
He can say it and I can point out that he's a bigotted insensitive jerk for doing so... and someone with mod points can mod him out of existence... if there is any justice on slashdot.
Re:Split (Score:3, Interesting)
As for hardware specs... on an i386 class box [which includes pretty much everything even the x86_64] the PCI bus is accessible through MMIO and I/O ports.
This doesn't change just because you're in BSD or Linux.
Sure the actual code may change due to the organization of the respective kernels but the hardware manual which explains how the device works is applicable to both.
The biggest problem with most hardware is
1. Undocummented hardware
2. "pointless revisions" [*]
[*] A typica
Re:Split (Score:3, Interesting)
If diversity holds open source back in any m
Re:Split (Score:2)
Hey, chimps are pretty smart. There's even one who holds a black belt in Karate! I've met many humans who I'd consider less intelligent than this. I think your use of that word here is insulting to chimps.
"Lemmings" and "sheep" are probably better terms here.
Re:Don't worry (Score:4, Interesting)
Re:Maybe misunderstood? (Score:2, Insightful)
Hmm.
Maybe you misunderstood? (Score:2)
But here's what i'm confused about - isn't the windows hardware certification thingy moreso for the drivers than the hardware it
Re:Troll Story Alert: Congrats to Bender (Score:4, Informative)