Slashdot Mirror
Free/Open Source Software Hardware Requirements?
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?"
If you release complete documentation of said hardware ...
Well documented, unencumbered interfaces would be a nice start.
[ouch]
Linux is not *BSD, and *BSD is not linux, maybe you don't want to look for compatibility between them.
ajf
My ininformed, off-the-cuff answer would be:
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.
... send a free piece of the hardware to every major kernel-programmer.
If you mod this up, your slashdot background will turn into a beautiful sunset!
...don't make the interface between your hardware and the software proprietary and closed.
Microsoft requirements (to their legacy code and operating system) are what really holds the PC back. Has there been any decent effort to break this mold?
A feeling of having made the same mistake before: Deja Foobar
Why not ask someone who doesnt know?
After all, this seems like there will be a 'right' answer to this question, and where's the fun in that?
And get the drivers accepted in BSD and Linux kernel too. Best way to make sure you are compatible with them.
Conform to freely available published standards. If you have good reason to produce proprietary hardware, publish the programming interface in sufficient detail for people to make a clean-room implementation of drivers. And don't worry -- free drivers will follow.
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.
The open source world is highly fragmented and factioned. It's hard enough to write software to run on most *NIX systems without it and a hand full of dependances being ported over.
Unfortunately that, IMHO, the biggest thing holding open source/free software back (other than Microsoft of course).
You can use linuxhardware.org to search compatible linux hardware.
h wcompat.ht ml
But maybe you can find this article a little more helpfull
http://www.control-escape.com/linux/lx-
You can use the distributions like RedHat, Mandrake, Debian to test the devices and put the specified support in kernel. Or better, why not send the hardware to one group of kernel developers.
http://www.michel.eti.br
The obvious solution is the Open Hardware Certification at http://www.open-hardware.org/
I always felt the term "Windows compatible hardware" was a big piece of bullshit. Shouldn't it be the software to conform to the hardware, and not the other way round? Hardware seems to be the lowest common denominator here.
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.
Score: i, Imaginary
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.
maybe GNU could launch a documentation database with docs from the manufacturers.
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!]
...then people will correct you if it's wrong. If you release open source drivers to the community and do it in a fashion which inspires feedback (mailing lists, forums, Sourceforge) and people find fault (bugs, standards compliance, bad code style) it can and likely will be fixed.
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..
Get your Unix fortune now!
THANK YOU!!! I wish more hardware manufacturers thought like you!
<Microsoft>Thats not a bug its a feature</Microsoft>
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!
Publicly document the hardware interface. That's all that's need, really. As a programmer and electrical engineer all I need is a decent spec sheet for a piece of hardware to construct an interface to a linux system.
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
Make all registers readable! Write-only registers are a pain in the #$@#$%^!
Like the beaver, it's just Dam one thing after another
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.
Maybe, but considering that Linux and friends have been accelerating in marketshare growth and visibility, the compatibility issues will become a greater priority for the OEMs and it will be the companies' employees who will take care of what would otherwise have been the dirty hippies' project. Just another instance of supply catching up with demand.
First of all, provide documentation and an engineering contact to answer questions about the documentation. Keep in mind that you will get asked questions from sources other than those related to the core Linux development team - the *BSD teams may have questions for you, some hobbiest may ask questions - answer them all. Incorporate the answers to their questions into your documentation, etc.
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.
If you write your own drivers for Linux and one of the BSDs and release them under the GPL and BSDL with the complete documentation. From that point on the community can take care of maintaining and porting them if you don't (it's better if you do).
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.
I agree
Intel is trying to release Linux drivers at the same they release hardware. They are also trying to create a hardware copatability matrix. If you are a system builder or VAR this would be very helpfull. Some background:n ux/2100-7344_3-5465225.html?tag=nefd.top/
http://seattletimes.nwsource.com/html/businesstech nology/2002099285_intelasialinux24.html/
http://seattletimes.nwsource.com/html/businesstech nology/2002099285_intelasialinux24.html/
http://techrepublic.com.com/5100-22_11-5465929.htm l?part=rss&tag=feed&subj=tr/
http/news.com.com/Intel+more+active+in+desktop+Li
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?
I have to say that don't even think about some proprietary binary no matter how wrapped and supported it was by distributions.
How is saying "no DRM" a poke at Microsoft? It's also a poke at Intel, DMCA, MPAA, RIAA, BSA, w/e. Sheesh. Aren't we defensive today.
- Slaving off to software what should be done in hardware, unless you're planning on going cross-platform with the software support. Think WinModems here.
- Closed. Binary. Firmware. There's a whole bunch of wireless hardware that it'll be years before anyone can use under Linux, if they even bother, for precisely this reason, and it bugs the hell out of me.
So, yeah - if you're going open, go all the way.This is a wonderful suggestion which is why every nerd and geek who furiously insists on porting Linux to a parking meter he stole at the last Trekkie convention will object to it.
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"?
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
Hey Bender,
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
Mimetics Inc. Twitter
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.
You know Microsoft is going to use this one...
"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?"
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!
quidquid latine dictum sit altum videtur.
As Linus said himself (almost TWO years ago), there is no fundamental incompatibility between DRM and Linux.
quidquid latine dictum sit altum videtur.
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.
Editor, A1-AAA AmeriCaptions
Hate speech is constitutionally protected. It is only a matter of time until laws curtailing it are tossed out, as long as the speech passes the "clear and present danger" test.
Viral software licensing is not freedom, it is in fact GNU/Socialism.
You can turn them off in your preferences.
We do not need HW guidelines like the windows world! We want standards for whole classes of hardware. We want a reasonable modem standard, and every modem on the world confirming to that standards. What we dont want is guidelines about winmodems, that need a specific driver for each different possible winmodem/OS/OSversion combination! It's not like it's that hard to create a nice standard for printers/SATA drives/whatever. But no, everyone creates his own hardware, and then needs to keep updating drivers. Thanks, Microsoft, for creating this non-problem.
We don't need you to write drivers for us. It would be nice, and we will thank you profusely if you do. But we're not requiring it. All we care about is access to the complete hardware specifications. It's that simple.
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.
Don't blame me, I didn't vote for either of them!
Did I say he couldn't say it?
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.
These requirements dictate (among other things) firmware interfaces, debug ports, and DRM.
Where in there does it say that the hardware they want to make FOSS-compatible requires DRM? It looks to me as though he was merely describing some of the Windows Logo requirements as examples. No need to holler, "Shields up!"
I'm not good in groups. It's difficult to work in a group when you're omnipotent. - Q
This guy is "in the hardware business".
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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I'm happy you're giving thought to the linux community, but i have to point out earnestly that you are under no "obligation" to provide "logo tested" hardware. During the years i ran windows i've installed many beta and non-logo-tested pieces of hardware and software and not had a problem.
Might i suggest "just saying no" to microsoft and encouraging other hardware manufacturers to do the same.
It's not your job to tailor make products for king bill the first, and if you feel youre being pressured i'd suggest getting together with industry allies who feel the same and filing a class action suit for trust activity.
and whatever you do don't hardware/firmware embed DRM.. if you do i hear about it.. if i hear about it thousands of my friends hear about it, and not one dime comes from my pockets.
If you do decide to gather forces and pursue a class action suit.. be sure to whip up a lot of media coverage. A lot of people simply accept their software begrudgingly, and would be happy to keep your business afloat for the simple fact that youre standing up and saying "no.. i'm running my business and designing my products.. not you"
Well, some glitches with various hardware is definately due to buggy/crappy drivers rather than the windows OS.
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.
Good answer!
<FLAME>Too bad your parents didn't know about birth control.</FLAME>
no seriously code weavers do certification too.
Desktop Linux CertifiedTM Program
Question: Why do applications run on Windows in a reasonably uniform manner?
Answer: Because software developers test their applications against the Windows API, that's why.
Wouldn't it be great if a similar mechanism existed for certifying Windows applications running on Linux desktops? Now there is...
In order to continue gaining credibility on the desktop, Linux needs its own certification program. That's why CodeWeavers has taken the lead in establishing Desktop Linux Certification. We have created a common Linux testing API (CrossOver), and a set of open, freely available testing tools (the Compatibility Center and its CXTest regression testing suite). By doing so, we are meeting the needs of users for superior functionality and true portability of their applications, no matter what operating system they were originally written for.
An application that is Desktop Linux CertifiedTM has passed a set of compatibility and reliability tests, and can be relied upon to perform in a productive fashion when running under CrossOver. Certification also demonstrates that the software developer for the certified application is serious about working with the Linux community.
We work actively with Independent Software Vendors (ISVs) to enable them to achieve and maintain Desktop Linux Certification. We can either work directly with the ISVs development and QA teams, or work independently to bring the needed application(s) into Certification.
Benefits for Linux Users
Certification gives software users:
# The assurance that their favorite Windows applications are also certified to run on all Linux desktops under CrossOver.
# The knowledge that your Application is portable across both Windows and Linux.
thank God the internet isn't a human right.
also at Apple, IBM, Dell, HP, and about every other hardware manufacturer out there....
1. linux standard base (LSB) has good docs
2. full docs of your hardware. such as what does this register do, timing, interfacing.....
3. snippets of code
released under GPL
community will take care of the rest.
~omi
that's what the guy wants to know. Where are the "freely available published standards"?
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 using as the design spec was available worldwide.
We had a distributor in Sweden who had sold quite a few copies of our software to Swedish corporations and the distributor made it quite clear that DES was a must have for those clients. We ended up disabling DES to satisfy the NSA by making the software check for the presence of a file in the executable's directory. If the file was present, DES was disabled. The software was shipped overseas with the file. NSA was happy, our distributor was happy.
... who thinks that jokes about grinding women and stuffing them in his freezer up are a hoot. You know HE doesn't ever get laid... unless he pays.
...I mean, if company "foo" has secrets they want to protect from company "bar", yet still want to provide OSS drivers. The solution would be to have an NDA for developers which forbids them to disclose it to, or work for "bar".
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
Live today, because you never know what tomorrow brings
From the way I understand the question it seems nobody understood what the poster meant.
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. *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 are also used.
Many of the free unix flavours (linux/bsd/etc.) share open source drivers; ethernet card drivers is a good example of that. The interface with the kernel may be slightly different across platform but the low-level hardware access remains fairly similar.
My best advice would be to look at existing drivers. They are all open source so you can look at the source code all you want.
If you can compile against last night's version of the kernel ABI, then you're good to go!
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.
My guess this guy is working as a systems integrator. AKA he is building boxs.
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?
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Don't change your sig, it's pretty fucking funny. HAH! Seriously, no sense of humor these days.
There are some standards which appear to be taking hold such as the Linux Standard Base (LSB) , GNU's programming standards, and any other standards documents you know of.
erm...he's talking about creating/certifying hardware that is compatible with both Linux and FreeBSD - the two main Free operating systems. He's asking if there's a certification program, like the one for windows, that looks at hardware compatibility for either and/or both. He wasn't making a claim that they are the same thing or have the same underlying hardware abstractions.
But here's what i'm confused about - isn't the windows hardware certification thingy moreso for the drivers than the hardware itself? Hardware is hardware, it's useless without drivers - so instead of certifying actual pieces of hardware, should he be asking about a driver certification program (not a bad idea to get the infrastructure started young..)?
Would you drop me an e-mail about your sig. I am interested in finding out about your source(s). Many thanks!
The answer is NO.
There are no officially published standards you can use to make your hardware 100% compatible with Linux.
I don't know why everyone else wouldn't just answer you outright instead of demanding that YOU provide the documentation, lol.
If you already have code lying around, consider releasing that under both the GPL (so it can be incorporated into Linux etc.) and the BSD license (for the *BSD systems).
BSD licensed code can easily be incorporated into Linux. You just can't go the other way (GPLed code in *BSD systems).
Windows free secure email www.loftmail.com
Sorry for the incomplete nature of this reply.
IIRC that a year or so ago there was some discussion about the IDE driver in Linux. At one point it was a kludge. Then someone redid it as a kind of SCSI interface that really cleaned it up and made it much more maintainable.
I think the reason the original one was inadequate had to do with trying to maintain compatibility with just the kind of Windows 'exceptions' you are referring to.
You might want to hunt up some of those old threads on the kernel mailing lists and see if they give you an insight into any of the issues.
Sorry I can't tell you more, this is not really my area.
S
you are a stupid piece of shit. fuck you.
-any better?
Is there a Linux/*BSD equivalent to the Microsoft requirements to allow hardware designers to build OS agnostic systems?
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 anything you care to do in the hardware arena as long as the interfaces are openly documented and unencumbered.
Break #3 (e.g. require a key to access function so and so and the key isn't publicly available) and you're dead. I mean really dead. The hackers will break your code for the challenge of it but the open source folks will avoid you like the plague.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
The worst piece of halfway documented hardware I had to run on a linux box was a NCR 53C400A SCSI controller.
Those were commonly sold with scanners in ISA bus times.
It had no interrupt lines and a tiny buffer of 128 bytes.
While I was scanning, time stopped, as Linux had to poll the chip with all interrupts disabled.
Reading through the freely available "documentation" (it consisted of Pascal sourcecode), I corrected the Linux driver to make use of the buffer (someone used wrong addresses to access the buffer and eventually disabled the code). But as you can guess, 128 bytes fill up pretty fast and often when scanning at 300dpi, so no real benefit.
Got a bus-mastering 53C810. Am still happy.
Don't design hardware that needs too much attention from the cpu. Real multitasking operating systems and their users don't like that.
Ah, but that was because of a computer error.
I've been reading Slashdot for years, and it's spelled CompatAbility..
Just thought you ought to know, because you look like an idiot who kan't spel.
How would a hardware integrator know what Video, SATA card, Raid controllers, and motherboards to use?
/., though.
Gee, I don't know...Google? Call the vendor? Build a few and test 'em? Definitely NOT ask on
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 industry. This restricts innovation etc.
Encourages closed source/design: barrier to entry for other OSs etc.
Does Linux need such a program? I think not. Having worked with hardware design of some Windows Logo-ised devices, you end up being driven in the direction MS wants you to go - which is not likely to be in the same direction you want to take your product (unless of course its another "me too" PC or PDA).
Engineering is the art of compromise.
Is this possible?
.. bytecode compiled forth..
/etc/OpenBoot-modules via a hotplug style daemon.
It seems to me that OpenBoot is a public standard. Does it require fee paying to use it?
OK let me give more info here. The driver is written in Forth, and compiled into
I think the compiled forth is stored on a flash in the hardware generally. (it can be upraded).
So you can just write a driver once, and it runs on Sun and on Apple.
I'm wondering if OpenBoot drivers could be used with Linux and BSD.
As in, write a generic driver interface to access OpenBoot drivers. (a generic interface for BSD and Linux).
Perhaps this is configurable via a file say
Interesting idea?
It could save a lot of time for hardware people, writing a driver once, then covers maybe 10% of hardware instead of writing three drivers (OpenBoot / BSD / Linux ) for the same 10%.
"Release complete documentation of said hardware" is that central guideline. Whether or not some minority of manufacturers aren't happy with that changes nothing.
Zing!
Best Retort Of 2005.
Good documentation has b een well covered here, so I'll just include it by reference :-)
A couple of things to watch out for. Make sure the vendor of any glue logic you plan to use is equally willing to release full documentation. The other big thing is plan to hide any IP you're not willing to release behind a layer of hardware or firmware so that you can freely document the interface to it.
Easy, you build it and try to install the latest Mandrake, Redhat, Debian and Suse. If something doesn't work, you find a different model.
Been there, done that...
...something, but what?
Choose your favorite
1... the prevailing sense of humor on slashdot is puerile (however you spell it)
2... that there are no women who read these pages.
3... that grinding women up and putting them in your freezer is generally thought to be good clean fun for everyone.
4... that most people who defended that comment probably are not in a relationship with any self respecting woman...
4a... and have a mental age of about... oh 14.
5... that most folks around here don't want a vile idea to get in the way of a good yuck.... although guys, when you grow up, you might find that a good fuck is a hell of a lot better than a good yuck...
6.... all of the above.
I should have known I was too old to still be reading Slashdot.
... right... what part of "world wide web" doesn't this guy get?
And remind me which part of the country finds grinding women up and putting them in the freezer funny... so I can avoid living there.
A reason that Apple and Sun can support their base products so well is because they limit what hardware components they use and support in their platforms and therefore limit the hardware that the operating systems have to support. The price might go up, but the ability for the hardware to "just plain work" are much better.
This is not true in the PC world where manufacturers of motherboards, bus adapters, networking, and peripharals don't have to support anything but Microsoft compatability. Microsoft defines the compatability, not Intel, not AMD, and Microsoft will be very happy to give the vendors shortcuts (firmware modifications, OS middleware) to help Microsoft software drive their products (printers, winmodems, networking cards, etc.). If the Windows driver compensates for buggy hardware, or the hardware compensates for Windows bugs, the open source OS platforms are worse off and are less likely to support the products.
So, if you go the PC route, just plain beware the incompatabilities of all of the components. A few companies provide value-add by integrating systems with open source operating systems (laptops, servers, storage) so that their customers will know it works. If you're just starting out, you're way behind. To catch up, check the compatability lists of each OS you plan to support and pick products that work with all of the operating systems you want to support.
Who needs computers anyway? Soon enough, the whole world will just be a virtual session into the Google server farms.
-ez
Karma (whore) - you look at your score after posting
I'm a woman and I laughed at the sig, but the asshole who posted 'you need to be slapped around by a man' is much more offensive. God, it was a joke. Get over yourself.
PLEASE use *REAL* modems and printers
The two biggest pains-in-the-butt that the average linux user runs into are the abortions called "winmodem" and "winprinter". They shave $5 or $10 off the price of each unit by dispensing with part of the modem or printer hardware.
In order to function without all the parts, these cheapskate components require *ADDITIONAL SOFTWARE DRIVERS* to emulate the functions of the missing hardware. Not only that, but they require a separate driver version for each OS, each major point release of each OS, and in some cases, each separate distro of linux or *BSD. It ain't worth the hassle.
A modem built over two decades ago for the IBM PC will run under just about any OS that supports PC hardware, without extra work. But Rockwell decided one day to cheap out with RPI (Rockwell Protocol Interface) "modems" that made the computer's cpu do part of the work. This was the model for "winmodems".
Even if a driver exists in Windows or linux, a v90 "winmodem" is slower than a real v90 modem. The CPU has to devote 100% of its attention to the download or else the modem drops characters, causing retransmits etc. Even playing solitaire while downloading may slow the download. This is *NOT* supposed to happen on a real multi-tasking computer, folks. Similar remarks for "winprinters".
This is not aimed against USB modems or printers; they're OK, although linux support for them may not be 100% mature. I'm complaining against incomplete peripherals that treat the computer's cpu as a substitute for missing hardware.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Just specify in your contracts that you get all specifications needed to create drivers, along with rights to publicly disclose them.
Have a lawyer write the relevant parts, but that is the idea. Just make sure there is no requirement for a NDA.
Once you have the specifications you put them on your website and inform some developers. If you can afford it, send a demo a developer of at least FreeBSD and linux (depending on your target there are other FOSS operating systems to target). Shouldn't be too much, and can go a long way to helping.
I've seen a lot of posts asking for "complete documentation" of a piece of hardware.
Basically, you're just asking for the hardware maker to back away.
Hardware makers often make use of 3rd-party technologies. Making documentation open might sound easy, but is legally difficult.
There are trade secrets to protect (if you don't choose to patent a novel design, you do the best that you can to keep it secret).
(for those of you who think there shouldn't be a reason for trade secrets and only evil corporations use it - think again - trade secrets also protect small companies from the big fishes, too)
The solution I can see is a public binary ABI for drivers that is *STABLE* (i.e. not completely revised every other major kernel release).
I'm a Linux user. In my short-sighted opinion, maintaining binary compatibility is the biggest weakness of all open source operating systems.
There should be a guideline - that, say, binaries compiled within a major versino of GLIBC should all at least load - with various levels of buginess.
It's fine if it *recommends* a version. But if it *requires* a version there might be something wrong - I was furious to see a binary that refused to load on a GLIBC 2.3.2 box just because it was compiled to link with GLIBC 2.3.3.
I agree. Ground up and boiled is funnier.
It's a joke, a pun. It's funny because you don't expect it, you expect something like "sweet and creamy" or "black and strong" or "white and steaming hot" but instead you get dead people.
If that doesn't make you laugh the first time you hear it, get a fucking sense of humor. I, for one, would never actually grind up a woman, or actually verify that the difference between children and pizza is that pizza doesn't scream after it's been in the oven for a bit, but I find such things, especially the coffee pun quite humourous.
What's even funnier is the people getting all offended and stuck-up about them because they are offensive to them, or god forbid they might offend someone. Christ, you're on the internet. ON FUCKING SLASHDOT. You should be used to "offensive" comments by now.
You know what would be offensive? If he was serious. If he actually liked his women ground up and boiled. That would be offensive.
Something's degree of offensiveness should be determined by intent, and not by content.
kaens.blogspot.com
#include
Servlet v2.4 container in a single 161KB jar file ? Try Winstone
"Gee, I don't know...Google? Call the vendor? Build a few and test 'em? Definitely NOT ask on /., though."
The Google answer is fine for building a personal system. Build a few and test them is fine for a large vendor.
But for a little guy both are a pain in the rear. It would be nice if OSL created a simple logo that means this works with Linux.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
As clearly explained before ( http://www.jwz.org/hacks/why-cooperation-with-rms- is-impossible.mp3 ),
you can not simply call it F/OSS, you should call it
Free Libre Open Source Software (FLOSS).
That defines the type of code that smells bad after you slide it between your charognard teeth.
How will I run my GNU Operating System without a kernel?
How will you run your L4 microkernel without device servers?
You can't "fight a war against terrorism" because terrorism is a means, not a thing or group of individuals.
However, you can "fight a war against companies that distribute Free operating systems designed to run on x86 PC hardware", just as you can "fight a war against al-Qaeda and other organizations that habitually use terrorism".
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.
What about "how do I do hardware so that it is compatible with any Free x86 operating system that cares to implement a driver?"
You have less freedom with your nvidia. There is always a choice of not using that hardware.
Not if both 1. you purchased the hardware before you converted to the Church of Emacs and 2. you have no money to buy a new laptop with Free onboard video.
At 1/10 of the market,Idoubt the logo idea would work. As an alternative they could maintain a "recognized as working" list. Sort of like LinuxPrinting, but less detailed.
Since this is for components it should just be "works" or "partially works". No details. No claim that something doesn't work. OSL could maintain a couple of machines that were used for testing these things with a few standard distributions. (Fedora, Debian Sid, and whatever Mandrake's equivalent of Fedora is come to mind. Novell should also be represented...but I don't know what version would be appropriate. Possibly Gentoo. Note that these are all fully GPL [or at least free] versions.) This would yield for each product a row of tiny icons which would be either yes, partially, or blank. (Yeah you could do it with letters in a spreadsheet, but icons look better on a web page.)
Note that OSDL would only test products on request and submission of a sample. I don't know if they should insist that the request come from the manufacturer or not.
Unfortunately, even this isn't without problems, as manufacturers are known to change the chips used in a product without changing the model number. So results with one batch may not be identical to results with another batch.
I think we've pushed this "anyone can grow up to be president" thing too far.
Disclaimer: Nothing you read on Slashdot is legal advice. Talk to your attorney if you have specific questions.
you cannot prove that someone doesn't work with the obfuscated code that they release.
The accuser of a GPL violation doesn't have to prove beyond reasonable doubt that the alleged violator worked with code and then obfuscated it. Unlike criminal cases, civil cases such as those alleging copyright infringement and/or contract breach are based on whichever side has at least a 51 percent probability of being right. So just show that it's not bloody likely that somebody would prefer to modify heavily obfuscated code, and you prove that the obfuscated source code is likely not the source code, which is likely to be enough to show violation of the terms of the GNU GPL. If not, expect a GPL 3 to clarify things.