kapare

skia 2D Graphics Library

2011-05-18T17:49:00.000-04:00

From time to time,

I try to understand what's surrounding my or should I say what is out there that tickle my curiosity.

When Android was release in 2007 I was trying to understand what was bind the user interface.
http://sgl.sourceforge.net/

"SGL consists of a set of cross-platform C++ libraries, built on top of OpenGL, which implements 3D scene graph functionality (sgl), some simple 3D model loaders (sgldb, sglobj, sgl3ds), and some miscellaneous utilities (sglu)."

So today that simple explanation come back into my head and I try to answer a bit more of what that sgl was doing in more details. When I arrive on the sgl page and notice that the last update was on 2004. This was not possible that Android was depending on old stuff like that. So with another search I found post:
http://stackoverflow.com/questions/2940117/android-2d-graphic-library

That was speaking about skia that I then found on code.google.com
http://code.google.com/p/skia/

So to get a better look of what this was all about I try to follow the contributor steps:
http://code.google.com/p/skia/wiki/ContributingHowto
That made me download the source code and then try to compile it.

NOTE: Ubuntu 11.04 needed to install a package to get ride of a error:
src/core/SkAdvancedTypefaceMetrics.cpp:21:22: fatal error: ft2build.h: No such file or director
Here the solution: sudo apt-get install ftgl-dev

Then a simple make compile everything without any problem.
make tests work without problem and also bench, gm, skimage and skhello

Since we're testing a user interface we are searching for a demo that will run on unix and hope to see some colors !

To do, a navigation into directories show us support for xcode, vc and more. But the what sounds interesting is the unix_test_app
cd unix_test_app
make
cd out
./output

Then boom a super UI with colors and a mouse event interactions that make my see a close comparison with a scrolling menu on a android phone ;)

Deeper look at the main.cpp look us see dependencies:
#include "X11/Xlib.h"
#include "X11/keysym.h"

#include "SkApplication.h"
#include "SkEvent.h"
#include "SkWindow.h"
#include "SkTypes.h"

The main create the window and start the window loop. The same window pointer will be reuse to process events.

The DrawBlue that is the implementation of our example reuse and modify the SampleCode.h. It inherit from SKView.

The next step should be to modify the source code to see how it behave.

Good morning to Usage-Based Billing!

2011-02-02T12:09:00.000-05:00

Here a nice letter from my ISP to tell me that I will now be controlled by the same limites as bigger company that control them. Welcome into super limited world of internet!!!

Bell was already sucking at services & quality off there network now they just suck ;)

-----------

Dear Acanac Customer,

The CRTC just decided to allow Bell Canada to charge independent ISPs, like Acanac Inc., what's called "usage-based billing"(UBB)on our customers.

This means that Bell will force us to pay usages fees similar to those that Bell charges to its own retail customers, when you exceed certain limits. Bell and other Big Telecom companies are obviously trying to gouge consumers, control the Internet market, and ensure that consumers continue to subscribe to their television services.

If we do not fight this you will have no choice but to pay MORE for LESS Internet. This will crush innovative services, Canada's digital competitiveness, and your wallet.

250,000 people across Canada have already signed the petition to stop these companies from charging you more. Signing the petition automatically sends Industry Minister Tony Clement an email. This is our best chance to stop usage-based billing.

Please Sign the Stop The Meter petition at: http://stopthemeter.ca/ Please also help us spread the word to your friends and neighbors.

Please make your voices heard. If we don't stop UBB, as of March 4th, 2011, Acanac will make the following changes to accommodate the charges that will be FORCED on us and subsequently you, our valued customers:

Ontario Residential 5Mbps DSL Plan:
First 25GB at up-to 5Mbps. Beyond 25GB your speeds will be reduced to 100Kbps with unlimited transfer.

If you wish to remain at up-to 5Mbps, you can buy an additional 100GB of transfer for $9.95 per month. Beyond 125GB, speeds will be reduced to 100Kbps with unlimited transfer.

Quebec Residential 5Mbps DSL Plan:
First 60GB at up-to 5Mbps. Beyond 60GB, your speeds will be reduced to 100Kbps with unlimited transfer.

If you wish to remain at up-to 5Mbps, you can buy an additional 100GB of transfer for $9.95 per month. Beyond 160GB speeds will be reduced to 100Kbps with unlimited transfer.

Ontario & Quebec Residential MLPPP DSL Plans:
Same as above but multiply it by the number of lines you have. If you have 2 lines or Home 10Mbps in Ontario, you would get 50GB included and you can buy an additional 200GB for $19.90. Once you reach your allocated transfer, your speeds will be reduced to 100Kbps per line with unlimited transfer. In this scenario you would have a total of 200Kbps after 250GB of usage.

What if the transfer options above are not enough?

Priority number one is to sign the Stop The Meter petition at:
http://stopthemeter.ca/

In addition to signing the petition you can use an Online PC as a bypass to the imposed usage-based billing on you by Bell and the CRTC. In partnership with http://www.zazeen.com/, you can continue downloading at over 1TB or 1000GB a month for as little as $23.95 per month.

How does this work?
Instead of downloading your data directly to your local computer, it is downloaded onto your Online PC located in our DATA Center. Your Online PC is connected to multiple Fiber optic lines capable of over 30Gbps or 30,000Mbps. This will bypass the Bell copper lines and the imposed usage-based billing.

Once the Data is downloaded onto the online PC how do I get it to my local computer?

Secure overnight DATA Shipment.

Step One:
Copy or move the Data that is to be shipped into an encrypted file container that only you have access to. (Provided within the Online PC)

Step Two:
Ship Zazeen a SATA Hard Drive with enough capacity to hold your encrypted DATA content. If you ship a hard drive that has more space than your Online PC, we can hold on to it until you fill it up completely. With Hard Drives currently passing over 2TB or 2000GB, you can continue to download without any additional UBB fees.

Step Three:
Zazeen will now copy your encrypted data onto the supplied Hard Drive. At this point, we will ship it overnight via FedEx: Acanac subscribers get 1 free data shipment per month.
More info at http://www.zazeen.com/Data-Shipment.html

Click below for an in depth video presentation of Zazeen's Online PC service. http://www.zazeen.com/Zazeen-Intro/Zazeen-Intro.html

Bandwidth Transfer tracking:
On Feb 20th, 2011, Acanac Inc. will have a new Internet usage section in the Management Area of our Web Site located at https://www.acanac.com/Login-Section.html In this location you will be able to pre-purchase additional usage blocks and check your daily bandwidth usage.

Once again please DO NOT FORGET TO SIGN the Stop The Meter petition at: http://stopthemeter.ca/

Best Regards,
Acanac Inc.
www.acanac.com
support@acanac.com
Telephone: +1 (866) 281?3538
Toronto 1-416-849-8520
Montreal 1-514-667-4304
Vancouver 1-778-786-4196
Ottawa 1-613-686-5217
Calgary 1-403-451-6156
Corporate Office
1650 Dundas Street East. Unit 204,
Mississauga, Ontario,
Canada
L4X 2Z3

Me getting some visibility!

2010-05-25T12:54:00.001-04:00

