Oracle Unbreakable Linux is a support program that provides enterprises with industry-leading global support for Linux. For less than half the cost, Oracle's Basic Support is equivalent to Red Hat's best service level. And Oracle's Premier Support provides the same level of enterprise-class support that Oracle provides for its database product.
Oracle site
Wednesday 31 January 2007
Monday 29 January 2007
Chinas' own computer? What's next?
It seems that after several Linux distributions (Red Flag, OpenRays) the Chinese made another step on the road to build their own computer.
China's own computer, interesting thought. Let's make acquaintance with the hardware that can make this happen.
It is known under different names, Godson, Loongson, DragonChip. The first incarnation of it took place in 2002, designed and produced by CAS. At just 266MHz it was not an impressive achievement maybe, but it seems that the Moore law do not apply to the Chinese microprocessor industry. On average the power of the Chinese chip doubles every year, which is roughly four times of what Moore's law predicted. From Godson 1 to Godson 2B, the capability of the chip has tripled, and from Godson 2B to Godson 2C, from Godson 2C to Godson 2E, the capability has continuously tripled.
There is one more interesting fact about this chips, they are MIPS -like which attracts after itself the fact that products based on it are incapable of running M$ Windows. I said MIPS-like, because actually they are not called MIPS, they are a completely independent, proprietary core implementation.
Let's sum up a bit: For 5 years the Chinese are developing microprocessors, now being at the rough equivalent of Intel P4@1.3 GHz, but on pure 64 bit. They develop MIPS like CPUs, thus relying on Linux or other Unix like Operating Systems, which they already have (I just mentioned two better known variants, but there are many more). The mini computers built around this architecture now cost around 200$ a piece, but once in mass production I expect the prices to be a bit lower.
What's next?
China's own computer, interesting thought. Let's make acquaintance with the hardware that can make this happen.
It is known under different names, Godson, Loongson, DragonChip. The first incarnation of it took place in 2002, designed and produced by CAS. At just 266MHz it was not an impressive achievement maybe, but it seems that the Moore law do not apply to the Chinese microprocessor industry. On average the power of the Chinese chip doubles every year, which is roughly four times of what Moore's law predicted. From Godson 1 to Godson 2B, the capability of the chip has tripled, and from Godson 2B to Godson 2C, from Godson 2C to Godson 2E, the capability has continuously tripled.
There is one more interesting fact about this chips, they are MIPS -like which attracts after itself the fact that products based on it are incapable of running M$ Windows. I said MIPS-like, because actually they are not called MIPS, they are a completely independent, proprietary core implementation.
Let's sum up a bit: For 5 years the Chinese are developing microprocessors, now being at the rough equivalent of Intel P4@1.3 GHz, but on pure 64 bit. They develop MIPS like CPUs, thus relying on Linux or other Unix like Operating Systems, which they already have (I just mentioned two better known variants, but there are many more). The mini computers built around this architecture now cost around 200$ a piece, but once in mass production I expect the prices to be a bit lower.
What's next?
Friday 12 January 2007
a release?
Hi people! I think everyone wants a release, and many have asked for one. but I wonder what shall be on our first release... and a first release of what.
a release of what? there another question comes to my mind... what are we (as product)? and I see four things.
Independence of the framework
To me the framework is the engine which makes OpenSDE move, the functionality, the architectures and building generic knowledge, the tools and helpers which make the project possible... and huge place for improvements. And a very sensitive field when it comes to the usability of OpenSDE itself.
Independence of the package database
It may sound weird but if you look at our development model what traditionally has defined our stability is the stability of the package database, keeping it up to date, increasing the amount of supported packages, been more clever on integrating them without affecting the flexibility needed by the targets and minimizing the amount of broken packages.
The package database expects some functionality (API?) on the framework but it's not really bind to how that framework is implemented, the package database is just information, patches and a few specific tricks. and it's very easy to break with one innocent update.
Independence of the powered-by distributions
The distributions on the other hand have a different kind of users, the final users, those which don't need to know about OpenSDE, and their developers are the users of the framework and the package database, what defines stability here is (imho) on a different universe than what defines stability on the previous two.
In their case I think we have to move every (except the generic) target into their own repository (or sub-repository) giving them their own trac and space for their own website or mailing list (http://$target.opensde.net or even helping people to keep those related projects under their own domain), and having a directory where everyone can choose which targets to link (svn:external) on their working copy. I would like to see these powered-by distributions making their own releases powered by certain version of the package database and certain version of the framework.
Independence of the documentation?
The documentation makes the framework and the package database accessible to the people, the documentation helps final system users know how to do thinks, the documentation is able to see the OpenSDE project as a whole. That's why we are working on a book, a handbook, trying to cover the different levels of OpenSDE, this book also has a different definition for stability and different reasons to make a tag, a branch or announce a release.
So... what do we want to release? what shall be there? do we grant the independence or bundle? how much can we split? how much would be sane to split? should we focus on what makes us equal or on what makes us different? what should we postpone to be able to achieve a release of something else?
what do you think?
a release of what? there another question comes to my mind... what are we (as product)? and I see four things.
- a framework and set of tools
- a package database
- a bunch of distributions (targets) powered by OpenSDE
- a book!
Independence of the framework
To me the framework is the engine which makes OpenSDE move, the functionality, the architectures and building generic knowledge, the tools and helpers which make the project possible... and huge place for improvements. And a very sensitive field when it comes to the usability of OpenSDE itself.
Independence of the package database
It may sound weird but if you look at our development model what traditionally has defined our stability is the stability of the package database, keeping it up to date, increasing the amount of supported packages, been more clever on integrating them without affecting the flexibility needed by the targets and minimizing the amount of broken packages.
The package database expects some functionality (API?) on the framework but it's not really bind to how that framework is implemented, the package database is just information, patches and a few specific tricks. and it's very easy to break with one innocent update.
Independence of the powered-by distributions
The distributions on the other hand have a different kind of users, the final users, those which don't need to know about OpenSDE, and their developers are the users of the framework and the package database, what defines stability here is (imho) on a different universe than what defines stability on the previous two.
In their case I think we have to move every (except the generic) target into their own repository (or sub-repository) giving them their own trac and space for their own website or mailing list (http://$target.opensde.net or even helping people to keep those related projects under their own domain), and having a directory where everyone can choose which targets to link (svn:external) on their working copy. I would like to see these powered-by distributions making their own releases powered by certain version of the package database and certain version of the framework.
Independence of the documentation?
The documentation makes the framework and the package database accessible to the people, the documentation helps final system users know how to do thinks, the documentation is able to see the OpenSDE project as a whole. That's why we are working on a book, a handbook, trying to cover the different levels of OpenSDE, this book also has a different definition for stability and different reasons to make a tag, a branch or announce a release.
So... what do we want to release? what shall be there? do we grant the independence or bundle? how much can we split? how much would be sane to split? should we focus on what makes us equal or on what makes us different? what should we postpone to be able to achieve a release of something else?
what do you think?
Sunday 7 January 2007
who owns development?
I have had a lot of times discussions with people from developing countries receiving donations, aid etc. and on my question: Do you own your development? mostly nobody answered with : yes.
May free software and open hardware be an opportunity to have positive answer on that question?
veki
May free software and open hardware be an opportunity to have positive answer on that question?
veki
The OpenSDE Handbook
The hard drive with the most recent copy of the book is broken :(. That'll teach me not to commit frequently. The point of this post is:
What do you want included in the book?
What do you want included in the book?
new usage
PKG and SDE usage
Hi there!
There is a proposal on a new usage for the existing wrapper sde and a new wrapper pkg. The idea is to seperate the commands to make it easier for the end user by reducing the command usage clutter. The pkg proposed for the end user, and the sde command is proposed for who ever is building with OpenSDE or maintaining it.
What do you think?
Hi there!
There is a proposal on a new usage for the existing wrapper sde and a new wrapper pkg. The idea is to seperate the commands to make it easier for the end user by reducing the command usage clutter. The pkg proposed for the end user, and the sde command is proposed for who ever is building with OpenSDE or maintaining it.
What do you think?
Saturday 6 January 2007
RTFB
Hi! let me introduce you the blog of the OpenSDE community. sweet, isn't it? ,-) Here every member of the OpenSDE community will be able to write about anything they want. From cooking receipts to the nightmare they are having with certain architecture or package, new targets, ... pictures from the last "dev-meeting" or the new hardware someone got.
Enjoy it! ... and Read The F* Blog ,-)
Enjoy it! ... and Read The F* Blog ,-)
Subscribe to:
Posts (Atom)
