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

[Karl Lattimer]

> On Tue, Dec 19, 2006 at 01:28:08PM +0000, Karl Lattimer wrote:
> > Is it so hard to open a terminal?
> 
> Based on what I have seen of Mac users, yes :p

Thats a cheap shot, I'm a mac user

Are you familiar with any of my work?

> > Anaconda kickstart anyone?
> > 
> > BTW: Uptime isn't a good rating of stability, if you've got a rogue
> > piece of kernel code destroying part of your raid array in silent the OS
> > is still unstable even though the uptime is OK and it didn't GPF or KP.
> 
> Erm, thats teh same kernel, thats not a debian thing, thats a kernel
> thing. Don't confuse the two.

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

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.

> 
> > That is what I'd hate about debian, especially in something as important
> > as mdadm. File the same bug to redhat, someone would fix it within 24
> > hours.
> 
> 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.

HAH, yeah and while you're waiting maybe you could call up the
department of the completely retarded ideas and file that one there
too. 

LMFAO!

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. 

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.

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

> > Based on the fact that debian isn't majorly supported by users, their
> > user base for servers is way lower than redhat, the build system is
> > archaic IMHO and lastly, it isn't a certified OS by any hardware vendor.
> > Is that enough of a reason not to risk a business on it.
> 
> 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

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? 

Big difference!

> 
> > REAL IT risk management would not let you put debian on a server because
> > there could be issues with the kernel that are quiet. Verified and
> > managed build processes with many a bug hunter and a thorough testing
> > process make it less of a risk to use redhat, especially as Dell, HP,
> > IBM and many others recommend it for servers.
> 
> You show me that you don't know what the debian crew are upto. The
> stable release of debian is more stable than any other distro, IMHO. I
> would risk my business on non other.

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

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!

> 
> > You obviously don't know enough about the OS's to comment on it. Volume
> > of machines is no indication at how good you are at running them or how
> > good you are at managing the risk.
> 
> No, you're right. Volume of machines is nothing, I have managed to setup
> these machines running debian with no clue as to what I am doing,
> without analysing the risk I have to businesses in doing so. No, I
> haven't tested the options, I haven't considered what I am doing. No, I
> have no clue what so ever. You keep thinking that. Me, I will keep using
> debian till I find something better.

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 don't want to have to buy someone a pint to prevent mdadm from
> > breaking my raid array. Thats just f*cking ludicrous! 
> 
> I don't have to either, I chose to, I bought them the pint to say thank
> you for the work they put in. Same reason I have done the same for other
> software developers in the OSS communittee.
> 
> As for the bug, the bug wasn't going to break my raid array, it just
> stops me from having more than 255 raid arrays on a single machine,
> which was a problem.

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.

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

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

K,