[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian's progress inspite of events (was Re: Dunk-Tank and the DD strike)



On Sun, Mar 18, 2007 at 11:46:08PM -0300, D G Teed wrote:
> On 3/18/07, Roberto C. Sánchez <roberto@connexer.com> wrote:
> >
> >On Sun, Mar 18, 2007 at 07:51:07AM -0300, D G Teed wrote:
> >>
> >> I agree that the kernel within the installer is something
> >> needing to be updated more often.
> >
> >Except that this means that the kernel in the installer needs to be
> >installable as a default kernel, which means that it must also be
> >supported by the kernel team and security.  There is a lot of work
> >involved in that.
> 
> 
> There was another project by a small group which seemed to get through
> this issue, at least for x86.  I don't think it is that bad.  The Debian
> releases
> that come out almost quarterly could include such an update to the
> installer's kernel.
> 
Times 13 hardware architectures
Times some number of optimized kernels (-k7, -686, etc)
Times testing every single one of the above for regression
Plus other changes

For example, since the release of Sarge the kernel has progressed to the
point where hotplug is no longer supported and udev is really the only
way to go.  This is a non-trivial change that could hardly be considered
appropriate for a Stable release.  These sorts of things are prone to
happenning, so where does one draw the line?

Don't get me wrong.  I think it would be awesome if the installer could
be updated periodically.  However, anecdotes like yours and statements
like "they could restrict it to the most popular architectures" and
other such things only serve to obscure the true difficulty of the task.
Not only that, but there is a huge amount of work in something as simple
as changing the installer kernel without even considering changing any
other component.  That is why in the time leading up so far to the Etch
release, every new upstream kernel release has sparked intense
discussion about whether its benefits outweigh the effort required to
retool the installer to use it.

Please understand that this is not a simple task.

> >I regard Debian as serious
> >> production class server OS, but there are others who weigh
> >> everything on the installer experience.
> >
> >I've heard it said that the reason Debian users generally don't care
> >about the installer is because it is something you only use once :-)
> 
> 
> It sounds easy if you have one server.  Suppose you have 21 that you
> want to migrate from FreeBSD.

Well, that is why you have netboot, preseeding and other things like
systemimager.

> If it takes a day to find and do a
> workaround,
> versus the usual  30 minutes to complete a direct install, then I think this
> is more significant.

If you are manually installing 21 servers (unless they all happen to be
o wildly different hardware, or performing wildly different tasks or in
different cities/countries), you are wasting your time.  There are
better ways.

> Anyway, anything that impacts a manager's
> perception is something that impacts the possibility of adopting Debian at
> all.
> 
That is true.

> That is, the difficulty is enough for them to think, or even
> decide "forget it, do Redhat".  If you want my bosses to conclude
> that, then the status quo of sarge's installer is the thing to keep.
> 
Right.  But please see my above comments about what it means to update
the installer.

> Except, that the commercial brand Linuxes suffer from the same problem.
> >They just tend to update their installers more frequently.  Windows XP
> >has the same problem, only many people never noticed once the installer
> >was 5 years old, since people get windows preinstalled or get some
> >customized restore CD from the OEM.
> 
> 
> Yep. That's all I'm asking to see happen.
> 
> Why are they freaked out by one-developer Linux distros out there?  They
> >don't even have to pay attention to such distros if they don't want to.
> 
> 
> The appearance of the multitudes is an immediate indication that just about
> anyone can make a distro.  If that is the case, then there are obviously
> poor ones.  It just doesn't make the scene look professional.  They
> associate
> that type of outcome with Tu-Cows and that sort of crap-shot of trying
> dozens of software until you find one that doesn't suck.
> 
Sorry, that just doesn't make sense.  They could just as easily go "name
brand" and ignore the rest.  I mean that is like saying because EDS, IBM
and a bazillion "little guys" provide Windows support, the windows
support scene looks unprofessional.  That is just nonsense.  If they
have the risk tolerance and want to go with a little guy, let them.  If
not, they can ignore the little guy and pay lots more to the bug guy.

> >They don't
> >> see Debian mentioned in many press announcements, so
> >> it is difficult to demonstrate how prevalent and robust
> >> Debian really is.
> >>
> >Netcraft is helpful in this respect :-)
> 
> 
> Already done.  HP's announcement of Debian support is the sort of thing
> we need more of.   That is visible to such managers without pointing them
> to some resource - unknown to them - claiming Debian has some
> sort of stats in production.
> 
> >Making things work for current hardware is one of the main
> >> things that will differentiate between a "works for me" type of
> >> distro, and a "works for everybody" well supported distro.
> >>
> >Why?  As I said, other distros have the same problem, they just tend to
> >update more frequently so it is not as visible.
> >
> 
> It's more than just visible.  If you can't install to disk due to the kernel
> being 2 years old, then you need to use some non-standard installation
> method.  This doesn't look good.  With a commercial distro we wouldn't
> have to go to a third party release - the vendor would be providing an
> updated installer a few times per year.

Really?  Is that why RHEL3 (released 10/2003) carries the same kernel
(customized 2.4.21) as the day it was released?

> A standard installer with an
> updated kernel solves everything.  I can't see how it is so difficult to
> accomplish.  The kernel isn't going to effect many applications.
> And as I pointed out, there is a small project that accomplished this.
> Several kernels could be made available on the same boot CDROM
> to keep it a risk free change to the installer.
> 
No change to the installer is risk free.  Plus, if you have a kernel in
the installer, you better be able to support it as the default installed
kernel.  Imagine if you get a "Sarge" installer with kernel 2.6.17 which
installs on your hardware real nice, then only lets you install 2.6.8,
which doesn't work with your SATA chipset (on which your / partition
resides)?  You'd be upset, right?

> In a world where you decide everything, these things are simple.
> 
> In an environment where IT managers with half a clue want to
> help make decisions, the road has to look good before they
> want to go down it.  Seeking installers from outside of the
> Debian project doesn't look good to them.  They are used to
> a world where the good quality vendor takes care of everything.
> 
Again, this fantasy-land which you describe does not exist in the world
of commercial Linux.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

Attachment: signature.asc
Description: Digital signature


Reply to: