Phone Laptop Tablet? PC?

This is where thing start getting interesting.
http://techreport.com/discussions.x/22544

What is a PC. Will we need them. The split between the 3 markets of Phone, Laptop and Tablet most likely will get smaller.

First thing this review points out is that the tablet is heavier than other tablets. Of course is simple to forget a device like this the tablet is a dock. So you can leave the dock in the room and not worry about any secure information being taken since the secure information is in the phone you took out of it.

For a traveller the biggest worry is total weight but the next is how long it can run from battery.

Reviewing these devices will have to be far more complete. Yes an add-on battery for a device will drive weight up as well.

There are also phones coming with projectors other integrated tech.

Of course KDE and Mozilla releasing there own OS's into this market next to Android to some looks a little foolish. Until you go and look at the phone market and have seen how many OS's are dead and gone. There is room for 4 majors in the phone market. Android and iOS have 1 and 2 at the moment. Rim barely holding on. Microsoft has been falling into background noise.

Ubuntu/Android hybrid items I expect to see more distributions do this somewhere in 12 months time. The trigger will be when the Linux mainline and Android kernels become one.

Wayland protocol change from X11 is going to be a little bumpy. This will solve large section of the problem of distribution in distribution. Since Wayland based can render to a buffer in another wayland server. So allowing Fedora Ubuntu and Debian to conexist running on the one kernel each running there own graphical environment. Yes the wayland change also makes it possible to run Android rendering to a buffer as well. So the future versions of the Android distribution hybrids should be true hybrids. This ends the need to virtualise Linux for anything other than secuirty reasons.

Will there be any major battles left. Yes audio for multi distribution is not sorted.

Systemd roll out will still take some time. Everything is heading in the right direction for a show down.

Big issue to Open Source. I am Important.

Linux Haters and others miss this issue because it makes them kinda non important. Since most of there arguments is that they are important.

Open Source projects really are the other way over. Most people expect programs to serve them. For successful open source the reverse has to be true you serve the open source program you got it for free the way you pay for it and get new features is treat it right and give back. You serve the Open Source project interest is a entity in its own right.

Upstream and Downstream is also important. Big problems come from Downstream thinking they are more important than upstream. Classic case of this is Ubuntu Wiki mind you Ubuntu is not they only one making this mistake. Most documentation in there really should not be there instead should be split up and stored at each of the projects they are talking about. One of the least commodity in the open source world is document writers. Clustering them at the upstream projects would get the most document writers in the one place to create documentation for everyone. This is for the good of the upstream projects.

So by running parallel wiki's to upstream you starve upstream of writers so harming the open source project you are depending on.

Next is patching issue been common with a lot of distributions history and now. "We are downstream we patch its our right" This over importance and forgetting about the entity the project is.

Ok how is this good for upstream its not good for upstream. Its also extremely bad for downstream since is means more hours work maintaining stuff.

If upstream has bad maintainers bugs will keep on coming. Forking is made out as a bad thing. Lot of project in the history of open source has forking been used to remove bad maintainers. Forking has one clear advantage for upstream. Number one the fork it self becomes a upstream number 2 since the fork and the parent don't have the same name bug reporting systems are not a nightmare.

Now patching does not have to be forbin. Instead all patching should be done in cooperation with the upstream project so preventing where able giving the upstream project a bad name when its not deserved.

Funny enough forking a project due to poor maintainer long term ends up less work. Reason the poorly maintained project most people will leave.

The most important question for a distribution maintainer should will my actions harm the upstream project. If so don't do.

Releasing beta versions to everyone as many distributions has been gulity of does not do upstream projects good. Beta versions are for testers ok there are acceptations like wine were the project prefers before reporting bugs the beta version is used. This is a upstream choice. Big problems are coming from downstream parts like distribution maintainers not following the upstream choice.

If maintainers were respectful of upstream and they want to do something against or without the advice of upstream the system to deal with it exists. Its forking. New name/version so the mistakes are clearly traceable to the maintainers head.

Big thing here is accountability. Failure to use forking makes seeing that the upstream project is not guilty of the problem so get blamed for problems they did not cause. So upstream gets flooded with bugs they should never have seen so start hating the distributions where these problems are coming from so become less responsive.

No More Secrets.

Yes I am quoting a classic move. The changes happening in compilers is making this more and more true.

LLVM is working integrating a decomplier framework. This allows optimization on binaries. Big difference is some of these optimizations could search for buffer overflows and other secuirty exploits.

This is truly no more Secrets to the closed source idea of improving security. If person can get hands on binary and scan it they will be able to find the same flaws as if they had the source code.

The magical encryption breaking box of the movie sneakers for closed source binaries is coming.

Of course embed device makers have been encrypting there firmware so those are not affected unless the encryption is poor.

The I Lack X application in FOSS issue.

Lets start off with the basics. Foss applications development is part controlled by there users and heavily controlled by there developers.

Even this rule of users effecting end product apply to commercial programs.

Key to get that X application you want in Foss is to find a group of people with equal goals and provide feedback. Prefer a group of people who are using the Foss program for profit since they can provide coders. How can a coder create a interface you will like if you don't tell that coder want you want. Chicken and Egg problem. User says foss programs don't provide what they want. Coder cannot provide what User wants because user does not tell them or find them to tell them.

Lets take one application as an example and its possible replacement.

