Slashdot Mirror
Moving from Binary Drivers to Open Source?
GerryGilmore asks: "We are a division, specializing in telecommunications equipment, of a very large hardware manufacturer. Our equipment, DSP and PSTN boards, has been supported under Linux through a set of binary driver modules and binary libraries implementing our API set. We are in the process of migrating to a completely open source-based software infrastructure to be more in sync with the rest of the Linux industry. However, not having any real experience with moving from proprietary to an open source model, we wanted to see if the Slashdot crowd has any similar experiences to share: The Good; The Bad; The Ugly; and how best to avoid the most common pitfalls."
Wow. That was one of the most useless comments I have ever seen.....
need... link... to.. *twitch*.. click.
HELP!
I have never made a migration on a scale like this, so I have no horror stories.. but I would like to commend you and all peoples making the move to open source where possible.
** "It's not my job to stand between the people talking to me, and the ones listening to me." -- Pego the Jerk
So the really important thing is to really look through your code first - you need to:
1) Check it is all really your code - you didn't buy any in 5 years ago? If you have a source code control system then actually being able to trace your code is great.
2) Read the comments - ok, so lots of closed source contains rather dodgy comments that you might not want to be public.
3) Check that releasing it wouldn't be revealing any information you got under NDA from any of your suppliers/partners.
Read the codingstyle document and look at what others are putting into the kernel!
The biggest mistake is some idiot using unusual function names, spreading his driver over atleast ten files and using 2 character indents or no indentation at all.
Especially if your source is ported from windows (or the programmer has only windows experience) make sure you do this right.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
This may be really useful for sales, but it may also lead to a serious amount of bug finding!
Are you really sure you want your device drivers debugged?
Sent from my ASR33 using ASCII
You could find more information at LKML. The archives are here, http://marc.theaimsgroup.com/?l=linux-kernel.
Many vendors have been moving from proprietary to open source. You can join LKML at http://www.kernel.org/.
Just another instance of a trend of insensible moderations that I've been seeing lately here on Dashslot
The worse thing i've seen in a (Windows) driver.
// stage 1 // stuff here // stage 2 // stuff here // stage 3 // lameness filter mary had a little lab, blah, bla, 1 3 5 7 11 13 17 19 23 29 31
for (i=0;i10;i++) {
switch(i) {
case 1:
case 2:
case 3:
}
}
how long until
Make sure that you release all documentation and tools (preferably with source) for the hardware and the drivers. The last thing a "free" developer wants to do is re-invent all of the wheels that your company created.
Provide Good Documentation
If you provide well organized and complete documentation to a quality product, developers will most likely flock to it.
Support the Developers
You will want to have staff on hand to answer questions about the technical details of the product. Create a forum that is monitored by the engineers who designed and create code for the product. Make sure that questions are answered thoroughly and quickly.
Um, you do realize that that story has now been posted twice?
be sure you dont have any SCO code in there ;)
Sort through the code. Take out everything you do not want shown.. comments and the like.
Sweep through the code to make it/make sure it is readable. This will attract more developers to your project.
Open a project. Still release the binary drivers, just let people get into the code and start making the fixes for the bugs they find. Once it's sufficiently linux-ized by members of the linux community, switch them to your main drivers instead of your binary drivers.
Your binary drivers work right now (I assume), so leave them as your defaults, until the open source community can go in, change, break, fix and test out your open source drivers with you.
And thanks for your future contributions to the comunity. Please post a follow up when they do go open source. This will generate more interest in your products, and I, and many other admins who are part the decision making process of picking hardware for their companies, will definately give your products another look if they have open source, stable drivers (Like 3Ware....they rock. Because of thier long time commitment to linux, they are the only hardware raid cards I buy for my linux servers).
Wow. That was one of the most useless comments I have ever seen........
Although I understand that NDAs can be involved, it often amazes me that hardware manufacturers keep to closed driver implementations.
While it's true that windows and linux are the biggest games in town, offering potential customers who run other OSes a way to use your hardware seems like a no-brainer: larger potential customer base -> more customers -> more profits.
It often seems like pulling teeth; take a look at the recent (and ongoing) attempt OpenBSD is making to get more documentation and relaxed licenses for hardware. Being able to point to $1 million of hardware already running under an OS and getting little or no response from a vendor for better support -> larger customer base -> greater profits? WTF is wrong with the PHBs?
And now, back to the topic:
Document, document, document. Although I don't have any directly relevant experience, I've occasionally taken over 5000+ lines of code with abysmal documentation; on one occasion, it became so painful I rewrote major portions because it ended up taking less time than having to figure out what was going on.
Include reasonable amount of documentation, like a README and an INSTALL file. Keep both short.
Try to use autoconf scripts, since that may help in the long run when people tries to build it on all kinds of strange platforms. Be clear of which platforms that are supported, and which are not. Be also clear of platforms known not to work.
Set up a bug report tool. Bugzilla is a well-known tool. Bugs will be reported, and you may also get fix feedbacks that way.
A clear versioning strategy is also necessary. Avoid a multitude of branches if possible. The preferred way is to have a public read-only CVS archive. (you can use cvsup to create a mirror of the real archive in case you have a security breach on the public server.)
Have a reasonable licensing for your software, it will pay off in the end. You may want to take a look at MySQL. Try to be flexible and not too complicated.
This seems to be what I could come up with on a short notice.
And GOOD LUCK!
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
1) fdisk
2) format
3) full installation
Now that I think about it, that's how you fix any software problems on a windows box.
OpenBSD is striving to open up all drivers, and refuses to allow binary modules. Currently, they are targeting Adaptec, trying to get the management interface opened up. We don't want them to write code for us, or to support it, we just want docs, so *we* can write the code, and support it.
1 8231311&mode=expanded
http://undeadly.org/cgi?action=article&sid=200503
It's great you're doing this. Make sure that people (i.e. potential customers) hear about it. Given a choice between two comparable products, if I know one of them supports the free software community, I'll choose them. I know I'm not alone. You're not only going to benefit (eventually, don't expect instant gratification) from code feedback, your sales will tick up, assuming you market yourselves well. Try to measure it, and then show the evidence to your company's other divisions.
Because hardware has a bad tendancy to hang around long after the vendors lose interest in it?
By making the drivers open source & letting the OS supplier recompile them for new releases they lessen the future load on their support desk from people complaining that their Linux 2.8 binary drivers won't work in Linux 4.2
As an observor on the sidelines, here's a few points that sometimes cause issues.
- Expect a rough transition.
Releasing your app to the community is like hiring a bunch of new developers but not giving them any management. If they like what you have, they will work with it; if they don't, they might re-implement things or openly disagree with your existing design. Get as much relevant information online as possible so others can make informed design decisions.
- Provide direction, but be flexible.
One benefit of OSS is that others can suggest fixes that may directly contradict your current view of the problem. By carefully accepting some of these changes, your software will become better.
- Don't expect the OSS community to do all the work.
Several major bloopers have come from companies saying, "fine; we're open-sourcing it; let them do the work". This is the road to stagnation. The community will support things that are useful to them; don't assume that your alpha-OSS release will generate immediate support. A small OSS community is excellent for porting existing software to new systems; they are generally slow for actual development work.
- Keep providing support.
During the initial transition, you will probably have more work than normal as people flock to your project asking questions. Then only those who like what they see will stay. At a minimum, your company should host an email list and an anonymous CVS or Subversion server.
- Advertise the transition to your users.
Make sure your customers understand that they can now customize things in-house. Make OSS a "value-added" feature. Encourage them to return their improvements back to the community.
- Make a good testing framework available.
Most of your end-users will only have access to the hardware they actually use. Your current Q/A process probably tests against a range of hardware. As such, you own a range of test machines. Network these to a test framework that can validate community changes as they are submitted. Maintain a "stable", in-house tested branch and an "unstable", bleeding-edge branch.
I couldn't agree more. micsmith for president!
http://www.intel.com/software/products/opensource/
http://www.intel.com/cd/ids/developer/asmo-na/eng/ 52779.htm
Be sure you have good documentation. Especially for all "gotchas" like timing-sensitive spots.
In fact I'd say the documentation is more important than the code itself! You can just create a web site with the documentation, and start collecting the code that other people write, and let your programmers basically do QA on it.
But anyway this is great, and I hope you plug the name of your company here somewhere so those of us in the right industry can recommend the products!
I am the maintainer of a driver in mainline Linux. An competing driver is offered by the actual hardware vendor (also Open Source). While working with their engineers has been quite pleasant, we have never been able to agree to work on the same driver.
So the people who know the hardware best are paid to work on a driver that few people use. Meanwhile, the driver in mainline keeps up with the frequent changes of in-kernel APIs but lacks the resources to make use of all the features the hardware offers.
A few companies (e.g. Intel with their eepro) seem to get it right: Have someone work with the community to write and maintain a driver in mainline. You are still largely in control as long as you are competent, and you are pushing the code people actually use.
Take a look at:
2 28
http://article.gmane.org/gmane.linux.network/23
lkml people refused their drivers because they used HAL. Avoid it if you want respect.
The autoconf scripts are a mess. They run slow. They take up 200 to 300 kB compressed. They test for various basic POSIX features that exist already on every OS you'd ever care to support. They add several extra layers of complexity.
Better way: good old #ifdef and such. It works.
Bugzilla is an isolation tool. (see the recent trouble with GNOME developers ignoring bug reports) At the very least, you must enable voting. You also face the problem of stale bugs. Try just using a public mailing list, as the Linux kernel developers do. The system used by Debian isn't all that bad, though stale bugs still collect.
CVS leads to political problems. Commit access becomes a status symbol. Sooner or later, you will find a need to revoke commit ability for a developer, leading to all sorts of trouble. Consider using a peer-to-peer system like BitKeeper instead.
Note that the LGPL can be used for non-library code. The LGPL and Mozilla licences offer GPL-like protection for your code (others must supply their modifications as source) while not affecting code that merely links to your code.
And yes, patience is needed if you expect major contributions. Mozilla is based on Netscape code that was opened up. Mozilla looked like a failure for several years. It took time for a developer community to grow, and time for the code to get cleaned up. Bug fixes and ports will show up soon though.
I'm not familiar with your market but it sounds like you won't have a huge developer community to support you.
On the other hand, I used to work at a place where we got a lot of equipment with serial numbers like 1 and 2. We spent a major amount of time getting stuff to work basically because we had no choice. In that light, I suspect that you should be talking to your customers; not us.
Redundant?? That's not redundant. It was a dupe! Hey...if you guys can do it, why can't we?
"That is what should be on the front page of Slashdot, not this stuff about drivers that I don't understand."
/. slogan for more details)
You, sir, are an idiot. (see
... do you know for sure it won't break in the future? Binary-only drivers are notorious for breaking in every kernel release (just look at nvidia's proprietary display driver).
In addition, to that, there are various other reasons for open sourcing drivers, (probably) the most important benefit being community-based maintenance and porting of the drivers.
Definitely release everything. But supporting the open source developers? That could be difficult/impractical .. I would go with a style similar to how linux develpoment is done .. accept patches that are good. Of course supporting the open source developers would be good in the ideal world, but it will be a tough sell to management. So probablyh the most sellable approach is to develop the software like any other project, except that the code is open source .. if others have contributions and improvements accept them. Oh yeah, and make sure it's released as GPL. So competitors can't use your ideas without themselves having to contribute their own improvements back.
Usually if your specialty is hardware, the driver won't give away a whole lot of hardware trade secrets anyway. Although most hardware ideas are better protected via patents that keeping it secret (others can come up with similar ideas independently). That said, I am against patents so don't flame me.
Actually, it took a short amount of time for the mozilla project developers to abandon the netscape codebase and start over on developing mozilla from scratch(though I'm not sure if no netscape code made it into the new mozilla code or not).
It then took a fair amount of time for the project to then reimplement most of netscape and create the firefox which I'm typing into right now.
1) As others noted, do a full code audit and make sure there's no proprietary code in there at all. When in doubt, take it out. You don't want a lawsuit on your hands. Make sure you have the rights to distribute all of your source.
2) Clean up your code. If the comments are incomplete, complete them, if there's something that's obfuscated for no good reason, unobfuscate it, etc. Remember that for it to be useful someone who's never seen it, and doesn't know how your stuff works. While doing that clean up any bad language in the comments and code.
3) Make sure your code builds completely to a final useful state on standard compilers (GCC on Linux, VisualStudio on Windows). If there's any special options that need to be set, document them. Don't release something that won't compile without tweaking, it should be ready to go.
4) Don't neglect binary versions. Keep them at least as current as the source versions, if not more so. Many (most?) people don't like fucking around with compiling their own stuff. It takes time, and the compiler is scary to non-programmers. Have an easy to install binary version as you did before. Goes double for Windows.
5) Do it for the right reasons, that being to get feedback from the world at large and to help out. Don't do it expecting the OSS community to pick up your slack and develop your drivers for you. You might get lucky and find that some extremely talented individuals do just that, but more than likely if you open them up and ignore them, they'll become crap.
6) If you take community contributed drivers that you have nothing to do with (like ports to an unsupported OS), make sure you make it clear on your site that they are different. Have a clear demarcation between drivers you created and supported (with or without community help) and drivers someone else did, but you didn't make and can't support.
In general I think it can work to your advantage, but only if you treat the OSS community as an additonal asset, not as your core development. Maintain the same team you have now, same standards for testing and quality (I'm assuming they are good here) and so on. Take any useful contributions the OSS community provides, but don't rely on them to start doing your job for you.
Something tells me that what these guys want to do will involve bigger issues than number of spaces to a tab. Especially given the existence of the indent program. But hopefully there won't be any huge barriers, nonetheless. To Gerry Gilmore: what you want to do is good on many levels -- good for Linux, good for society, and quite certain to be good for your company too. You have my thanks, and my best wishes with it :)
You may want to check out the open Zaptel interface driver suite. [Google for Zapata Telephony]
It was originally developed by Jim Dixon for his Tormenta T1 card (open source GPLed hardware BTW) but has since been used with open source telephony projects such as Asterisk.
Asterisk is an interesting example to study in respect of open versus closed telephony drivers.
Some vendors have closed driver support for Asterisk, eg. Intel/Dialogic which means their drivers can only be sold through a non-GPL Asterisk License. This however means that they rely on sales through Digium, who hold rights in Asterisk. The irony is that Digium are also a telephony interface card vendor and thus a competitor.
Voicetronix have open source driver support for Asterisk through their own GPLed drivers. Yet, the action on open source drivers is with Zaptel and so Voicetronix have to do the work on their open source drivers all by themselves and their drivers lack features that Zaptel drivers have.
Sangoma Technologies support Zaptel in addition to their own drivers. To Asterisk and other telephony packages using Zaptel, a Sangoma device is just another Zaptel device. A significant benefit for end users, open source projects and the vendor.
Zaptel is now supported on Linux (x86 and PPC) and BSD. In addition, work is under way for Zaptel on Solaris and MacOS X.
the macintosh asterisk mailing list http://www.astm
NVidia's case is even worse. The kernel driver is just a hook for their closed-source OpenGL libraries. The company prevents other software from being able to use the various 3D and animation features of their cards by hiding them inside the OpenGL library, and the open source community has no opportunity to contribute or gain from that software. Because the OpenGL libraries are closed source and the licensing does not allow even binary distribution without individuals signing the NVidia agreement, they can't be directly integrated into any package management system and updating the OpenGL packages will also break the NVidia usage. It also means that X Windows configuration tools can't be written to fully detect and use the NVidia cards, the X configuration files have to be manipulated by hand or by the NVidia installation tool.
Make sure you tag each release with a tag appropriate to its stability (prealpha, alpha, beta, stable etc.) Also you might want to do what redhat did with fedora and have a section if the team working on the drivers in an open source manner. naturally keep the binaries available for download too. And make sure it compiles on GCC and mingw. Good Luck!
Open-Source > *
And you, sir, have been trolled.
Thank you for your interest in finally removing your head from your posterior.
I would like to suggest the following:
- Communicate with your application developers openly. You rob yourself of invaluable feedback when the forums you sponsor are not as free as the source.
- Particiapte. While it's not neccessary to feed the trolls, your guidance and expertise are critical to the success of the project.
- Take a resolute approach. An insistance on silly extra clauses added to otherwise good licenses only curtails adoption. Be free, or don't bother.
That doesn't mean that you wouldn't want to scrutinize the comments carefully. Profanity might not be a big issue, but sexism, racism, or homophobia would look very bad for your company, for example. Also, you might want to remove trenchant criticism of your own (or even other companies) products.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Existence isn't enough: they've got to actually use indent in order for it to be useful.
And preferably a PCI Express board too...
they lessen the future load on their support desk
At some companies, the support desk just has a button on the phone to transfer the complaining customer to sales. *ring* "Yes, you want to buy one of the newer, supported fribbitzes?"
Not saying it's good, or bad.
I am the CTO for a telecom company that once used hardware from this "very large supplier". Having worked with their products, I would be very surprised if the code for their drivers is not a train wreck. We struggled for over a year to get their PSTN boards to work with a generic ISDN PRI network.
We switched from this company to a smaller vendor that shipped PSTN and VoIP boards with stable drivers. We've never had a problem since, and will never go back to the previous vendor.
As for open source, if I am paying ten or twenty grand for telecom hardware, I expect the vendor to have developed and debugged their drivers. I am a customer. I am not their development team. So I could care less if the drivers are OSS or not if they work. If they don't work, I am going to buy hardware from another vendor.
Maybe I am cynical, but I suspect this company is looking at OSS as a way to dump more work on their customers.
Interesting, a study we did showed that in terms of productivity and readability 2 space tab indents was optimimum. "Why?" I hear you ask - any developer that's worked on a project of any size above "tiny" will know that large indents don't aid readibility, unless your code is very 'squished'. Which brings us onto one of the most important aspects of any project - white space.
Let's look at the following chunks of code;
Many would write a simple for-loop like this (using standard 8-space unexpanded tabs);
for(int l=0;l10;++l){
printf("%d\n",l);
}
versus the more experienced coder (using 2 space expanded tabs);
for ( int l = 0; l 10; ++l )
{
printf ( "%d\n", l );
}
Maybe it's just my opinion (and many others on projects I've worked on), but the second is far more readable and when a new coder comes along to maintain the code she/he would have a much easier job going through the code to figure out how it works. You may not believe me, but take any large chunk of code you may have and take the time to space it out and re-indent it - I guarantee that any decent coder will see my argument is correct.
I wrote that driver, you insensitive clod!
We are a division, specializing in telecommunications equipment, of a very large hardware manufacturer. Our equipment, DSP and PSTN boards, has been supported under Linux
So? I use and sell FreeBSD. Unless your drivers work on FreeBSD why should I care?
The zaptel people^H^H^H^H^H^Hmanagement don't^H^H^H^H^H^Hdoesn't support FreeBSD, but I can get FreeBSD drivers at least.
If your hardware is closed source, how is it gonna run on FreeBSD if you don't support FreeBSD?
Well?
http://developers.slashdot.org/article.pl?sid=05/0 3/19/1411219&tid=117&tid=190&tid=156
from which one can locate this very relevant title:
"Unmodified Device Driver Reuse and Improved System Dependability via Virtual Machines" at
http://l4ka.org/publications/paper.php?docid=1208
?
sort of looks like a good solution....
Get into the official kernel. If a driver isn't in Linus's tree, it doesn't matter, so you will be on an endless treadmill of API breakage. Once your driver is in the official kernel tree, the kernel hackers will take responsibility for most of the API refactoring.
Know the politics. Most Linux kernel developers aren't accountable to anyone and don't negotiate. You will have to put up with whatever requirements they give you if you want your code to be part of the kernel.
Know the effort. You will probably be asked to rewrite your drivers, possibly more than once. This will take months. If you don't do it, then open-sourcing the drivers was mostly wasted effort.
As others mentioned, coding style is important. Also, wrappers are not allowed in the kernel, so call kernel APIs directly instead of wrapping them. The result is a totally Linux-specific driver, but the rules are the rules (see above).
We were using a PCI card from a company that previously had only provided precompiled binaries (and possibly windows DLLs, but that wasn't well documented.. you were supposed to you their app). But their app was a bit buggy and had some weird quirks and we wanted to run our systems on Linux through Python. We got some drivers from the company that were obviously recently opened. The sample program that they gave us to show how the API worked didn't quite work properly because there were bugs in the kernel extension. And nothing was documented/commented except for about half of the struct members. Some of the defines were called MAGIC_NUMBER and half the features accessible in Windows were commented out. And on top of all that, there were two naming conventions in the same module. I suggest not doing any of those things, and document/comment throughout as people will be using it and trying to understand or customize it.
The Code Master
As a developer of binary drivers you are used to having complete control over your code, and "pushing" all updates down-stream. But once your code goes in the kernel (which I highly recommend - don't let it languish outside Linus' tree), you'll have to consider how to deal with code changes coming TO you FROM the kernel developers.
This is both a good thing and a bad thing. It's good because you'll get fixes from people testing your code on all sorts of weird platforms you've never heard of. It's bad because you can wake up one morning and discover the kernel API for your type of driver has changed overnight, and your code won't even compile until you re-write half of it (there go your plans for the weekend). A certain amount of lag is acceptable, and you can restrict support to the stable kernel series only if you want, but expect to hear a lot of whining from users who will demand that you keep up with the cutting-edge development code.
If you don't have any concern on piracy, counterfeit, probably ok. Companies can steal and clone the hardware, microcode. I've seen many they just change the logo, company name in the binary and claim it is their products. Opening the source is pretty much a "thank you very much", now we don't even have to worry about being caught that our binary is the same as theirs. (Just not long ago it was sort of a big news that 5 major cdrom makers use the same firmware original made by another company) Many think it is fine since our primary market is the US and we know our clients. Remember most of the customers have no knowledge on how to tell the difference. Does your company have time and energy to deal with it when someone import them to your primary markets?
I can think of two things to look at with respect to comments.:
First of all, you would like your comments to be meaningful, understandable and accurate. (I'm sure I could find you some juicy counter-examples in my own code).
The second thing (which, I think the grandfather post referred to) is: You might want to edit out comments like
- "I was going to shoot George Bush but this seems even more insane",
- "This is the worst IP violation I've ever committed", or
- or "This code stinks worse than our hardware."
You know -- stuff that just might embarrass your PR group if it got published on slashdot. There probably isn't a whole lot of stuff like that, but you should hire a couple of young code monkeys to go a quick read thru your code, and flag anything even vaguely questionable for your more senior programmers to vette.Murphy's law says that you won't necessarily catch everything that might be embarrassing, but if only one or two nasty examples make it past the review, you can always blame it on too much coffee. If there's lots of stuff that you find on a quick audit, then you might want to delay the public release for a couple more months while you go over the code with a fine toothed comb.
If you can find some code monkeys with OpenBSD style auditing experience, then you could possibly add in cleaning up the actual code to the benefits of such an audit. This code is going to represent your company (unless you release it anonymously), so it'd be good to release the best code your resources allow you to generate.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
In this case, you're talking about *your* house, not about a house you built that someone else bought. If your house-builder had locked rooms in YOUR house that you weren't allowed in, wouldn't you be a little suspicious, if not a whole lot ticked off?
I really fail to see how anyone can expect to continue to own any part of something they've sold. It's just plain silly and it's going to become very damaging to society at large before long.
I hardly threatened to come lock him up for it. I am giving some advice of what to do before release. The fact of the matter is that the code released will reflect on his company. You want that reflection to be as professional as possible. Well, bad language is generally seen as unprofessional, so it's a good idea to eliminate it. It certianly won't hurt, it's not necessary to convey how the code works, so just take it out.
:).
However, it's just my advice, I'm certianly not trying to force it on him. If you don't like it, you can go fuck yourself with a rake
You know -- stuff that just might embarrass your PR group if it got published on slashdot.
I've found that most PR groups are a bunch of idiots who can't give up control. "You cannot use the 'official' university font or logo in any of your webpages or documents" kind of crap.
It's funny to think of handing them a million lines of source-code and asking them to check it before you release it a week later.
I hate to bring this back on topic, but the subject is device drivers for linux. There is no need for any configure script because they only need to run on the current kernel. You know in advance exactly what is there. The most you might need is a depends line in the makefile to be sure your not getting compiled when someone you need isn't. (that is don't compile your SCSI card driver if the SCSI subsystem isn't installed) Should be trivial to do this.
I use 4 myself, been coding in C/C++ since 1987.
A 2 space tab is too small to see the relative indents over several lines of code, most of which seems to be nested between 5 and 7 levels deep for the real guts of it.
And a tab size of 8 is way too wasteful.
One good reason is that it can be a practical impossibility to guarantee that your code and/or the associated hardware doesn't infringe someone's patent, particularly a software patent. Maybe your competitor's patent. Maybe your competitor didn't have a clue either, until they looked at your (now open) source that they couldn't see before. Oops.
By definition, PHB's are not technically astute, but they have lots of practice thinking about risk.
You really have to understand where your IP is... if you can move you IP to software and keep as much intelligence and cost out of your hardware you will save money for all of us. It is far better for the community to have IP in software that saves hardware costs than to have big markups on hardware and trying to obfuscate the IP into the hardware unnaturally. Most anyone can sell added value through software cheaper than through hardware, plus you can then permit generic hardwave to be used.
... you will just add costs and reduce innovation for all. we don't need any more chips with unnecessary embedded hardware that could be done in software, were it not for that fact that not one seems to worry about "open sourced" chips rather than what is open sourced. We don't need any more complex, hard to update hardware when the key (IP) code can be done in the host.
So, don't make move your paid IP into hardware just so your can make your product "open source"
Using nVidia drivers specifically (since I have seen it), their driver source exposes a whole heck of a lot of their IP. I am sure their stockholders would not be too thrilled to have the lionshare of the companies value (and their stocks) exposed simply to satisfy a desire.
I see no problem with binary drivers and wish linux had better support for such instead of having to roll everything into the kernel...uggh. I have gotten into some really nasty arguments with some of the kernel people about the ABI (you know who...). It's one of two or three big issues that severely hurt linux on the desktop...
Just as IBM is being asked to pull out 30 years worth of source code for SCO, your company might be asked to do the same by some company abusing the legal system. If your whole source evolution may be viewable, that suggests that only a ground-up rewrite can hide some of your nastier ethical and social improprieties. The best option in this situation is making it open-source from the start (even basing on open source code) and black box testing against your old code. Making it open will do a lot to keep it clean and test it hard.
True, your company may have signed all sorts of legal entanglements with your old source, but you'll probably have to rebuild it all from scratch anyway in eighteen months or whenever Longhorn is finally unleashed. Starting over is inevitable; get a jump on things and start that re-construction effort from scratch now with an open source driver. Whatever changes you have to make for Longhorn, you'll be starting from a trunk of source that's stable in execution and legality.
My personal view is that two-space indents encourage excessively deep nesting. It's just too easy to nest conditional structures and loops very deeply without your code looking too contorted at a glance.
;-)
... and work with other indenting schemes when doing quick fixes to less familar code. Big deal - it doesn't seem to matter that much if your editor doesn't suck.
Of course, that's the viewpoint of someone who doesn't use two-space indenting
I'll use whatever the code I'm working on uses reasonably comfortably though. I currently regularly work on code with:
<ul>
<li>4-spaces-indenting with a tabstop of 8</li>
<li>4-spaces-indenting with a tabstop of 4</li>
<li>4-spaces expanded indenting</li>
</ul>
My own code is usually 4-space-expanded for Python code, 4-tabstop for C++, and 4-space-8-tabstop for Java. Those those are the conventions followed by the code I work with most in each language, and they work OK for me.
The only language I even understand why people care strongly about indenting in is Python (where I maintain that unexpanded tabs are madness).
Nested 5 and 7 levels deep?
Eek.
The only code I have to work with that's like that is a jungle of pseudo-OO spaghetti, full of 500-line-long case statements and loops. It's horrifying.
I've never yet been happy with my own code when control structures end up nested more than about 4 levels deep, except sometimes in _extremely_ localised blocks.
In the telecoms world, many drivers aren't that interesting; all they do is provide an interface between the application and the firmware running on the (usually DSP-based) card - I bet that's not going to be part of the source.
So you'll need to watch out for people who see this as an attempt to outsource the OS driver work (for free), while retaining proprietary control over the firmware (and thus limiting what can be done with the hardware).
http://support.intel.com/support/go/linux/mbqskit. htm
With all due respect, your advice seems rather inappropriate for the kind of drivers we are talking about here. This is not about storage controllers or video cards.
If every vendor of telephony gear was to insert their APIs and drivers into the Linux kernel, you will have to rename it to something like "kernel mode telephony library with some minor operating system features attached".
the macintosh asterisk mailing list http://www.astm
If you are talking about the features, those features are *obvious* to the purchaser and thepublic at large (unless you are spending money on capabilities you don't want people to know about). So the features can be copied with or without your hardware or software.
Paranoia is correct - the unreasoning fear that someone is out to steal your hardware.
When the people on slashdot feel comfortable letting the marketing guys handle servers, I'm sure the marketing guys will let the people on slashdot handle branding issues.
- Hubert
This point is too subtle for most ./ers. They are so religious about their indentation level that they become combative and stupid from the outset and will never understand the difference between TAB and an indentation level setting. Given the current level of discourse we should get rid of the TAB character altogether and mandate space-only indentation.
That's just fine. But if they want control over everything, they need to be responsive by getting things done and have useful information on the school website.
As a blatant example, it's a disgrace to the school to have sports and music schedules that are 3 years old attached to "upcoming events" on the main page. Equally lame was that PR would not allow departments to post lists of classes being offered.
But I think the most absurd was that PR would not even allow the School of Business, which has professors being entrusted with teaching things like marketing and branding, to have input about what was on the website for the School of Business.
It's really sad because while the website is pretty, it's really devoid of useful information. If I were a prospective student I would quickly dropped the school from consideration just based on how lame the website was. In my case, I worked at the school (systems administrator) and got a nice discount.
It was frustrating telling professors and department heads, "Sure, you COULD have your course schedules put online, as well as a staff directory. In a technical sense, it's quite simple to do, really. But you'll have to get it past PR first."
Going back to responsiveness, I was assisting a professor with creating documents for a series of seminars he was contracted by the state to do through the university. We created brochures for the seminars, giving descriptions, agenda, etc. Because it was done through the U, PR demanded final approval on the things. I would agree with that in general. But, even with persistent hounding, they did not bother to take a look at them until after the seminars had already passed. How were we supposed to get the word out, and people registered (and paying) for the seminars if we can't send brochures?
So, maybe I'm tainted by my bad experience with PR where I worked for several years. But my general feeling is that PR folks are arrogant asses who don't give a shit about what other people are trying to accomplish and who feel that as long as it looks pretty, there's no need to have current or useful information available for people.
That's not good branding. It's just being an ass.
How can my ORIGINAL post be redundant? Is it redundant because the response to my post was QUOTING me? Ever heard of QUOTATION MARKS?
Nobody has mentioned any of what my original post says before me. It may not be of interest to you, but one thing is absolutely certain: It is NOT REDUNDANT. You may want to learn the art of reading first, Mr.Moderator, you definitely have some catching up to do there.
the macintosh asterisk mailing list http://www.astm
Obviously, you worked at a space where the PR peoplke had a serious power fixation and had implemented their plans of local domination. I'd say that the Borrd of Governors needs to jerk their chain something fierce.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.