Mailing List Archive

Alan Cox wrote:
> > I agree; why CAN'T we configure the linux kernel more like we do the
> > BSD ones? Their code and schema is very elegant and simple. And

> The BSD setup is not end user friendly. There is actually only one
> fundamental end user problem with our current setup. When a user
> says 'I want XYZ' it should turn on everything needed to get XYZ.

> If I hit my capture card option it should turn on i2c,
> video4linux,procfs, etc
Which either means that the user doesn't ever see the option to turn
on i2c, video4linux, procfs, and that behind the scenes those files
are compiled and linked appropriately.
Or, the options automatically turn on once you hit the capture card
option.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Sat, May 27, 2000 at 01:34:21AM +0100, Alan Cox wrote:
> The BSD setup is not end user friendly. There is actually only one fundamental
> end user problem with our current setup. When a user says 'I want XYZ' it
> should turn on everything needed to get XYZ.
What exactly do you call user friendly? I've not built a BSD
kernel, so I can't speak to them. But I'm waiting for a usable,
user-friendly linux kernel system.
I've tried menuconfig, xconfig, and the like. Last I looked,
you had to specifically hunt for what you needed, and it was far from
intuitive what subheadings they lived in. Not to mention the obscure,
interesting, or fun options you can come across.
I went back to "make config" and have happily stayed there. I
never miss an option I never knew I needed, and make oldconfig takes the
pain out of tweaking.
I'm waiting for a user friendly front end for that. It'll
probably be something like debconf, I guess. Or a windows wizard.
If Eric's new system allows me to configure in this way (or in
some way that doesn't hide my possible pratfalls and makes me aware of
what is available), and it makes dropping in a new module, driver, or
plain config choice that much easier, I'm all for it.
Who cares what language he does it in? I don't much like Python
from a programming standpoint (personal prejudice against '\'
continuation lines and what I can do with my whitespace for
readability), but it gets the job done as well as Perl or Pike or
whatnot. A single language for this is better than 7 or so. I have
Python on all my boxes. If you don't like it, reimplement his reference
implementation in C, as has been suggested.
Do not evaulate his proprosal based on his implementation.
Evaluate it on what it can do for the kernel. If we were frozen to one
implementation, we'd be using mbufs.
Joel
--
Life's Little Instruction Book #222
"Think twice before burdening a friend with a secret."
jlbec@evilplan.org
http://zenII.uk.linux.org/~jlbec/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> I've tried menuconfig, xconfig, and the like. Last I looked,
> you had to specifically hunt for what you needed, and it was far from
> intuitive what subheadings they lived in. Not to mention the obscure,
> interesting, or fun options you can come across.
I don't want to seem that kind of guys that likes to push software in
computers
with numeric keypad linked into serial port, but why we need more friendly
then menuconfig or xconfig ?
Not all users need to rebuild the kernel, and if users feels afraid by
*config probably they fall
forgetting some essential driver or feature that makes its machine not
properly working or
even locked down.
Most distro comes with practically all modules precompiled so that adding a
new driver is as easy as editing
a boot file.
Now if such building tool is published as an external ( read very optional )
package that can or can not be installed by means of individuals choice,
it's ok.
The thought to include it into the kernel make me feel a bit depressed.
Davide
--
Feel free, feel Debian !
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

