According to this comment from slashdot user guantamanera, it is possible to strip off the cci flag when using the HDHomerun Prime you own with a modified VDR-SC. HDHomerun Prime is one of the three cable card tuners available for pc's. The other two are the Hauppauge WinTV DCR-2650 and the Ceton InfiniTV 4. I have no idea if it is possible with the other two. According to an AC who commented in that thread

VDR-SC is one of the many cardsharing and softcam emulators out there. I preffer SASC-NG. These tools were meant for DVB Satellite(dishnetwork) but they're easily modifiable to be used in NA cable providers. In cardsharing mode, just like the name suggest the card can be shared with multiple devices or people, and it can leave you with a clear stream no flags.

A softcam is a software conditional access module. Softcam's make cardsharing possible allowing multiple receivers to share a single smart card to decrypt a satellite DVB stream. After reading that thread and looking into it, I can find no documentation anywhere on how to get any softcam to operate with a cable card tuner at all much less strip out the copy control information. It would make sense that is possible though, the cable card standard is somewhat related to DVB standards. If anyone knows how please reply. Good luck AlphaWolf_HK if you attempt to go down this road. I'd like to know if you manage to get this working.

After Hurricane Allison here

I think you mean Tropical Storm Allison. Man that thing flooded the hell out of Houston. Then went on to travel over land all the way to the mid-Atlantic States flooding pretty much everywhere it went. Following this the name Allison was retired from the Hurricane name list. It remains the only name to be retired from the list for a named storm that never reached Hurricane strength.

A judge should check whether someone acts within the limits set by the law. A judge shouldn't be publicly trying to change the laws, just like a politician should not try to get involved in a court case to get someone convicted.

Normally, I'd agree with this sentiment, but I think it's important to remember that software patents were more or less created by the judiciary not the legislature. They are not found in statute. The patent office only started granting them because they lost too many court cases telling them they had to. Algorithms are math and math is not suppose to be patentable.

The best way I've ever seen my objection to this point put is that there is no conceivable disaster that could ever befall the Earth that would make it less habitable than any of the other planets are right now. Mars is already in worse shape for human habitation than we could ever make Earth, and every other planet out there is worse still.

Establishing bases and eventually non-self-sustaining colonies on the Moon and/or Mars develops the tech that makes survival of several kinds of conceivable disasters on Earth much more likely. Independent biosphere type things. While we could just develop this technology outside of space program, it would have little use and with a base/colony on Mars, we would have a strong incentive to make sure it actually worked.

a truly independent colony is basically impossible at our current tech level.

Nor does it make sense for things that require heavy infrastructure to manufacture and are light to ship. I mean depending on how you define truly independent colony, America's not a truly independent colony because we depend on say Southeast Asia for hard drives.

Like the other poster said it's a bit of a catch 22. You can't do a nandroid backup without a custom recovery image. Can't do a custom recovery image without unlocking the bootloader. Can't unlock the bootloader without wiping the phone.

I had this same problem on the nexus one. The trick is to root the phone without unlocking the bootloader and then using a backup utility that requires root (Titanium Backup or whatever, I actually preferred MyBackup Root). This can be done by using a local root exploit. I think it took me two days to find one that worked on my phone at the time. I think you can even get a clockwork mod installed and install a new bootloader without wiping, backup the whole phone, and then install cyanogen mod that way. I say think because I didn't know at the time but sometimes clockwork mod just plain fails to install a new bootloader and you have to try multiple times. Having already backed everything up I just unlocked the bootloader at that point. The Titanium Backup/MyBackup Root don't create a backup image of the whole phone if I remember right, but instead backup all the data/individual applications. I think they failed to restore one or two of the things on my phone, but they were things synced with my google account anyway so it didn't matter.

Finding a premade local root exploit is surprisingly difficult. Most rooting guides use the unlock bootloader method and many of those give you no warning it will wipe the phone. All of this information is surprisingly hard to come by and the documentation leaves much to be desired. Everyone says rooting and installing cyanogen is easy on the nexus's, but it turns out that is only true if you don't care at all about the current content of your phone something you'll only discover when you actually try to do it. For that matter you would think backing up your phones contents would be something that would be easy to do. I mean that seams like the sort of thing normal people would want to do, ya know?

