If you really want to do a custom interface and have a little hardware skills you should try an Arduino. You can interface to any hardware device and feed the data to the computer over serial USB.
I've been using my smart phone(s) for SSH access for the last couple years. I run a small business and have very demanding customers (who pay a substantial amount for support), and therefore need quick response. The smart phone has let me do that a couple ways:
First and more importantly it means I'm always connected to my email and voicemail. Being able to respond quickly with a call or email is a big benefit, and any smart phone can do that level of support reasonably well. You didn't ask about that, but I mention it because I feel it is the most important benefit.
Now, back to the phones with SSH. I've used two of them extensively. I had an Cingular 8125 (HTC Windows Mobile) for about 20 months and I now have a Blackberry Curve (8130) which I've used for the last 4 months.
During the 20 months I had a half dozen or so real occasions to use the SSH support. I used it for file transfers, I used it to examine and fix clients machines, and I used it to do other administrative tasks that were only available from my site. That's not often, but for those moments when it was needed it saved me a lot of time and was worth the cost of the data service.
The HTC phone had the better keyboard. On unix systems we use the special characters too much, and getting to those on the BlackBerry is a difficult. Both keyboards are too small to do anything quickly with them. In both cases the screen is really small. The connection is slow (neither unit is 3G), but for a text input it's OK. It reminds me of the old 9600 baud terminals on a main frame. The bottom line is that for occasional access to important information/applications it works just fine. It is in no way useful for extended work. If you a task takes more than 5 minutes you'd be better off finding WiFi at a Starbucks and using your laptop.
My clients are primarily in California and in major cities or along major highways, so that's where I have the most coverage experience. I've found the data service is fine everywhere I go. I use the email, web, etc. very regularly so I tend to notice the loss of data service.
My opinion is that smart phones work OK for occasional emergency SSH access. The keyboard limitations are the weakest link, but given the rest of the constraints on speed, screen, etc. I'm not sure it matters. As long as you're only doing this for short periods in case of a emergency it's a good answer.
A corollary is that if you have something you need to do regularly using the keyboard and SSH on your smart phone, you really ought to set up a web page. The web interfaces on the phones are better and it allows you to control the presentation. It also works better on a wider variety of phones.
1) Sell Training Write books, on-line training, seminars, whatever, and sell that as an adjunct to your open source project. Of course, those can be open source as well.
2) Sell Customizations Offer to develop custom features or just consult on deployment. Some of those may be rolled in to a future version of the existing package if that makes sense.
3) Sell Support Get people to buy support for the package and offer telephone/email support for issues. If the application is critical to a business, they may pay to have support on hand.
4) Sell access to the code under non-GPL license Some applications are release GPL, but offer the option of paying to get a closed source commercial license.
5) Split the package in to open and commercial packages. Bundle the basic system as open source and then have add-ons that are commercial. This is sort of getting them hooked on the free version and then hoping they grow in to needing the features of the add-ons.
Regardless of which method you pick, you should realize it takes a lot of work develop a successful community around a piece of open source software. If your plan is to just throw the code out under an open source license, you're likely to fail. You need to promote your product, develop a group of users, have forums/lists for them to communicate, encourage developers, review and work on submitted code, and you need to spend time participating in those activities. Even then if your product isn't unique and interesting enough you won't get a following. Bottom line is that you need to be really committed to your open source project and it had better be best of breed or users will move to alternate choices.
ESR is getting all the attention he wanted, but posting his public letter all over the Linux web sites. Unfortunately, everyone is falling for it. Just because he jumps and down and screams doesn't mean he deserves the attention. It's also interesting how he mixes a few personal technical items with a big political issue. That gets people frothing (on one or the other), but doesn't really provide constructive discussion.
Let's look at the reality:
1) ESR has a package conflict. In an attempt to fix that he removed a library that was critical to the functioning of the package system, and then he was stuck, unable to restore his system.
Users aren't supposed to delete libraries from their system. If they try to do this with the package system it complains and stops them. If you do it by hand or you use the switches that allow you to override the system, then it's up to you to know what you're doing. Obviously ESR didn't know what he was doing, because it caused him these problems. You can sum this up as:
ESR removed the safty, waved the gun around, and pulled the trigger, and then was surprised when he shot himself in the foot. He should know better.
2) ESR didn't say what packages he had a problem with.
A lot of work goes in to making sure the primary Fedora repositories are consistent and work, but mistakes do happen. A bug report would have been more useful than just ranting about it.
I often see consitency problems in unsupported repositories and work around them. They're unsupported, which means it isn't Fedora's fault and is sort of to be expected.
3) ESR wants RPM to be statically linked so this can't happen.
Unfortunately, ESR hasn't looked at the realities of a modern distribution. Statically linking key applications used to be a good idea, but Linux today has a lot of pieces that won't function without shared libraries. Given all the things the package managers do, they need a fully functional system. Statically linked applications work when you're doing system recovery, but that's about it.
4) ESR couldn't fix his system.
Fedora ships with a system recovery disk. It is a full Linux system running from a CD. It's designed to let you fix just about anything that happens with your system. He could reinstalled the missing library by using that. Rescue disks are far from perfect. You really need to understand what you're doing to use them. But he didn't try, and didn't ask for help, and clearly didn't know how to do it himself.
5) ESR is important and everyone should listen to what he says
ESR is no more important than any other developer out there. Developers and users should get listened to. But if you look at the history you'll see that ESR has pulled this sort of histrionics several times before. And if you go through the archives and compare the state of things today, you'll even see that many of ESR's ideas have been implemented regardless of how loudly he shouted about it, and claimed that they've wronged him, and they don't respect his years of work.
Now the big political fight. ESR thinks Linux should include closed source modules when no open source version exists. Since Ubuntu is doing that, he's going to switch to Ubuntu. Good for him. I don't care. There was no reason to send the fact to web site expect to get attention.
It's good that Ubuntu gives you that option. Fedora made the choice to stay 100% open source. Ubuntu may get more people using Linux. That's a good thing. Fedora may get more people to develop the missing pieces. That's a good thing. I can't predict which will be more effective in the long term, so they're both good options. Everyone can make their own choice.
So what do we make of all this? ESR threw a hissy fit, and it got him attention. That's what he wanted so it worked for him. He may have hurt people at Fedora and he may may have attracted more Linux people to Ubuntu. Those are both very selfish actions. Reacting to his hissy fit is bad, because it hurts communication and it promotes more hissy fits in the future. So next time ESR rants, read it for the points it makes, but don't react to the hissy fit. Then maybe next time he'll have a discussion instead of trying to grab attention.
I had my first booth at SIGGRAPH this year. I'm demonstrating my uncompressed 2k playback system. It's turned into a really nice product and the archtecture is developing nicely. You can seem more about it on my webite:
http://www.digitalordnance.com/
Strictly economics. The studio wants to control the spread of the movie to maximize profit.
Movies often open in the US 6-9 months before they show in Europe. In many cases, the US DVD is out before the move has opened in Europe. With region codes they make it hard for Europeans to buy the DVD instead of going out to the theater.
I think this is a neat art project, but this would have been much easier to do with a digital camera, GPS, and a latop. No stopping to change rolls of film. No worrying about sequencing the rolls. Easier to make into a flash movie. A hell of a lot cheaper to process.
I do like this idea. I may have to try it on my motorcycle for my next long trip.:)
Well that sounds more like how I thought it worked, which is that the quiet codes were only sent at the start of a message. That doesn't match the description of the continuous subcarrier that other people mentioned.
Which is it? I admit I've never looked into the details, I just read the instructions that came with my FRS, so my technical expertise in this area is severely lacking.:)
Yes, but FRS has 14 channels and 38 quiet codes(*), which means you can pick a configuration where you don't hear them. It shouldn't be a problem.
(*) Quiet codes are little bursts that are sent prior to transmitting, so that multiple people can share the same channel. It's not perfect, but it works pretty well.
A color channel with 5 bits will split up the 256 color output values as:
0=0, 1=64, 2=128, 3=192, 4=255
A color channel with 6 bits will do something like
0=0, 1=51, 2=102, 3=153, 4=204, 5=255
So, even if you ignore the least significant bit, the color values are never going to match up. That's the difference between 16 bit and 15 bit. If you're hardware supports 15 bit (packed into 16 bits of storage) then you get the right behavior.
Not in any measurable way. You'd need 640x480/4=76kB more memory for graphics. The rest of the hardware doesn't change, you're just driving a DAC with an extra bit for red and blue.
Only on a Mac.:) Under X a 16 bit display is 5,6,5. X also allows 15 bit color which is 5,5,5 with the last bit ignored. Also remember that the pixel format is independent of the pixel packing. So you can have a 24 bpp display with a 32 bpp packing just because it's easier for the graphics card to handle.
That extra bit for alpha can be useful for things like pixmaps and texture maps before they are put down on the framebuffer.
The difference is that the color space is uniform, which means you can have true greys. 16 bits is done as 5 red 6 green 5 blue. That means you can't really have true greys because the color values are spread out differently among the color channels. There will always be a little more or less green. Having 18 bits makes that smooth and is a significant advantage.
There are really two places you can find people to respond to your RFP. The first is the appropriate developers mailing list. Most open source projects have one. Don't send the whole RFP, just say that your company is interested in funding some work on the project and point them at the RFP. This will hit a broad audience of people who know the package.
The second choice would be the consulting/professional services groups at most of the Linux companies. They have skilled developers who know a lot about Linux and Open Source and can contribute to a variety of problems. Chances are they'll see the mail to the developers list as well, but it doesn't hurt and pretty much insures you'll get a response.
Finally, you can and should ask that whoever does the work do it as open development and release it as open source. You can benefit the projects and get the pieces you want. That's they way most of our graphics drivers were developed.
It amazes me what people in the new economy have come to expect from their jobs. Some perks are a benefit to the company and the employee and that's great. Happy employees are more productive, but that's a business descision. A lot of new economy employees got spoiled by lots of perks and high salaries, and in the end, the new economy business couldn't afford to stay in business.
It is good to have a job you enjoy. That means you enjoy doing the work that the employer is paying you to do. It is good when you have bright and interesting coworkers to work with and learn from. You're lucky if that happens.
Enjoy your job, but remember it is a business. The company is paying you to do work that they sell to pay your salary and make a profit. They are not paying for you to play. If you're not working a full day; you're not doing your job. It isn't your employers job to entertain you.
Also keep in mind that there are many many people who aren't as fortunate as those of us in the technology industry. They go to their job for 8 hours and do work they don't like, because they have to make a living.
Enjoy what you do. If you want to have fun, have a life outside of work.
Darn good question. It seemed to make more sense at the time. VA thought they were going to make workstations, and then there might have been some synergy. They ended up pulling the plug on workstations, then all of hardware, and finally professional services. So the trend ended up being rather negative.
VA has shut down their professional services organziation. The DRI developers (Kevin Martin, David Dawes, Brian Paul, Keith Whitwell, Jeff Hartmann, Alan Hourihane, Allen Akin, and myself) were all part of that layoff.
VA wasn't provinding the funding for us. We were funded by a number of other projects for graphics vendors and for other graphics research organizations.
There are efforts underway to get the team reassembled at another organization, but that is still very up in the air.
Yes, I've got the 7004AWBR and it does allow you to do DHCP reservations. I can assign specific MAC addresses to specific IPs. Very handy for the laptop that moves between work and home!
By the way, they've been updating the firmware fairly regularly. I had problems with the Orinoco early on, but they got it fixed in the next firmware release.
Once again, people are confusing the concept of ownership versus licensening.
Any code Sistina wrote is owned by Sistina.They can license it any way they want. The license indicates how you're allowed to use the code that they own.
IF Sistina wrote all the code, (I don't know if they did or didn't) then they can choose to relicense future versions any way they choose.
Users have to submit "substantial" patches for Sistina to lose their ownership. Substantial is defined by the courts. Sistina could choose to rewtite those parts and regain complete ownership.
Because their previous code was licensed with the GPL, it remains free. People are free to work on that code in a separate repository, as they have done with OpenGFS.
It sounds like no one broke any rules. You may not like that outcome, but it is legal. I do understand it from a business perspective. It is really tough to keep a business running if you don't find some way to protect your IP. I've spent the last year and half trying with XFree86/3D and we weren't particularly successful.
Except that is isn't a layer. It's integrated into the X server just like any other protocol operation. They cost you nothing more than any other X call.
Try doing a little research before you anonymously post sarcastic remarks.
I thought it was sort of interesting that many of the X vs Berlin features actually said X does this too. That doesn't make it very much of a "vs" argument.
The key thing that many people seem to forget is that X has a nice extension mechanism. Everything Berlin is doing could be done as extensions to X. The alpha compositing is already being done via the RENDER extension. The Resize and Rotate extension will allow you to switch via mode and rotate on the fly. You could do the rest as extensions if you wanted.
The big advantage of extending X is that you don't throw the baby out with the bath water. All the old applications still work. Applications can decide which extensions to use when they are ready. This makes it easy to see what works and what doesn't and to let each application progress at it's own pace.
If you really want to do a custom interface and have a little hardware skills you should try an Arduino. You can interface to any hardware device and feed the data to the computer over serial USB.
I've been using my smart phone(s) for SSH access for the last couple years. I run a small business and have very demanding customers (who pay a substantial amount for support), and therefore need quick response. The smart phone has let me do that a couple ways:
First and more importantly it means I'm always connected to my email and voicemail. Being able to respond quickly with a call or email is a big benefit, and any smart phone can do that level of support reasonably well. You didn't ask about that, but I mention it because I feel it is the most important benefit.
Now, back to the phones with SSH. I've used two of them extensively. I had an Cingular 8125 (HTC Windows Mobile) for about 20 months and I now have a Blackberry Curve (8130) which I've used for the last 4 months.
During the 20 months I had a half dozen or so real occasions to use the SSH support. I used it for file transfers, I used it to examine and fix clients machines, and I used it to do other administrative tasks that were only available from my site. That's not often, but for those moments when it was needed it saved me a lot of time and was worth the cost of the data service.
The HTC phone had the better keyboard. On unix systems we use the special characters too much, and getting to those on the BlackBerry is a difficult. Both keyboards are too small to do anything quickly with them. In both cases the screen is really small. The connection is slow (neither unit is 3G), but for a text input it's OK. It reminds me of the old 9600 baud terminals on a main frame. The bottom line is that for occasional access to important information/applications it works just fine. It is in no way useful for extended work. If you a task takes more than 5 minutes you'd be better off finding WiFi at a Starbucks and using your laptop.
My clients are primarily in California and in major cities or along major highways, so that's where I have the most coverage experience. I've found the data service is fine everywhere I go. I use the email, web, etc. very regularly so I tend to notice the loss of data service.
My opinion is that smart phones work OK for occasional emergency SSH access. The keyboard limitations are the weakest link, but given the rest of the constraints on speed, screen, etc. I'm not sure it matters. As long as you're only doing this for short periods in case of a emergency it's a good answer.
A corollary is that if you have something you need to do regularly using the keyboard and SSH on your smart phone, you really ought to set up a web page. The web interfaces on the phones are better and it allows you to control the presentation. It also works better on a wider variety of phones.
You've got several choices:
1) Sell Training
Write books, on-line training, seminars, whatever, and sell that as an adjunct to your open source project. Of course, those can be open source as well.
2) Sell Customizations
Offer to develop custom features or just consult on deployment. Some of those may be rolled in to a future version of the existing package if that makes sense.
3) Sell Support
Get people to buy support for the package and offer telephone/email support for issues. If the application is critical to a business, they may pay to have support on hand.
4) Sell access to the code under non-GPL license
Some applications are release GPL, but offer the option of paying to get a closed source commercial license.
5) Split the package in to open and commercial packages.
Bundle the basic system as open source and then have add-ons that are commercial. This is sort of getting them hooked on the free version and then hoping they grow in to needing the features of the add-ons.
Regardless of which method you pick, you should realize it takes a lot of work develop a successful community around a piece of open source software. If your plan is to just throw the code out under an open source license, you're likely to fail. You need to promote your product, develop a group of users, have forums/lists for them to communicate, encourage developers, review and work on submitted code, and you need to spend time participating in those activities. Even then if your product isn't unique and interesting enough you won't get a following. Bottom line is that you need to be really committed to your open source project and it had better be best of breed or users will move to alternate choices.
ESR is getting all the attention he wanted, but posting his public letter all over the Linux web sites. Unfortunately, everyone is falling for it. Just because he jumps and down and screams doesn't mean he deserves the attention. It's also interesting how he mixes a few personal technical items with a big political issue. That gets people frothing (on one or the other), but doesn't really provide constructive discussion.
Let's look at the reality:
1) ESR has a package conflict. In an attempt to fix that he removed a library that was critical to the functioning of the package system, and then he was stuck, unable to restore his system.
Users aren't supposed to delete libraries from their system. If they try to do this with the package system it complains and stops them. If you do it by hand or you use the switches that allow you to override the system, then it's up to you to know what you're doing. Obviously ESR didn't know what he was doing, because it caused him these problems. You can sum this up as:
ESR removed the safty, waved the gun around, and pulled the trigger, and then was surprised when he shot himself in the foot. He should know better.
2) ESR didn't say what packages he had a problem with.
A lot of work goes in to making sure the primary Fedora repositories are consistent and work, but mistakes do happen. A bug report would have been more useful than just ranting about it.
I often see consitency problems in unsupported repositories and work around them. They're unsupported, which means it isn't Fedora's fault and is sort of to be expected.
3) ESR wants RPM to be statically linked so this can't happen.
Unfortunately, ESR hasn't looked at the realities of a modern distribution. Statically linking key applications used to be a good idea, but Linux today has a lot of pieces that won't function without shared libraries. Given all the things the package managers do, they need a fully functional system. Statically linked applications work when you're doing system recovery, but that's about it.
4) ESR couldn't fix his system.
Fedora ships with a system recovery disk. It is a full Linux system running from a CD. It's designed to let you fix just about anything that happens with your system. He could reinstalled the missing library by using that. Rescue disks are far from perfect. You really need to understand what you're doing to use them. But he didn't try, and didn't ask for help, and clearly didn't know how to do it himself.
5) ESR is important and everyone should listen to what he says
ESR is no more important than any other developer out there. Developers and users should get listened to. But if you look at the history you'll see that ESR has pulled this sort of histrionics several times before. And if you go through the archives and compare the state of things today, you'll even see that many of ESR's ideas have been implemented regardless of how loudly he shouted about it, and claimed that they've wronged him, and they don't respect his years of work.
Now the big political fight. ESR thinks Linux should include closed source modules when no open source version exists. Since Ubuntu is doing that, he's going to switch to Ubuntu. Good for him. I don't care. There was no reason to send the fact to web site expect to get attention.
It's good that Ubuntu gives you that option. Fedora made the choice to stay 100% open source. Ubuntu may get more people using Linux. That's a good thing. Fedora may get more people to develop the missing pieces. That's a good thing. I can't predict which will be more effective in the long term, so they're both good options. Everyone can make their own choice.
So what do we make of all this? ESR threw a hissy fit, and it got him attention. That's what he wanted so it worked for him. He may have hurt people at Fedora and he may may have attracted more Linux people to Ubuntu. Those are both very selfish actions. Reacting to his hissy fit is bad, because it hurts communication and it promotes more hissy fits in the future. So next time ESR rants, read it for the points it makes, but don't react to the hissy fit. Then maybe next time he'll have a discussion instead of trying to grab attention.
Since sequences of buttons can be arbitrarily long, has he actually found all the possible cheats? Isn't he still working on that part?
I had my first booth at SIGGRAPH this year. I'm demonstrating my uncompressed 2k playback system. It's turned into a really nice product and the archtecture is developing nicely. You can seem more about it on my webite: http://www.digitalordnance.com/
Did anyone else do the math?
He's visited over 4000 locations in 7 years. That works out to about 11 locations a week.
Starbucks is opening an average of 10 stores a week.
The guy is doomed if he doesn't really pick up the pace.
http://action.eff.org/action/index.asp?step=2&item =1723
Strictly economics. The studio wants to control the spread of the movie to maximize profit.
Movies often open in the US 6-9 months before they show in Europe. In many cases, the US DVD is out before the move has opened in Europe. With region codes they make it hard for Europeans to buy the DVD instead of going out to the theater.
I think this is a neat art project, but this would have been much easier to do with a digital camera, GPS, and a latop. No stopping to change rolls of film. No worrying about sequencing the rolls. Easier to make into a flash movie. A hell of a lot cheaper to process.
I do like this idea. I may have to try it on my motorcycle for my next long trip.
Well that sounds more like how I thought it worked, which is that the quiet codes were only sent at the start of a message. That doesn't match the description of the continuous subcarrier that other people mentioned.
Which is it? I admit I've never looked into the details, I just read the instructions that came with my FRS, so my technical expertise in this area is severely lacking.
Thanks. I misunderstood how they worked.
In any case, it should avoid the rhino bursts.
Yes, but FRS has 14 channels and 38 quiet codes(*), which means you can pick a configuration where you don't hear them. It shouldn't be a problem.
(*) Quiet codes are little bursts that are sent prior to transmitting, so that multiple people can share the same channel. It's not perfect, but it works pretty well.
No you can't. Think about it.
A color channel with 5 bits will split up the 256 color output values as:
0=0, 1=64, 2=128, 3=192, 4=255
A color channel with 6 bits will do something like
0=0, 1=51, 2=102, 3=153, 4=204, 5=255
So, even if you ignore the least significant bit, the color values are never going to match up. That's the difference between 16 bit and 15 bit. If you're hardware supports 15 bit (packed into 16 bits of storage) then you get the right behavior.
Not in any measurable way. You'd need 640x480/4=76kB more memory for graphics. The rest of the hardware doesn't change, you're just driving a DAC with an extra bit for red and blue.
Only on a Mac.
That extra bit for alpha can be useful for things like pixmaps and texture maps before they are put down on the framebuffer.
The difference is that the color space is uniform, which means you can have true greys. 16 bits is done as 5 red 6 green 5 blue. That means you can't really have true greys because the color values are spread out differently among the color channels. There will always be a little more or less green. Having 18 bits makes that smooth and is a significant advantage.
There are really two places you can find people to respond to your RFP. The first is the appropriate developers mailing list. Most open source projects have one. Don't send the whole RFP, just say that your company is interested in funding some work on the project and point them at the RFP. This will hit a broad audience of people who know the package.
The second choice would be the consulting/professional services groups at most of the Linux companies. They have skilled developers who know a lot about Linux and Open Source and can contribute to a variety of problems. Chances are they'll see the mail to the developers list as well, but it doesn't hurt and pretty much insures you'll get a response.
Finally, you can and should ask that whoever does the work do it as open development and release it as open source. You can benefit the projects and get the pieces you want. That's they way most of our graphics drivers were developed.
It amazes me what people in the new economy have come to expect from their jobs. Some perks are a benefit to the company and the employee and that's great. Happy employees are more productive, but that's a business descision. A lot of new economy employees got spoiled by lots of perks and high salaries, and in the end, the new economy business couldn't afford to stay in business.
It is good to have a job you enjoy. That means you enjoy doing the work that the employer is paying you to do. It is good when you have bright and interesting coworkers to work with and learn from. You're lucky if that happens.
Enjoy your job, but remember it is a business. The company is paying you to do work that they sell to pay your salary and make a profit. They are not paying for you to play. If you're not working a full day; you're not doing your job. It isn't your employers job to entertain you.
Also keep in mind that there are many many people who aren't as fortunate as those of us in the technology industry. They go to their job for 8 hours and do work they don't like, because they have to make a living.
Enjoy what you do. If you want to have fun, have a life outside of work.
Darn good question. It seemed to make more sense at the time. VA thought they were going to make workstations, and then there might have been some synergy. They ended up pulling the plug on workstations, then all of hardware, and finally professional services. So the trend ended up being rather negative.
VA has shut down their professional services organziation. The DRI developers (Kevin Martin, David Dawes, Brian Paul, Keith Whitwell, Jeff Hartmann, Alan Hourihane, Allen Akin, and myself) were all part of that layoff.
VA wasn't provinding the funding for us. We were funded by a number of other projects for graphics vendors and for other graphics research organizations.
There are efforts underway to get the team reassembled at another organization, but that is still very up in the air.
Yes, I've got the 7004AWBR and it does allow you to do DHCP reservations. I can assign specific MAC addresses to specific IPs. Very handy for the laptop that moves between work and home!
By the way, they've been updating the firmware fairly regularly. I had problems with the Orinoco early on, but they got it fixed in the next firmware release.
Once again, people are confusing the concept of ownership versus licensening.
Any code Sistina wrote is owned by Sistina.They can license it any way they want. The license indicates how you're allowed to use the code that they own.
IF Sistina wrote all the code, (I don't know if they did or didn't) then they can choose to relicense future versions any way they choose.
Users have to submit "substantial" patches for Sistina to lose their ownership. Substantial is defined by the courts. Sistina could choose to rewtite those parts and regain complete ownership.
Because their previous code was licensed with the GPL, it remains free. People are free to work on that code in a separate repository, as they have done with OpenGFS.
It sounds like no one broke any rules. You may not like that outcome, but it is legal. I do understand it from a business perspective. It is really tough to keep a business running if you don't find some way to protect your IP. I've spent the last year and half trying with XFree86/3D and we weren't particularly successful.
Except that is isn't a layer. It's integrated into the X server just like any other protocol operation. They cost you nothing more than any other X call.
Try doing a little research before you anonymously post sarcastic remarks.
I thought it was sort of interesting that many of the X vs Berlin features actually said X does this too. That doesn't make it very much of a "vs" argument.
The key thing that many people seem to forget is that X has a nice extension mechanism. Everything Berlin is doing could be done as extensions to X. The alpha compositing is already being done via the RENDER extension. The Resize and Rotate extension will allow you to switch via mode and rotate on the fly. You could do the rest as extensions if you wanted.
The big advantage of extending X is that you don't throw the baby out with the bath water. All the old applications still work. Applications can decide which extensions to use when they are ready. This makes it easy to see what works and what doesn't and to let each application progress at it's own pace.