Same thing. First, verify it's where it's supposed to be. Second, if the resolution is good enough (and they weren't sure it would be) see if it seems to be oriented correctly.
If it's not where it's supposed to be, then there's a partial explanation of why it's not responding -- it's off course -- and also tells them their options are limited to setting it straight again. If it is, but it's oriented incorrectly, then the batteries are not getting recharged and you focus on getting it oriented correctly so it can get power again. If it is present, oriented correctly, and still not responding, then you've got a different set of options.
To lie to your boss in order to make you look good? Scotty sounds like the stereotypical primadonna programmer.
No -- to lie to your boss to get him to accept the numbers that will make him appear predictable and reliable. Sounds like a stereotypical primadonna manager.
I had a project once that came out to about six months in duration in planning. One task was "surprises - 3 weeks". My manager asked me to explain this, and I told him that since we never did a formal post-mortem on projects I couldn't say exactly why, but it seems our schedules were consistently off about a week for every two months of planned activity. So three weeks for six months would just about give us the correct date.
He didn't disagree, but this was unpalatable to him, because he couldn't justify it to his manager, so we added one day to each of fifteen carefully chosen subtasks. He went away happy, and the project came in "on time".
Afterward, I'd ask if he wanted schedules done for "calendar time" or "engineering time". He always chose "calendar time", loudly whistled a tuneless whistle when I explained the difference, and was pleased (and rewarded by his management) when it came in on time or early.
Sometimes the world ain't perfect but you learn how to get things done anyway. That's Scotty's legacy. Miracles may just be bad scheduling but good career management is observing what happens around you anyway and using it to your advantage.
Yup, I've been to OSDL. It's real. And it's got more than two cubicles (well, more than three now that "the other Andrew" has joined.) OSDL does more than house those three and throw them a food pellet once in a while -- they've got folks to support the hardware they have there and the software initiatives that they are spearheading, like carrier-grade Linux.
Linus and Andrew (and I suspect, now, "the other Andrew") tend not to be at the office but instead work remotely, coming into the office for meetings when needed. That said, Linus did move to the Portland area. But working from home allows him a great deal of flexibility and better able to spend time with his family. Not unlike many other people who telecommute (he wrote from his basement office as his daughter watched a video upstairs after her nap.)
To avoid the problems with Newton's Law knocking the spacestation about, how about we load the garbage up on a special GMD (Garbage Movement Device), give it a relatively modest push out of the space station (model rocket engine, maybe, or even just a burst of compressed air), wait several hours for it to get far enough from the space station, then fire off its propulsion system (also low-grade, providing maybe 25-50 mph thrust) which puts it more quickly (and hopefully more predictably) into a reentry and burn orbit. The modest push should affect the station minimally and might even be used to compensate for the natural decay of the station anyway.
The idea would be to use low-power thrust to slowly lower the garbage's orbit. If it takes days or weeks for it to reach burn level, so what? This is not a time-critical operation. Then the question is, does such a low-power thrust device exist? Solar power and a propeller probably won't do it:) but is there anything else low-cost and disposable (that is relatively cheap to build and transport to the station in the first place?)
(Yes, I'm dodging the issue of whether burning garbage in our atmosphere is a good thing and focusing on the technical obstacles. And no, I haven't done the physics because those brain cells were discarded a ways back:)
Since I think people lump the loadbalancing portion of an SMP system in with the "scheduler" then clearly the overall scheduling and running of processes is not O(1).
Correct. I think the part of scheduling that most people are interested in is "I have an idle processor; how expensive is it to give it a process?" That process (if you will overlook the pun) has been made effectively O(1). The overall load of the scheduler on the system continues to have some dependency on the load of the system. However, even the 2.6 scheduler has some heuristics now that say, "this level of finesse is no longer important after the load is this high" and start shedding some of the clever stuff after a point. Much of the work now is figuring out those heuristics and where the breakeven point on them are, and not surprisingly a lot of them have to do with load balancing between processors.
So the calculation is done per process as they finish their time slice, rather then at the end when all the processes are done. I still don't see why this would imply better efficiency. Am I missing something?
Depends on whether you're measuring the time to select another process to run, or the overhead necessary to do correct scheduling. Timeslice recalculation must happen, that's true. But on 2.4, it needed to happen in conjunction with other information gathered from the task list. There was one queue: the system task list. And to safely access that you need to take a read side of a read/write spinlock. Seems harmless enough, until you consider the side effect that a read lock will block a write lock from being acquired. So every time the scheduler has to inspect that list, it may be stopping some other part of the scheduler (possibly on another processor) from implementing some decision. In the worst case, you hold a read lock long enough that other processors' decisions become invalid. Once they acquire write permission they realize that the process has died or gone to sleep or is no longer a good choice for other reasons and then they must go back, grab a read lock (!) and search again. Thus blocking others who have reached decisions, etc.
2.6 (O(1)) significantly reduces lock contention. That alone accounts for tremendous savings under load. The cost is a little more memory and moderately more complexity. In this case, it is a very good trade.
They achieved O(1)ness by making it extremely rare to have to do linear searches of greater than one. Not impossible, but very rare.
There are 140 possible priorities. Per processor. Each priority has its own pair of queues -- runnable-and-not-yet-run (active), and runnable-but-waiting-for-more-time (expired). (If a process isn't runnable, it doesn't even appear in the run queue; already an improvement over 2.4). In the 2.4 scheduler, the system task list WAS the runqueue list, and you had to inspect it, from beginning to end, holding a lock, to find the next best process to run. As the system got busier, guess what -- that search got longer and your holding of the lock had a bigger, cascading effect. With multiple cpus, you might finally have multiple processors decide on the same process... then the first one grabs it and n-1 processors would have to go back and find the next best choice. Maybe they would conflict again. In 2.6, with 140 priorities often your queue of best processes is very short because you have so many places to put runnable processes, and on a per-processor basis no less.
But let's take a worst case example -- a heavily loaded system. You've got 1000 processes, but a lot of them are daemons waiting for something to happen. Still, as luck would have it, you have 200 processes runnable and waiting to run because your web server just got hit, and 4 processors handling them. Let's further assume that due to bad luck, all of them are stuck on only one of those cpus. And let's slap them with incredibly bad luck and place them ALL at the same priority, which is unlikely but certainly possible. Now that O(1) flies out the window, right? because you have 200 processes in one queue, just like before and now you have to look at all of them to figure out who runs next, right? Wrong. It's a FIFO linked list, and since you know they're all the same priority, you do the fair thing and take the one at the head. Took you a mere blink to determine the highest priority queue that had something (find first bit over a bitmap for the queues) and then a simple assignment to take the first thing off the list and select the fairest choice. As these processes use up their timeslices they are placed on the expired queue, again in FIFO order, and when the active is empty, with another simple assignment the expired becomes the active.
What's the down side? Well, the 2.4 scheduler had one queue (the tasklist) for all the cpus, and that meant it was self-balancing. You didn't end up with "200 processes on one processor"; as the processors needed processes they were handed one from The One Queue. However, in 2.6, a process doesn't randomly wander from its processor's queue. You do need to occasionally go move processes from processor to processor to insure they're not waiting too long for their turn. Otherwise, in the worst case, one processor has all of the runnable processes (all but one waiting) while the other processors sit idle.
So to summarize, under heavy load, 2.4's scheduler spent more and more time agonizing over which process to run, when you really needed it to be more and more efficient. 2.6 spends the same time under heavy and light load, which means more of the cpu is available to actually do the work. The effect is similar to removing three layers of middle management:)
political spam would be a drop in the bucket. It's not like politicians will be able to get away with things like abusing open relays or refusing to honor opt-outs -- at least, not without affecting their campaign.
That's why the abuse would take a more nefarious form: spam that appears to come from candidate A and violates good practice, but is actually sent by candidate's B people who made it look like it came from candidate A in an effort to turn the tide against A.
Then when candidate A denies sending it after the expected uproar, and accuses B, you really won't know who to believe... you'll just have a pile of email you didn't request and can't stop, just like now.
Since I've already identified myself as an IBM kernel hacker just by participating, this answer will definitely require that I state, for the record, that I do not represent IBM's views on this. These are my personal opinions, and if you sue IBM and make me lose my job, I will find you and get you kicked out of your trailer park.
Now then...
The short story is, the problem is not one of proper licensing. It's one of losing a business advantage. And I think it's fair to suggest this dilemma is not being faced solely by IBM either.
Let's examine your theoretical snippet of AIX code. It could fall into one of three buckets.
Useless. Nobody cares if it's open sourced. The overhead and accompanying fear is unnecessary. (That's almost always discovered in hindsight, unfortunately:)
Useful but hardly secret. The main danger here is that while not secret, it still gives some advantage to "the competition". Maybe the breakthrough was to drop the bubblesort and use a B-tree. Hardly revolutionary but sometimes clever code really isn't complex. (Simple example, I know, but you get the point.) If "the competition" hasn't figured this out already, IBM doesn't want to give them any clues.
Patent or trade secret. Ok, now IBM has invested real dollars in documenting and protecting this information. Serious scrutiny will happen before it goes out, just because of the dollars already invested.
And of course, remember through all this that "the competition" is not Linux or even Open Source. It's those companies (who may also be promoting and participating in Open Source) who simply happen to send sales people to the same customers IBM is sending sales people to. If IBM can show AIX is better in some way, it would be karma-good but business-stupid to give that up voluntarily. And by placing advantageous code into Open Source they will both make it available to the community at large (good thing) and make it available to the competition (not a good thing.)
Determining code that is patented or constitutes a trade secret is relatively easy. Separating useless from useful is hard (read/. moderating flames if you need an example!) and involves even more lawyers and hackers alike. That's what takes most of the time and effort.
It may comfort you to know there are a host of Linux hackers, only a subset of which participated in the interview, which are hammering at your questions all the time. The engineers hammer, and the lawyers hammer back. In general, the perception is that engineers could care less about IP and lawyers could care less about sharing with the community. Neither is entirely true. Their jobs and goals are very different, and objectively, their ongoing battles -- ahem, I mean dialogues -- do in the end yield a pretty good balance.
True -- the importance of GPA to corporations can't be stressed enough. The importance to actual recruiters varies greatly. Many, sadly, will use it as their primary and sole filter. However, when I was hired into my first job, it was with the "pitiful" GPA of 3.4. The person interviewing me fortunately had also come from that University and understood, without even asking, the implications of some of the coursework, course load, and jobs I'd had. He scheduled an interview and, after confirming his theory, fast-tracked me into an on-site interview and so began my career.
I think that was an excellent example of how to really find good people, and I've tried to return the favor. The GPA doesn't tell the whole story. I've met some 3.97 people with a PhD in CS and a MS in Physics and Astronomy who couldn't handle a simple perl script. (But we did have a fascinating discussion about solar events and their effect on the ionosphere.)
Yes, I chat up the 3.9+ folks. There's no denying that in today's tougher job market, that GPA will be your best billboard. But I also talk to 3.2 and 3.4 folks if I recognize job experience or coursework in their resumes and transcripts which looks interesting.
And yes, again sadly, that's unusual. But we do exist.
One, less than a year out of college I got an unsolicited offer from within 50 miles of home. Considering I was now 1500 miles from home, and considering they were offering a 20% raise, I considered it a nobrainer. But my current employer offered me a promotion and 30% raise for me to stay. In the end, I figured longevity at my first job would look better on my resume, and with some apprehension, stayed with my then-current employer. Right decision. 2 more promotions and five years later, I left on my own terms because I didn't like the new projects being handed to the group, and my not liking that wasn't going to change anything.
Then several years ago, I vented at my boss after being asked to give up an already-planned weekend vacation that considering the sacrifices being asked of me and considering the positions and salaries of those around me, I was underpaid. It was not an ultimatum, just a firm statement of opinion. I concluded (in person) that "while this isn't enough for me to go distribute my resume, on the day that I do do that, if you ask me when I first became disenchanted with my job, I will probably say today."
And they apologized, agreed, and offered me a small raise (about 3%) with the promise that this was above and beyond my salary review (due in a couple of months.) And they were good to their word.
There are three things that make me want to work somewhere: 1) The people I work with, 2) The things I am doing, and 3) What I get paid. On any given day, these can be in different order of importance. Whenever I feel any two of them are out of whack, I start looking for a new job. If only one is out of whack, I talk to my manager about it to see if something can be improved. So far, in almost all cases, it could. In those cases when it couldn't, I found a new job and entertained no counter offers, because the counters, I felt, didn't address ALL of my concerns.
Loyalty now is to people, not companies. If I respect my manager I'll try to work with him or her. If I respect my co-workers, I may actually stay because of them. But loyalty to a company is an (unfortunately) outdated concept, because companies are no longer loyal to employees.
And hey, guess what -- I'm not afraid of my managers reading this because I've already had this conversation with them.
All of the people listed are still employed by IBM, working on Linux, and reading slashdot (including me). (Well, ok, not sure if all of them read slashdot:)
Yes, the layoffs did not completely miss the Linux folks in Beaverton (or elsewhere) but I think IBM's commitment to Linux is underscored by how it was minimized.
Slashdot Mirror
Same thing. First, verify it's where it's supposed to be. Second, if the resolution is good enough (and they weren't sure it would be) see if it seems to be oriented correctly.
If it's not where it's supposed to be, then there's a partial explanation of why it's not responding -- it's off course -- and also tells them their options are limited to setting it straight again. If it is, but it's oriented incorrectly, then the batteries are not getting recharged and you focus on getting it oriented correctly so it can get power again. If it is present, oriented correctly, and still not responding, then you've got a different set of options.
More information can only help.
To lie to your boss in order to make you look good? Scotty sounds like the stereotypical primadonna programmer.
No -- to lie to your boss to get him to accept the numbers that will make him appear predictable and reliable. Sounds like a stereotypical primadonna manager.
I had a project once that came out to about six months in duration in planning. One task was "surprises - 3 weeks". My manager asked me to explain this, and I told him that since we never did a formal post-mortem on projects I couldn't say exactly why, but it seems our schedules were consistently off about a week for every two months of planned activity. So three weeks for six months would just about give us the correct date.
He didn't disagree, but this was unpalatable to him, because he couldn't justify it to his manager, so we added one day to each of fifteen carefully chosen subtasks. He went away happy, and the project came in "on time".
Afterward, I'd ask if he wanted schedules done for "calendar time" or "engineering time". He always chose "calendar time", loudly whistled a tuneless whistle when I explained the difference, and was pleased (and rewarded by his management) when it came in on time or early.
Sometimes the world ain't perfect but you learn how to get things done anyway. That's Scotty's legacy. Miracles may just be bad scheduling but good career management is observing what happens around you anyway and using it to your advantage.
Linus and Andrew (and I suspect, now, "the other Andrew") tend not to be at the office but instead work remotely, coming into the office for meetings when needed. That said, Linus did move to the Portland area. But working from home allows him a great deal of flexibility and better able to spend time with his family. Not unlike many other people who telecommute (he wrote from his basement office as his daughter watched a video upstairs after her nap.)
Um, it's not obelisk shaped, is it?
....
I thought this was supposed to be on a Jovian moon
To avoid the problems with Newton's Law knocking the spacestation about, how about we load the garbage up on a special GMD (Garbage Movement Device), give it a relatively modest push out of the space station (model rocket engine, maybe, or even just a burst of compressed air), wait several hours for it to get far enough from the space station, then fire off its propulsion system (also low-grade, providing maybe 25-50 mph thrust) which puts it more quickly (and hopefully more predictably) into a reentry and burn orbit. The modest push should affect the station minimally and might even be used to compensate for the natural decay of the station anyway.
:) but is there anything else low-cost and disposable (that is relatively cheap to build and transport to the station in the first place?)
:)
The idea would be to use low-power thrust to slowly lower the garbage's orbit. If it takes days or weeks for it to reach burn level, so what? This is not a time-critical operation. Then the question is, does such a low-power thrust device exist? Solar power and a propeller probably won't do it
(Yes, I'm dodging the issue of whether burning garbage in our atmosphere is a good thing and focusing on the technical obstacles. And no, I haven't done the physics because those brain cells were discarded a ways back
Correct. I think the part of scheduling that most people are interested in is "I have an idle processor; how expensive is it to give it a process?" That process (if you will overlook the pun) has been made effectively O(1). The overall load of the scheduler on the system continues to have some dependency on the load of the system. However, even the 2.6 scheduler has some heuristics now that say, "this level of finesse is no longer important after the load is this high" and start shedding some of the clever stuff after a point. Much of the work now is figuring out those heuristics and where the breakeven point on them are, and not surprisingly a lot of them have to do with load balancing between processors.
Depends on whether you're measuring the time to select another process to run, or the overhead necessary to do correct scheduling. Timeslice recalculation must happen, that's true. But on 2.4, it needed to happen in conjunction with other information gathered from the task list. There was one queue: the system task list. And to safely access that you need to take a read side of a read/write spinlock. Seems harmless enough, until you consider the side effect that a read lock will block a write lock from being acquired. So every time the scheduler has to inspect that list, it may be stopping some other part of the scheduler (possibly on another processor) from implementing some decision. In the worst case, you hold a read lock long enough that other processors' decisions become invalid. Once they acquire write permission they realize that the process has died or gone to sleep or is no longer a good choice for other reasons and then they must go back, grab a read lock (!) and search again. Thus blocking others who have reached decisions, etc.
2.6 (O(1)) significantly reduces lock contention. That alone accounts for tremendous savings under load. The cost is a little more memory and moderately more complexity. In this case, it is a very good trade.
There are 140 possible priorities. Per processor. Each priority has its own pair of queues -- runnable-and-not-yet-run (active), and runnable-but-waiting-for-more-time (expired). (If a process isn't runnable, it doesn't even appear in the run queue; already an improvement over 2.4). In the 2.4 scheduler, the system task list WAS the runqueue list, and you had to inspect it, from beginning to end, holding a lock, to find the next best process to run. As the system got busier, guess what -- that search got longer and your holding of the lock had a bigger, cascading effect. With multiple cpus, you might finally have multiple processors decide on the same process ... then the first one grabs it and n-1 processors would have to go back and find the next best choice. Maybe they would conflict again. In 2.6, with 140 priorities often your queue of best processes is very short because you have so many places to put runnable processes, and on a per-processor basis no less.
But let's take a worst case example -- a heavily loaded system. You've got 1000 processes, but a lot of them are daemons waiting for something to happen. Still, as luck would have it, you have 200 processes runnable and waiting to run because your web server just got hit, and 4 processors handling them. Let's further assume that due to bad luck, all of them are stuck on only one of those cpus. And let's slap them with incredibly bad luck and place them ALL at the same priority, which is unlikely but certainly possible. Now that O(1) flies out the window, right? because you have 200 processes in one queue, just like before and now you have to look at all of them to figure out who runs next, right? Wrong. It's a FIFO linked list, and since you know they're all the same priority, you do the fair thing and take the one at the head. Took you a mere blink to determine the highest priority queue that had something (find first bit over a bitmap for the queues) and then a simple assignment to take the first thing off the list and select the fairest choice. As these processes use up their timeslices they are placed on the expired queue, again in FIFO order, and when the active is empty, with another simple assignment the expired becomes the active.
What's the down side? Well, the 2.4 scheduler had one queue (the tasklist) for all the cpus, and that meant it was self-balancing. You didn't end up with "200 processes on one processor"; as the processors needed processes they were handed one from The One Queue. However, in 2.6, a process doesn't randomly wander from its processor's queue. You do need to occasionally go move processes from processor to processor to insure they're not waiting too long for their turn. Otherwise, in the worst case, one processor has all of the runnable processes (all but one waiting) while the other processors sit idle.
So to summarize, under heavy load, 2.4's scheduler spent more and more time agonizing over which process to run, when you really needed it to be more and more efficient. 2.6 spends the same time under heavy and light load, which means more of the cpu is available to actually do the work. The effect is similar to removing three layers of middle management :)
That's why the abuse would take a more nefarious form: spam that appears to come from candidate A and violates good practice, but is actually sent by candidate's B people who made it look like it came from candidate A in an effort to turn the tide against A. Then when candidate A denies sending it after the expected uproar, and accuses B, you really won't know who to believe ... you'll just have a pile of email you didn't request and can't stop, just like now.
Now then
The short story is, the problem is not one of proper licensing. It's one of losing a business advantage. And I think it's fair to suggest this dilemma is not being faced solely by IBM either.
Let's examine your theoretical snippet of AIX code. It could fall into one of three buckets.
- Useless. Nobody cares if it's open sourced. The overhead and accompanying fear is unnecessary. (That's almost always discovered in hindsight, unfortunately
:) - Useful but hardly secret. The main danger here is that while not secret, it still gives some advantage to "the competition". Maybe the breakthrough was to drop the bubblesort and use a B-tree. Hardly revolutionary but sometimes clever code really isn't complex. (Simple example, I know, but you get the point.) If "the competition" hasn't figured this out already, IBM doesn't want to give them any clues.
- Patent or trade secret. Ok, now IBM has invested real dollars in documenting and protecting this information. Serious scrutiny will happen before it goes out, just because of the dollars already invested.
And of course, remember through all this that "the competition" is not Linux or even Open Source. It's those companies (who may also be promoting and participating in Open Source) who simply happen to send sales people to the same customers IBM is sending sales people to. If IBM can show AIX is better in some way, it would be karma-good but business-stupid to give that up voluntarily. And by placing advantageous code into Open Source they will both make it available to the community at large (good thing) and make it available to the competition (not a good thing.)Determining code that is patented or constitutes a trade secret is relatively easy. Separating useless from useful is hard (read
It may comfort you to know there are a host of Linux hackers, only a subset of which participated in the interview, which are hammering at your questions all the time. The engineers hammer, and the lawyers hammer back. In general, the perception is that engineers could care less about IP and lawyers could care less about sharing with the community. Neither is entirely true. Their jobs and goals are very different, and objectively, their ongoing battles -- ahem, I mean dialogues -- do in the end yield a pretty good balance.
True -- the importance of GPA to corporations can't be stressed enough. The importance to actual recruiters varies greatly. Many, sadly, will use it as their primary and sole filter. However, when I was hired into my first job, it was with the "pitiful" GPA of 3.4. The person interviewing me fortunately had also come from that University and understood, without even asking, the implications of some of the coursework, course load, and jobs I'd had. He scheduled an interview and, after confirming his theory, fast-tracked me into an on-site interview and so began my career.
I think that was an excellent example of how to really find good people, and I've tried to return the favor. The GPA doesn't tell the whole story. I've met some 3.97 people with a PhD in CS and a MS in Physics and Astronomy who couldn't handle a simple perl script. (But we did have a fascinating discussion about solar events and their effect on the ionosphere.)
Yes, I chat up the 3.9+ folks. There's no denying that in today's tougher job market, that GPA will be your best billboard. But I also talk to 3.2 and 3.4 folks if I recognize job experience or coursework in their resumes and transcripts which looks interesting.
And yes, again sadly, that's unusual. But we do exist.
Two experiences from two different employers.
One, less than a year out of college I got an unsolicited offer from within 50 miles of home. Considering I was now 1500 miles from home, and considering they were offering a 20% raise, I considered it a nobrainer. But my current employer offered me a promotion and 30% raise for me to stay. In the end, I figured longevity at my first job would look better on my resume, and with some apprehension, stayed with my then-current employer. Right decision. 2 more promotions and five years later, I left on my own terms because I didn't like the new projects being handed to the group, and my not liking that wasn't going to change anything.
Then several years ago, I vented at my boss after being asked to give up an already-planned weekend vacation that considering the sacrifices being asked of me and considering the positions and salaries of those around me, I was underpaid. It was not an ultimatum, just a firm statement of opinion. I concluded (in person) that "while this isn't enough for me to go distribute my resume, on the day that I do do that, if you ask me when I first became disenchanted with my job, I will probably say today."
And they apologized, agreed, and offered me a small raise (about 3%) with the promise that this was above and beyond my salary review (due in a couple of months.) And they were good to their word.
There are three things that make me want to work somewhere: 1) The people I work with, 2) The things I am doing, and 3) What I get paid. On any given day, these can be in different order of importance. Whenever I feel any two of them are out of whack, I start looking for a new job. If only one is out of whack, I talk to my manager about it to see if something can be improved. So far, in almost all cases, it could. In those cases when it couldn't, I found a new job and entertained no counter offers, because the counters, I felt, didn't address ALL of my concerns.
Loyalty now is to people, not companies. If I respect my manager I'll try to work with him or her. If I respect my co-workers, I may actually stay because of them. But loyalty to a company is an (unfortunately) outdated concept, because companies are no longer loyal to employees.
And hey, guess what -- I'm not afraid of my managers reading this because I've already had this conversation with them.
Since it's a problem with the communication, it's a telco problem. Six months is the soonest a technician could get out there ...
All of the people listed are still employed by IBM, working on Linux, and reading slashdot (including me). (Well, ok, not sure if all of them read slashdot :)
Yes, the layoffs did not completely miss the Linux folks in Beaverton (or elsewhere) but I think IBM's commitment to Linux is underscored by how it was minimized.