Good luck

I'll ask the easy question.. WHY?

Easy answer. WinCE and administering devices through the finicky unholy abortion that is ActiveSync.

WinCE is almost as fragmented as linux is, not as fragmented as linux's arm tree, which is a total mess, but still. Then there's ActiveSync. What I wouldn't do to avoid that. Will it see the handheld today? Will it see any handheld today? Will it remember this handheld? Will it think this handheld is some other handheld and totally confuse their settings? It really is almost enough to inspire one to cross their fingers and hope they don't run into linux power management issues on an arm device.

Seriously, when you business relies on a machine that must work or you are losing money, everyone wants someone to turn to when it doesn't work. That someone isn't a man page or IRC channel or mailing list or whatever support for $foo GPL program here.

Was he not asking if anyone knew a vendor who supported this sort of thing? Perhaps I got the wrong impression of the question.

When you want a computer you control, you run linux, when you want a computer that grandma can use, you give her a Mac and when you want retail system that checks people out, you run whatever OS that your POS maker asks you to.

Or, if you are currently in the market for a POS, you define your requirements or desired features to include the OS you want, with the kind of support you want, and you look to see if anyone is offering anything you want anywhere near your price range. It's not like desiring an OS you can strip down to almost no running processes you're not actually using on what is basically a thin client that runs on batteries is that crazy a thing to desire.

Comes with open source OpenGL ES drivers?

It uses the Freescale i.MX515 soc. The gpu is some sort of Imageon. I think Freescale licensed the gpu design before AMD sold it to Qualcomm who renamed it Adreno. The i.MX515 uses an Open Source kernel shim for the gpu and a closed source user space library for doing OpenGL. At least this was the situation last December. The library is entirely in user space, which means it should be easier to reverse engineer than a driver that is partly in kernel space. Dave Airlie, maintainer of the drm portion of the kernel, has rejected the kernel shim from inclusion in the kernel. He rejects all patches to the kernel that come his way that can not be used by open source code in userspace.

The ATI drivers for Linux were never perfect, but they worked decently. But ATI/AMD would drop support for older chips that were still in use. The open source community never provided a shim to let these older drivers work with newer builds of X.

Does open sourcing the drivers really fix the compatibility problem? To me, not building a shim suggests a general lack of caring about ATI drivers. Do we really need the source to give a future to aging ATI/AMD chips?

As of January 19 phoronix, puts the average speed of the latest available open-source driver at roughly 70% the speed of the Catalyst driver before the pre-R600 support was discontinued in early 2009. This is using composite results from the ATI Radeon X1800XL, Radeon X1800XT, and X1950PRO graphics cards being benchmarked on Nexuiz, Warsow, OpenArena, World of Padman, and Urban Terror. These cards use the R300g driver. Newer cards using the R600g driver (cards with HD in the name) are not currently anywhere near these results.

A bit of history:

A long time ago, documents describing the specifications of graphics cards were generally available under NDA to XFree86 developers. Then Nvidia started releasing binary only drivers. ATI eventually followed suite. The last series with docs available from this era is ATI's R200. The R300 released in 2002 did not have docs released for it. Following the lack of docs, driver development stagnates.

April 6, 2004 XFree86/X.org fork.
After Keith Packard was kicked out of the XFree86 core group and XFree86 switched to non-gpl compatible license a fork ensues. Project Leadership of XFree86 had been basically hostile to developers and had retarded increases in the developer base and improvements in the graphics stack for literally years. Following the fork a renaissance in X Server development begins.

July 24, 2006 AMD acquires ATI.
Speculation about open drivers begin.

May 10, 2007 Red Hat Summit
AMD's Henri Richard says something about improving the open source drivers. Speculation becomes flood of rumors.

September 06, 2007 ATI/AMD's New Open-Source Strategy Explained
AMD announces plans to contribute specification documents and code to the open source drivers. By this time successive X.org releases have seen:

• Removal of XIE, PEX and libxml
• Window translucency, XDamage, Distributed Multihead X, XFixes, Composite
• EXA, major source code refactoring. Switch to autotools build system instead of Imake
• EXA enhancements, KDrive integrated, AIGLX
• Removal of LBX and the built-in keyboard driver, X-ACE, XCB, autoconfig improvements
• Input hotplug, output hotplug (RandR 1.2), DTrace probes, PCI domain support.

September 11, 2007 XDS2007 Program
The "softpipe" talk by Keith Whitwell of Tungsten Graphics is the earliest reference I can find to Gallium3D. References to Gallium3D show up on Tungsten Graphics website at approximately the same time according to internet archive. Apparently Tungsten Graphics released a softpipe driver (gallium driver for cpu) at this time, along with a "proof of concept" i915 driver.

September 12, 2007 AMD Releases 900+ Pages Of GPU Specs
RV630 Register Reference Guide and M56 Register Reference Guide.

January 04, 2008 AMD Releases Additional R600 GPU Programming Documentation
M76 and RS690 register guide weighing in at 458 and 422 pages respectavly. Contains LVTMA and i2c information not found in previous docs. LVTMA is the second digital output block on the ATI R500/600 series and can handle TMDS and LVDS for DVI/HDMI and LCD panels, respectively.

February 22, 2008 AMD Releases 3D Programming Documentation
300 pages. This 3D programming documentation covers the R500 series and even goes back with information on the R300/400 series as well. Document contains programming guide and register specifications. Among the areas covered in this 3D guide are the command processor, vertex shaders, fragment shaders, Hyper-Z, and the various 3D registers. Previous documents have just covered R500/600 card support with mode-setting, LVTMA, TMDS, i2c, and other basic but critical elements.

February 28, 2008 AMD Updates Its 3D Programming Guide
Covers more vertex program formats than the v1.1 draft. 4 more pages than the v1.1 draft.

March 14, 2008 AMD Releases R300 3D Register Guide
Just 99 pages long but covers registers for color buffer, fog, geometry assembly, graphics backend, rasterization, clipping, setup unit, texture, fragment shaders, vertex, and Z-Buffer.

The R300 open-source support had largely been reverse-engineered and built upon the R200 open-source support, which came from documentation ATI had released to open-source developers under Non-Disclosure Agreements several years ago. The Radeon R300 series consists of such graphics cards as the Radeon 9500, 9800, X300, X550, and X600 -- both AGP and PCI Express parts.

March 19, 2008 AMD Releases Production Microcode For All Radeon GPUs
This is the microcode found in the fglrx driver and it covers the Radeon R100 to R600 product families. This microcode dump can be found in the Mesa/DRM git tree in shared-core/radeon_cp.c. This file is made up of the microcode (arrays made up of hex) for the R100, R200, R300, R420, RS600, RS690, R520, R600, RV610, and RV620. Microcode is low-level instructions for the graphics processor.

April 01, 2008 AMD Releases Revised R500 Document
Version 1.3 includes expanded coverage of the Command Processor (CP) found on the R500 graphics processors.

June 11, 2008 AMD Releases R600 GPU Documentation
This ISA (Instruction Set Architecture) documentation covers the unified shader block found on the Radeon HD 2000/3000 series and newer. This PDF document is 342 pages long and does go into detail surrounding R600 vertex and geometry shaders.

July 25, 2008 AMD Releases New AtomBIOS Parser
New AtomBIOS Parser should be small and clean enough to go into the kernel for kernel modesetting. Not going to replace parser in X. That would be work for no gain.

December 29, 2008 AMD Releases Open-Source R600/700 3D Code
Code drop. Documentation was to be released as well, but wasn't fully sanitized before holidays. Code includes a working DRM, working EXA acceleration, an initial X-Video implementation and the working r600_demo program. This code covers R600 and R700 series.

January 26, 2009 AMD Releases R600/700 3D Documentation
The R600 3D register guide is 166 pages long and covers R600 shader instructions, R700 shader instructions, shader textures, and various other registers needed to program a 3D graphics driver.

March 29, 2009 AMD Releases R700 Instruction Set Architecture
In this new R700 ISA documentation is 392 pages worth of information on various topics, particularly about the Stream processing abilities of the R700 family.

