When we were making the Itanium work at HP, we ran into the reason that binary drivers are not sufficient, no matter what the interface.
A lot of the development of Linux performance has been at the driver level. This is entirely logical, and shows no sign of stopping. You should also note that a major cause of Windows crashes, perhaps the #1 cause now, is the third-party device driver that they don't control.
Rather than provide Linux support, please just document it for other people who would write drivers. That's really all we want.
Do you know about TAPR? That would probably be the best organization to run this out of. They make hardware successfully and have been doing so for 25 years. They are sympathetic to the goal-set.
Well, they've been the poster boys for accepting non-free stuff into Linux lately. So, I'm not sure they'd be sympathetic. But if I had the right people, I would give Mark a try.
The gate array manufacturers have already been asked to document their bitstream by any number of people over the years. They consider it part of their "secret sauce" because it reveals something about the structure of the chip that they'd rather keep quiet. At least that's what they say.
The main improvement in gate-arrays is in density, not architecture, and density is a property of the fabrication process, so we're not really talking about 10-year-obsolete chips.
But not everyone feels that firmware BLOBs (or opaque firmware files) are cool, even if they are to run in the separate processor on the card. RMS certainly doesn't like them, and that was part of his discussion with Theo. I think that properly handled - which means loaded at run time from a user-mode program - they would be GPL-compliant because they aren't running in the same processor or address space as the kernel. But if I had my druthers, I'd have the source.
I don't like that Mandriva, Ubuntu, and SuSE accept that stuff either, and I agree that it works to undermine us. But you're not really talking about Linux developers. Just Linux commercializers.
I think the question of whether you can Open Source place-and-route software is one of efficiency vs. time. No doubt some of the expensive code out there gets as close as possible to the theoretical maximum you can get from the device. I think that if we are willing to accept less efficiency at the start, we can get what we need from Open Source. Consider what the Linux kernel was like when it was new, and how it has developed over 10 years.
I have looked at the FCC rule-making and do not see that it prevents Open Source drivers, regardless of the hardware. Those drivers should enforce operation within the part 15 regulations, unless they are being operated by a licensed Radio Amateur. We do have open drivers for a number of cards, and FCC has never made an issue of it.
Hm. There are two issues here and I'm a bit confused regarding which you mean.
One is place-and-route of the full-custom design itself. We might have to use proprietary software to make the mask. I'm not insisting on starting from first principles.
The second is compiling VHDL to the Open Source bitstream. In this process you have to decide how to make the requested logic by interconnecting the raw logic blocks of the gate array. My impression is that Open Source does exist to do at least part of this job. I don't know how good it is.
I remember being copied on some of the discussion between Theo de Raadt and Richard Stallman. I think what happened is that Theo started out to get BSD-licensed BLOBs from manufacturers. And then, perhaps even through discussion with Richard, Theo was convinced that BLOBs were bad even if they were BSD-licensed. There was also some discussion from Theo about the fact that FSF and Richard hadn't ever supported Theo's work. And at some point they must have worked all of this out.
But FSF aren't the Linux developers. If you ask them, they will be very adamant about that.
AC wrote: What would end the argument, Bruce is open-source hardware.
Yes, that would be excellent. How do we get there? OpenCores.org has the start. However, all of the gate-arrays that they have to work with have a proprietary bitstream format and thus they require proprietary tools to program them. We need an Open Source gate-array to facilitate Open Source hardware. Initial full-custom full-wafer mass fabrication cost is about $1 Million. At that point, you can get the parts down to a reasonable price. You can do small runs in MOSIS (or whatever they have these days) to make sure the design works before you go that far.
I figure this is at least $2 Million to get done. We need good hardware designers and people to help write the grant. If I can hook up with such people, I'll do whatever I can to help. I don't have the hardware expertise to lead this, or I'd already be started. Any volunteers? I'm quite serious.
BLOBs are bad, and their legality in the kernel is questionable.
Of course really free drivers that let us extend devices are better.
Leaving BLOBs in the kernel might just mean you have
different plaintiffs than if you used a reverse-engineered driver.
However, full clean-room reverse-engineering a free driver with full source
code, rather than one that you have to disassemble and figure out, is a
reasonably easy task. And, we have to write a Linux driver anyway. So,
find one friend to work with and get started.
One person must not write any kernel code concerned with the driver.
That person must read the existing driver, document the hardware, and publish
the document. The document should not reproduce algorithms in the existing
driver unless they are integral to driving the device and there isn't another
way to do it.
A second person must not look at the existing driver. This person reads
the document and writes a new driver.
Keep notes about the entire process. You could someday have to
testify that you did it the right way.
When I worked for HP and we were making plans to discontinue this system, there were 5000 customers. And these computers were boat-anchors then:-) But their audience were bigger zealots than Linux ever had. I had the CTO of the major non-HP MPE services vendor sit me down at HP world and tell me why Unix would never make it. It took me a while to realize he was talking about Unix, not Linux.
We actually talked about Open Sourcing MPE. I think it sunk because 1) the MPE folks were afraid that IBM would use the code to make a porting kit, as if IBM didn't have bigger markets to pursue and 2) After all that time, HP didn't know what code was its own and what wasn't. I think the TCP came from Woolagong. Save the meta-data. Keep it with the code, not in the attorney or manager's file cabinet, folks. I've seen so many companies lose touch with what pieces they own and what pieces they don't after only a few years.
OK, I live in a McMansion, but I have wires too. I arranged for them to be off the floor, along the wall. But it's true that you have to pick up a bit before setting the Roomba off. It's pretty easy to recognize the stuff it would jam on, after the first time it happens. The hallway is not too narrow if you can walk through it. The Roomba knows how to follow a wall edge.
It's not your mum. Maybe you should invite her over to do some chores:-)
If Intel is still making XScale, they are hardly leaving the embedded market. They are just discontinuing processors that these days aren't worth the silicon, commodity low-margin products that other companies make well.
I am not going to see this yet because I don't have cable. Not much time in my life to view TV. But I'm told I'm in it, and would like to hear exactly how I'm in it. Also, if you work for the beeb, it would be nice to send me a DVD. Otherwise, I'll wait until it goes free and ask someone out on the net for one.
The audio amplifier, you mean. But your point about adjusting the call volume is belied by the existence of handheld speakerphones, isn't it? I think the main reason for limitation of call volume is that they don't want to get sued for ruining your hearing.
Let's look at the audio a bit more. First, you don't really need a linear amplifier there, you can use a transistor in switching mode and low-pass filter the output. That's more efficient, and doesn't use any significant power during silent times. So, your power drain is going to be related to the duty cycle of speech, which has a lot of pauses, etc. Take 50 miliwatts for held-to-ear mode and cut that in half for a 50% duty cycle, and you get 25 miliwatts. Then consider that one of the CPUs (there are usually two CPUs, although they might be on the same chip - one, generally an ARM7, runs the GSM stack and the other, an ARM9, runs the UI and PDA functions) is probably running the GSM codec in both directions while the call is in progress. The CPU might still be using more power.
The transmitter, depending on its distance to the cell site (cell transmitters only use as much power as necessary for the link budget), could be putting out up to 600 miliwatts with about a 1:3 duty cycle and 60% efficiency.
You mean looking for heat is a bad hueristic for parts that radiate some other energy? Well, if you have really efficient components. Even if RF amplifier transistors are run as switching rather than linear devices, they are not 100% efficient and make some heat. If you run them in their linear region, they are going to spend a lot of time acting like resistors and will make a lot more heat. LEDs warm up a bit, too.
Consider that microprocessors are CMOS digital devices, we're not unused to getting some heat out of them.
I think it's a really simple hueristic that works almost all of the time. I have heard from some less technical folks who think that their "200 watt powered PC speakers" are using 200 watts of AC power all of the time. Explaining the heat thing works really well for folks like that.
Slashdot Mirror
A lot of the development of Linux performance has been at the driver level. This is entirely logical, and shows no sign of stopping. You should also note that a major cause of Windows crashes, perhaps the #1 cause now, is the third-party device driver that they don't control.
Rather than provide Linux support, please just document it for other people who would write drivers. That's really all we want.
Thanks
Bruce
Thanks
Bruce
I suppose that from the accompanying documentation and from incremental reprogramming of the device one might figure out what's in each frame.
Thanks
Bruce
Bruce
Bruce
The main improvement in gate-arrays is in density, not architecture, and density is a property of the fabrication process, so we're not really talking about 10-year-obsolete chips.
Bruce
But not everyone feels that firmware BLOBs (or opaque firmware files) are cool, even if they are to run in the separate processor on the card. RMS certainly doesn't like them, and that was part of his discussion with Theo. I think that properly handled - which means loaded at run time from a user-mode program - they would be GPL-compliant because they aren't running in the same processor or address space as the kernel. But if I had my druthers, I'd have the source.
Bruce
Bruce
Bruce
Thanks
Bruce
Thanks
Bruce
Bruce
As far as I can tell, the new Slashdot software does not prevent the joke posting from coming before the one with substance. :-(
One is place-and-route of the full-custom design itself. We might have to use proprietary software to make the mask. I'm not insisting on starting from first principles.
The second is compiling VHDL to the Open Source bitstream. In this process you have to decide how to make the requested logic by interconnecting the raw logic blocks of the gate array. My impression is that Open Source does exist to do at least part of this job. I don't know how good it is.
Bruce
But FSF aren't the Linux developers. If you ask them, they will be very adamant about that.
Bruce
Can you say why?
Yes, that would be excellent. How do we get there? OpenCores.org has the start. However, all of the gate-arrays that they have to work with have a proprietary bitstream format and thus they require proprietary tools to program them. We need an Open Source gate-array to facilitate Open Source hardware. Initial full-custom full-wafer mass fabrication cost is about $1 Million. At that point, you can get the parts down to a reasonable price. You can do small runs in MOSIS (or whatever they have these days) to make sure the design works before you go that far.
I figure this is at least $2 Million to get done. We need good hardware designers and people to help write the grant. If I can hook up with such people, I'll do whatever I can to help. I don't have the hardware expertise to lead this, or I'd already be started. Any volunteers? I'm quite serious.
Bruce
Leaving BLOBs in the kernel might just mean you have different plaintiffs than if you used a reverse-engineered driver.
However, full clean-room reverse-engineering a free driver with full source code, rather than one that you have to disassemble and figure out, is a reasonably easy task. And, we have to write a Linux driver anyway. So, find one friend to work with and get started.
One person must not write any kernel code concerned with the driver. That person must read the existing driver, document the hardware, and publish the document. The document should not reproduce algorithms in the existing driver unless they are integral to driving the device and there isn't another way to do it.
A second person must not look at the existing driver. This person reads the document and writes a new driver.
Keep notes about the entire process. You could someday have to testify that you did it the right way.
Bruce
We actually talked about Open Sourcing MPE. I think it sunk because 1) the MPE folks were afraid that IBM would use the code to make a porting kit, as if IBM didn't have bigger markets to pursue and 2) After all that time, HP didn't know what code was its own and what wasn't. I think the TCP came from Woolagong. Save the meta-data. Keep it with the code, not in the attorney or manager's file cabinet, folks. I've seen so many companies lose touch with what pieces they own and what pieces they don't after only a few years.
Bruce
It's not your mum. Maybe you should invite her over to do some chores :-)
Bruce
Bruce
Thanks
Bruce
Cookies are a much better indicator of what browser you are communicating with.
Also, most spiders don't bother with cookies, so that's another way to tell something isn't a real user.
Unfortunately, some users disable cookies. And then all you can do is fall back on their IP address.
It would be nice to see cookie-tracking support in Open Source stats engines like awstats.
Bruce
Let's look at the audio a bit more. First, you don't really need a linear amplifier there, you can use a transistor in switching mode and low-pass filter the output. That's more efficient, and doesn't use any significant power during silent times. So, your power drain is going to be related to the duty cycle of speech, which has a lot of pauses, etc. Take 50 miliwatts for held-to-ear mode and cut that in half for a 50% duty cycle, and you get 25 miliwatts. Then consider that one of the CPUs (there are usually two CPUs, although they might be on the same chip - one, generally an ARM7, runs the GSM stack and the other, an ARM9, runs the UI and PDA functions) is probably running the GSM codec in both directions while the call is in progress. The CPU might still be using more power.
The transmitter, depending on its distance to the cell site (cell transmitters only use as much power as necessary for the link budget), could be putting out up to 600 miliwatts with about a 1:3 duty cycle and 60% efficiency.
Bruce
Consider that microprocessors are CMOS digital devices, we're not unused to getting some heat out of them.
I think it's a really simple hueristic that works almost all of the time. I have heard from some less technical folks who think that their "200 watt powered PC speakers" are using 200 watts of AC power all of the time. Explaining the heat thing works really well for folks like that.
Bruce