You want Sony Vegas open source and free. Best project out there for matching the requirements is a program called blender. Blenders goals are far huger than Sony Vegas. A single tool that can build and video edit a full 3d movie from begining to end.

Case study on Blender is interesting. At first most of it users were blender trained personal. So improving the interface was not important. Adding features to get stuff done has been. So out siders would come along and hit a nasty interface. Over time some users got past that nasty interface due to blender being the only thing providing particular features.

Since those people have got into the project the interface is improving. Currently most of Blenders population is 3d modelers so focus on the video production side is just means to ends.

Population in project is key to there development. Just like the population of Sony Vegas users has controlled its development.

The argument that open source cannot provide X program is a bad argument. The question should be why have not the seed population of users started work on X program and got X program good enough to be used by commercial interests.

Long lasting and great developing open source makes someone a profit somewhere so they pay for developers removing need for direct sales.

Basically people forget how important to a programs development are the users. As FOSS usage numbers grow so will the range of applications on hand.

Open Source vs Closed Source=Ying vs Yang

Both sides are trying to kill to say there idea is better. Old saying is important its a ill wind that brings no good.

Closed source and Open source are two sides of exactly the same coin. Problem is neither can exist well without the other. Just like Ying and Yang they can get out of balance with each other.

Advantage of closed source is that programs can be sold as programs to recover development costs.
Disadvantage of closed source when programs become not supported any more they are not repairable.

Advantages of open source programs source code is accessible so program is maintainable into the future.
Disadvantage to harder to recover development costs due to giving away source code. You cannot give people taste of application so they will buy it as simply.

They are mirrors. Some companies like ID that make like the likes of Quake and so on have taken a halfway point. Application closed source for so long then released open source when no longer supporting application. This provides the advantage of both systems to end users and developer.

As with all things this is a repeat of history. The history repeat is books. Before the first printing press there was no required central storage of books. After the printing press it become law if you where publishing a book that it go to a central archive.

Both software and books are both protected by copyright. There is no reason why software cannot have the same rules applied. So the law becomes you wish to release closed source you have to give source code to a central repository for safe keeping until such time the application become unsupported then the source code gets released to everyone.

This forces maintainer ship and improvements on software markers.

Problem with closed source is nothing more than a repeat of lack of regulation like what effected books before the invention of archives. Without archives when books videos went public domain they might no longer exist for the public to have access to them.

Same problem is happening with software it is vaporising leaving people without ways of recovering there documents. 70 years like most book copyrights are is not really required. People need access to the software when it goes no longer maintained to access there data.

I want to know what right closed source companies have to take away a person right to access there own data on more modern day machine. Answer is really none. Yet we let them get away with this. This is the miss balance that needs to be-corrected.

I am back Sorry about such long time between posts.

Part of it is lack of ideas other part is time. Hopefully my muse will visit soon.

Myth 4: Longer release times equals better quality applications.

Sorry to say is one of the largest and very badly wrong ideas.

So a project releases every 2 months doubling that to 4 months really does not make a difference. To really understand how to do it correctly is looking at the Linux Kernel. Distributions failing to hit release timetables closely could also pay to read this.

Linux Kernel release a new version every 3 months. Reason why the can do releases so fast is Linux Kernel Development model. No patch going into a release goes straight into final Linux Kernel then out to Public. All patches have to go through a peer vetting process. Most cases at least 3 different people have signed off that the code is of good quality and passed there tests.

Out of that 3 months over 2 months is quality checking of the patches that got approved. Any patch/alteration that missed the 2 week windows for include in the next Linux kernel goes into a side tree for testing. If quality is not good enough it don't merge into the main Linux kernel. Some patches have taken over 2 years before they eventually make it into the Main kernel. Yet in that time there have been 3 monthly releases.

Then there is a kernel testing frame work to make sure no errors have slipped in.

Theory you could ramp the Linux kernel up to daily released without dropping quality. The over lap of the testing process with the release process makes it possible. Patches that get released into the Linux kernel have been tested way more than 3 month release cycle.

Most Distributions have made the problem of quality control many times harder due to there packaging systems. Where Linux kernel can do a incremental update with 2 parts using 2 different systems to the same job side by side packaging systems cannot. Deprecated functions in the Linux kernel is an example of this. Function is Deprecated but is still around for the drivers that use it.

Distributions need to be able to do Deprecated dependencies while applications are on the system that have not been tested against the new dependencies those applications allowed to use older deprecated ones. Most distributions cannot do this. There packaging systems have been designed completely with the idea of 1 .so file 1 configuration system and so on. So Distribution are getting overloaded trying to make every application and dependency work with everything else on the system at once.

Basically breach of Quality control maintainers should never be force to rush there quality testing like they are now. If X application is stable with Y dependencies maintainer not happy that replacement dependencies have not been tested enough yet maintainer should be able to delay it. Where maintainers hit hell is delaying Y dependencies from being updated will block other applications from being installed so they get other maintainers on there back or just forced to use the newer dependencies because the older ones are not being provided. This is where the pressure is coming from for Maintainers to rush the Quality control process.

Longer and smoother transition from one distribution version to another is required. Please note the word transition installed version in the transition would be part way between versions. No sudden changes. Sudden changes equals major over load of Quality Control processes. Its like slowing down for school zones it makes sense.

The release time issue is nothing more than a smoke screen covering up design bugs forcing quality controls to be rushed or lack of quality controls put in place.

Lot of work is need to bring Linux Kernel style quality control processes to lots of open source and closed source project out there.