April 18, 2009 AMD Pushes Out New R600/700 3D Code
This code will allow open-source 3D acceleration on the Radeon HD 2000, 3000, and 4000 series of graphics cards.

May 07, 2009 AMD Releases R600/700 Programming Guide
This 43 page document, that is entitled "Radeon R6xx/R7xx Acceleration", provides a basic overview of the ASIC architecture and a small programming guide. This document also covers the packet definitions and information concerning synchronization and cache flushing for these newest graphics processors. Explained in detail is the second generation Superscalar Unified Shader Architecture, technical changes between the R600 and R670, technical changes between the R670 and R700 series, the R600/700 3D pipeline, and various other topics that excite graphics driver developers.

November 09, 2009 ATI R300 Gallium3D DRI Support Is "Done"
The DRI state tracker report now states "done". First R300 Gallium3d component to reach complete status. R600g driver still considered extremely early in development.

December 22, 2009 AMD Publishes Evergreen Shader Documents
362 pages. A shader instruction set documentation for the R800 "Evergreen" graphics processors. Titled "Evergreen Family Instruction Set Architecture - Instructions and Microcode."

February 01, 2010 Open-Source ATI Evergreen Support Arrives
User-space mode-setting support for the Radeon HD 5000 series GPUs. No 3d or even 2d acceleration. No kernel mode setting.

February 09, 2010 There's Evergreen KMS Support & More To Test
Includes new I2C code that supports the hardware I2C engines found on Radeon graphics cards and exposes it to user-space, a PLL algorithm rework, DRM power management support, basic Evergreen "R800" KMS support, and various other fixes and new additions. Still no 3d or even 2d acceleration.

April 08, 2010 Open-Source ATI Evergreen Acceleration Builds Up
New kernel DRM code that adds support for the command processor, interrupts, and graphics initialization on the Evergreen ASICs. New microcode. Support for power tables. Still no 3d or even 2d acceleration, but the foundation for acceleration is now laid down.

July 22, 2010 Intel's Preparing To Push Its New GLSL Compiler Into Mesa
New GL shading language compiler for Mesa dubbed "GLSL2"

August 17, 2010 Intel's GLSL2 Branch Is Merged To Mesa Master
Goal is to support current and future versions of the GL Shading Language required for OpenGL 3.x/4.x support. Current goal is GLSL 1.3 support. Also faster than previous driver and addresses tons of bugs. This compiler will be used by all drivers not just intel. Adds 85,000 lines to Mesa code-base.

August 20, 2010 Open-Source 2D, 3D For ATI Radeon HD 5000 Series GPUs
2D EXA, X-Video, and OpenGL acceleration. 332 days after the first Evergreen graphics cards were released, the public finally has the first open-source hardware-acceleration support for ATI Radeon HD 5400/5500/5600/5700/5800/5900 series ASICs. This commit ends up adding over 12,000 lines of code to the R600 DRI driver. It may be close to the same speed and feature parity as the drivers that support earlier product generations -- even the previous-generation Radeon HD 4000 series that has quite decent open-source 3D support within its classic Mesa driver. First-run opengl driver. Following this, the Evergreen register documentation that is released to the public will also be updated and released. 332 days may seem like a long time between product release and 2d/3d acceleration support but it is actually a record low. Roughly ~31 months from launch to GL2 for 6xx, ~19 months for 7xx, less than 12 months for Evergreen. New ASICs should see a lower time until 2d/3d acceleration support.

November 22, 2010 Open-Source AMD Fusion Driver For Ontario Released
This initial open-source support should be at around the same level of support and capabilities as where the open-source Radeon HD 5000 "Evergreen" support is at right now. This includes user-space mode-setting, kernel mode-setting, 2D EXA, X-Video, and 3D/OpenGL support. This support comes nearly at time of product release.

