http://www.xogiving.org/ is running a special promotion, give one, get one starting November 12th of 2007. If you purchase an XO laptop for one child, you may also purchase one for yourself. The project will allow developers to get their hands on what could become one of the most common computers on the planet.
I think David Pogue's video blog on the OLPC drives home this simple idea that is really about advancing education. Textbooks are expensive. The OLPC can act as a textbook reader even in harsh day light. The OLPC can charge off of solar panels.
Most shockingly, it exposes it's own operating system code to the end user in a unique way I've never seen. Control commands expose the Python code behind every screen. That's amazing... could this mean that there is a potential horde of newly minted Python coders on the horizon? What does that mean?
2007-10-29
2007-10-25
People you don't like...
I can't find an official quote but I once saw a televised question and answer session with Warren Buffet. When an audience member asked what it was like being one of the world's richest men.
In Warren's reply he said: "One benefit is, I don't have to deal with people I don't like." Warren then went on to explain with grandfatherly charm that his days were spent dealing with people he admired or otherwise liked because he could afford to select those people to surround him. He explained that finding good people and investing in them was one of his keys to success.
Only the most wealthy of people can seriously claim that they don't have to deal with people they don't like. For everyone else in the world dealing with people who annoy you is just a fact of life. There's no real way out. Few of us can afford to ignore or avoid our bosses, coworkers, or authority figures if we want to.
Not having to deal with people you don't like is an expensive luxury.
In Warren's reply he said: "One benefit is, I don't have to deal with people I don't like." Warren then went on to explain with grandfatherly charm that his days were spent dealing with people he admired or otherwise liked because he could afford to select those people to surround him. He explained that finding good people and investing in them was one of his keys to success.
Only the most wealthy of people can seriously claim that they don't have to deal with people they don't like. For everyone else in the world dealing with people who annoy you is just a fact of life. There's no real way out. Few of us can afford to ignore or avoid our bosses, coworkers, or authority figures if we want to.
Not having to deal with people you don't like is an expensive luxury.
2007-10-23
Some advice from a smart guy
"Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."Make your software small, simple, and powerful.
-- Albert Einstein
2007-10-22
Issues of Concurrency
I have a problem. I have two databases. One old one and one new one. The new one is fully normalized and the old one is not. Both databases drive their own front ends. One is a Perl front end the other is a Spring Java front end. The data between both interfaces has to stay in sync. Our DBA has elected to use triggers to keep the databases in sync.
Hibernate uses its own Version column to keep up with which version got committed to the database and when it happened. There are articles dealing with JPA, Hibernate, and Concurrency... my problem is a little different.
Here's my example of the problem.
Let's say you have a web application using an ORM engine like Hibernate. There is Entity version 1 in the database. User Alice checks out version 1. User Bob checks out version one.
Alice edits her copy of version 1 and sends it back. The ORM engine checks the object version against the database version and they match and on commit of Alice's changes the database version number is set to 2.
Bob makes changes to his copy of version 1 of the Entity and checks his version in. The ORM checks the database version and sees version 2 in the database. Version 1 is old and Bob gets an error reporting mid-air collision.
Now lets say you introduce a second database. This second database uses different Relational mappings but is itself an OLTP. Let's pretend both databases have exact copies of the data initially and an update trigger mechanism keeps the two OLTP's in sync.
If Alice checks out version 1 from the first database and the first interface and Bob checks out version 1 from the second database and the second interface. When Alice makes her change and creates first version 2 (2' or two prime) and Bob commits his changes to create second version 2 or (2'' or two double prime) the trigger from the first database to update the second will fire simultaneously as the trigger from the second.
In other words Alice's OLTP is unaware of changes made on Bob's OLTP and both changes are in route to the other's.
How should the two databases proceed?
Should last saved win? Should both databases error and roll back? Should the systems attempt to "merge" changes? Should one system be elected the "authority" for this data electing that Alice's interface and OLTP are always the right ones?
Hibernate uses its own Version column to keep up with which version got committed to the database and when it happened. There are articles dealing with JPA, Hibernate, and Concurrency... my problem is a little different.
Here's my example of the problem.
Let's say you have a web application using an ORM engine like Hibernate. There is Entity version 1 in the database. User Alice checks out version 1. User Bob checks out version one.
Alice edits her copy of version 1 and sends it back. The ORM engine checks the object version against the database version and they match and on commit of Alice's changes the database version number is set to 2.
Bob makes changes to his copy of version 1 of the Entity and checks his version in. The ORM checks the database version and sees version 2 in the database. Version 1 is old and Bob gets an error reporting mid-air collision.
Now lets say you introduce a second database. This second database uses different Relational mappings but is itself an OLTP. Let's pretend both databases have exact copies of the data initially and an update trigger mechanism keeps the two OLTP's in sync.
If Alice checks out version 1 from the first database and the first interface and Bob checks out version 1 from the second database and the second interface. When Alice makes her change and creates first version 2 (2' or two prime) and Bob commits his changes to create second version 2 or (2'' or two double prime) the trigger from the first database to update the second will fire simultaneously as the trigger from the second.
In other words Alice's OLTP is unaware of changes made on Bob's OLTP and both changes are in route to the other's.
How should the two databases proceed?
Should last saved win? Should both databases error and roll back? Should the systems attempt to "merge" changes? Should one system be elected the "authority" for this data electing that Alice's interface and OLTP are always the right ones?
2007-10-17
Linux Forgotten Root Password
Oh no, you've forgotten the root password to your laptop or other Linux desktop.
If they are set up with grub all is not lost. At the grub splash screen key in 'e' for edit. You'll now be able to edit the boot options. Select the line with the kernel on it and add the word 'single' as the last parameter. When you hit enter the edit mode will exit. Striking the 'b' for boot command will boot this configuration and your kernel will boot into the magical single user mode where you can type 'password' to change root's password without having to know what that forgotten original password was.
Now you can use the awesome power of root to change the other forgotten passwords on the system. If you think this presents a security hole and don't want to allow 'e' from the grub splash... you can secure grub with a password.
If they are set up with grub all is not lost. At the grub splash screen key in 'e' for edit. You'll now be able to edit the boot options. Select the line with the kernel on it and add the word 'single' as the last parameter. When you hit enter the edit mode will exit. Striking the 'b' for boot command will boot this configuration and your kernel will boot into the magical single user mode where you can type 'password' to change root's password without having to know what that forgotten original password was.
Now you can use the awesome power of root to change the other forgotten passwords on the system. If you think this presents a security hole and don't want to allow 'e' from the grub splash... you can secure grub with a password.
2007-10-15
Symbol System Manipulation
If thought is just the manipulation of symbols. Then computers think. If thought is more than the manipulation of symbols... then how do you know people think?
If you can't accept that the mechanical manipulations of symbol systems carried out by a computer are thought... then how can you accept that the mechanical symbol manipulations carried out by organic beings are thought?
Artificial Intelligence beats real stupidity every time.
Waxing a tad philosophical, perhaps the mechanical symbol manipulations of any system be it a human brain or a computer are the echo of thought. In the case of the computer the program is the echo of a thought left by its programmer. In the case of a brain these are the echoes of thoughts begun in the minds of others and advanced or reproduced yet again.
The idea is that thought-stuff can move between noggins and that the computer offers a similar place of purchase for the thought-stuff as a rather simple minded noggin. So thought-stuff lives in noggins. Thought-stuff can be preserved in medium like a seed of an annual plant it lays dormant on a page. Thought-stuff gets planted in a noggin and sprouts.
Living thought stuff that bears fruit as action and turns to seed is shot across the divide between noggins in speech, on paper, or as code. The result is germinated. In the case of code the germination can occur in the artificial soil of a computer.
If you can't accept that the mechanical manipulations of symbol systems carried out by a computer are thought... then how can you accept that the mechanical symbol manipulations carried out by organic beings are thought?
Artificial Intelligence beats real stupidity every time.
Waxing a tad philosophical, perhaps the mechanical symbol manipulations of any system be it a human brain or a computer are the echo of thought. In the case of the computer the program is the echo of a thought left by its programmer. In the case of a brain these are the echoes of thoughts begun in the minds of others and advanced or reproduced yet again.
The idea is that thought-stuff can move between noggins and that the computer offers a similar place of purchase for the thought-stuff as a rather simple minded noggin. So thought-stuff lives in noggins. Thought-stuff can be preserved in medium like a seed of an annual plant it lays dormant on a page. Thought-stuff gets planted in a noggin and sprouts.
Living thought stuff that bears fruit as action and turns to seed is shot across the divide between noggins in speech, on paper, or as code. The result is germinated. In the case of code the germination can occur in the artificial soil of a computer.
2007-10-12
The new Alfresco
TriLUG last night had a special presentation from principal architect Jon Cox. Jon Cox had developed software for the Interwoven product suites and is now working for Alfresco which has released a new versioning engine based on Jon's work.
The new alfresco tool's new features include Native Office integration, multiple locking models, adaptive workflow engines based on jBPM, REST style API, a new Web 2.0 front end, web portal integration, and web content management features. The big win here is the long awaited Office integration. Unfortunately, this feature is apparently very new and doesn't have good documentation around it yet.
For a programmer the most common use of versioning is in source code version management with tools such as SVN. The difference between Alfresco and SVN was described by Cox using this analogy:
Imagine you have a window pane and you are looking at the Mona Lisa. You can draw on this pane, erase it, do what ever you want and no one but you can see it. Now imagine there are three of you... Alice, Bob, and Charlie. Charlie puts a mole on Mona Lisa, Bob puts a mustache, and Alice adds a goatee. If Charlie commits (permanently saves) his mole Alice and Bob will suddenly see the mole show up underneath their window panes.
This is very different from source code control in products like SVN and CVS. In source code the developers all have their copies that they work on. When they are done they commit their changes. In SVN if Charlie has committed that mole neither Alice nor Bob will see the mole until they go to commit. When they try to commit they get an error. Alice and Bob each have to update manually and then make changes to accommodate Charlie's mole addition.
This is inappropriate behavior for managing documents. And, that is why Alfresco can be set up with either pessimistic locking (source code type locking) or optimistic locking (everyone sees each other's changes immediately).
I took away these key concepts:
Alfresco versioning composed of three layers... The official copy, the working copy, and the preview.
The official copy is like the Mona Lisa under glass, the working copy you have is like a pane of glass that you can draw on and no one can see. The preview exists behind you as a preview that you can send "links" to other people who can then look "over your shoulder". This set of concepts allows people to play "what if" scenarios with their documents and web sites.
The working copy can pass through an approval process before it reaches the official copy. You may snapshot a working copy before you send a preview and only allow a preview of the snap shot. And all this can be used to version sets of documents or websites.
Toward the end of the talk Jon entertained the long term vision that the Alfresco object-version system could be used for source code control. It would allow for the implementation of different policies on how source code could be modified and worked with... and could be used to implement radically different software work patterns then what we use now.
The new alfresco tool's new features include Native Office integration, multiple locking models, adaptive workflow engines based on jBPM, REST style API, a new Web 2.0 front end, web portal integration, and web content management features. The big win here is the long awaited Office integration. Unfortunately, this feature is apparently very new and doesn't have good documentation around it yet.
For a programmer the most common use of versioning is in source code version management with tools such as SVN. The difference between Alfresco and SVN was described by Cox using this analogy:
Imagine you have a window pane and you are looking at the Mona Lisa. You can draw on this pane, erase it, do what ever you want and no one but you can see it. Now imagine there are three of you... Alice, Bob, and Charlie. Charlie puts a mole on Mona Lisa, Bob puts a mustache, and Alice adds a goatee. If Charlie commits (permanently saves) his mole Alice and Bob will suddenly see the mole show up underneath their window panes.
This is very different from source code control in products like SVN and CVS. In source code the developers all have their copies that they work on. When they are done they commit their changes. In SVN if Charlie has committed that mole neither Alice nor Bob will see the mole until they go to commit. When they try to commit they get an error. Alice and Bob each have to update manually and then make changes to accommodate Charlie's mole addition.
This is inappropriate behavior for managing documents. And, that is why Alfresco can be set up with either pessimistic locking (source code type locking) or optimistic locking (everyone sees each other's changes immediately).
I took away these key concepts:
Alfresco versioning composed of three layers... The official copy, the working copy, and the preview.
The official copy is like the Mona Lisa under glass, the working copy you have is like a pane of glass that you can draw on and no one can see. The preview exists behind you as a preview that you can send "links" to other people who can then look "over your shoulder". This set of concepts allows people to play "what if" scenarios with their documents and web sites.
The working copy can pass through an approval process before it reaches the official copy. You may snapshot a working copy before you send a preview and only allow a preview of the snap shot. And all this can be used to version sets of documents or websites.
Toward the end of the talk Jon entertained the long term vision that the Alfresco object-version system could be used for source code control. It would allow for the implementation of different policies on how source code could be modified and worked with... and could be used to implement radically different software work patterns then what we use now.
Subscribe to:
Posts (Atom)