Slashdot Mirror
Upping The Softmodem Code Bounty -- To $20,000
Alex Pilosov writes: "I've announced a bounty for completion of softmodem code (20k$) on linmodems-discuss list. If this is successfully completed, we'll have a completely universal driver for any kind of winmodem without any proprietary code which result in all sorts of kernel version problems." Here's the full text of the announcement and conditions.
seems to me that $20,000 is an awful lot to pay for the ability to reliably run softmodems in linux...almost like we're trying to beat the corporations more than accomplishing the goal.
with the prevalence of high speed connections these days, i find it odd that we're seeing a big surge for a (slowly) dying technology. linux users tend to be people who value their connection enough to get dsl or a cable modem.
i guess my observations of the current state of technology are a bit skewed by living in a college town where every apartment has "T1 Ethernet" (ha), so i'd be interested in hearing what others think about the worth of modem development.
Can't people figure out the following reasons for such a project being interesting ?
- Low cost internet station for places out of reach of xDSL / cable modem connections.
- Viable internet connection for legacy hardware / second hand hardware
- Excellent solution for development countries where xDSL is faar away yet.
The keywords here are LOW and COST.. Did you ever consider that Linux and second hand hardware might be the ultimate combination for places where they don't have as much cash as yourselves ?
d9s
life+universe+everything=42
I was curious about his @pilosoft.com address, but the site is blank. However, a google search on his name revealed a personal homepage.
One thing worth noting: he's 22 years old.. hmmm. According to his resume, he has contributed to apache, mod_perl, postgresql and freebsd.
My personal guess is that he has convinced one of his employers to pay for this (Lazard Ferez & Co., which he works for, seem potential, but i don't know enough about them). I'll be following the bounty thread.
Anyway, I think he is for rea and wish him good luck. Here's a picture of our hero
-Kraft
Live and let live
Regardless of the coolness factor of this bounty, the fact still remain: A GPLed softmodem driver still requires certification by the telephone companies before any device is legally connected to the telephone network using the driver.
My guesstimate are that it's much more difficult to obtain certifactions for the driver around the globe than it is to write the driver. The telephone companies are rather picky about what the allow onto their networks
Thomas S. Iversen
Have you actually looked at the drivers available in linmodems.org? look for example at the Cirrus Logic driver and look at the IBM's MWave driver - they have some common goal - they're emulating V34 and V90 protocols for example - but each chip is doing this TOTALLY differently, try to play a bit with the binary only ltmodem to see what I mean...
A unified driver won't work here since almost each DSP chip which is a WinModem is totally different from others - look at the HSF modems DSP chips (conexant) VS. Lucent WinModem DSP chips VS Cirrus Logic VS TI's DSP chip...
Or I might didn't understand you well Alex, could you give more details? You also didn't give any details about what do u offer for a group of programmers - who will get what...
Hetz (Heunique)
You MUST have background in signal processing
Dear Mr. Torvalds,
We could not permit your so-called "operating system" to use GNU license because you do not have proven experience in the operating system design and your background is not sufficient. In order to satisfy our customers,
and maintain high project code quiality, we accept contributions only from candidates who have experience in the particular area and passed interview with some of our managers.
(signed)
Free Software Foundaiton
I think that this bounty thing could maybe be a really good way to fund the development of opensource software.
I think it is very nice that Alex Pilosov supplies the money for this, but there could have been a better way to get the money for bountys like this one. I think there are a lot more than 20000 people that run linux on a notebook with a softmodem and like to have a piece of the software like this. If they would all have spend a dollar, this would have been a mucher nicer method of raising the money for a bounty like this.
I want a webpage that is a combination of PayPal, freshmeat and sourceforge. Where users could donate money to a bounty for a project they choose. If no one is able to reach the goal that is needed for the bounty the users get their money back.
Jan
I'm just wondering if perhaps someone has patented the algorithms used to drive these soft modems. A Free Software implementation of a soft modem driver will thus be in violation of the patent then. As far as I can tell the ITU, the standards body that defines these modem standards, allows what the W3C calls RAND licensing, as they state in patent policy (excerpt):
It's paragraph 2.2 that worries me. If any patents exist on the modem standards implemented by soft modems that are thus RAND-licensable, any GPL implementation is impossible. I believe some of the compression algorithms used in some of the modem standards are already known to be patented, such as the infamous LZW compression algorithm held by Unisys that has caused the huge flap over GIF's a couple of years back.
Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
You'll worry about performance when it's working, silly.
Besides even with a low-end processor by today's standards, the "crawling" will be like below 10% CPU usage.
Oh, and if it's still too slow, someone may just optimize the code with MMX kind of stuff. But you can't optimize what does'nt exist. And you should'nt obsess about optimizing before you have something actually working.
As far as I can tell, this project doesn't solve the problem of winmodem manufacturers not releasing hardware specs. In other words, you'd have a driver that can tell a DAC/ADC driver what to squirt down the line and work out what the stuff that comes back means, but you still wouldn't be able to use the actual winmodem; you'd have to use a DAC/ADC for which you have drivers. This means either buying a supported modem or a separate DAC, or trying to figure out how to drive the winmodem's DAC and ADC directly.
Of course, persuading manufacturers to release one or two port adresses and a little info on how to use them may be easier than getting them to release full Linux drivers or complete DSP specs. Likewise, working out how to access the DAC/ADC on a winmodem is probably easier than trying to figure out its DSP (although the DAC/ADC may be only accessible to the DSP, which may make things hairy).
No serious developer is going to go after a bounty, because you only have a 1/N chance of getting the prize if there are N other contenders. The person who finishes first is going to be the one who cuts the most corners and spends the least amount of time on design and documentation, so you'll end up rewarding the person who can produces the crappiest software to a minimum standard faster than anyone else!
The competitive aspect also makes people keep their work secret, preventing peer review and feedback.
Sheesh, if someone has $20,000 to spend on software development they should just HIRE a skilled person who will get the job done properly. It's not like there's a shortage of skilled software developers at the moment! They don't even have to be a free software developer because if you're hiring them you call the shots and choose whatever license you want.
WinModems, in contrast, are just a big hassle: they consume oodles of CPU time, they have non-standard drivers, and you have to worry about them with every OS. If your laptop has one built-in, complain to its manufacturer (it probably would have cost nothing to add a real modem) and don't bother using it.
Not only you are right, but also any communication equipment connected to the phone network must be licensed by the local communications agency. This happens in many countries. Most of them will never bother to go after people connecting linmodems on the phone network, but some countries are very rigid in this control. This licensing, or approvement, must apply to the communication equipment as a whole. You can't license only the hardware part of software modems, since many times is the software that will decide the line levels to be used. (In Lucent winmodems, these levels are selected via AT commands, when you select the country you are in. This is done via software). This process is necessary to avoid people connecting devices to the phone network that could ruin the network.
So, in short, even if we don't worry with the patent issues of v.xx, we still have to worry on licensing the linmodem software, but since free software can always be modified, there will always have a non-approved version of it, which can cause legal problems.
Say no to software patents.
I doubt you can implement those ITU standards without infringing on a couple of patents (at least a few companies will claim infringement as soon as you publish the code).
If you have to pay the lawyers from your $20,000, this doesn't appear to be a fair deal.
I've often thought that it is in many companies interests to find ways to screw over Microsoft, even in ways that are apparently not directly beneficial to them. I've always thought that this is probably one of the main motivating factors behind openoffice.org - it might not generate much profit for Sun, but it has the potential to kick Microsoft where it hurts, as the cream of their profits come from Office. Similarly with IBM's support and nurturing of SUSE, Mandrake and Redhat.
Of course there many be companies that have identified places they want to kick Microsoft but don't want to do it publicly. Take Intel for instance - despite their long-term relationship with Microsoft I'm sure they would prefer to drive sales of their processors by releasing open source developers toolkits that exploit new features they add to their processors. So its in their interest to promote the uptake of Linux, but without risking the wrath of Bill. This is one way they could do it - give bounties via a third party for development that they see as strategic for the wider uptake of Linux.
And not just Intel - there are many other companies that have the motivation to do this type of thing but don't want attention drawn their way.
Perhaps if he placed a deposit with some trusted third party (Mad Dog, Eric Raymond etc) people might be happier to devote the time.
Bounty $20000 for developing an application that will bring your computer to a crawl.
AFAIK nobody suggested that the driver has to be written in Java
disclosure: I AM a Java developer and I was just being sarcastic - no flames please
You can accomplish anything you set your mind to. The impossible just takes a little longer.
V.42bis and MNP5 should be optional.
As long as the software is able to properly negotiate no compression with the other modem, requiring Compression adds a substanial amount of work that can be post-poned or have another person work on it.
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com
No one has heard of
linuxfund.org
?
I've had enough abrasive sigs. Kittens are cute and fuzzy.
I would think that the motivation for something like this would be obvious. For a company to develop drivers, either for their own hardware or someone elses, would be WAY more than $20,000. That's a couple of months of contract time for one person, if you are lucky.
This way, they get the drivers they want, the OSS community gets another wrench for the toolbox, and everybody wins.
Why look a gift horse in the mouth, folks? Get coding!
"You can't have everything. Where would you keep it?" -- Steven Wright
Code must not rely on DSP, pure C required.
So let me get this straight: If the modem is an HCF modem (i.e. has its own DSP) you aren't allowed to use it. In other words, the guy is putting up $20k for someone to write a universal HSP driver. Interesting notion.
I'm sure there's v.34 code available. v.90 may be a little trickier. The neat part about this is that you should (in theory) be able to use your soundcard and a part-68 interface for a modem if this is pulled off.
M$ has convinced many hardware makers that M$'s method of code breaking and bloat are the only way to drive new hardware sales.
I think this probably underestimates the sophistication of thinking at hardware manufacturers, and the diversity of the market.
Take, for instance, the 3D computer graphics sector. I am sure Intel was very pleased when Microsoft started to make a big drive to get NT used by companies in the 3D graphics production/rendering market, because they regularly buy lots of boxes. However, I bet they are even happier now that NT/Windows is no longer seen as attractive in this sector, and everyone is moving to Linux. Why? Because now they can add features to their chips that make them more attractive to this sector, and release the code as Open Source to stimulate need and uptake. They tried to do something similar before with Windows, but MS firmly stamped on their efforts.
Hmm. It looks like he's a troll from sector 7G sir.
ALEX PILOSOV
83-60 118 St., Apt. 7G
Kew Gardens, NY 11415
hmm... for fun I enjoy launching DDoS attacks against 127.87.42.5
Interesting; I did not see this second message from Alex. Have I been unsubscribed from the list over the weekend, I wonder?
I'm going to answer a few questions that have been raised, and a few that haven't.
Is anybody working on the code?
Fabrice started first. Unfortunately, he has been quiet for a very long time, and I have no idea if Fabrice has done further work on the modem code. I hope he is still well and healthy.
Meanwhile, I have been secretly still working on my code base (that's the one at tantalophile) all this time. It has been an on and off affair, and I've found it difficult to find the time, energy or focus what with the day job and other projects. I keep foolishly trying to improve on the standard algorithms ;-) Nevertheless, bugs have been fixed, features added, tests done, signals are processed better than ever and I have a nice set of graphs showing simulated error performance of the V.34 core under various conditions.
In other words, there's a long way to go and please, nobody hold their breath, but there has been substantial progress and it is not on the tantalophile web site. So don't slashdot it, thanks :-) I'm making no promises about when my new material will appear, but I do promise it will be announced on the linmodems mailing list.
About the bounty
It's a bit of a nice surprise to see that offered. I'll be contacting Alex, but to be honest I am motivated to complete the project anyway. I don't want funding to dictate the goals of the project (which should be educational and of high quality, IMHO, as well as functional), although some influence would be understandable. It is likely to make a difference to the schedule though.
Legal clarification and/or commercially backed negotiation on the patent issue would be invaluable, and help with testing is also very valuable.
I didn't respond to the original $5000 request because it is not a lot of money. Considering the large amount of time, effort and to some extent resources already spent on the project, as an estimate for the remaining work, I would certainly not accept a commercial contract at that sort of rate. $20000 is rather more interesting, but I think Alex's request for V.90 is unrealistic if he wants it on a short timescale.
One thing that would be a bit upsetting is if all my work were quickly overshadowed by someone else, suddenly motivated by cash, throwing something together. But I cannot complain as I haven't exactly been speeding ahead or keeping with the community on this. I know how the Hurd feels ;-)
Standards compliance, approval, and "homologation"
This is quite hard, because anyone can modify the code and thereby break any certification of the code.
Different countries have different standards. There are differences in the energy that can be emitted, both the peak instantaneous energy and a longer term average are limited. And you don't always want to max out the energy anyway, as you're avoiding distortion.
The relationship between voltage and current is not the same everywhere. Dialing tones, engaged tones and so on vary. V.90 coding varies because the USA operates at a lower digital bit rate than most of Europe.
Some people have said that it is the hardware which is subject to regulation. This is not true. I believe there is a certain certification level for the hardware itself, for avoiding excessive energy input, making sure the hardware doesn't go up in flames when receiving the 100V ring pulses or a lightning bolt, that the impedance is matched, and so on.
However, it is (theoretically) necessary to certify the software as well for many reasons. A good example: by modifying the software, you can transmit more energy on a USA telephone line, using a USA modem, than is permitted by federal regulations. That excessive energy is considered to potentially interfere with other people's telephone calls. So, you do have to get the software right.
Fortunately we have a good example of certification in the Linux kernel. Some versions of the Linux ISDN code are certified for use on the German telephone networks, I believe. The source code is checksummed. I note with interest that it's the source that's certified, and not the binary (so the beurocracy is ignoring bugs in the compiler or the rest of the kernel).
For myself, I am very keen to write code which certainly does conform to all the known requirements. I don't feel comfortable hacking together some "it seems to work" code of this kind and releasing it like that. It's partly a reputation thing, and partly a responsibility thing.
On patents
Yes, there are many patents. Unfortunately the detailed patent situation is unknown. It is possible that the patents don't apply to software implementations in most countries, but we don't know to what extent and where each patent applies.
We don't even know which patents apply! However, there is an online list at the ITU which may be helpful.
This is hopefully an area in which Alex Pilosov and his (possibly) commercial backing can help in a big way.
I am of the opinion that users have, in general, already paid for their modems and so they should already have permission to use the techniques. It seems to be the case that software modem drivers for Windows are downloaded and installed with no attention paid to these matters, so it should not be any more of an issue for Free Software. It would be good to know for sure.
The developing world
Telephone line driver chips are cheap! For the developing world, getting an internet connection over crappy copper would be a wonderful achievement, and with full access to a software modem, you could cobble the modems together from parts.
For this reason I think it is important that the softmodem works well over poor lines as well as good ones. And yes, I would love to code "workarounds" for when the standard algorithms don't perform well on Nepalese copper lines, or wherever. It would have to be a special variant of the code, for the regulatory reasons stated earlier, but it's a lovely thought.
Is it still worth writing a software modem in order to use "winmodems" on Linux?
The motivation has certainly waned, now that many previously windows-only modems are now supported on Linux by binary-only drivers from the manufacturers. Of course, you cannot use them if you're using the wrong kernel, or SMP, or if you have more than one modem, if you don't permit binary-only drivers, if you are using an Alpha or a PPC-based iMac, or if you want to run any-BSD. But hey, a lot of users are happy enough now, so that does remove some of the motivation for writing the code.
Which leaves the educational aspect. The interior of a modern modem is not well documented, even in books about signal processing. To be sure, many of the classic algorithms are very well written up, but the details as they apply to modern modem standards are not, and there are some algorithms which V.34 and V.90 clearly require which I have yet to find any information about. (Welcome to re-inventing the wheel, but it is fun!) As Alan Cox once said, the V.90 standard is "semi secret". Read it sometime, if you don't mind paying the relatively modest fee, and you'll see what he means.
Revealing just how a modern modem works, in the form of working code that (I hope) is readable by those who wish to study it, then, is as much a goal for me as getting winmodems working. And it's interesting because I'm still figuring it out myself :-)
Interfacing with the hardware
Several people pointed out, quite correctly, that a software modem won't actually work with any of the hardware "winmodem" devices. This is correct; we need device drivers too, and that is accomplished by reverse engineering the original drivers.
I don't know Alex's exact requirements. He doesn't mention needing PCM drivers -- perhaps he has his own drivers already? But if he requires reverse-engineered PCM drivers as well then that's quite a bit more work.
Progress on that front is being made, by several people, but it is really a separate project. It is worth noting that there's a GPL'd Lucent modem driver that can do PCM. It is actually quite old now. I have faith that the PCM driver part of this problem will be solved by eager contributors if there is a good softmodem to make use of it.
Cheers,
-- Jamie
I'll be brief with the hurdles you will have to overcome:
Motorola holds the base patents on host signal processing, and I'm not sure how the Open Source community can get around those patents. Given Motorola's hard times, I doubt anyone will convince them to provide a royalty-free license to the patent -- especially as they have a soft-modem product in the race. (But then again, they concentrate in the Windows marketplace, so a Linux license could happen...maybe...if the moon is right.)
Then there is the CPU intensive nature of HSP modems. Depending on the quality of modem you are trying to do, CPU horsepower requirements are huge. A bare-bones V.34 implementation requires around 40 MHz of a Pentium-class CPU, while a robust bells-and-whistles version needs something like 90-95 MHz. Don't expect a 486 to handle the load. To be as good as possible on as many platforms as possible, the signal processing code would have to use integer arithmetic instead of floating-point, because the floating-point performance of x86 class processors varies quite a bit from chip type to chip type.
Can it be done? Yes. Can it be done to the expectations of the Linux community? I don't think so, unless one of the big boys (Motorola, Connexent, Nortel, USRobotics) decides to weigh into the market and provide already-developed code and an interface.
I'm investigating which precisely patents are these (some of them have patent numbers, some don't).
One of these is U.S. Patent 4,558,302 on LZW compression that the V.42bis standard uses, owned by Unisys Corporation. Unisys's policy since mid-1999 has been not to license the LZW patent to free software projects.
Will I retire or break 10K?