Oiaohm Battle Ground

Big issue to Open Source. I am Important.

2009-11-26T14:49:00.000-08:00

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.

2009-10-28T16:46:00.000-07:00

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.

2009-10-04T15:44:00.000-07:00

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

2009-04-01T02:49:00.000-07:00

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.

2009-02-06T22:16:00.000-08:00

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.

2009-01-03T01:22:00.000-08:00

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.

What sets the path of Linux?

2008-12-26T02:41:00.000-08:00

Ok been off the blog for a while sorry Christmas/work caught up with me.

This is one of the more interesting fields. Something I find most people don't know.

Lot of people think Distributions. Report bugs to them will change future direction of Linux. Most case no. Reason lot of distributions don't send there bugs upstream to the projects that you are using.

Linux kernel developers come from all sorts of companies and all sorts of fields. Each of these fields have different needs. Problem for many years most of the fields that made up the Linux kernel had no need of a graphical environment. So yes the make up of developers in the Linux kernel sets part of the path.

Some thing that personally makes me laugh. When people say they use a Linux Desktop and X year will be the year of the Linux Desktop. I am sorry there is no such thing. Linux graphical environments are mostly X11 environments who future is highly effected by freedesktop.org. Freedesktop.org is OS neutral any one is welcome to take part in there mailing lists. Of course you have distribution alterations on top of the default X11 enironment but under it all its still a X11 desktop.

Same with xfce gnome kde and others. Users are welcome to take part in there mailing lists. To request features complain about features or even thank developers for adding features.

Simple answer to what sets the path of Linux is who ever takes the interest. Yes sometimes you ideas get out votes but that is the way of life.

The words of the three wise monkeys apply to Linux. Speek no evil, Hear no evil, and See no evil. Does evil still exist? Answer is yes. Just no one is looking or listerning for it. Or everyone is seeing evil and not talking about it.

Lot of people try Linux and leave Linux without ever posting 1 bug report or feature request. Then wonder why when they come back after years have passed the same fault remains. Of course not all bugs will get fixed at least by posting the report you can say truthfully you tried. If programmer sees few hundred users wanting the same feature fixed it moves up list.

Same problem effects the Open Source world. I really don't know what need to be done to make it happen more? Yes a open topic what would you suggest to increase feedback to developers from end users.

Bad language and Linux Kernel.

2008-12-14T02:46:00.000-08:00

This is out the just for fun. Personally take a guess what you think the highest swear word would be in the Linux Kernel.

Then ask your self if it would out number the word penguin.

http://www.vidarholen.net/contents/wordcount/ << Then see if you are right.

Now it would be fun if we had the same stats on Windows.

Development tools and how they fail everyone.

2008-12-12T16:32:00.000-08:00

There is a reason why Microsoft is moving to .net.

Sad part is that it is only curing part of the problem that should have been cured years ago. Problem is coming from OS design and compliers lack of means to handle it.

Gcc is a pretty bad offender. llvm one of gcc relations does a far better job at finding secuirty flaws. Simple little flaw http://gcc.gnu.org/wiki/LinkTimeOptimization . Lack of Link time optimistation. Optimisation engines where added to Gcc to detect buffer overflows and other defects problem is they are basically rendered usless when the problem crosses 2 object files.

Even llvm and MSVC are not perfect. Instead of being like gcc where defect exists between 2 object files that make up an executable. There defect exists between the .so/.dll and the executable. It is basically the same problem. Complier building the executable cannot inspect the code in the .so/.dll to make sure that code is not going to malfunction.

All 3 so far stated llvm gcc, MSVC all offer runtime buffer overflow protection optional build option. Problem with runtime buffer overflow detection it basically equals crash in case of buffer overflow poor users lose what they are working on.

Now of course someone here will think java and .net are the save all. There design has the same defect as what executables and .dlls normally have. You have executable and loaded part. Code audit in java and .net is done when the application is converted to bytecode that process does not inspect again for reactions between the dependancies and the application leading to unwanted events.

Now what happens if a dependancy changes between build of the application there is no way at moment to effectively audit to see if the change has created a new secuirty hole.