-----BEGIN PGP SIGNED MESSAGE-----
I was thinking more along the lines of the fact I can whip up
a kernel config file with vi; start with some GENERIC and LINT
files, and let us at 'em. I don't object to menuconfig; I'd
just like a bsdconfig. It wouldn't be that much harder to output
a file along the lines of the bsd style than the current
CONFIG_XXX=blah crap is it? So I use menuconfig to get close to
what I want, then use vi and go in and tweak to my hearts content.
--sig--
It isn't true unless it makes you laugh, but you don't
really understand it till it makes you cry.
On Sat, 27 May 2000, Alan Cox wrote:
> The BSD setup is not end user friendly. There is actually only one fundamental
> end user problem with our current setup. When a user says 'I want XYZ' it
> should turn on everything needed to get XYZ.
>
> If I hit my capture card option it should turn on i2c, video4linux,procfs, etc
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOS/AXsK9HT/YfGeBAQH1SwP/eAMsqLW9QUGrnumgqSvrLnvoWe4bQ+Kr
IT7SYZcgIvK7SbMLCDA90hYIEQUYy+pcwXSLPNoD/eIgFLn45aMMeYGLT1WchP1r
HHXYtXIpnTToVl9IOh9jIVPaBsJBcxM1Pps6psuNXAUSEOQOi5KvDIMUQXx4KcON
4kdGWxDM1Nc=
=KxfO
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Hi Rogier.
>>> I agree; why CAN'T we configure the linux kernel more like
>>> we do the BSD ones? Their code and schema is very elegant
>>> and simple.
>> The BSD setup is not end user friendly. There is actually
>> only one fundamental end user problem with our current
>> setup. When a user says 'I want XYZ' it should turn on
>> everything needed to get XYZ.
>> If I hit my capture card option it should turn on i2c,
>> video4linux,procfs, etc
> Which either means that the user doesn't ever see the
> option to turn on i2c, video4linux, procfs, and that
> behind the scenes those files are compiled and linked
> appropriately.
> Or, the options automatically turn on once you hit the
> capture card option.
More likely, "if something is selected that requires these
options to be set a certain way, force them to that, else
ask the user anyway".
Best wishes from Riley.
* Copyright (C) 2000, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Hi Alexander.
> Feel free to join... Another source of fun: take a random
> file from inlude/*/, pick a random prototype defined there,
> grep the tree for said beast. Estimate the probability of
> finding the function in question
> a) called by somebody
> b) defined somewhere
> c) (a) && !(b)
> Admittedly, P(c) is pretty low, but non-zero. P(!b) is
> _far_ from zero.
Also watch out for constructs like the following...
sample.h
#define FOO BAZ
void FOO (void);
sample.c
void BAZ (void) {
:
}
Yes, I have come across programs doing tricks like that. I'm not
aware of any occurrances of it in the kernel source, but it
wouldn't surprise me...
Best wishes from Riley.
* Copyright (C) 2000, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> only partially applied. Advansys.c was the part that wasn't applied. I
> can shave off almost 100k from it by dropping stuff for earlier that
> 2.2.x.
Advansys maintain the driver as a single common module. Last I heard they
wanted it left like it is, and since they do the maintaining who are we
to bitch 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Austin Schutz <tex@gblx.net> said:
> On Wed, May 24, 2000 at 09:25:18PM -0600, Neil Schemenauer wrote:
[...]
> > Especially since freeze requires the entire source for the Python
> > interpreter (unless freeze has been significantly since I last
> > looked at it).
> This is a critical point. How big is this stuff frozen?
Any extra libraries (as is the case when you compile Perl)?
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Fri May 26, 2000 at 09:32:17PM -0400, Eric S. Raymond wrote:
> The tty mode of CML2 gives you this kind of feedback when you hit a
> constraint violation. I'm working on making the feedback more informative.
>
> Again, this is the sort of thing that requires an atemporal, declarative
> view of the world rather than a temporal, imperative one. Which is why
> the change to the CML2 language is really important -- it makes doing
> dselect-like things possible.
Both dselect and apt work to perform the job of installing applications while
managing antecedent dependancies and conflicts, but neither dselect are apt
were written in CML2. Both were written in C++, and the source code is freely
available.
-Erik
--
Erik B. Andersen Web: http://www.xmission.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox said once upon a time (Sat, 27 May 2000):
> Our relationships are heirarchical so you can build a dependancy graph and
> then recursively backtrack to find the dependancies.
>
> Alan
Not in all cases. The other day teaching I found there is a something
under "Character devices/Video For Linux" which depends on sound being
built. It was during class, so I didn't have the time track down exactly
which driver it was. This was with the kernel source that ships Red Hat
6.2 (I bet the non-heirarchical dependancy exists in the regular kernel
too).
Dax Kelson
Guru Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

George (greerga@nidhogg.ham.muohio.edu) writes:
> Since when do you link your kernel with Xlib?
Oh, I see your point. No, if Xlib is linked with any utilities I try to
provide with the kernel, I have to include Xlib as well, and it's not feasible
to do tha on a floppy-based router.
--
Ed Carp, N7EKG erc@pobox.com 940/367-2744 cell phone
http://www.pobox.com/~erc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

andersen@xmission.com (Erik Andersen) wrote on 27.05.00 in <20000527100039.A758@xmission.com>:
> On Fri May 26, 2000 at 09:32:17PM -0400, Eric S. Raymond wrote:
> > The tty mode of CML2 gives you this kind of feedback when you hit a
> > constraint violation. I'm working on making the feedback more
> > informative.
> >
> > Again, this is the sort of thing that requires an atemporal, declarative
> > view of the world rather than a temporal, imperative one. Which is why
> > the change to the CML2 language is really important -- it makes doing
> > dselect-like things possible.
>
> Both dselect and apt work to perform the job of installing applications
> while managing antecedent dependancies and conflicts, but neither dselect
> are apt were written in CML2. Both were written in C++, and the source code
> is freely available.
C++ is bad, too. Not bad in the same way as Python, but I don't want to
choose.
Anyway.
Both dselect and apt *do* use a declarative language like CML2. It's the
stuff you find, for example, in Packages files (or debian/control or /var/
lib/(dpkg/available). The syntax is stolen from the RFC-822 mail syntax.
And apt-get also compiles the stuff into a binary database. There are
really a lot of parallels here.
The Debian dependencies are written in control file syntax, not in C++.
The (proposed) kernel dependencies are written in CML2, not in Python.
Oh, and there exist implementations of control file syntax in Perl at
least :-)
Oh, and yet another footnote. Perl *is* compilable into C, in the same way
as Python is. "perl -MO=C source" or "perl -MO=CC source" will do it. (See
the man pages of B::C and B::CC for details.)
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

In article <linux.kernel.3930881C.AD2F1891@quark.vpplus.com>,
Brian Gerst <bgerst@quark.vpplus.com> wrote:
>Alan Cox wrote:
>>
>> > only partially applied. Advansys.c was the part that wasn't applied. I
>> > can shave off almost 100k from it by dropping stuff for earlier that
>> > 2.2.x.
>>
>> Advansys maintain the driver as a single common module. Last I heard they
>> wanted it left like it is, and since they do the maintaining who are we
>> to bitch 8)
>
>With all the junk still from kernels as ancient as 1.2.x? Ugh. That
>driver is the single largest C file in the kernel, weighing in at 687k.
>If they feel they need to maintain the drivers for kernels that old then
>the source is still available in the old kernel's tarball. There comes
>a point when we can't continue to carry this cruft forward anymore.
``we'' aren't carrying this cruft forward. _Advansys_ is carrying
this cruft forward, and if they want to properly maintain their
device drivers why stop them from doing so? Their code would
probably be a lot smaller if there was a published stable device
driver interface, but that's not going to ever happen in the
baseline kernel, so there's nothing that can be done about it.
____
david parsons \bi/ Pity the UDI people seem to have trainwrecked.
\/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox wrote:
>
> > only partially applied. Advansys.c was the part that wasn't applied. I
> > can shave off almost 100k from it by dropping stuff for earlier that
> > 2.2.x.
>
> Advansys maintain the driver as a single common module. Last I heard they
> wanted it left like it is, and since they do the maintaining who are we
> to bitch 8)
With all the junk still from kernels as ancient as 1.2.x? Ugh. That
driver is the single largest C file in the kernel, weighing in at 687k.
If they feel they need to maintain the drivers for kernels that old then
the source is still available in the old kernel's tarball. There comes
a point when we can't continue to carry this cruft forward anymore.
--
Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On 27 May 2000, Kai Henningsen wrote:
> > Both dselect and apt work to perform the job of installing applications
> > while managing antecedent dependancies and conflicts, but neither dselect
> > are apt were written in CML2. Both were written in C++, and the source code
> > is freely available.
>
> C++ is bad, too. Not bad in the same way as Python, but I don't want to
> choose.
>
> Anyway.
>
> Both dselect and apt *do* use a declarative language like CML2. It's the
> stuff you find, for example, in Packages files (or debian/control or /var/
> lib/(dpkg/available). The syntax is stolen from the RFC-822 mail syntax.
>
> And apt-get also compiles the stuff into a binary database. There are
> really a lot of parallels here.
>
> The Debian dependencies are written in control file syntax, not in C++.
> The (proposed) kernel dependencies are written in CML2, not in Python.
>
But we don't want a tool like dpkg/dselect: complex to mantain, hard to
add features and impossible to have it bug-free.
I think that CML2 with Python is a step better that dselect (also because
it has simpler rules: no version checking,...).
giacomo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

cate@neper.ethz.ch (Giacomo Catenazzi) wrote on 28.05.00 in <Pine.LNX.4.21.0005281022020.18157-100000@neper.ethz.ch>:
> On 27 May 2000, Kai Henningsen wrote:
> > The Debian dependencies are written in control file syntax, not in C++.
> > The (proposed) kernel dependencies are written in CML2, not in Python.
> But we don't want a tool like dpkg/dselect: complex to mantain, hard to
> add features and impossible to have it bug-free.
There's two reasons for that:
(1) Programming style
(2) Circular and versioned dependencies
(2) is not a problem for the kernel, and (1) is certainly avoidable.
> I think that CML2 with Python is a step better that dselect (also because
> it has simpler rules: no version checking,...).
Compare with apt-get, not dselect. Dselect is *old*. Much has been learned
since it was written.
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

rhw@MemAlpha.cx (Riley Williams) wrote on 27.05.00 in <Pine.LNX.4.21.0005271419140.2428-100000@Consulate.UFP.CX>:
> >>> I agree; why CAN'T we configure the linux kernel more like
> >>> we do the BSD ones? Their code and schema is very elegant
> >>> and simple.
>
> >> The BSD setup is not end user friendly. There is actually
> >> only one fundamental end user problem with our current
> >> setup. When a user says 'I want XYZ' it should turn on
> >> everything needed to get XYZ.
>
> >> If I hit my capture card option it should turn on i2c,
> >> video4linux,procfs, etc
>
> > Which either means that the user doesn't ever see the
> > option to turn on i2c, video4linux, procfs, and that
> > behind the scenes those files are compiled and linked
> > appropriately.
>
> > Or, the options automatically turn on once you hit the
> > capture card option.
>
> More likely, "if something is selected that requires these
> options to be set a certain way, force them to that, else
> ask the user anyway".
Or, better:
"You just selected the video capture card option. This depends on the i2c,
video4linux, and procfs options, which are currently not selected.
Choose: (a) turn on the i2c, video4linux, and procfs options
(b) turn off the video capture card option"
MfG Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On 28 May 2000, Kai Henningsen wrote:
> cate@neper.ethz.ch (Giacomo Catenazzi) wrote on 28.05.00 in
> <Pine.LNX.4.21.0005281022020.18157-100000@neper.ethz.ch>:
>
> > On 27 May 2000, Kai Henningsen wrote:
>
> > > The Debian dependencies are written in control file syntax, not in C++.
> > > The (proposed) kernel dependencies are written in CML2, not in Python.
>
> > But we don't want a tool like dpkg/dselect: complex to mantain, hard to
> > add features and impossible to have it bug-free.
>
> There's two reasons for that:
>
> (1) Programming style
> (2) Circular and versioned dependencies
>
> (2) is not a problem for the kernel, and (1) is certainly avoidable.
Do we REALLY want to avoid programming style?! :-)
> > I think that CML2 with Python is a step better that dselect (also because
> > it has simpler rules: no version checking,...).
>
> Compare with apt-get, not dselect. Dselect is *old*. Much has been learned
> since it was written.
I'm all in favour of a new configuration system, anyway, and CML2 looks
like it fits the bill pretty well. Having the first implementation written
in Python shouldn't be too much of a problem; if someone really needs
another implementation later, no doubt it will get written soon enough.
Right now, IMO, the important thing is to get something which actually
works, even if it's written in Word macros...
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> > >> If I hit my capture card option it should turn on i2c,
> > >> video4linux,procfs, etc
> >
> > > Which either means that the user doesn't ever see the
> > > option to turn on i2c, video4linux, procfs, and that
> > > behind the scenes those files are compiled and linked
> > > appropriately.
> >
> > > Or, the options automatically turn on once you hit the
> > > capture card option.
> >
> > More likely, "if something is selected that requires these
> > options to be set a certain way, force them to that, else
> > ask the user anyway".
>
> Or, better:
>
> "You just selected the video capture card option. This depends on the i2c,
> video4linux, and procfs options, which are currently not selected.
>
> Choose: (a) turn on the i2c, video4linux, and procfs options
> (b) turn off the video capture card option"
(c) show me what else needs i2c, video4linux, and procfs in a hierarchical tree
This could help newbies and experts alike explore options in the kernel and how they interrelate. I've always wanted to do this with Debian packages, maybe just for the "cool" value of it.
And hey, another opportunity to be cooler than Microsoft :) And not that hard to code, too!
Kenneth
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Fri, May 26, 2000 at 08:37:04PM -0700, david parsons wrote:
> The whoops-time-to-fork-the-linux-kernel showstopper for me is that
> the reference implementation of this new configuration language is
> written in Python, and, given the fluidity of linux kernel
That's not even funny. If you want to fork the kernel because of 1 buildtime
dependency, your priorities are messed up badly.
Regards,
bert hubert.
--
| http://www.rent-a-nerd.nl
| - U N I X -
| Inspice et cautus eris - D11T'95
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Kenneth C. Arnold <kcarnold@yahoo.com>:
> > "You just selected the video capture card option. This depends on the i2c,
> > video4linux, and procfs options, which are currently not selected.
> >
> > Choose: (a) turn on the i2c, video4linux, and procfs options
> > (b) turn off the video capture card option"
>
> (c) show me what else needs i2c, video4linux, and procfs in a hierarchical tree
>
> This could help newbies and experts alike explore options in the kernel and how they interrelate. I've always wanted to do this with Debian packages, maybe just for the "cool" value of it.
I'm working on this now.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
No one who's seen it in action can say the phrase "government help" without
either laughing or crying.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

** On May 27, Ed Carp scribbled:
> George (greerga@nidhogg.ham.muohio.edu) writes:
>
> > Since when do you link your kernel with Xlib?
>
> Oh, I see your point. No, if Xlib is linked with any utilities I try to
> provide with the kernel, I have to include Xlib as well, and it's not feasible
> to do tha on a floppy-based router.
Geez, man! How in a world would you like to compile a 90MB source tree on a
floppy router?? First show us a way to do that, then moan about Xlib.
marek
<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
<!-- attachment="01-part" -->
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

In article <linux.kernel.20000529010106.A21839@home.ds9a.nl>,
bert hubert <ahu@ds9a.nl> wrote:
>On Fri, May 26, 2000 at 08:37:04PM -0700, david parsons wrote:
>
>> The whoops-time-to-fork-the-linux-kernel showstopper for me is that
>> the reference implementation of this new configuration language is
>> written in Python, and, given the fluidity of linux kernel
>
>That's not even funny.
It's not funny. If the kernel ceases to be buildable, *I can't use it*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On 29 May 2000, david parsons wrote:
> In article <linux.kernel.20000529010106.A21839@home.ds9a.nl>,
> bert hubert <ahu@ds9a.nl> wrote:
> >On Fri, May 26, 2000 at 08:37:04PM -0700, david parsons wrote:
> >
> >> The whoops-time-to-fork-the-linux-kernel showstopper for me is that
> >> the reference implementation of this new configuration language is
> >> written in Python, and, given the fluidity of linux kernel
> >
> >That's not even funny.
>
> It's not funny. If the kernel ceases to be buildable, *I can't use it*
The Python code can be "frozen" into C, so you only need Python if you
modify the Python source - a bit like autoconf. If you are trying to build
a kernel without access to a C compiler, good luck to you - otherwise,
what's the problem?
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Marek Habersack (grendel@vip.net.pl) writes:
> ** On May 27, Ed Carp scribbled:
> > George (greerga@nidhogg.ham.muohio.edu) writes:
> >=20
> > > Since when do you link your kernel with Xlib?
> >=20
> > Oh, I see your point. No, if Xlib is linked with any utilities I try to
> > provide with the kernel, I have to include Xlib as well, and it's not fea=
> sible
> > to do tha on a floppy-based router.
> Geez, man! How in a world would you like to compile a 90MB source tree on a
> floppy router?? First show us a way to do that, then moan about Xlib.
Oh, *please*. You don't *develop* on a floppy-based system...but you have to
include Xlib with your executables.
Are you being deliberately dense, or is it that you don't understand how
dynamic libraries work?
--
Ed Carp, N7EKG erc@pobox.com 940/367-2744 cell phone
http://www.pobox.com/~erc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/