As mentioned in a different comment. The only place where you will find older kernels in production these days will be in a VM. These are completely relevant for the people who will be running older kernels. Old hardware dies and the services migrate. Old software doesn't die, it just keeps on living in a VM.
Considering the efforts going into VM these days and the massive deployments in Fortune 500 companies, the performance of VM based systems is predictable. All the testing with Phoronix Test Suite is repeated until there is less than 3% variance between the results - or the result set is discarded.
Realistically, looking at older kernels on modern hardware is actually a very critical dimension for corporate server environments. There are applications in that space that are deployed and supported only on some old distribution. Being able to achieve and understanding how Red Hat 7.1 will act vs Red Hat 5 is critical for some environments.
If the requirements and restrictions on the Internet in China are enshrined in Law in China, you may be putting your visa at risk.
It's like a Australian 18 year old coming to the US and drinking alcohol and getting caught. In Australia, there no restriction above 18, in the US, it's 21. You get caught, you may not be able to enter the country again.
A local law is a local law, no matter what your views are. What you can do freely in your country may be illegal and carry harsh punishments in others.
It's Free, it's Open Source and has a bucketload of tests already. You can combine result sets and you can even get the results uploaded for comparison at http://global.phoronix-test-suite.com/
Creating your own tests is nice and easy too.
(Full disclosure - I am one of the project members).
In multi-card/X Screen (:0.0) mode, you only have Xinerama - and minimal configurability.
In multi-card/multi-screen mode, you have RANDR per screen + Xinerama extensions for glass layout.
If the above sounds like some obscure language, it is. The X code is only really understanding 2 heads with lots of X developers trying to kill multiple-GPU configurations (thanks Intel). It's not pretty, but the skeleton is mostly there. Look for comment the comment below http://games.slashdot.org/comments.pl?sid=1655284&cid=32248342 for an example of a 4 multi-card/4 screen setup with 3x2 monitor layouts for each screen.
24 Displays done under Linux - on October last year. The drivers were carefully teased into that condition, and so the tech is on it's way.
Be aware that the RANDR/Xinerama maturity in Linux is weak, so it will take a few years for it to be able to handle >2 - note that it's take almost a decade to get reasonable 2-head support...
You should have a closer look at Phoronix Test Suite. The infrastructure is the half of the hard part in testing, so then it comes down to just writing the tests.
24 monitors, 4 cards, 1 PC. All consumer grade. All running Linux. And yes, there is bezel correction.
Yes, there are black lines for the monitors. I couldn't get the budget to do 24 50" Plasmas. But think beyond the demo part of the tech and think about the possibilities.
Your support, validation and sustaining costs don't contribute to the bottom line of your business. If you have a part of the product that takes a unnecessarily large proportion of the bottom line, you look at the value proposition. You do something as simple as removing the client for a platform, you save money.
BUT, if the product is based around open standards, the Linux community has a high probability of making something that will work anyway. For FREE. No support costs for a client, no development and validation costs either. Linux, with it's "Freedom" has an extremely high cost to be an ISV on, you have kernels, X versions, distributions.. All subtley different and all having precious consideration for the cost of operating in that ecosystem.
Google has many examples of killing/not creating a client, but fostering the capability. Google talk is a great example. Google still gets the branding value of the service, but doesn't need to have a client, I have *NEVER* heard anyone talk about "Google's JMPP or Jabber Service". I would expect that this is the same, but for google voice. The people carrying credit will probably be handled.
Judging by your posts and your handle, you work in or around servers - a lot.
You would probably be aware that security, stability, and all such things are a set of tradeoffs of risks and benefits/costs.
You can make a system 100% secure, but it may not be useable. You can make a system five 9's stable, but you have to pay for it. You make the assessment of the risk (in this case data corruption), against the benefit/costs (double the speed in some cases).
SuSE seemed to have made the assessment of risk without understanding the cost. They enabled barriers by default to take the high moral ground, but then didn't understand the cost of doing so.
Your analogy about buying a new gas oven is interesting. You look at the manuals and there are *many* ways that you can blow up your oven. It is just that the risk (of someone naively or accidentally blowing themselves up) has been balanced against the benefit of lower consumption of energy. There are many ways of managing risks - redundancy, accepting the risk, etc.
My prime point was that the benchmarking which yeilded questions - without the answers given - are extremely valuable. They allow the upstream people developing systems to understand that they need to consider the bigger picture and apply a risk/cost/benefit judgement and not close of all risks. I would expect that in later versions of SuSE they have turned off barriers now that the risk has been sufficiently understood and the costs determined as being commercially relevant.
Or using your analogy. The tests that the oven may blow up but save 50% on the energy bill has been shown that the net benefit is on the side of the oven that may potentially blow up!
The question and answer don't need to be provided by the same voice. It is when you have someone questioning, and then someone answering, then you have a discussion, then finally you have progress.
To make it worse, there is virtually no reason that any number of the organizations supporting the leading developers can't invest a small amount of infrastructure and run the tests themselves. Phoronix Test Suite is absolutely trivial to use. The amount of "software development in autopilot" is frightening, this applies equally to Open Source as it does to Proprietary.
Read David's blog - http://airlied.livejournal.com/ - there are a whole pile of potential problems about that driver. David accepts that it was on questionable ground, and so it will probably never see the light of day.
The first pass, 'Damn, that Linux is expensive, even more expensive than Vista', the reflexive response is that these are the same models and to assume that you customize up, not down.
Presubmission reviews are the strongest ways
on
PMD Applied
·
· Score: 1
The classic - sit in a room and review - doesn't work, the engagement factor drops considerably.
The process that I have implemented within my team is quite simple.
1) Before review, the developers prepare the submission comments as well (low quality checkin comments are as bad as low quality code)
2) The developers then run a script to prepare a diff for review
3) The review is set to *all* developers
4) Any developer can hold the review based on logical, syntactical or stylistic criteria.
5) When a developer okays the change, they are attached to the checkin comment as a reviewer.
Some retorts that I have received from people outside the group (and my response)
1) Diffs don't provide enough context ; If you can't interpret a context diff, you don't know your code
Some observations on what happens when the developers get used to it
1) Developers can do this as part of their day-to-day life
2) Developers will eventually learn to rely on the code review as a way of understanding
3) Developers begin to get paranoid about code that has not been reviewed:)
4) Reviewer developers begin to focus on particular areas of their concern (magic numbers, style, correctness, code familiarity)
5) It doesn't hold back development,since the half-backed checkin doesn't occur nearly as much, and hence no rework.
6) The developers begin to strive for a clean review - hence increasing quality
7) The developers begin to make the process more stringent *on their own*
Surprisingly, the psychological aspect of the review process plays to increase it's strength.
Now the next area for me to get the developers fully engaged on is formal SDLC artefacts:).
So when an IHV posts includes 'Linux Support' to their drivers, what happens when an OEM has a stop ship? Who will answer the phone? Who will work for 2 weeks straight to diagnose and resolve the issue?
What this approach does is allow the Linux market to flourish despite itself. It actually moves us further away from having OEM preloads with Linux installed.
It sounds like you are currently unilingual - don't underestimate the amount of internal training that you will have to do.
Children learn slowly, adults try to learn quickly, give your self time.
Never assume the a translation carries the meaning, it won't.
Now on the learning
Learn with Hiragana and Katakana if at all possible, Romaji will end up adding more complexity to learning, it is only a standardized approximation to the actual language.
Don't rely on electronic-only methods, write read and use a paper dictionary.
Get children's books - they are simple and give you the basics
Get a hiragana based japanese-english/english-japanese dictionary
Get a kanji based japanese-english dictionary
For Linux software I use gjiten, edit and uim
Slashdot Mirror
As mentioned in a different comment. The only place where you will find older kernels in production these days will be in a VM. These are completely relevant for the people who will be running older kernels. Old hardware dies and the services migrate. Old software doesn't die, it just keeps on living in a VM.
Considering the efforts going into VM these days and the massive deployments in Fortune 500 companies, the performance of VM based systems is predictable. All the testing with Phoronix Test Suite is repeated until there is less than 3% variance between the results - or the result set is discarded.
Realistically, looking at older kernels on modern hardware is actually a very critical dimension for corporate server environments. There are applications in that space that are deployed and supported only on some old distribution. Being able to achieve and understanding how Red Hat 7.1 will act vs Red Hat 5 is critical for some environments.
If the requirements and restrictions on the Internet in China are enshrined in Law in China, you may be putting your visa at risk.
It's like a Australian 18 year old coming to the US and drinking alcohol and getting caught. In Australia, there no restriction above 18, in the US, it's 21. You get caught, you may not be able to enter the country again.
A local law is a local law, no matter what your views are. What you can do freely in your country may be illegal and carry harsh punishments in others.
Oh yes it does - look again - also look at http://slashdot.org/comments.pl?sid=1659510&cid=32286766
Phoronix Test Suite ( http://www.phoronix-test-suite.com/ ) supports Win7 now. It also allows comparison against OSX and Linux ( http://www.phoronix.com/scan.php?page=article&item=linux_windows_part3&num=1 ).
It's Free, it's Open Source and has a bucketload of tests already. You can combine result sets and you can even get the results uploaded for comparison at http://global.phoronix-test-suite.com/
Creating your own tests is nice and easy too.
(Full disclosure - I am one of the project members).
The ATI drivers support Xinerama and RANDR.
In multi-card/X Screen (:0.0) mode, you only have Xinerama - and minimal configurability.
In multi-card/multi-screen mode, you have RANDR per screen + Xinerama extensions for glass layout.
If the above sounds like some obscure language, it is. The X code is only really understanding 2 heads with lots of X developers trying to kill multiple-GPU configurations (thanks Intel). It's not pretty, but the skeleton is mostly there. Look for comment the comment below http://games.slashdot.org/comments.pl?sid=1655284&cid=32248342 for an example of a 4 multi-card/4 screen setup with 3x2 monitor layouts for each screen.
Setting that puppy up was a complete PIA!
Obligitory link - http://www.youtube.com/watch?v=N6Vf8R_gOec
24 Displays done under Linux - on October last year. The drivers were carefully teased into that condition, and so the tech is on it's way.
Be aware that the RANDR/Xinerama maturity in Linux is weak, so it will take a few years for it to be able to handle >2 - note that it's take almost a decade to get reasonable 2-head support...
Sure, back when people knew the IPs of their local archie and simtel archives.
Those where the days...
Plug alert.
You should have a closer look at Phoronix Test Suite. The infrastructure is the half of the hard part in testing, so then it comes down to just writing the tests.
From the launch activities for the 5800 family.
http://www.youtube.com/watch?v=N6Vf8R_gOec
24 monitors, 4 cards, 1 PC. All consumer grade. All running Linux. And yes, there is bezel correction.
Yes, there are black lines for the monitors. I couldn't get the budget to do 24 50" Plasmas. But think beyond the demo part of the tech and think about the possibilities.
Aargh. Cat5 provides many more options than coax.. My bad.
If you have lots of coax running through pipes and if it is free, then use the coax as a wirepull to rewire the house.
Cat5 provides many more options than cat5.
The economics are fairly simple.
Your support, validation and sustaining costs don't contribute to the bottom line of your business. If you have a part of the product that takes a unnecessarily large proportion of the bottom line, you look at the value proposition. You do something as simple as removing the client for a platform, you save money.
BUT, if the product is based around open standards, the Linux community has a high probability of making something that will work anyway. For FREE. No support costs for a client, no development and validation costs either. Linux, with it's "Freedom" has an extremely high cost to be an ISV on, you have kernels, X versions, distributions.. All subtley different and all having precious consideration for the cost of operating in that ecosystem.
Google has many examples of killing/not creating a client, but fostering the capability. Google talk is a great example. Google still gets the branding value of the service, but doesn't need to have a client, I have *NEVER* heard anyone talk about "Google's JMPP or Jabber Service". I would expect that this is the same, but for google voice. The people carrying credit will probably be handled.
Phoronix Test Suite (http://www.phoronix-test-suite.com/) is open source.
Join the community, help define meaningful tests and benchmark.
http://www.phoronix.com/scan.php?page=news_item&px=NzUyNA
over 60 megapixels. (4 GPUs, multi-head mode, with X-plane.)
The 24 head flight simulator at the launch was running Linux
http://www.legitreviews.com/article/1069/1/
Display are 4 x 3x2 layouts, multi-asic with each having 1 head. Single processor, Ubuntu, X-Plane.
RANDR is great for configuring each head. You can't do multi-head with RANDR.
Judging by your posts and your handle, you work in or around servers - a lot.
You would probably be aware that security, stability, and all such things are a set of tradeoffs of risks and benefits/costs.
You can make a system 100% secure, but it may not be useable. You can make a system five 9's stable, but you have to pay for it. You make the assessment of the risk (in this case data corruption), against the benefit/costs (double the speed in some cases).
SuSE seemed to have made the assessment of risk without understanding the cost. They enabled barriers by default to take the high moral ground, but then didn't understand the cost of doing so.
Your analogy about buying a new gas oven is interesting. You look at the manuals and there are *many* ways that you can blow up your oven. It is just that the risk (of someone naively or accidentally blowing themselves up) has been balanced against the benefit of lower consumption of energy. There are many ways of managing risks - redundancy, accepting the risk, etc.
My prime point was that the benchmarking which yeilded questions - without the answers given - are extremely valuable. They allow the upstream people developing systems to understand that they need to consider the bigger picture and apply a risk/cost/benefit judgement and not close of all risks. I would expect that in later versions of SuSE they have turned off barriers now that the risk has been sufficiently understood and the costs determined as being commercially relevant.
Or using your analogy. The tests that the oven may blow up but save 50% on the energy bill has been shown that the net benefit is on the side of the oven that may potentially blow up!
The Phoronix benchmarking is intended to provide you the answers as to why. It is to highlight the stuff that has happened.
If performance management is going on within the kernel community, then this shouldn't come up as a shock. The whole purpose of independent testing is that you see something that looks out of place, investigate and resolve. A perfect example is http://www.phoronix.com/scan.php?page=article&item=intel_atom_four&num=1 phoronix article, that showed that SuSE was trailing. This causes this http://lizards.opensuse.org/2008/12/16/comments-on-phoronix-benchmarking-opensuse-111/ discussion.
The question and answer don't need to be provided by the same voice. It is when you have someone questioning, and then someone answering, then you have a discussion, then finally you have progress.
To make it worse, there is virtually no reason that any number of the organizations supporting the leading developers can't invest a small amount of infrastructure and run the tests themselves. Phoronix Test Suite is absolutely trivial to use. The amount of "software development in autopilot" is frightening, this applies equally to Open Source as it does to Proprietary.
Although I can't find the original anymore, this same concept was presented in 1999.
http://portal.acm.org/citation.cfm?id=1268359
Bzzzz - wrong.
Read David's blog - http://airlied.livejournal.com/ - there are a whole pile of potential problems about that driver. David accepts that it was on questionable ground, and so it will probably never see the light of day.
The headline price for the different operating systems are the critical steps in deciding which one to go down and look at.
l s.aspx/dimen_e520?c=us&l=en&s=dhs&cs=19 - $369x ?c=us&cs=19&kc=6V440&l=en&oc=DDCWAN3&s=dhs - $679x ?c=us&cs=19&kc=6V440&l=en&oc=DDCWAV3&s=dhs - $599
Vista E520 - http://www.dell.com/content/products/productdetai
FreeDos E520n - http://configure.us.dell.com/dellstore/config.asp
Linux E520n - http://configure.us.dell.com/dellstore/config.asp
The first pass, 'Damn, that Linux is expensive, even more expensive than Vista', the reflexive response is that these are the same models and to assume that you customize up, not down.
The classic - sit in a room and review - doesn't work, the engagement factor drops considerably.
:)
:).
The process that I have implemented within my team is quite simple.
1) Before review, the developers prepare the submission comments as well (low quality checkin comments are as bad as low quality code)
2) The developers then run a script to prepare a diff for review
3) The review is set to *all* developers
4) Any developer can hold the review based on logical, syntactical or stylistic criteria.
5) When a developer okays the change, they are attached to the checkin comment as a reviewer.
Some retorts that I have received from people outside the group (and my response)
1) Diffs don't provide enough context ; If you can't interpret a context diff, you don't know your code
Some observations on what happens when the developers get used to it
1) Developers can do this as part of their day-to-day life
2) Developers will eventually learn to rely on the code review as a way of understanding
3) Developers begin to get paranoid about code that has not been reviewed
4) Reviewer developers begin to focus on particular areas of their concern (magic numbers, style, correctness, code familiarity)
5) It doesn't hold back development,since the half-backed checkin doesn't occur nearly as much, and hence no rework.
6) The developers begin to strive for a clean review - hence increasing quality
7) The developers begin to make the process more stringent *on their own*
Surprisingly, the psychological aspect of the review process plays to increase it's strength.
Now the next area for me to get the developers fully engaged on is formal SDLC artefacts
So when an IHV posts includes 'Linux Support' to their drivers, what happens when an OEM has a stop ship? Who will answer the phone? Who will work for 2 weeks straight to diagnose and resolve the issue?
What this approach does is allow the Linux market to flourish despite itself. It actually moves us further away from having OEM preloads with Linux installed.
A few things to remember.
It sounds like you are currently unilingual - don't underestimate the amount of internal training that you will have to do.
Children learn slowly, adults try to learn quickly, give your self time.
Never assume the a translation carries the meaning, it won't.
Now on the learning
Learn with Hiragana and Katakana if at all possible, Romaji will end up adding more complexity to learning, it is only a standardized approximation to the actual language.
Don't rely on electronic-only methods, write read and use a paper dictionary.
Get children's books - they are simple and give you the basics
Get a hiragana based japanese-english/english-japanese dictionary
Get a kanji based japanese-english dictionary
For Linux software I use gjiten, edit and uim
Have a look atd =11127916
http://ask.slashdot.org/comments.pl?sid=133148&ci
Or feel free to hunt me down on Rage3D, and contact me on one of the IM systems referred to my account there.