No complier system in existance is currenty taking the problem of dynamic parts causing failures. Now you might say why don't .net or java just do it on first run. Problem with auditing applications it is slow. Most users are not going to put up with a 5 min delay as the application gets checked for defects when they want to use it now. Bytecode that stays bytecode hits a wall.

Should application+depenancy reaction checking been a feature Anti-virus firms tried to develop yes. Detecting new secuirty flaws before they can be used would shutdown a lot of problems.

Should the same feature be in the development tools yes. We cannot expect programmers to know every out come of every function they call in a thrid party library. Complier saying ok this is wrong gives developer chance to fix it.

This now causes a major problem. How do you provide enough information to the complier that it can audit if calling X function with Y options will cause a secuirty defect or not. This is why open source get loved by people developing highly secure systems. You can run auditing engines over it. Black box's of closed source reduce the effectiveness of automatic defect detecting tools like http://www.coverity.com/ .

.Net and Java with there partly reversable bytecode may provide a way for closed source developers to stay in game.

Yes closed source developers try to dispute the simple audit issue. Really solution needs to be developed for Linux, Windows and OS X. Part gets updated and everything that uses gets inspected to make sure it did not cause a secuirty flaw our problems would be far less.

Trying to design a New OS without facing this problem is only going to cause the same problems in time.

People said what convity does was impossible. Reason they though scanning a complete program as a hole was too complex. Scaning segment by segment is impossable. Scanning need to be done over the complete program at once with it broken down into segments that react with each other.

Now here is the rub. Since developer are the only ones that use Development tools there is normally not that much interest in fixing them. Numbers of developers are small. Market of end users is huge. So guess where the money is. Remember Development tools are the fountation of all applications out there. If they don't work to the best everything on top risks falling in.

Ok time to break one of the Golden Rules

2008-12-11T23:41:00.001-08:00

Never ask a question you don't know the answer to.

What areas do you guys want me to look at? Either my posts are outside interest, Too complex of read or just no one can find a flaw in the logic. Or worse I need to slow down on posts because I am not giving you guys enough time to dig threw them.

There are plenty of paths I can choose with my background. If I am boring everyone silly there is no fun in that.

Just for fun is my main reason for doing this. I do enjoy doing research. I do enjoy a good debate as well.

Myth 3: Anti-viruses are always required.

2008-12-11T16:50:00.000-08:00

Now this is one could really bring havoc.

First to understand why this is a myth you need to understand what a anti-virus does really.

Real-time scanning for unknown viruses is really the following. Checking for code attempting to use known exploit points and for any strange change in behavior of an application. Something OS security really should be doing.

If someone has a system that there user account always contains no executable data and there applications are from safe locations and there security system works most of the unknown virus scanning is covered. To be correct with exploit removal as high priority they can be at even less risk. Microsoft using patch security flaw when it breached model is kinda too late. Only now is some media starting to complain about it.

Known virus scanning is scanning against signatures of threats. Next question people never ask is how do honey pot runners find out about unknown viruses that have beaten there security. Its really simple they use the reverse of the way anti-virus works. Instead of scanning for a thread scan for what you know should be there anything else is a threat that needs investigation model.

Honey pot systems don't need anti-virus software. Heavy security OS's some of them can get by without them.

Anti-Viruses are not always needed if correct preventive action is taken. If you have an OS like Windows where the core security system is flawed you can be forced to use Anti-Virus software. Should you be happy about it no way in hell.

Its remembering everything has to suit its environment or its pointless. Running anti-virus over a stack of files that don't contain any threats that can be signature on an mirror to an anti-virus ie Host Intrusion Detection can save company many hours of computer processing time.

There are quite simply times when anti-virus software is pointless and an waste of resources. Does this mean the files don't need protection from something the answer is no. Security always has to be maintained anti-virus software is just one of the optional tools to do it.

Sad part is even some Anti-Virus companies believe this myth that they are always required. So research into Host Intrusion Detection the mirror of Anti-Virus signatures has not been done as completely as threat detection.

The Weaknesses in Overall Linux Secuirty

2008-12-08T15:35:00.000-08:00