http://www.linux.com/news/featured-blogs/185-jennifer-cloer/312233-the-people-who-support-linux-driving-4000-miles-to-linuxcon

Is the system clock set to local time or to GMT?

2010-05-10T14:24:00.005-04:00

This explain difference between GMT and local time, perfectly by bashing on proprietary OS :)
Summary: see bold

### Local vs. UTC ###

The first and most important question you'll have to answer is whether you
want to store the time in your machine in either UTC or local time format. UTC
(Universal Time Coordinated) is the same as GMT (Greenwich Mean Time). Local
time is the time that is displayed on a clock hanging on a wall near you. Each
format has its own advantages and disadvantages, but both of them are
discussed in this hint.

Traditionally, all POSIX machines (i.e. Solaris, BSD, UNIX) have their
system time in UTC format. The more stupid OS's (mainly the Microsoft ones)
require their users to configure their machines for local time. Fortunately,
Linux can handle both the normal UTC machines and the machines suffering from
Microsoft diseases that have their system time in local format.

At this point, you'll have to decide what it's gonna be; local or UTC time.
Some guidelines: If you're running Windows and Linux together on 1 box, I
recommend you use local time. If you have Windows but you hardly use it or if
you don't have Windows at all, it's a good idea to store your time in UTC
format. Once you've decided, edit /etc/sysconfig/clock. Use UTC=0 for local
time and UTC=1 for UTC (GMT) time.

reference: http://www.linuxfromscratch.org/hints/downloads/files/time.txt

So what happen if you use virtual machine?
The virtual machine will add abstract layer to add the time offset from real hardware clock.

reference: http://www.vmware.com/pdf/vmware_timekeeping.pdf

Randall Spear Single

2010-02-11T11:22:00.002-05:00

Friends invite me last night at Place des arts to see their friend Randall Spear for his first show for the release of his Single!

http://www.laplacedesarts.com/pda-evenement/3755/week-ends-de-la-chanson-quebecor,-randall-spear-s.fr.html

The show was amazing and Randall and is band were ready and gave intimate and nice show. I was felling lucky to be part of that emotional experience! Special thanks to Jerome and Genevieve!

You can found more about Randall Spear music on My Space:
http://www.myspace.com/randallspear

There will be a nice article on Randall on the Montreal journal on the weekend section.

Randall congratulation for that amazing achievement!

Acanac DSL Internet review

2010-01-30T16:40:00.016-05:00

This is simply to write about my first experience with the ISP Acanac internet.
The reason why I'm writing this is because I have read a lot of negative comments about that ISP. Other ISP were saying that I will called then and beg then to go back with them.

So let see!

The reason why I decide to go with them is because it was the best offer for the less expensive.

18.95 / month! So is it really that price? Yes but we need to add some detailed.

1- Dry loop (ligne seche) 8.00 / month * 12 month = 96 * 4.80 (GST) = 100.80
2- DSL modem cost 50$
3- 18.95 * 12 = 227.40$
2+3- 277.40 + 13.82 = 291.22$
4- Total each month = 291.22 + 100.80 = 392.02 / 12 = 32.67$ / month all included.
5- Year after that I will have no need to buy the new DSL modem so my payment will deacrease to : 241.22 + 100.80 = 28.50$

Company offering DSL that have been compared:
acanac.com
aei.ca was 29.95 / month taxes not included + dry loop at 10$ + modem 100$ - 25$ if you were old client for more then 3 years.
b2b2c.ca around 35$ without modem and dry loop without taxes.
bell.ca Since all other company in my test were using bell network I was more intrested in not using bell to help other then the conpany having the monopol.
www.ca.inter.net 29.99 without tx + dry loop at 11$ + modem ~75$

Speed test used:
http://www.speedtest.net/result/700265229.png

Acanac interesting tutorials:
https://www.acanac.com/Tutorials.html

I place my internet order with Acanac on Wesdnesday January 20 night at 10pm. On Friday Januray 22 I was receiving my first billing account of 100.80 for the dry loop installation. Acanac were calling me to ask me to be at home on Wesdnesday January 27 from 9h00 to 17h00. I received my DSL modem on Tuesday January 26 by Fedex. The Bell technician activate my line at 12h00 on the Januray 27. I plug the DSL modem configure it with the documentation that was coming with. Couple of minutes after that I was surfing :)

Since then I have bridge my DSL modem with my linksys WRT54GL to have wireless. This step a clearly explained in the Acanac tutorial. Note that the user interface of my DSL modem is not the same but it is very easy to fill the gap.

Conclusion:
Acanac offer a perfect service and the best price on the market. I will have paid more then 10$ / month with other ISP for the same service. The reason why Acanac offer the best price is because they are the only one offering a deal if you pay all the year in one payment. Otherwise it will cost more then AEI internet per month if I look a the web page. AEI will be my choice if I was not able to paid in one payment. Mmmm maybe not since the dry loop cost more you should check.

Making Skype working on Ubuntu 9.04

2009-10-03T23:55:00.003-04:00

Install skype

sudo apt-get install skype

Setup sound and mic for skype.

killall pulseaudio
sudo apt-get remove pulseaudio
sudo apt-get install esound
sudo rm /etc/X11/Xsession.d/70pulseaudi

Reference:
http://boostmyworld.wordpress.com/

Write and Submit Your First Kernel Patch

2009-09-25T14:15:00.042-04:00

From the LinuxCon 2009 Tutorial on write and submit your first patch to filling the gap of what is missing in my toolbox.

So first thing first, I will describe technically what we have done and what Greg Kroah Hartman explain to us. For all the details about that tutorial go to:
http://www.kroah.com/log/diary/2009_09_11.html

1- Clone the last git tree of Linus was a requirement to assist to that tutorial. All patch that are send are done by synchronising with his git tree:
cd ~
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6

2- Then after downloading the source we need to start modifying the source so for that we create our own branch to do our own development.
git branch tutorial

3- After creating that branch we need to update the HEAD, where this is the index of where we are on the tree go to
http://git-scm.com/
for more infos, to be on our new branch
git checkout tutorial
git branch // to see if branch have been created and we are checkout on it. there is a star '*' before the name of the branch to determine where are HEAD is pointing.

3a- The step 2 and 3 could have been done in one step:
git checkout -b tutorial

3b- That raise a question: How to delete a branch? And what happen if we are checkout on that branch? So to answer the first question man git-branch gives:
-d
Delete a branch. The branch must be fully merged in HEAD.

-D
Delete a branch irrespective of its merged status.

So that is what I was expecting, both gives the same error. I need to update the index of the HEAD to another branch before being able to to this:
git checkout -b tutorial2
git branch -d tutorial2
error: Cannot delete the branch 'tutorial2' which you are currently on.
git checkout tutorial
git branch -d tutorial2
Deleted branch tutorial2.

4- So let's go back to the tutorial. Founding warning with checkpath script was the task that have been ask for the tutorial to demonstrate how to send a patch. To do this there is a script inside the script directory that can help us checking the coding style. Each people on the room have receive a file to fix:
4a- Found warning.
./scripts/checkpatch.pl --terse --file drivers/staging/comedi/drivers/amplc_pc263.c

