Some great points, however we don't even need greenhouses or irrigation to do this.
Check out this story of the transformation of some of the most arid, salty and generally hard to farm land in Jordan that has been transformed into productive farmland that captures and stores its own water supply completely self sufficiently:
Greening the desert
So how do you propose to make system calls directly in your user-land program without including Linux header files? Note that calls via libc are not system calls themselves.
This pretty much explains the reasons behind Google's decision to go with Dalvik (well, except the specifics of the failed negotiations over J2ME licensing).
In short J2ME as licensed by Sun/Oracle under the GPL has deliberately had the 'classpath exception' removed. Developers targeting a GPL J2ME are forced to release their code as GPL due to the linking with all of the GPL'd libraries. According to their plan this would make paid J2ME licensing under non-GPL license a the only option for mobile vendors. Sun specifically did this for J2ME and not J2EE or J2SE as this is where they saw the most licensing money.
All this talk of complete implementation getting a patent license is moot it seems. Google decided that the paid licensing from Sun was prohibitive for one reason or another and that forcing the GPL on Android app developers was unacceptable. So when they took the decision to clean-room a VM from scratch any efforts to make the implementation complete would not have been rewarded with a patent grant.
My 'works for me' attitude is only the equivalent of your 'they suck as it won't work for me' attitude. I was just making a counter example where the results from the open source radeon driver have been excellent.
I can't stand fanboism either, my emphasis on the word *Ubuntu* was meant to mean : 'hey, its been stable for me *even* on Ubuntu' who don't have the best record on QA and have a reputation for putting features before stability.
Anyway its a shame you've had such a nightmare with the radeon driver but don't paint the efforts being made by AMD as worthless for everyone from your bad experience with one mobile GPU, there's a lot of happy users out there too.
Mobility X1400 (r500) in Thinkpad T60 user here. Radeon has been working great for well over a year now and KMS seems totally solid now, laptop goes for up to week or more at a time between reboots (suspend to RAM every night). 2D compiz is superbly smooth, even Flash plays smoothly full screened at 1650x1050. And thats on 64-bit *Ubuntu*.
You are missing the fact that when AMD introduced their open source strategy, they had a huge backlog of 'IP' to trawl through and review before releasing the documentation. Things started slowly and the wait for my R500 based laptop GPU to reach a decent level of support felt like a long time.
But from what we are seeing now AMD have made steady gains and have reached a point where they are releasing an OSS *driver* (albeit an immature one) for their latest GPU series less than a year after the hardware was released. Being able to 'drop' support for the proprietary drivers on legacy hardware earlier (in favour of the OSS driver option) will free up more developers within AMD to work on drivers for the latest GPUs. As the OSS driver team become and more more integrated within the workflow of the company we can expect to see OSS driver code and documentation get closer and closer to the hardware releases.
In short it looks like things are paying off for AMD and the OSS driver strategy. Keep up the good work AMD!
My one criticism is that those DNS-323's are really slow.
Its not that bad compared to most home other home NAS boxes though. Also if you put Debian on it the more recent kernels have had performance improvement work done by Marvell.
I was thinking along the lines of adding a PIC controller with a simple clock/timer routine preprogrammed on it, and making it available through the i2c bus and connecting an output to the poweron pin of the xbox. Some kind of simple daemon could manage requests for 'wakeups' by storing a list of requests and making sure the most imminent one was loaded onto the PIC controller. Upon shutdown/wakeup the daemon could update the chip to the next required 'wakeup'. Maybe you could ask your friend how difficult it would be to attach a simple pic device to the i2c/smbus and have it available at a given address - I have limited hardware hacking skills
It may be possible to alter the code on the onboard PIC16LC chip which already controls the power/reset, eject and led functions. This chip has also been alleged to contain the realtime clock (by bunnie) as it is powered when the xbox is switched off (will run for some time after power cord is removed from a capacitor). Microsoft have probably blown the fuses that would have allowed for this.
A lot of the currently supported devices are USB1.1 and thus they have a
maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub.
This is not enough for receiving the complete transport stream of a
DVB-T channel (which is about 16 MBit/s). Normally this is not a
problem, if you only want to watch TV (this does not apply for HDTV),
but watching a channel while recording another channel on the same
frequency simply does not work very well. This applies to all USB1.1
DVB-T devices, not just the dvb-usb-devices)
Seems that maybe more cards will do the same, I can only confirm that the AverTV DVB-T USB2.0 runs fine on USB 1.1 under linux,
it should be possible to plug into as many as 3 DVB-T tuners (4 if you dont need a controller/remote) to your xbox as each port has full 1.1 bandwidth. using dma the xbox should have no trouble recording multiple streams to disk
I am trying to build a distro from scratch based on uclibc, running 2.6 kernel (required for dvb), with directfb/xdirectfb, mythtv/qt3/mysql. the directfb project specifically supports the onboard nvidia gpu incl. mpeg motion compensation:)
As I said earlier (as an AC in grandparent) the only thing stopping us from having a legal 'killer' pvr out of this is the lack of standby/wakeup and general power management support on the xbox. the PIC controller which manages the power/eject buttons and leds has been alleged to contain the realtime clock and is powered as long as the box is plugged in (runs from a capacitor for a while after unplugging) , if someone could figure out a mod to allow us to run a small timer wakeup routine either from this pic or from an added one we could set up recordings. only other option would be to spindown hd and issue noops to reduce power in between recordings.
btw Im new to posting here, how do I link a url to a word of my choice rather than posting the whole url?
Slashdot Mirror
Some great points, however we don't even need greenhouses or irrigation to do this. Check out this story of the transformation of some of the most arid, salty and generally hard to farm land in Jordan that has been transformed into productive farmland that captures and stores its own water supply completely self sufficiently:
Greening the desert
Anyone have a 'Religiousness Cure' app handy that can help people become atheist? Would be fun to watch the reactions when Apple approve that one...
So how do you propose to make system calls directly in your user-land program without including Linux header files? Note that calls via libc are not system calls themselves.
This pretty much explains the reasons behind Google's decision to go with Dalvik (well, except the specifics of the failed negotiations over J2ME licensing).
In short J2ME as licensed by Sun/Oracle under the GPL has deliberately had the 'classpath exception' removed. Developers targeting a GPL J2ME are forced to release their code as GPL due to the linking with all of the GPL'd libraries. According to their plan this would make paid J2ME licensing under non-GPL license a the only option for mobile vendors. Sun specifically did this for J2ME and not J2EE or J2SE as this is where they saw the most licensing money.
All this talk of complete implementation getting a patent license is moot it seems. Google decided that the paid licensing from Sun was prohibitive for one reason or another and that forcing the GPL on Android app developers was unacceptable. So when they took the decision to clean-room a VM from scratch any efforts to make the implementation complete would not have been rewarded with a patent grant.
My 'works for me' attitude is only the equivalent of your 'they suck as it won't work for me' attitude. I was just making a counter example where the results from the open source radeon driver have been excellent.
I can't stand fanboism either, my emphasis on the word *Ubuntu* was meant to mean : 'hey, its been stable for me *even* on Ubuntu' who don't have the best record on QA and have a reputation for putting features before stability.
Anyway its a shame you've had such a nightmare with the radeon driver but don't paint the efforts being made by AMD as worthless for everyone from your bad experience with one mobile GPU, there's a lot of happy users out there too.
Mobility X1400 (r500) in Thinkpad T60 user here. Radeon has been working great for well over a year now and KMS seems totally solid now, laptop goes for up to week or more at a time between reboots (suspend to RAM every night). 2D compiz is superbly smooth, even Flash plays smoothly full screened at 1650x1050. And thats on 64-bit *Ubuntu*.
But from what we are seeing now AMD have made steady gains and have reached a point where they are releasing an OSS *driver* (albeit an immature one) for their latest GPU series less than a year after the hardware was released. Being able to 'drop' support for the proprietary drivers on legacy hardware earlier (in favour of the OSS driver option) will free up more developers within AMD to work on drivers for the latest GPUs. As the OSS driver team become and more more integrated within the workflow of the company we can expect to see OSS driver code and documentation get closer and closer to the hardware releases.
In short it looks like things are paying off for AMD and the OSS driver strategy. Keep up the good work AMD!
My one criticism is that those DNS-323's are really slow.
Its not that bad compared to most home other home NAS boxes though. Also if you put Debian on it the more recent kernels have had performance improvement work done by Marvell.
First UK software patent - March 2008.
after the UK IPO appealed against the EU patent office and lost in the high court. Slashdot missed this one (I submitted a story but it was ignored).
I was thinking along the lines of adding a PIC controller with a simple clock/timer routine preprogrammed on it, and making it available through the i2c bus and connecting an output to the poweron pin of the xbox. Some kind of simple daemon could manage requests for 'wakeups' by storing a list of requests and making sure the most imminent one was loaded onto the PIC controller. Upon shutdown/wakeup the daemon could update the chip to the next required 'wakeup'. Maybe you could ask your friend how difficult it would be to attach a simple pic device to the i2c/smbus and have it available at a given address - I have limited hardware hacking skills
It may be possible to alter the code on the onboard PIC16LC chip which already controls the power/reset, eject and led functions. This chip has also been alleged to contain the realtime clock (by bunnie) as it is powered when the xbox is switched off (will run for some time after power cord is removed from a capacitor). Microsoft have probably blown the fuses that would have allowed for this.
Useful links:http://www.xbox-linux.org/wiki/SMBus_Controller
http://www.xbox-linux.org/wiki/Xbox_Hardware_Overv iew#PIC16LC
http://www.xenatera.com/bunnie/proj/anatak/xboxmod .html
2.2. USB1.1 Bandwidth limitation
A lot of the currently supported devices are USB1.1 and thus they have a maximum bandwidth of about 5-6 MBit/s when connected to a USB2.0 hub. This is not enough for receiving the complete transport stream of a DVB-T channel (which is about 16 MBit/s). Normally this is not a problem, if you only want to watch TV (this does not apply for HDTV), but watching a channel while recording another channel on the same frequency simply does not work very well. This applies to all USB1.1 DVB-T devices, not just the dvb-usb-devices)
Seems that maybe more cards will do the same, I can only confirm that the AverTV DVB-T USB2.0 runs fine on USB 1.1 under linux,
Using adapters such as this one:
http://www.stegen.com/product_info.php/products_id /725?osCsid=e9a729b96d16f40938...
it should be possible to plug into as many as 3 DVB-T tuners (4 if you dont need a controller/remote) to your xbox as each port has full 1.1 bandwidth. using dma the xbox should have no trouble recording multiple streams to diskI am trying to build a distro from scratch based on uclibc, running 2.6 kernel (required for dvb), with directfb/xdirectfb, mythtv/qt3/mysql. the directfb project specifically supports the onboard nvidia gpu incl. mpeg motion compensation :)
As I said earlier (as an AC in grandparent) the only thing stopping us from having a legal 'killer' pvr out of this is the lack of standby/wakeup and general power management support on the xbox. the PIC controller which manages the power/eject buttons and leds has been alleged to contain the realtime clock and is powered as long as the box is plugged in (runs from a capacitor for a while after unplugging) , if someone could figure out a mod to allow us to run a small timer wakeup routine either from this pic or from an added one we could set up recordings. only other option would be to spindown hd and issue noops to reduce power in between recordings.
btw Im new to posting here, how do I link a url to a word of my choice rather than posting the whole url?