Since 2007 the radeon driver has seen the switch from the memory manager being in X to being in the kernel "GEM and/or TTM", the switch from User Mode Setting to Kernel Mode Setting, the switch from the "classic" mesa to "gallium" mesa, and the switch from DRI to DRI2. The R300g and R600g drivers that have all these changes in them have not really hit distros yet. Distro's have been shipping the R300c and R600c drivers which have some of these changes. The R300g is now more or less at feature-parity with the R300c and has better performance and should be hitting distros soon. As stated at the beginning of this post it is now running at ~70% the speed of the catalysts driver before the pre-R600 support was discontinued in early 2009. The R600g development lags behind the older, more mature R300g. The R600g only became capable of running glxgears in July 2010 is now more or less at feature-parity with the R600c. All development is now focused on the R300g/R600g drivers. Over the past 3.5 years almost all the re-archtechturing groundwork for radeon in Mesa/X/Drm/Dri is complete and specifications for the R400, R500, R600, R700, and Evergreen have been released and support for them incorporated into the drivers. Developers have been focused on implementing things correctly and only now are they beginning to do optimization work and see the payoff for the previous 3.5 years of work.

The remaining archtechture groundwork is to see Mesa's OpenGL support go from 2.1 to 3.0 to 3.1 to 3.2 to 3.3 to 4.0 to 4.1. A majority of the various GL extentions for 3.0, 3.1, 3.2, and 3.3 are done. The gl shader compiler on the other hand is going to need a ton of work. The number of intermediate representations to get from shader program to actual byte code running on the gpu is fairly large and glsl 1.3 is not yet supported.

So why should they build, test and support new roms for every different Android device out there?

Better question, why can a bunch of amateurs working only in their spare time support Android 2.2 on every phone they have ever released a ROM for, including the first Android phone that was released to the market, while giant multinational cell phone manufactures can't? They don't even come close. They don't manage to support it on all the phones they are selling right now. Amateurs are providing, for free, better support than the manufactures people actually paid money to manufacture and support their phones. The support is so much better that the research you should do when shopping for a phone is to make sure 3rd parties, which happen to always be unpaid amateurs, can support the phone you are buying because the amateurs can be trusted to support the product in the long term and to produce a better software stack in the short term much more than the multi-billion dollar companies that actually built them. This is ridiculous. These companies should be ashamed of themselves. Instead, some of them are not only not ashamed, but are actively thwarting 3rd party support by locking down the bootloader necessitating the aforementioned research.

I realize you and the parent comment you were replying to were talking about google providing android, but really the manufactures are doing an unbelievably bad job. You should be able to expect your manufacture to rebuild the os when google releases a new version of android. You can't, they are slow when they do, and some of them prevent 3rd parties from doing it for them. Some manufactures are deliberately ruining their own products. I would understand if they also sold an unruined product and made you paid more for it, but as it is there is no apparent business reason for them to ruin their own product. This is pretty messed up.

Long Term Support
Amateurs do
Motorola doesn't

some people purport that it an idealogical struggle so by releasing software they are fighting against a future owned by corporations that create for profit software.

Exactly. The problem is that Canonical / Ubuntu are just the kind of corporation I was trying to fight. If Open Source / Free Software won't fight them, I need something else that will.

I sincerely do not understand. What sort of things has Canonical done wrong? I use to use debian starting in 2000 and now use Ubuntu, mainly due to the 6 month release cycle. I prefer things to break once every six months rather than whenever with unstable or taking forever for things to be released with stable. Should I not use Ubuntu? Is there something really wrong with it? I respect you, the work you've done, the way you represent open source software in a professional manner, and your opinion a great deal. I do not understand why you seem to consider Canonical the enemy or what's wrong with them. Is it because they distribute non-free software? So does debian. (I try to avoid non-free especially drivers.) I really don't understand and I really want to.

The space shuttles engine is reusable 0 times without a complete and total dis-assembly and rebuild.

This hasn't been true in a long time. It was true for the first major version of the Space Shuttle Main Engine, but they are on at least the fifth major version of the SSME now. They are taken off the orbiter for inspection every two flights now and taken off for rebuild every four flights. An SSME costs about 75 million to build. A delta IV rocket engine, which is made by the same company and is roughly comparable to an SSME, costs about 25 million. I've never been able to figure out the maintenance cost on an SSME. The SSME has a very excellent safety record. One of the reasons for this is because being reusable they can test the hell out of it. It is one of the best rocket engines ever. The shuttle taken as a whole may not be very good, but most of the parts are fantastic, and the SSME is definately a fantastic part and an example of one of the things they got right with a reusable vehicle. The shuttle is the first and only reusable launch vehicle ever built and we have learned many things on how not to design a reusable launch vehicle. The shuttle is a sample size of one and should not be taken to mean reusable launch vehicles are inherently bad, expensive, or impossible to build.