4b- Fix the warning.
vim // fix warning

4c- Commit the changed after removing all the warning.
git commit -a
This command will ask you to explain your changed so on the top of that text file we enter an explanation of our changes and save it:
Staging: comdedi: fix coding style

The commit message could be entered from the command line directly:
git commit -a -m "Staging: comedi: fix coding style"

To change the editor that is used during the commit do:
git config --global core.editor "vim"

NOTE: Changing the editor to vim, and other stuff also, help me to fix error that checkpatch.pl was giving me (trailing whitespace) during step 5 and later.

Here's my settings:
vim ~/.bashrc
export GIT_COMMITTER_EMAIL=kevyn.alexandre.pare@gmail.com
export GIT_COMMITTER_NAME='Kevyn-Alexandre Paré'
export GIT_AUTHOR_EMAIL=kevyn.alexandre.pare@gmail.com
export GIT_AUTHOR_NAME='Kevyn-Alexandre Paré'

vim ~/.vimrc
highlight RedundantSpaces term=standout ctermbg=red guibg=red
match RedundantSpaces /\s\+$\| \+\ze\t/
set tabstop=8 softtabstop=8 shiftwidth=8 noexpandtab

5- Next step, creating a patch. That patch will be created from comparing the master branch to the tutorial branch.
git format-patch -s -n master..tutorial
This will create the patches in current directory, 000x.patch files
0001-Staging-comedi-fix-coding-style.patch

6- Check the patch with the script:
./scripts/checkpatch.pl --terse --patch 0001-Staging-comedi-fix-coding-style.patch
The --patch is not needed since it is the default option.

7- Send the patch:
git send-email --from "Kevyn-Alexandre Paré" --to "lkml@vger.kernel.org" --cc "greg@kroah.com" --smtp-server smtp.gmail.com --smtp-user kevyn.alexandre.pare@gmail.com --smtp-pass YOURPASSWORD --smtp-ssl --subject "Staging comedi fix coding style" *.patch

Now jump around and enjoy your first patch submission to the linux kernel!

Day 2 & 3 Road trip from Montreal to California

2009-09-21T09:58:00.005-04:00

Day 2

The day start with a search for the breakfast. After asking to a guy walking next to the road he suggested me to go to Doncun Donut mmm. This was far from the eggs and fruit like meal at the Cora. On my way to the Cora I remeber that place were giving coffee in "Stirophone" Eurk! It change the taste and that shit material should not exist since it is far from ecologic. When I was waiting in the line I was really sad to be far from Cora our other nice morning resturant from Montreal :(. I grab my food and get back on the road. I catch a guy speaking on the radio about if we were doing bad think and getting way from God it was impossible to came back to him. AAAAA help! Right there I was saying to my self should I go back home? If I'm not able to found nice food in California like home and other stuff that I'm used to it :(.... I will not detail how far the reflexion continue on my head but be sure that it was really far :) When I came back to reality it was already noon. Yes I know my dive into the dark abyss of my conscience are really deep mouhahaha. I write a lot of stuff during that psychoterapy done by my self! Since I bought 2 sandwiches at doncun donut I did need to stop to eat at noon only take some gas.

I cross Illinois, Iowa, Nebraska and I stop into a rest area. I will sleep in the confort of my car :) I feel like a trucker :) I start my day at 8h00 and now it is 1:20 am and I'm a bit tired.

What I have to say about Iowa and Nebraska, there is a lot of field every where. In Nebraska the road is increadibly flat and straith. No hill even little bump on the road. It is like a mirror lake on a morning without wind! So after passing Iowa and arriving to flat Nebraska the speed change to 75 mph mouhahha I was driving between 130-140 km and at 130 I was following 45 feet truck :O! Field at my right my left and some parts with a lot of eolien! Woow at the ended of the day I was still in Nebraska and the sun was going down direct on the road where I was. The 80 is all way direct East to West in my case. I had the chance to ride with an incredible sunset. I was suppose to end my day to Salt Lake city but their is still 250 miles to do and I'm tired so sleep time!

Day 3

This was my first sleep in my car! I get up at 6h00 am and was really surprise of my night of sleep. it was more confortable then I tought, viva the rest area. When I woke up I was not alone to have done that :) I hit back on the road at 6h30 letting me some times to wake up. I drive a 1hour and more then finally decide to stop for breakfast and what the best place to have a healthy breakfast? At Mcdonald's :) mmmm I like my American meal. I did found better place and my stomack was screaming and when it does I have to listen to it!!!

When I get back on the road it I was really happy because the sunrise and I was able to see the first montain :) Wyoming, Utah, Idaho and finally the Oregon woow! I have seen a lot of beautyful things. Also I arrived at sunset in the Gorge of Oregon 1h30 before arriving to the Marriott hotel where I used there wifi to found me a cheaper hotel with Hotwire.com, 48$ for 2 double bed internet, cable, gym, pool etc :) .... This was it I just need to prepare my self for the LinuxCon 2009 :)

Day 1 Road trip from Montreal to California

2009-09-17T01:07:00.009-04:00

The day beging early and finish early also. Going on the road a 6h30, arriving at noon to Toronto and arriving at 16h00 at USA border, where the fun begun!

I remember before crossing the USA border the voice of one of my friend telling me don't speak about the fact that you are interrested are could pass an interview?! It seem that I remeber that just at the proper time but did think that I could have a entire search again in my car. The guy start by asking for how long I will stay? how much money I have? Then if I was having a job? I answer the truth no.... He left go with the other agent in my car and came back and ask my was is this? The this was my resume (CV) euh it is my resume? So I decide to play the guy that explain everything except the fact that I'm going to offer my service to USA to work :P that resume is inside the folder of the of the compagnie in Montreal that is helping me to found a job in MONTREAL. I had to reexplain a lot the story of my going to meet some friend that I meet on internet to do Kiteboarding hehehe :P Part is true some is pure invention and the temperature was rising inside of me I don't know why ;) The more I was repeating my story even me I start believing that I was going in California to meet some friend to do ONLY kiteboarding. Lesson learn never bring Resume at the boarder :)) If you do even want try remeber that you must said that it is normal for you to bring job in vacation lol.

Finally, I got back on the road a bit stressed I don't know why??? oups? I arrived many hours later at Benton Harbor, Indiana where I eat at Ben something restaurant where technologies was free (wifi). I seen couple of nice mail. One was the guy from couch surfing that I ask to stay but I was enable to call him I was always falling on is voice mail. This could have been my first couch surfing experience (http://www.couchsurfing.org/). I get back on the road and when I arrived at Michigan City, Indiana the couch surfing town of the guy I try one last time to call him. I try but not in ordinary place the Blue Chip casino hahaha I add the chance to access wifi and reserve a room on Hotwire 50$ at 2520 173rd St, Lansing, IL 60438. From where I'm writhing that blog ;) 10 minutes before 2h00 am I arrived at 12h00

at the hotel giving me time to shave and take a shower.

View Larger Map

Pictures on the road tomorrow:

Reverse engeering of suunto X10 Part 2

