On Sun, 12 Jan 2003, Alex Chudnovsky wrote:

> On Saturday 11 January 2003 21:28, Tzafrir Cohen wrote:
> >
> > And re-install all of your programs. And hopefully you have your config
> > saved.
>
> Talking about re-installation of Windows here, not Linux.

Me too. What about all of your configuration there? Or do you give it up
in advance?

If so: an equivalent (and faster) linux solution would be a kick-start
installation...

> > > > Basically, all this keeps LINUX as an OS for **experts**.
> > >
> > > IMHO, what is required to bring Linux out of the expert OS niche, is :
> > > - Vendor-supplied hardware drivers , no matter if binary or not, or at
> > > the very least open specifications. And please stop telling me all this
> > > nonsense about "And what if vendor decides to stop supporting those
> > > drivers?" And what if the hardware is rare and those who have it, can't
> > > write code? And why should we the users wait several years till the
> > > drivers are there? I personally prefer working hardware and then all
> > > these freedom principles, but YMMV.
> >
> > Anybody here with ADSL modems that are not supported under win98?
>
> At least if you happen to have recent Windows, you haven't to wait several
> years for Linux community to reverse-engineer the driver.

What is the market share of those unsupported OSs?

FYI, linux 2.0 is still maintained.

> >
> > What about the (pctel?) binary-only winmodem drivers that required you to
> > move back to a sepecific, obsolete, and insecure kernel just to be
> > connected to the internet? (I usually want to make sure I have a fixed
> > kernel when I connect to the internet)
>
> Vote with your purse - don't purchase such modem, if the vendor doesn't have a
> driver for your particular distribution ( or for your particular version of
> Windows). Or purchase it and wait several years for the driver to be
> reverse-engineered ( this may never happen ).

The particilar cas I'm talking about is one in which the original vendor
no longer existed.

> >
> > Do you know how many people had to compile their kernel just because of
> > those binary-only drivers?
>
> Blame kernel developers for that - the kernel has NO INTERFACE to accept
> binary third-party drivers.

I don't want to blame them for producing a better kernel. I don't want to
blame them for breaking unnecessary legacy cruft to remove some of the
existing bloat.

> In my book, it's a serious obstacle.
> IMHO, hardware vendor support for Linux is necessary for Linux to become
> mainstream desktop system.
> There are three ways for a hardware vendor to provide such support- either the
> vendor publishes the specs or it writes a binary driver or it writes an
> open-source driver.
> In the first case, the hardware would be supported in any Linux kernel, but
> you as a user have to face a good bit of delay till the driver be actually
> written.

Unless the venor actually writes the driver. Recall that it is the vendor
interested in selling hardware, just as much  (or even more than) you
interested in buying it.

This mean also that this vendor is the only one wit the full source to
your kernel (and thus the only one in a good position to give you support)

> > > - Sensible defaults. You shouldn't dig around a ton of configuration
> > > files just to get something simple to work. You may tweak it later, but
> > > it should work out of the box. This is getting better, but it isn't there
> > > yet.
> >
> > IMHO it's quite there. Care to give an example?
>
> XFree86 configuration. Change a monitor from 17" to some old 14" ( say your
> monitor is broken) and risk just damaging the 14" one or X failing to start.
> Or change a mouse from PS\2 one to USB one. The values are hardcoded into the
> configuration file leaving no way for autodetection. Stupidity at its best,
> pure and simple.

What about your distro's X config tools? Last time I tried, Mandrake's
DrakeX was useful enough. It is also run at install time.

> > > I use Mandrake too. While overall it is a very good distro, part of their
> > > Drak* tools are actually exactly what I've described - half-baked
> > > underdeveloped POS,
> >
> > Example, please?
> DrakConnect.
> >
> > > sorry for being brutal. It's actually a lot easier to
> > > comprehend and tune configuration files by hand then to use these tools.
> > > Let's formulate it like the following : for anything that goes inside a
> > > distro, if it includes a configuration file, there must be some GUI tool
> > > to configure it. And this GUI tool should be INTEGRATED with another
> > > configuration tools.
> >
> > Mandrake's tools (almost all) run both in X and in full-screen terminal
> > mode. All of them are availble from the main "control panel" and from the
> > menus.
>
> And you still have KDE control center, GNOME control center and Mandrake
> control center, with overlapping functions. OK, there are tools in the Cooker
> enabling embedding drak* tools into the KDE control center.

The lapping functionalities are (IMHO) because the kde and gnome
control-centers should have nothing to do with system-administration.

> >
> > A GUI tool should not be there to configure a file, because the end user
> > should not be assumed to know that this file is needed in the first place.
> > The tool is needed to help the user configure something (printer,
> > networking, etc.).
>
> What I've tried to say is that there must be a GUI tool wherever there is a
> configuration file. "It" in "GUI tool to configure it" means "a software
> package", "anything that goes into a distro". There should be a GUI tool to
> configure a printer. A GUI tool to configure SAMBA. A GUI tool to configure
> ANYTHING.

What is lacking in Mandrake and in RedHat?

> >
> > The approach of MAndrake is quite different: Currently debian is lacking
> > in the "setup tools" department. But it has a standard interface for
> > packages to configure themselves: debconf. Each package can present the
> > user a series of questions (depending on the level of questions the ser
> > asked in advanced to be asked), and configures itself accordingly.
>
> That's not all. The package should know to RECONFIGURE itself in case the
> environment changes. Once more, XFree86 doesn't know that, for example.
>

In Mandrake, if your X server fails and you run under {g|k}dm, you are
offered a number of options. One of which is to run DrakeX, IIRC.

I don't think that kudzu can detect a change of the screen, though.

Debian does not have a proper XFree configuration handling

-- 
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
http://www.technion.ac.il/~tzafrir


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to