[Klug-general] Re: You can't dis apple

[J D Freeman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Dec 19, 2006 at 01:56:41PM +0000, Karl Lattimer wrote:
> Thats a cheap shot, I'm a mac user
> 
> Are you familiar with any of my work?

No, but by the sounds of it, I don't want to be.

> I wasn't, if you build a kernel for i686 and run it on i386 how does it
> behave? 

that would be a boom like noise :p

> Erratically same kernel can have different bugs on different OS's how
> much testing goes into a debian kernel? I expect a little short of the
> 100,000 or so redhat testers do.

I wouldn't be so certain on that one. I will get back to you, I can
assure you tho its alot.

As for 100000 thats 500+ weeks of solid 24/7 testing. So much for one
release a year then.

Not to mention, that debian has several thousand developers (not the 4
you mentioned) which is *ALOT* more than redhat.

> > Great, file the following with redhat, and get back to me:
> > 
> > "software raid on linux has a hard limit of 256 devices on a single
> > machine, I need more".
> > 
> > Let me know how long it takes to fix.
> 
> If you need more that 256 software raid devices the hit on the processor
> would be so great that for every write you're system has to realign 256
> disks, this could take a while. 

Who said anything about 256 disks? Raid works on top of LVM too. As for
the penalty, it works out as only a few extra instructions per
write/read, and on the machines this is on, there is no noticable
performance hit.

> Software raid is intended to do small jobs, not enormous raid jobs, for
> what you're asking you should be looking at SAN not RAID.

No, for what we are looking for, we need more software RAID devices.
Sorry, this is what we want.

> The 256 limit I believe was introduced by Alan Cox, although I could be
> wrong, and is sensible!

It was found to be pants, and was removed for many drivers and replaced
with a 20bit long limit, rather than just 8 bits. This is reflected in
parts of the kernel, but not others. IIts to do with the number of minor
numbers.

> > Hmm, Supermicro have certified hardware for it. As has tyan. The
> > userbase is IMHO, no good guide. As for their build system, it works
> > very well.
> 
> Are these components or actual servers, which are designed for business?
> If they're servers, what kind of support do I get from Supermicro?
> Probably as much as Lucky Goldstar ;P

This is supermicro servers. What support do you want from supermicro?
Personally all I want is someone to come out with a new hardware part
should one fail. I don't want software support for that, I have a pet
kernel developer when I need software doing. 

> Lifes good ;)
> 
> Another question would be, is it certified by an independent testing lab
> or, supported i.e. drivers are provided or are in the kernel? 

All in the kernel, I don't want no 3rd party stuff.

> LMFAO, you really need your head looking at! Certified OS's are all I'd
> risk anything on.

Groovy, we have a different idea of acceptable levels of risk.
Personally I use my own judgement and knowledge, rather than relying on
a sticker from a manufacturer.

> How long does a stable release of debian take to emerge? Slightly longer
> that the 12months for RHEL and 6 for fedora core... Well slightly
> longer, I mean something like what was it 7 years last time LOL!

I consider this a feature, not a bug.

> Well, I only think it because of your responses, you say apple suck and
> debian are good. Take a step back and consider what that means. Risk
> assessments done by external audits will show up debian as a serious
> business risk. RHEL isn't, nor is SLES because they've been hardware
> certified by hardware vendors, not component manufacturers.

I think I could argue actually that the use of debian is not a risk, and
is not in anyway anything other than a strength.

This does however depend alot on the business. If its that important, I
wouldn't use redhat either, I would use solaris, on sun kit. If its not
enough to warrent sun hardware and sunkit, then debian will be fine.
Redhat is noteable for not being either of the two options.

> That as previously mentioned isn't a bug, its a sensible limit. Which I
> imagine now takes mdadm in debian away from that of the standard
> version. This is bad, very very bad.

And 8.3 file lenghts isn't a bug either, its a sensible limit.

You ever played with an IBM Z series?

> Calling that a bug is like saying that having 4 processor cores isn't
> enough per chip, you need more. Its hardly a bug! 

I would say only being able to have 4 cores is a bug, if it means I can
never, ever, have a cpu with 8 cores when I need it.

> Having sensible limits to stop people like you from building
> frankenservers is a good idea!

*pat* *pat*

Yes, you keep with that.

Out of interest what is it you do ?

J
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFFh/LB42M0lILkmGIRAuSzAKDv+qApzYstJvuHVMjZa1blwG6eMgCdHhqy
4PNH1hNgBcacev2D35PiRgU=
=1Tw0
-----END PGP SIGNATURE-----