2009-04-26T11:10:00.003-04:00

Since I was stock to windows to analyse the serial protocol I found software call Free Serial communication analyser to analyse the trame that Trek Manager, Suunto program that came with the watch, and the trame from the watch.

It is possible to isolate specific part of initialisation of the watch by unplugging the watch from the cable during the initialisation of the Trek Manager when we click on connect.

The principal data that the watch retrieve are :
1- Trails
2- Routes
3- Special categories of waypoint like river, clif, etc that come from Hikking directories.
4- Memory space left....

Here example of the first trame that the trek manager send to the watch:

3C 2A 00 0D 38 F7 12 00 23 3E O3 F3 00 04 02 0C
< * null \r 8 division # >
01 07 00 01 00 04 05 00 03 00 17 01 10 00 2F 01

3E
>

Quick analyse:
It is possible to found a pattern for the header and the tail. Since the trame are very often build like HEADER+DATA+CHECKSUM+TAIL I must search in finding to recreate that.

TODO:
1- Found a way to sniff between watch and the trek manager software.
2- The software should be able to receive trame from both wait, add capability to edit the trame since we need a way to play with differents parameters and send back the new edited trame.
3- Must search if such software exist on linux ???

ESTIMATED TIME:
1- mmm this can take a lot of time because we don't have specification of the data.

Reverse engeering of suunto X10

2009-04-24T10:44:00.001-04:00

Reverse engeering of suunto X10::::

lsusb
Bus 002 Device 004: ID 0403:f680 Future Technology Devices International, Ltd Suunto Sports Instrument

dmesg
[1443485.684052] usb 2-2: new full speed USB device using uhci_hcd and address 4
[1443485.890639] usb 2-2: configuration #1 chosen from 1 choice
[1443485.894286] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[1443485.894932] ftdi_sio: Detected FT232RL
[1443485.896295] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0

[1443698.444725] ftdi_sio 2-2:1.0: device disconnected

Web site of chip:
http://www.ftdichip.com/
The chip FT232RL, classified as FT232R
http://www.ftdichip.com/Products/FT232R.htm

Speak to a LCD with FTDI chip (serail communication...)
https://www.linuxquestions.org/questions/linux-hardware-18/glcd-ftdi-usb-364888/

Minicom VS Kermit
http://linux.about.com/od/mdm_howto/a/hwtmdm16t01.htm

Solution:

For automatic scritp Kermit!

Reference: In my opinion it's easier to set up Minicom, there is less to learn, and you can still use kermit from within Minicom. But if you want to write a script for automatically doing file transfers, etc. Kermit is better.

Nice tool:
gpsbabel - Universal gps format translator
http://manpages.ubuntu.com/manpages/gutsy/man1/gpsbabel.1.html

Data from gpsbabel::::
www.gpsbabel.org/htmldoc-1.3.5/gpsbabel-1.3.5.pdf
Suunto Trek Manager (STM) .sdf files (stmsdf)
This format can...
• read and write tracks
• read and write routes
This format supports the .sdf files from the Suunto product family 'Suunto Trek Manager', 'Suunto Ski
Manager' and 'Suunto Sail Manager'. The contents of the sdf file depends on the used product and can be
one route or one track. Thatswhy when you want to use sdf on the output side you have to use the -r OR
the -t option. This will tell GPSBabel which type of data should be written.
Currently we can read the following file types:
77
The Formats
4 = M9 TrackLog
5 = Route
28 = X9 TrackLog
gpsbabel -i gpx -f some-routes.gpx -r -o stmsdf,index=3 -F single-
route.sdf
Suunto Website [http://www.suunto.fi]

Task:
1- Reading and understanding FT232RL protocol.
2- Kermit -> cross compile
3- Kermit -> communication with chip
4- Kermit -> Automatisation of script
5- Kermit -> Backup data (found size of Route and GPS track???(real name for path follow))
6- validate data on .sdf files

Task 1: Reading and understanding FT232RL protocol.
Time plan 4-8 hours:
http://www.ftdichip.com/Products/FT232R.htm
Summary::

Android SDK1.0 Maturity

2009-02-03T19:05:00.003-05:00

How to consider if Android is mature?

The first step should be to define what maturity means for us.
Maturity definition
...in use for long enough (for years or more likely decades or longer) that most of its initial faults and inherent problems have been removed or reduced by further development

So time should be considered and the fact that initial faults and inherent problems have been removed.

.... to be continued

G1 Android Dev Phone Activation

2009-01-17T13:59:00.014-05:00

Task:::
How did I activate my G1 with Rogers, this is the reason of that post:

What I have done::::

Go to futurshop or elsewhere, where they sell SIM, and buy a SIM card.
Follow SIM instructions to call rogers and ask for a voice + data package (48$ = 200 min + 500MB).
Slide the screen to access the keyboard and remove the back case to insert the SIM and the battery. Set case back. I don't remember if I add to recharged the bat for my first boot?
Start Phone by pressing on the red phone on the down right buttons.
The screen finish to boot and ask to touch the screen, so click and click to sign in since I already have google account.
Just before trying to sign I have to set the APN = Access Point Names for Rogers.
Remove all other T-Mobile since they are not needed, in my case, and that someone said that this could cause conflict?? Not sure of that. To do this click on one and pressed menu and click Delete APN. Do this for all T-Mobile.
After that click on menu + New APN and enter those two APN and remember to Save by pressing menu + Save:

* Name: Rogers
* APN: internet.com
* Username: wapuser1
* Password: wap
* MCC: 302 - should be preset correctly
* MNC: 720 - should be preset correctly

* Name: Rogers MMS
* APN: media.com
* Username: media
* Password: mda01
* Server: *
* MMSC: http://mms.gprs.rogers.
* MMS Proxy: 10.128.1.69
* MMS Port: 80
* APN type: mms

I don't remember if I added to reboot but finishing the process of sign in after that work and the Android Desktop appears to my eyes :)

What problem I have encountered:::

APN - I still don't know if this is because I remove all T-Mobile APN that it works or that I, see next problem.
The fact that Rogers ask me to do a first external call with the SIM to activate it? I used the phone of a friend to do a call by inserting my SIM to is Phone and switch it back to my G1. Since I needed to sign in into my google account I was not able to do that first call! This cause me to question my self about what was the problem APN or SIM activation?

Reference:::
oliverfisher.blogspot.com

G1 Android + Beagleboard + Gumstix

2009-01-17T13:49:00.004-05:00

These are my embedded toys.

Fedora 9 to Fedora 10 to Ubuntu 8.10

2008-12-10T08:45:00.004-05:00

I am using a vostro 1310 and was sad to see that using
Network controller: Broadcom Corporation BCM4312 802.11b/g
needed ndiswrapper and my WLAN was slow to initialise. Was ndiswrapper, NetworkManager Applet 0.0.7, Fedora 9 and mixte of all ? I don't now.

I upgrade to Fedora 10 and was hopping for something better :(
ndiswrapper was required, my laptop keyboard was not working at boot up and I had needed to plug a usb keyboard :((

So I try to install Ubuntu 8.10 :))))
Woooww everything works out of the box. The NetworkManager was really fast!!!! It's the same version of Fedora 9 and Fedora 10.

