[plug] kernels and Debain versions

[Sham Chukoury]

On Sun, 2004-03-21 at 15:16, smclevie wrote:

> Q2.  Is a Debian 'suite' limited or best suited to any version of
> kernel?
>         eg.  is 'stable' limited to say kernels 2.2.20 through to
> 2.4.24 ?
>         this would imply that if you want to use the latest kernels
> you should be running 'testing' ...

More or less, yeah.. Running closer to the Debian bleeding edge (Deb
unstable) means that running the latest kernel is usually painless,
since it has the userspace stuff needed to support that kernel. :P
Running a recent kernel on a stable version of Debian shouldn't be too
hard if you know what userspace tools the kernel needs.


> Q3.  During a kernel build, one can select a large number of options
> in menuconfig ... 
>         But how do you know what options are the same as the option in
> a previous kernel??
>         eg say in kernel 2.4.24 an option equates to thingymejig.o
> .... 
>         what in kernel 2.6.4 equates to thingamejig.o ???
>         Do you then have to inspect/compare the config file in /boot
> all the time?
>         This file is never twice the same !!!  It is a real
> organisational mess !!!

As far as I know, the config files are consistent. I always build new
kernels based on my old kernel configs, then save the new config for
later reference. Of course, this doesn't apply to major kernel version
changes. :) When moving from 2.4.23 to 2.6.0, I didn't load my 2.4.23
config file into the 2.6.0 menuconfig, since I suspected the config
system had undergone major changes since 2.4.*. So I did the 2.6.0
config from scratch, with the 2.4.23 config loaded in a separate
(2.4.23) menuconfig in another term - for reference. :P Took a while..
but hey, once it was done, I had a new config base for my 2.6.* kernel
builds. :)

I wouldn't recommend comparing config files, in order to configure a new
kernel build - menuconfig is much more user friendly.


> This whole process of doing Linux has shown me more than ever how hard
> it is to polish a product and present it well.
> (I saw Onno's comments about 2.6.4 albeit briefly before accidentally
> deleting)
> It is clearly obvious that because you can program does not mean you
> know how to make it useable.
> The point-of-view from the programmer is very different than the POV
> of the end-user (Bob User).

Usability is not a simple issue... It's not an issue of "hey, let's just
make a very cool gui and so it will be usable, since people can just
point and click!" There's a heap of observations and assumptions that
have to be taken into account, when trying to make something usable...
The interface has to be as flexible as possible, to allow advanced users
to do stuff their own way, while keeping the process as simple as
possible, for those less experienced users.

It's true that programmers don't necessarily take into account the
user's point of view. That's especially since the programmer might have
written the program for his own personal use, in the first place, and
made the interface to be such that he/she was most comfortable with it.
This poses problems for other people who use the program, since they are
not familiar with the interface.


> Take a look at the new Sarge beta 3 installer !!  What a mess... same
> old same old and even MORE involved !!
> To partition a hard drive into 10 partitions you need to go through
> some 20 - 30 screens !!
> 
> Take a look at the Mandrake installer for a comparison... One
> higher-res screen with mouse.

As I said above.. a higher res gui won't necessarily solve the usability
issue. :) To make a simple and effective installer, it would take
someone who understands the installation process quite well. From that
understanding, the person would then come up with an interactive
'script' to take the user through the process. When I say 'script' in
this context, I don't mean "Shell script" - think of it more in the
context of movie script, or storyline.. except it's interactive. :)
(Multimedia, anyone?) The script could be made 'smart', or 'dumb'. A
dumb script is one which would throw stacks of technical details at the
user, or even one which would abstract the process entirely, making big
assumptions along the way (thus, not flexible). A smart script, on the
other hand, would be more adaptable to the user - perhaps by organising
information efficiently on the screen. The obvious stuff would be on the
screen, with advanced technical details not assumed and abstracted away,
but neatly tucked away, simply waiting for the user to ask for it. Thus,
the user would be able to 'talk' to the script easily - the script would
approach the user with a friendly interface, asking simple questions,
then the user would interact with the script at his/her own skill
level...

More interesting discussion of human-computer interfaces (and the CLI vs
GUI issue) --> http://osnews.com/story.php?news_id=6282


> There seems to be a real time warp situation happening.. an
> ideological black hole or something...

What do you mean by that?

§:)