These all need fixing. Major one from a security point of view is the use of Apparmor. Ubuntu and Suse along with others go on making out to users that Apparmor simple to use yet the fail to say something important. Just like any other experiment science security systems should under go review by other parties. Apparmor failed its review for include by default in the Linux kernel.

Yes designing a security system for a OS is a science. You try something it fails you improve it and try again until you get something that works. Of course to save repeating the mistakes of others it pays to read what has worked before starting out and what has failed.

Where did Apparmor fail quite simply path based there is no framework in the Linux kernel to enforce that and there system for doing it is flawed. Tomoyo another security framework using paths is working on solving the enforcement issue always putting there designs forward for review in the Linux Kernel mailing list because they want to get it completely right.

Until issue is fixed from an reviewed security model neither Tomoyo or Apparmor should be used in production systems. Since using a defective security system in Linux is equal to using a defective anti-virus.

Next major weakness is between all the security systems of Linux there is not a single file format to describe what they all require from an application developers point of view. So distributions create there own security profile. The teams who know the most about an application are the developers not the maintainers in distributions.

Distributions sticking to old security designs is also a major problem. Would you really by a old car with defective tires. Linux kernel basically keeps old security designs alive for backwards compatibility so the old distributions can be kept running. Yet for some reason people seam to think its still fine if its still in kernel. Sorry no old defective should replaced with something better when distributions rework there packages.

Suid bits have been able to be not used for a while now. Suid bits change user to the owner of the file to perform an task. Anyone else see the problem with running ping as root and 1000's of other programs. Its like a huge kick me sign a single one have an exploitable defect and you are stuffed. Posix file capabilities the Linux version of them is designed to do away completely with giving application a fully non controlled root access. Ping only need higher network access no other special powers. Yet there are still thousands of distributions out there when you check ping its got too many privileges. Other side effect of what they have done. If you build the Linux kernel with root user having privileges removed then try to run there distribution on it the complete distribution stops dead. Distribution will posix file capabilities setup right does not require root. Linux kernel has recently had to go as far as making it imposable to build without posix file capabilities because lots distribution were going as far as disabling them. At the rate its going one day Linux kernel is going to have to release without a root user by default to make some of these distribution pull there head out sand and fix the security problems. Where are the pitch forks of users killing Distributions why should they get a free ride on not keeping security designs up to date.

Configuration. This is a major security issue all distributions alway have wanted to go there own path on this. This leads to a hard to maintain system to keep configured right. It is requiring freedesktop.org to come in and sort the issue out between application developers. Please be aware policy kit at freedesktop.org has very few distributions who show any great interest in creating a common solution. Same again why are not users of distributions not up there ribs to get a common configuration system.

If you are going to attack somewhere get it right. Complancy is a big problem in the Linux World. It will not stay secure if you don't speek up particularly in your distribution and media.

Myth 2: Unix the be all and end of of Security.

2008-12-07T17:40:00.000-08:00

This is the biggest myth you hear when people are trying to say Linux is secure.

Unix design first is not called Unix. Its called Posix. So yes name is wrong to start off with.

Lets just go over what Posix covers for 1 min.

System will have a root user to admin system. This is first problem most OS's like Solaris and Linux that people like to call Unix existence of a Root user is optional. Its a historic relic of the Unix days. Reason why its optional is that it a security risk.

Services run as lower users ok up until a point. Posix standard never formally ratified Posix Capabilities. So all services connect to ports under 1024 must at least partly start up as root on an as per Unix model system. Linux and Posix Capabilities allow powers of root to be granted in a segmented way.

No firewall is defined anywhere in the Posix define of what should be there.

There is no defined Mandorary Access Control.

Now as you can see Unix Model security is not that great. Linux, OS X, BSD's, Solaris have all extended past this model. All the Unix Model does is provide some common sense ideas.

Worst part of this Unix Model worship is the myth that root user is good. Sorry root user is one of the biggest design flaws in the complete Unix Model.

Sudo and su are from the Unix world both flawed ideas. What is the root users most dangerous problem. Operations performed by root are not logged by default. There is no way to tell what user who has access to root power did what.

Policykit and more modern systems of the Posix world provide far better logging and finner grain control over users of it. Even selinux role based security provides finer control. You don't hear any of them yelling from the roof tops that X distribution comes with selinux role based security enabled.

Sorry everyone some typos sneaked in. Boy do I like this method at least I can fix them.

Future of Linux next 6 months.

2008-12-07T17:14:00.000-08:00

Linux kernel proper desktop support.

DRI2 fixes up large block of performance issues in X11 and crashes.
April 2009 if everything sticks to time table Linux gets Kernel Mode Switching or DRM mode switching. Removing the issues of switching backwards and forwards between X11 and console causing crashes also making kernel panics truly be displayed. No more sitting there wondering if computer has fully crashed or is just in meditation due to load.

Cross distribution packaging at this stage is looking to be just outside this time frame. Cross distribution binaries should start appearing in numbers.

KDE 4.2 will land also KDE 4.3 is also predicted to land. Both of these are working to having a configuration system independent to distribution to configure the system.

Nvidia and Vmware should wake up to how much trouble there closed source drivers in kernel space are in. Ksplice is working on a extention called kreplace what is basically replace complete kernel while user is using it. Closed source driver developers have complained about not having a stable internal kernel abi its now got the level worse. Its not even stable at runtime.

Is this going to make closed source drivers impossable answer is no. cuse and fusd are both working on solutions so closed source drivers run in userspace even Linux kernel developers are interested in them for no longer supported drivers. Currently Linux kernel developers have two options with no longer supported drivers leave them in kernel and hope a developer turns up or b delete the from the kernel and hope they don't hit users. Userspace drivers provide a thrid option kick them out to userspace so they no longer have to be kept in sync with the changing internal abi.

As what has been recently compained about is firmware yes it is the other option for closed source drivers. Lot of driver developers hate it just as much as userspace. Firmware does not interface directly with any kernel structs of the OS so once you release Firmware your device can end up operating on any OS that someone creates a driver for. Also not directly interfacing with kernel also removes options to tweek kernel performance.

These are just the highlights.

Myth of IT 1: Market Share explains Virus Numbers

2008-12-06T03:08:00.000-08:00

Market Share explains virus numbers alone.

Since Microsoft has 90 percent of desktop they are allowed to have the viruses.

Sorry to say this is myth. Even when Apple has the lion share of home computer market virus numbers on Dos was higher in virus numbers. People claiming this myth have not checked there history. There are stacks of abnormalities in the numbers.

Possible valid answers for virus numbers is the combination of the following.

Over all OS Security. If a OS does not have good security its a welcome sign for attackers same with if defective applications are run without enough security. Microsoft Windows is guilty of this one.

Ease of programming for platform. Simpler it is to create applications for the platform the simpler it is to create malware and viruses. Windows is fairly simple for this one.

Market Share. Now there is a problem here yes Microsoft has a large desktop market share. Linux has a high server market share. Depending on what the attacker is doing different market types interest them. If attacker are after something always on they will go after servers. So yes market share alone does not explain the numbers.

Following the myth has allowed the major virus problem like we have now to happen.

Welcome

2008-12-06T02:53:00.000-08:00

This is my battle ground. So far Linux Hater and Linux Hater's Redux has left the building. At least Linux Hater has been good enough to leave the building with a final message.

I am not like either. I am not exactly out to make Linux look bad alone. If Linux is defective in an area lets go for it. If any other OS is defective in a area same thing lets go for it.

I do follow Linux a lot so some things here will be my predictions on the technology coming to Linux and its short term effects. None of these predictions normally be longer than 12 months.

There will be no room for freetard or wintard or any other tard arguments. If something is a myth and I or anyone else here says bust it.

One word of warning in advance. Windows Vista and before don't dare say its secure. Simple fact its not. This is where Linux Hater's Redux hit the wall.

I will do from time to time how computer secuirty should work. Now if any OS or Distrobution out there is claiming to be secure when its not bring it on. For fun from time to time I will bring up Myths of IT. These will be Tard arguments or incompetent reporters. Lets have some fun.

Luser and other abusive term used without facts supporting you will see your post deleted. This is the first and only warning. If you are not sure don't use abusive terms.