My needs are
1- Tools to develop software (java,C,C++ and android,git,kdiff3)
2- ssh
3- nfs +-
4- vlc/mplayer
5- flash
6- Torrent

Diff between Fedora and Ubuntu:
sudo yum install == sudo apt-get install
ssh server need to be install since that I install Ubuntu desktop this is not included
sudo apt-get install openssh-server

So I'm now a new and happy Ubuntunien!

KDiff3 on Ubuntu 8.10

2008-12-10T08:24:00.004-05:00

sudo apt-get install kdelibs4c2a

wget http://launchpadlibrarian.net/10679965/kdiff3_0.9.92-2ubuntu1_i386.deb
wget http://launchpadlibrarian.net/13473685/libkonq4_3.5.9-0ubuntu7_i386.deb
wget http://launchpadlibrarian.net/10679966/kdiff3-doc_0.9.92-2ubuntu1_all.deb
sudo dpkg -i *.deb

References:
bugs.launchpad.net/ubuntu

Kernel Driver Statement

2008-11-03T17:41:00.001-05:00

Why am I doing this post:
http://www.linuxfoundation.org/en/Kernel_Driver_Statement

Keep screaming your frustration unhappy customer will leave and dell customer support will make customer happy some day by explaining the problem to the business & marketing guys. Then those will react to make more money :))

Maybe they (dell nvidia etc) don't know HOWTO::::
Go on http://www.mjmwired.net/kernel/Documentation/HOWTO

Maybe they are to lazy to click so:

HOWTO do Linux kernel development
---------------------------------

This is the be-all, end-all document on this topic. It contains
instructions on how to become a Linux kernel developer and how to learn
to work with the Linux kernel development community. It tries to not
contain anything related to the technical aspects of kernel programming,
but will help point you in the right direction for that.

If anything in this document becomes out of date, please send in patches
to the maintainer of this file, who is listed at the bottom of the
document.

Introduction
------------

So, you want to learn how to become a Linux kernel developer? Or you
have been told by your manager, "Go write a Linux driver for this
device." This document's goal is to teach you everything you need to
know to achieve this by describing the process you need to go through,
and hints on how to work with the community. It will also try to
explain some of the reasons why the community works like it does.

The kernel is written mostly in C, with some architecture-dependent
parts written in assembly. A good understanding of C is required for
kernel development. Assembly (any architecture) is not required unless
you plan to do low-level development for that architecture. Though they
are not a good substitute for a solid C education and/or years of
experience, the following books are good for, if anything, reference:
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
- "Practical C Programming" by Steve Oualline [O'Reilly]
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]

The kernel is written using GNU C and the GNU toolchain. While it
adheres to the ISO C89 standard, it uses a number of extensions that are
not featured in the standard. The kernel is a freestanding C
environment, with no reliance on the standard C library, so some
portions of the C standard are not supported. Arbitrary long long
divisions and floating point are not allowed. It can sometimes be
difficult to understand the assumptions the kernel has on the toolchain
and the extensions that it uses, and unfortunately there is no
definitive reference for them. Please check the gcc info pages (`info
gcc`) for some information on them.

Please remember that you are trying to learn how to work with the
existing development community. It is a diverse group of people, with
high standards for coding, style and procedure. These standards have
been created over time based on what they have found to work best for
such a large and geographically dispersed team. Try to learn as much as
possible about these standards ahead of time, as they are well
documented; do not expect people to adapt to you or your company's way
of doing things.

Legal Issues
------------

The Linux kernel source code is released under the GPL. Please see the
file, COPYING, in the main directory of the source tree, for details on
the license. If you have further questions about the license, please
contact a lawyer, and do not ask on the Linux kernel mailing list. The
people on the mailing lists are not lawyers, and you should not rely on
their statements on legal matters.

For common questions and answers about the GPL, please see:
http://www.gnu.org/licenses/gpl-faq.html

Documentation
------------

The Linux kernel source tree has a large range of documents that are
invaluable for learning how to interact with the kernel community. When
new features are added to the kernel, it is recommended that new
documentation files are also added which explain how to use the feature.
When a kernel change causes the interface that the kernel exposes to
userspace to change, it is recommended that you send the information or
a patch to the manual pages explaining the change to the manual pages
maintainer at mtk.manpages@gmail.com.

Here is a list of files that are in the kernel source tree that are
required reading:
README
This file gives a short background on the Linux kernel and describes
what is necessary to do to configure and build the kernel. People
who are new to the kernel should start here.

Documentation/Changes
This file gives a list of the minimum levels of various software
packages that are necessary to build and run the kernel
successfully.

Documentation/CodingStyle
This describes the Linux kernel coding style, and some of the
rationale behind it. All new code is expected to follow the
guidelines in this document. Most maintainers will only accept
patches if these rules are followed, and many people will only
review code if it is in the proper style.

Documentation/SubmittingPatches
Documentation/SubmittingDrivers
These files describe in explicit detail how to successfully create
and send a patch, including (but not limited to):
- Email contents
- Email format
- Who to send it to
Following these rules will not guarantee success (as all patches are
subject to scrutiny for content and style), but not following them
will almost always prevent it.

Other excellent descriptions of how to create patches properly are:
"The Perfect Patch"
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
"Linux kernel patch submission format"
http://linux.yyz.us/patch-format.html

Documentation/stable_api_nonsense.txt
This file describes the rationale behind the conscious decision to
not have a stable API within the kernel, including things like:
- Subsystem shim-layers (for compatibility?)
- Driver portability between Operating Systems.
- Mitigating rapid change within the kernel source tree (or
preventing rapid change)
This document is crucial for understanding the Linux development
philosophy and is very important for people moving to Linux from
development on other Operating Systems.

Documentation/SecurityBugs
If you feel you have found a security problem in the Linux kernel,
please follow the steps in this document to help notify the kernel
developers, and help solve the issue.

Documentation/ManagementStyle
This document describes how Linux kernel maintainers operate and the
shared ethos behind their methodologies. This is important reading
for anyone new to kernel development (or anyone simply curious about
it), as it resolves a lot of common misconceptions and confusion
about the unique behavior of kernel maintainers.

Documentation/stable_kernel_rules.txt
This file describes the rules on how the stable kernel releases
happen, and what to do if you want to get a change into one of these
releases.

Documentation/kernel-docs.txt
A list of external documentation that pertains to kernel
development. Please consult this list if you do not find what you
are looking for within the in-kernel documentation.

Documentation/applying-patches.txt
A good introduction describing exactly what a patch is and how to
apply it to the different development branches of the kernel.

The kernel also has a large number of documents that can be
automatically generated from the source code itself. This includes a
full description of the in-kernel API, and rules on how to handle
locking properly. The documents will be created in the
Documentation/DocBook/ directory and can be generated as PDF,
Postscript, HTML, and man pages by running:
make pdfdocs
make psdocs
make htmldocs
make mandocs
respectively from the main kernel source directory.

Becoming A Kernel Developer
---------------------------

