Please - this is one of the most pointless whines out there.
99.9% of people don't have the context to fix the bugs. "Fix it yourself" is a tired and pointless refrain - we need to fix our own house, not ask every guest to pick up a hammer.
I can fix some of the kernel code. I would have no clue how to fix X or Gnome. The world is complex. People need to specialise.
And we need to stop producing broken code (note that I say we, not they).
No, Windows drivers do not have an advantage here. They have a necessity for another layer of management because they have a decentralised codebase.
Linux has all the code in one tree - the versioning you speak of is the kernel version itself. That is why it is critical to get drivers merged into the tree before they're usable.
Merge the code. There is no issue here... move along.
"The Penguin gets more and more support from the two biggest rivals that Microsoft have ever had."
Please. IBM is OK for Linux in general, but Lotus Notes is the biggest piece of shit ever. All the people INSIDE of IBM hate it, let alone anyone else.
I hate Microsoft, but please, please... use Exchange instead. Hell, use ANYTHING else.
"Since we already have excellent Linux for PowerPC Macs,
the device driver and BIOS issues have already been dealt with"
That makes no sense to me. It's a totally different BIOS (it's EFI not openfirmware, for starters) and I suspect it's not the same device driver set on the whole, though there might be some overlap
Other thing I find works well for this kind of thing is the clear plastic stick-on covers they sell for protecting palm-pilot screens. Change it every few months, and it works great. Much thinner than a case...
You're making the wholly incorrect assumption that it's all about features. There are much more important questions like:
1) will it run your apps (ISV base) 2) will it fall over in a jibbering heap 3) does it run on commodity hardware. 4) how much TLC does it need on an ongoing basis.
POSIX compliance is not necessarily a good thing. I'd rather it did something sensible that worked.
So what is the going rate in the UK nowadays for "senior programmer" types? I finally gave up in disgust and moved to the US, but I'm curious if it got any better since 1998...
The UK just does NOT value techies like the US does, in my experience.
Firstly, because both RHEL and SLES pull their base from mainline kernel. I'm damned if I'm going to fix bugs 3 times - RHEL, SLES, and back in mainline. Let's fix it once, before it spreads.
Secondly, it's MUCH, MUCH easier to fix a bug the night after it went in, not 3 months later. Everyone has context as to what's goin on fresh in their minds, and the change hasn't been buried under 7 tons of other crap.
For one, did you actually bother to look at the results at all, and what tests are being run, and published?
For another, this is only the tip of the iceberg as to what can be done, but I'm not going to lock whatever I have now in some dingy dungeon until it's "finished". What's there is useful, ableit incomplete. Testing is *never* complete.
The main goal, as you put it, is to improve the quality of the linux kernel. If we can ensure the kernel builds, boots, and runs basic tests... in a fully automated way... then it frees up other resources to do more sophisticated tests, without getting dragged down by basic crap.
The results are all there if anyone wants to play with them. Go to the results matrix, and click on the numerical part of the green box. Pick a test, and drill down to the results directory.
The numbers are there, it's just a question of drawing graphs, etc. I have some for kernbench already, but I'm not finished automating them. If anyone wants to email me code to generate them from the directory structure published there, feel free;-) Preferably python or perl into gnuplot.
There is indeed an internal self-test suite on the harness. It's not desperately sophisticated, and I wouldn't dare show it to anyone;-) However, it does catch a lot of stupid bugs. It requires some manual intervention/inspection to work.
Plus, there's a separate development grid where we test new test-harness code before it's put onto the production grid.
Indeed. The automation system I wrote is just a wrapper around an internal harness called ABAT that has a massive amount of work behind it. If systems crash it can detect that, power cycle them, etc.
Going from 90% working to 99.9% working is frigging hard. I had all this working 3-6 months ago, but the results weren't good enough quality to be published. Several people internally put a massive amount of work into improving the quality and stability of the harness.
Compiles, boots, runs dbench, tbench, kernbench, reaim, fsx. If one test fails, it'll highlight it in yellow, rather than green or red. I have a few of those in the internal tests, but not the external set.
This is only the tip of the iceberg as to what can be done. We're already running LTP, etc internally, and several other tests. Some have licensing restrictions on results release (SPEC)... LTP is a pain because some tests always fail, and I have to work out the differential against baseline. Will come later.
I automatically test every nightly -git snapshot release, so it's fairly well tied in anyway. This also means my heaviest usage of our machines is at night, when most of the (US) developers are asleep.
So it's fairly well tied in already... and the whole -rc cycle should enable us to catch a lot of stuff.
> Now the ultimate machine would have SGIs > architecute (memory) and #CPUs per node using > the PowerPC CPU. We know that IBM and SGI > would never colaborate on something like this, > but can't a geek dream!
Ummm. Have you seen the Regatta-style stuff? It's faster than the SGI archticture. And with Power 5, even though the CPU count might be lower, the overall machine would probably be at least as fast.
Slashdot Mirror
Please - this is one of the most pointless whines out there.
99.9% of people don't have the context to fix the bugs. "Fix it yourself" is a tired and pointless refrain - we need to fix our own house, not ask every guest to pick up a hammer.
I can fix some of the kernel code. I would have no clue how to fix X or Gnome. The world is complex. People need to specialise.
And we need to stop producing broken code (note that I say we, not they).
That doesn't fix anything.
It just pushes the problem around somewhere else where it's harder to syncronise and control.
We need to FIX the bugs, not have magic shit that restarts itself when it crashes.
No, Windows drivers do not have an advantage here.
... move along.
They have a necessity for another layer of management because they have a decentralised codebase.
Linux has all the code in one tree - the versioning you speak of is the kernel version itself.
That is why it is critical to get drivers merged into the tree before they're usable.
Merge the code. There is no issue here
Excersise for the reader: Please count all the bugs in the Linux kernel, and tell us how many there are.
(hint: you can't).
Not that I disagree with your grammar, but still.
> Also, I can't see any way to make things look "slick and cool" or to render them in anything but a simplistic cartoon-like style.
It has texture mapping.
> Maybe at google they have a range of keyboards that you can swap over every few days, but not here.
They do, indeed.
Great. Now we have the bloat of Gnome *and* KDE combined. Fucking A.
What other really bad plans in the name of political comprimise can we come up with?
Let's make sure that we really get the worst of both worlds by including the
non-configurability of Gnome, and buggy shit like gamin too.
Who comes up with this crap?
"The Penguin gets more and more support from the two biggest rivals that Microsoft have ever had."
... use Exchange instead. Hell, use ANYTHING else.
Please. IBM is OK for Linux in general, but Lotus Notes is the biggest piece of shit ever. All the people INSIDE of IBM hate it, let alone anyone else.
I hate Microsoft, but please, please
I doubt it. you'll just get a large bandwidth bill, and your server will fall over.
"Since we already have excellent Linux for PowerPC Macs,
the device driver and BIOS issues have already been dealt with"
That makes no sense to me. It's a totally different BIOS (it's EFI not openfirmware, for starters) and I suspect it's not the same device driver set on the whole, though there might be some overlap
And in other news, a huge 55 gallon drum of lard flew past the window really, really slowly, after taking 5 minutes to launch itself off the ground.
If they focused on making the thing lean and mean, rather than a bloated collection of more and more features, maybe it'd be more interesting.
Other thing I find works well for this kind of thing is the clear plastic stick-on covers they sell for protecting palm-pilot screens. Change it every few months, and it works great. Much thinner than a case ...
... apart from Ingo
You're making the wholly incorrect assumption that it's all about features. There are much more important questions like:
1) will it run your apps (ISV base)
2) will it fall over in a jibbering heap
3) does it run on commodity hardware.
4) how much TLC does it need on an ongoing basis.
POSIX compliance is not necessarily a good thing. I'd rather it did something sensible that worked.
So what is the going rate in the UK nowadays for ...
"senior programmer" types? I finally gave up in disgust and moved to the US, but I'm curious if it got any better since 1998
The UK just does NOT value techies like the US does, in my experience.
"Do you need permission to turn on the TV and watch open air TV shows?"
... yes. Seeing as the article points to the UK, you need a TV license.
Ironically
As one of the presenters referred to ... I object.
... but I also understand the value not weighing 400lb, and eating a whole cake at every sitting.
I do understand the importance of office suites
Open office takes about 30s to start on my 256Mb Pentium 3 laptop. Sorry, but that's fucking ridiculous.
Firstly, because both RHEL and SLES pull their base from mainline kernel. I'm damned if I'm going to fix bugs 3 times - RHEL, SLES, and back in mainline. Let's fix it once, before it spreads.
Secondly, it's MUCH, MUCH easier to fix a bug the night after it went in, not 3 months later. Everyone has context as to what's goin on fresh in their minds, and the change hasn't been buried under 7 tons of other crap.
For one, did you actually bother to look at the results at all, and what tests are being run, and
... in a fully automated way ... then it frees up other resources to do more sophisticated tests, without getting dragged down by basic crap.
...
published?
For another, this is only the tip of the iceberg as to what can be done, but I'm not going to lock whatever I have now in some dingy dungeon until it's "finished". What's there is useful, ableit incomplete. Testing is *never* complete.
The main goal, as you put it, is to improve the quality of the linux kernel. If we can ensure the kernel builds, boots, and runs basic tests
Onwards, and upwards
The results are all there if anyone wants to play with them. Go to the results matrix, and click on the numerical part of the green box. Pick a test, and drill down to the results directory.
;-) Preferably python or perl into gnuplot.
The numbers are there, it's just a question of drawing graphs, etc. I have some for kernbench already, but I'm not finished automating them. If anyone wants to email me code to generate them from the directory structure published there, feel free
There is indeed an internal self-test suite on the harness. It's not desperately sophisticated, and I wouldn't dare show it to anyone ;-) However, it does catch a lot of stupid bugs. It requires some manual intervention/inspection to work.
Plus, there's a separate development grid where we test new test-harness code before it's put onto the
production grid.
Indeed. The automation system I wrote is just a wrapper around an internal harness called ABAT that has a massive amount of work behind it. If systems crash it can detect that, power cycle them, etc.
Going from 90% working to 99.9% working is frigging hard. I had all this working 3-6 months ago, but the results weren't good enough quality to be published. Several people internally put a massive amount of work into improving the quality and stability of the harness.
Compiles, boots, runs dbench, tbench, kernbench, reaim, fsx. If one test fails, it'll highlight it
... LTP is a pain because some tests always fail, and I have to work out the differential against baseline. Will come later.
in yellow, rather than green or red. I have a few of those in the internal tests, but not the external set.
This is only the tip of the iceberg as to what can be done. We're already running LTP, etc internally, and several other tests. Some have licensing restrictions on results release (SPEC)
I automatically test every nightly -git snapshot release, so it's fairly well tied in anyway. This also means my heaviest usage of our machines is at night, when most of the (US) developers are asleep.
... and the whole -rc cycle should enable us to catch a lot of stuff.
So it's fairly well tied in already
> Now the ultimate machine would have SGIs
> architecute (memory) and #CPUs per node using
> the PowerPC CPU. We know that IBM and SGI
> would never colaborate on something like this,
> but can't a geek dream!
Ummm. Have you seen the Regatta-style stuff?
It's faster than the SGI archticture. And with
Power 5, even though the CPU count might be
lower, the overall machine would probably be at
least as fast.