The Federal suit contains two main arguments, a civil rights argument and a preemption argument. I'm only addressing the latter.

The current Federal suit contains nothing about civil rights. It's all preemption. There is actually already precedent on this (immigration, specifically) saying states can make laws. The Arizona law is not yet being enforced. Civil Rights violations only occur when the law is enforced in a manner that violates civil rights. When that happens, the Feds will probably launch a suit on that basis.

I ordered a touchbook from Always Innovating. on Nov. 15. It uses an arm cpu (A8 Cortex 600Mhz) and runs linux. They are a startup, and they have backlog so they don't process orders or charge you until they have enough stock. I probably won't get it until December. It has a usb bluetooth dongle in it, but I can't find out what kind. The specs just call it a Bluetooth Class 2.1 USB dongle powered by CSR chipset. I can't figure out what hardware that is by looking at the dmesg either, but no one seems to have complained about the bluetooth on it. Most of the complaints have been about build quality. Sometimes the batteries or counter-weights get loose, and you have to glue them back down. The first ones also had a problem where if you opened the screen past 90 degrees it would fall backwards. Also the software is Beta, but they tell everyone that straight up so... Anyway it uses a OMAP3530 soc like the beagleboard and Pandora. The graphics use closed drivers, and the dsp is programed with a closed source ti compiler. The odd thing is there is or was a gcc port to the TMS320C6x dsp's in 2004 and 2005. It did not at the time support the C64x dsp which is what the OMAP 3530 uses, and I can't seem to find any reference to anyone trying to do so. I would think someone would be making an effort on that front.

I've been thinking the same thing in regard to phones as computers (people were using zaurus's as computers years ago and those were using arm cpu's way less powerful than todays) and am probably getting a new phone in Dec or Jan so I've done some research on that. Most of the android phones out now use some kind ARM11 processor. Anandtech gave a fairly good comparison of Arm11 vs. Arm Cortex A8 during their iPhone 3g, iPhone 3GS, and Palm Pre comparisons. The articles are here, here, and here. The iPhone 3g uses a 412Mhz Arm11 while the iPhone 3GS uses a 600Mhz Cortex A8. The 45% clock speed boost resulted in between 42% and 200% faster in application load time and around 100% faster in browsing using either cellular or wifi. The articles talk about the CPU architecture differences between ARM11 and A8 Cortex. The articles also talks about some of the PowerVR graphics chips (the touchbook above uses a PowerVR SGX530 GPU), but doesn't go into as much detail about those. Apparently most phones use some kind of PowerVR chip. There is an additional artice from June, which is a large review of the Palm Pre, in which he says he expects multicore Cortex A9 phones to be out in around 12 months. I am not sure I see that as happening.

I have heard Android's bluetooth support is not currently very good. Specifically that it does not support bluetooth keyboards. They may have fixed that by now, I'm not sure, but they should definately fix it at some point. I am really surprised it has taken this long since they are using linux's bluetooth stack which does support keyboards as far as I know.

My sister has an apple bluetooth keyboard and mouse on her mac. The only real problems she has with it is when she has to replace the battery. The mac has "lost" the keyboard once or twice in the time she has had it and she's had to turn the keyboard on and off and what not to make the mac find it again. This is a ppc macMini, which tells you how long she's had it, and she has been using it with a bluetooth keyboard and mouse since she got it or right near there. We did have to set those up using a regular mouse and keyboard at first I think, and I do seem to remember some sort of trouble getting the mac to recognize most of the mouse/keyboards we had since most of them were ps/2 not usb. I did borrow her keyboard once to see if it would work on a PS3, and it would not. Undoubtedly the little differences between an apple and normal keyboard were significant enough to prevent the PS3 from recognizing it.

Let me know if you want to tell you anything more about the touchbook when I get it. I could try pairing it with her mouse/keyboard, sending files to/from phones, sending files to her mac through bluetooth, whatever.