If you do not know anything about Linux kernel development, you should
look at the Linux KernelNewbies project:
http://kernelnewbies.org
It consists of a helpful mailing list where you can ask almost any type
of basic kernel development question (make sure to search the archives
first, before asking something that has already been answered in the
past.) It also has an IRC channel that you can use to ask questions in
real-time, and a lot of helpful documentation that is useful for
learning about Linux kernel development.

The website has basic information about code organization, subsystems,
and current projects (both in-tree and out-of-tree). It also describes
some basic logistical information, like how to compile a kernel and
apply a patch.

If you do not know where you want to start, but you want to look for
some task to start doing to join into the kernel development community,
go to the Linux Kernel Janitor's project:
http://janitor.kernelnewbies.org/
It is a great place to start. It describes a list of relatively simple
problems that need to be cleaned up and fixed within the Linux kernel
source tree. Working with the developers in charge of this project, you
will learn the basics of getting your patch into the Linux kernel tree,
and possibly be pointed in the direction of what to go work on next, if
you do not already have an idea.

If you already have a chunk of code that you want to put into the kernel
tree, but need some help getting it in the proper form, the
kernel-mentors project was created to help you out with this. It is a
mailing list, and can be found at:
http://selenic.com/mailman/listinfo/kernel-mentors

Before making any actual modifications to the Linux kernel code, it is
imperative to understand how the code in question works. For this
purpose, nothing is better than reading through it directly (most tricky
bits are commented well), perhaps even with the help of specialized
tools. One such tool that is particularly recommended is the Linux
Cross-Reference project, which is able to present source code in a
self-referential, indexed webpage format. An excellent up-to-date
repository of the kernel code may be found at:
http://users.sosdg.org/~qiyong/lxr/

The development process
-----------------------

Linux kernel development process currently consists of a few different
main kernel "branches" and lots of different subsystem-specific kernel
branches. These different branches are:
- main 2.6.x kernel tree
- 2.6.x.y -stable kernel tree
- 2.6.x -git kernel patches
- 2.6.x -mm kernel patches
- subsystem specific kernel trees and patches

2.6.x kernel tree
-----------------
2.6.x kernels are maintained by Linus Torvalds, and can be found on
kernel.org in the pub/linux/kernel/v2.6/ directory. Its development
process is as follows:
- As soon as a new kernel is released a two weeks window is open,
during this period of time maintainers can submit big diffs to
Linus, usually the patches that have already been included in the
-mm kernel for a few weeks. The preferred way to submit big changes
is using git (the kernel's source management tool, more information
can be found at http://git.or.cz/) but plain patches are also just
fine.
- After two weeks a -rc1 kernel is released it is now possible to push
only patches that do not include new features that could affect the
stability of the whole kernel. Please note that a whole new driver
(or filesystem) might be accepted after -rc1 because there is no
risk of causing regressions with such a change as long as the change
is self-contained and does not affect areas outside of the code that
is being added. git can be used to send patches to Linus after -rc1
is released, but the patches need to also be sent to a public
mailing list for review.
- A new -rc is released whenever Linus deems the current git tree to
be in a reasonably sane state adequate for testing. The goal is to
release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks.
- Known regressions in each release are periodically posted to the
linux-kernel mailing list. The goal is to reduce the length of
that list to zero before declaring the kernel to be "ready," but, in
the real world, a small number of regressions often remain at
release time.

It is worth mentioning what Andrew Morton wrote on the linux-kernel
mailing list about kernel releases:
"Nobody knows when a kernel will be released, because it's
released according to perceived bug status, not according to a
preconceived timeline."

2.6.x.y -stable kernel tree
---------------------------
Kernels with 4-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant
regressions discovered in a given 2.6.x kernel.

This is the recommended branch for users who want the most recent stable
kernel and are not interested in helping test development/experimental
versions.

If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
kernel is the current stable kernel.

2.6.x.y are maintained by the "stable" team , and are
released as needs dictate. The normal release period is approximately
two weeks, but it can be longer if there are no pressing problems. A
security-related problem, instead, can cause a release to happen almost
instantly.

The file Documentation/stable_kernel_rules.txt in the kernel tree
documents what kinds of changes are acceptable for the -stable tree, and
how the release process works.

2.6.x -git patches
------------------
These are daily snapshots of Linus' kernel tree which are managed in a
git repository (hence the name.) These patches are usually released
daily and represent the current state of Linus' tree. They are more
experimental than -rc kernels since they are generated automatically
without even a cursory glance to see if they are sane.

2.6.x -mm kernel patches
------------------------
These are experimental kernel patches released by Andrew Morton. Andrew
takes all of the different subsystem kernel trees and patches and mushes
them together, along with a lot of patches that have been plucked from
the linux-kernel mailing list. This tree serves as a proving ground for
new features and patches. Once a patch has proved its worth in -mm for
a while Andrew or the subsystem maintainer pushes it on to Linus for
inclusion in mainline.

It is heavily encouraged that all new patches get tested in the -mm tree
before they are sent to Linus for inclusion in the main kernel tree. Code
which does not make an appearance in -mm before the opening of the merge
window will prove hard to merge into the mainline.

These kernels are not appropriate for use on systems that are supposed
to be stable and they are more risky to run than any of the other
branches.

If you wish to help out with the kernel development process, please test
and use these kernel releases and provide feedback to the linux-kernel
mailing list if you have any problems, and if everything works properly.

In addition to all the other experimental patches, these kernels usually
also contain any changes in the mainline -git kernels available at the
time of release.

The -mm kernels are not released on a fixed schedule, but usually a few
-mm kernels are released in between each -rc kernel (1 to 3 is common).

Subsystem Specific kernel trees and patches
-------------------------------------------
A number of the different kernel subsystem developers expose their
development trees so that others can see what is happening in the
different areas of the kernel. These trees are pulled into the -mm
kernel releases as described above.

Here is a list of some of the different kernel trees available:
git trees:
- Kbuild development tree, Sam Ravnborg
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git

- ACPI development tree, Len Brown
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git

- Block development tree, Jens Axboe
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git

- DRM development tree, Dave Airlie
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git

- ia64 development tree, Tony Luck
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git

- infiniband, Roland Dreier
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

- libata, Jeff Garzik
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

- network drivers, Jeff Garzik
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git

- pcmcia, Dominik Brodowski
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git

- SCSI, James Bottomley
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git

- x86, Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git

quilt trees:
- USB, Driver Core, and I2C, Greg Kroah-Hartman
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/

Other kernel trees can be found listed at http://git.kernel.org/ and in
the MAINTAINERS file.

Bug Reporting
-------------

bugzilla.kernel.org is where the Linux kernel developers track kernel
bugs. Users are encouraged to report all bugs that they find in this
tool. For details on how to use the kernel bugzilla, please see:
http://bugzilla.kernel.org/page.cgi?id=faq.html

The file REPORTING-BUGS in the main kernel source directory has a good
template for how to report a possible kernel bug, and details what kind
of information is needed by the kernel developers to help track down the
problem.

Managing bug reports
--------------------

One of the best ways to put into practice your hacking skills is by fixing
bugs reported by other people. Not only you will help to make the kernel
more stable, you'll learn to fix real world problems and you will improve
your skills, and other developers will be aware of your presence. Fixing
bugs is one of the best ways to get merits among other developers, because
not many people like wasting time fixing other people's bugs.

To work in the already reported bug reports, go to http://bugzilla.kernel.org.
If you want to be advised of the future bug reports, you can subscribe to the
bugme-new mailing list (only new bug reports are mailed here) or to the
bugme-janitor mailing list (every change in the bugzilla is mailed here)

http://lists.linux-foundation.org/mailman/listinfo/bugme-new
http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors

Mailing lists
-------------

As some of the above documents describe, the majority of the core kernel
developers participate on the Linux Kernel Mailing list. Details on how
to subscribe and unsubscribe from the list can be found at:
http://vger.kernel.org/vger-lists.html#linux-kernel
There are archives of the mailing list on the web in many different
places. Use a search engine to find these archives. For example:
http://dir.gmane.org/gmane.linux.kernel
It is highly recommended that you search the archives about the topic
you want to bring up, before you post it to the list. A lot of things
already discussed in detail are only recorded at the mailing list
archives.

Most of the individual kernel subsystems also have their own separate
mailing list where they do their development efforts. See the
MAINTAINERS file for a list of what these lists are for the different
groups.

Many of the lists are hosted on kernel.org. Information on them can be
found at:
http://vger.kernel.org/vger-lists.html

Please remember to follow good behavioral habits when using the lists.
Though a bit cheesy, the following URL has some simple guidelines for
interacting with the list (or any list):
http://www.albion.com/netiquette/

If multiple people respond to your mail, the CC: list of recipients may
get pretty large. Don't remove anybody from the CC: list without a good
reason, or don't reply only to the list address. Get used to receiving the
mail twice, one from the sender and the one from the list, and don't try
to tune that by adding fancy mail-headers, people will not like it.

Remember to keep the context and the attribution of your replies intact,
keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and
add your statements between the individual quoted sections instead of
writing at the top of the mail.

If you add patches to your mail, make sure they are plain readable text
as stated in Documentation/SubmittingPatches. Kernel developers don't
want to deal with attachments or compressed patches; they may want
to comment on individual lines of your patch, which works only that way.
Make sure you use a mail program that does not mangle spaces and tab
characters. A good first test is to send the mail to yourself and try
to apply your own patch by yourself. If that doesn't work, get your
mail program fixed or change it until it works.

Above all, please remember to show respect to other subscribers.

Working with the community
--------------------------

The goal of the kernel community is to provide the best possible kernel
there is. When you submit a patch for acceptance, it will be reviewed
on its technical merits and those alone. So, what should you be
expecting?
- criticism
- comments
- requests for change
- requests for justification
- silence

Remember, this is part of getting your patch into the kernel. You have
to be able to take criticism and comments about your patches, evaluate
them at a technical level and either rework your patches or provide
clear and concise reasoning as to why those changes should not be made.
If there are no responses to your posting, wait a few days and try
again, sometimes things get lost in the huge volume.

What should you not do?
- expect your patch to be accepted without question
- become defensive
- ignore comments
- resubmit the patch without making any of the requested changes

In a community that is looking for the best technical solution possible,
there will always be differing opinions on how beneficial a patch is.
You have to be cooperative, and willing to adapt your idea to fit within
the kernel. Or at least be willing to prove your idea is worth it.
Remember, being wrong is acceptable as long as you are willing to work
toward a solution that is right.

It is normal that the answers to your first patch might simply be a list
of a dozen things you should correct. This does _not_ imply that your
patch will not be accepted, and it is _not_ meant against you
personally. Simply correct all issues raised against your patch and
resend it.

Differences between the kernel community and corporate structures
-----------------------------------------------------------------

The kernel community works differently than most traditional corporate
development environments. Here are a list of things that you can try to
do to try to avoid problems:
Good things to say regarding your proposed changes:
- "This solves multiple problems."
- "This deletes 2000 lines of code."
- "Here is a patch that explains what I am trying to describe."
- "I tested it on 5 different architectures..."
- "Here is a series of small patches that..."
- "This increases performance on typical machines..."

Bad things you should avoid saying:
- "We did it this way in AIX/ptx/Solaris, so therefore it must be
good..."
- "I've being doing this for 20 years, so..."
- "This is required for my company to make money"
- "This is for our Enterprise product line."
- "Here is my 1000 page design document that describes my idea"
- "I've been working on this for 6 months..."
- "Here's a 5000 line patch that..."
- "I rewrote all of the current mess, and here it is..."
- "I have a deadline, and this patch needs to be applied now."

Another way the kernel community is different than most traditional
software engineering work environments is the faceless nature of
interaction. One benefit of using email and irc as the primary forms of
communication is the lack of discrimination based on gender or race.
The Linux kernel work environment is accepting of women and minorities
because all you are is an email address. The international aspect also
helps to level the playing field because you can't guess gender based on
a person's name. A man may be named Andrea and a woman may be named Pat.
Most women who have worked in the Linux kernel and have expressed an
opinion have had positive experiences.

The language barrier can cause problems for some people who are not
comfortable with English. A good grasp of the language can be needed in
order to get ideas across properly on mailing lists, so it is
recommended that you check your emails to make sure they make sense in
English before sending them.

Break up your changes
---------------------

The Linux kernel community does not gladly accept large chunks of code
dropped on it all at once. The changes need to be properly introduced,
discussed, and broken up into tiny, individual portions. This is almost
the exact opposite of what companies are used to doing. Your proposal
should also be introduced very early in the development process, so that
you can receive feedback on what you are doing. It also lets the
community feel that you are working with them, and not simply using them
as a dumping ground for your feature. However, don't send 50 emails at
one time to a mailing list, your patch series should be smaller than
that almost all of the time.

The reasons for breaking things up are the following:

1) Small patches increase the likelihood that your patches will be
applied, since they don't take much time or effort to verify for
correctness. A 5 line patch can be applied by a maintainer with
barely a second glance. However, a 500 line patch may take hours to
review for correctness (the time it takes is exponentially
proportional to the size of the patch, or something).

Small patches also make it very easy to debug when something goes
wrong. It's much easier to back out patches one by one than it is
to dissect a very large patch after it's been applied (and broken
something).

2) It's important not only to send small patches, but also to rewrite
and simplify (or simply re-order) patches before submitting them.

Here is an analogy from kernel developer Al Viro:
"Think of a teacher grading homework from a math student. The
teacher does not want to see the student's trials and errors
before they came up with the solution. They want to see the
cleanest, most elegant answer. A good student knows this, and
would never submit her intermediate work before the final
solution."

The same is true of kernel development. The maintainers and
reviewers do not want to see the thought process behind the
solution to the problem one is solving. They want to see a
simple and elegant solution."

It may be challenging to keep the balance between presenting an elegant
solution and working together with the community and discussing your
unfinished work. Therefore it is good to get early in the process to
get feedback to improve your work, but also keep your changes in small
chunks that they may get already accepted, even when your whole task is
not ready for inclusion now.

Also realize that it is not acceptable to send patches for inclusion
that are unfinished and will be "fixed up later."

Justify your change
-------------------

Along with breaking up your patches, it is very important for you to let
the Linux community know why they should add this change. New features
must be justified as being needed and useful.

Document your change
--------------------

When sending in your patches, pay special attention to what you say in
the text in your email. This information will become the ChangeLog
information for the patch, and will be preserved for everyone to see for
all time. It should describe the patch completely, containing:
- why the change is necessary
- the overall design approach in the patch
- implementation details
- testing results

For more details on what this should all look like, please see the
ChangeLog section of the document:
"The Perfect Patch"
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

All of these things are sometimes very hard to do. It can take years to
perfect these practices (if at all). It's a continuous process of
improvement that requires a lot of patience and determination. But
don't give up, it's possible. Many have done it before, and each had to
start exactly where you are now.

----------
Thanks to Paolo Ciarrocchi who allowed the "Development Process"
(http://linux.tar.bz/articles/2.6-development_process) section
to be based on text he had written, and to Randy Dunlap and Gerrit
Huizenga for some of the list of things you should and should not say.
Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for
their review, comments, and contributions. Without their help, this
document would not have been possible.

Maintainer: Greg Kroah-Hartman

Android is now Open Source

2008-10-23T13:45:00.002-04:00

:))))))))))

I will try to port it to my gumstix verdex XL6P and then on my next toys BeagleBoard (Christmas)!

http://android-developers.blogspot.com/2008/10/android-is-now-open-source.html

http://source.android.com/

Compression test

2008-10-20T22:19:00.005-04:00

[kapare@p11634 ~]$ du -sh folder
423M    folder

[kapare@p11634 ~]$ ls -lh folder.*
-rw------- 1 kapare G-CCUSERS 156M 2008-10-01 16:21 folder.tar.7zip
-rw-rw-r-- 1 kapare G-CCUSERS 203M 2008-10-01 16:01 folder.tar.bz2
-rw-rw-r-- 1 kapare G-CCUSERS 213M 2008-10-01 16:13 folder.tar.gz

# Comments on free-electrons.com
bzip2 20-25% better than gzip
7-zip 10-20% than bzip2.

tar -cvf folder.tar folder

# Leave the .tar
7za a folder.tar.7zip folder.tar

# Take the tar to transform it into tar.gz
gzip folder.tar
tar -cvf folder.tar folder

# Take the tar to transform it into tar.gz
bzip2 -v folder.tar 

# Nice way to skip the tar part for bzip2 and gzip, because 7-zip do not need tar.
gtar jcvf folder.tar.bz2 folder

# Didn't try:
tar cvf - folder | bzip2 > folder.tar.bz2

Quick HOWTO bootchart & Fedora9

2008-10-20T22:05:00.003-04:00

Install and reboot

sudo yum install bootchart
reboot

Generate bootchart image

bootchart -f png

View bootchart image

gimp bootchart.png

Example

Links
www.bootchart.org

Update ndiswrapper for kernel 2.6.26.3-29.fc9.i686

2008-09-29T20:28:00.011-04:00

Follow instruction of sideways:::
http://fedoraforum.org/forum

I had to do something differently:

sudo rpm -ihv ~/rpmbuild/RPMS/i686/kmod-ndiswrapper*.rpm

replace by

sudo rpm -ivh /usr/src/redhat/RPMS/i686/kmod-ndiswrapper*.rpm

Maybe because sideways place in another order the steps that I paste here?

sudo yum groupinstall "Development Tools"
sudo yum install rpmdevtools yum-utils kmodtool
rpmdev-setuptree

yumdownloader --source kmod-ndiswrapper
rpmbuild --rebuild --target=i686 --define "kernels 2.6.26.3-29.fc9.i686" ndiswrapper-kmod*.src.rpm
sudo rpm -ihv ~/rpmbuild/RPMS/i686/kmod-ndiswrapper*.rpm

After that redo those steps:

# Verify if install succeed
ndiswrapper -l
bcmwl5 : driver installed
 device (14E4:4315) present
sudo depmod -a
sudo modprobe ndiswrapper
ndiswrapper -ma

You should see the blue wifi led on your laptop goes on and NetworkManager Applet reconnect automatically, that depends on your setup.

Gumstix and fedora 9

2008-06-24T12:41:00.007-04:00

Untill Steve add fixes for Fedora 9 this is the way to setup the things.

I have used Fedora 7 instruction:
openembedded
Yum used:

su -c "yum install python m4 make wget curl ftp cvs monotone subversion tar bzip2 gzip unzip python-psyco ccache perl texinfo texi2html diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git quilt groff linuxdoc-tools patch linuxdoc-tools gcc gcc-c++ help2man"

Setting up a build environment:
www.gumstix.net

Link to fix build problem
www.nabble.com

Fedora 9 Vostro 1310 with BCM4310 USB and ndiswrapper

2008-06-15T18:35:00.024-04:00

Vostro 1310 Components:
Intel® Core™ 2 Duo T5670 (1.8GHz, 2MB L2 Cache, 800MHz FSB)
13.3 inch Widescreen XGA LCD Display
2GB Shared Dual Channel DDR2 SDRAM at 667MHz, 2 DIMM
250GB 5400RPM SATA Hard Drive
8X DVD+/-RW with double-layer DVD+/-R write capability & Roxio
IntelJ Integrated Graphics Media Accelerator X3100
Dell Wireless 1395 802.11g Wi-Fi Mini Card
High Definition Audio 2.0
58 WHr 6-cell Lithium Ion Primary Battery
Standard Touchpad

Download fedora 9 DVD and burn it and install:
http://fedoraproject.org/en/get-fedora

Now let's the fun begin!
Installing the wireless card:

[root@vostro ~]# lspci | grep BCM4310
06:00.0 Network controller: Broadcom Corporation BCM4310 USB Controller (rev 01)
su -
yum install kmod-ndiswrapper
mkdir ndiswrapper_drivers
cd /ndiswrapper_drivers

Add blacklist bcm43xx in

vi /etc/modprobe.d/blacklist

Download the driver for windows XP from dell support web site:
http://support.dell.com/

cd /tmp
unzip Dell_multi-device_A17_R174291.exe
cp bcmwl5.inf /ndiswrapper_drivers
cp bcmwl5.sys /ndiswrapper_drivers
cd /ndiswrapper_drivers
sudo ndiswrapper -i bcmwl5.inf
# Verify if install succeed
ndiswrapper -l
bcmwl5 : driver installed
 device (14E4:4315) present
sudo depmod -a
sudo modprobe ndiswrapper
ndiswrapper -ma
echo "alias wlan0 ndiswrapper" >> /etc/modprobe.conf

Install flash player
Go to : Adobe's site
To get sound for flash player

yum install libflashsupport

Web site used to get things working:
http://linux.dell.com/wiki/index.php/Tech/Wireless/Truemobile_ndiswrapper

http://fedorasolved.org/mobile/fc-wireless/ndis-yum-livna

http://www.my-guides.net/en/content/view/103/26/#kde