> In what universe is this a "simple tool" with "well defined inputs and 
> outputs"?

ls is a good example of a program that *doesn't* have well-defined 
outputs, in the sense that scripts should never rely on parsing ls 
output. ls is supposed to have *human-readable* output.

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Ah yes, but in Unix land, a device driver is counted as part of the 
>> kernel. ;-)
> 
>   There are many pros in monolithic kernels. Of course there are cons,
> but many people believe that the pros outweight the cons in this case.

I just prefer being able to add new drivers without having to recompile 
the kernel and reboot the machine - but that's just me...

OOC, what are the benefits?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

>   Autoconf exists because not all systems have the same tools or libraries
> installed, nor all systems have the same versions of those tools/libraries.

As far as I can tell, autoconf exists because some systems use BSD awk 
and others use GNU awk, and the two aren't precisely compatible. 
Multiply this by the 50,000 other tiny utilities you may or may not need 
to set up this program and you have a configuration nightmare so bad it 
requires an automated tool to make things remotely tractable.

And it seems to me that most of this has happened because the entire 
system has been poked and prodded by so many different people over time 
that you now have a huge tangled mass of different implementations all 
of which are only semi-compatible.

>   Autoconf also exists because computer architectures are different.
> For instance, some architectures may be little-endian while others are
> big-endian. Some architectures may be 32-bit while others are 64-bit.

Shouldn't the compiler be dealing with those issues?

>   Portability is a key feature of unix-like systems.

That I don't have a problem with... ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> Warp wrote:
>>   Autoconf also exists because computer architectures are different.
>> For instance, some architectures may be little-endian while others are
>> big-endian. Some architectures may be 32-bit while others are 64-bit.
> 
> Shouldn't the compiler be dealing with those issues?

No. If the compiler "dealt" with little endian and big endian, by making 
the C code always see one or the other, it would make the other 
architecture much slower.

Also, the C standard only mentions minimum sizes for data types. A 
compliant C implementation may have 64-bit bytes if it wants to.

Post a reply to this message

>> Shouldn't the compiler be dealing with those issues?
> 
> No. If the compiler "dealt" with little endian and big endian, by making 
> the C code always see one or the other, it would make the other 
> architecture much slower.

What I meant was, shouldn't the programmer be able to just write their 
program, and let the compiler generate the correct code depending on the 
actual processor architecture?

But then, since C is little more than semi-portable machine code, I 
guess that would be quite hard to do.

> Also, the C standard only mentions minimum sizes for data types. A 
> compliant C implementation may have 64-bit bytes if it wants to.

IOW, the C standard is insane. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> Shouldn't the compiler be dealing with those issues?
>>
>> No. If the compiler "dealt" with little endian and big endian, by 
>> making the C code always see one or the other, it would make the other 
>> architecture much slower.
> 
> What I meant was, shouldn't the programmer be able to just write their 
> program, and let the compiler generate the correct code depending on the 
> actual processor architecture?
> 
> But then, since C is little more than semi-portable machine code, I 
> guess that would be quite hard to do.

Of course there is a lot of code that can be written without caring 
about endianness. In which case you wouldn't tell autoconf to do that check.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I just prefer being able to add new drivers without having to recompile 
> the kernel and reboot the machine - but that's just me...

  I have never had to recompile the kernel or reboot the machine because
of requiring a new driver.

  man modprobe

> OOC, what are the benefits?

  For example, the interfaces and protocols between the kernel and the
drivers can be modified easily without having to worry about backwards
compatibility. If an existing interface or protocol results to be a bad
design choice, or it results to have some inefficiencies in a newer
architecture, they can all be changed without problems. Basically, the
kernel is not burdened with backwards compatibility issues with regard
to drivers.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:

> >   Autoconf exists because not all systems have the same tools or libraries
> > installed, nor all systems have the same versions of those tools/libraries.

> As far as I can tell, autoconf exists because some systems use BSD awk 
> and others use GNU awk, and the two aren't precisely compatible. 

  In other words, autoconf exists to increase portability. My point exactly.

> Multiply this by the 50,000 other tiny utilities you may or may not need 
> to set up this program and you have a configuration nightmare so bad it 
> requires an automated tool to make things remotely tractable.

  You seem to have quite many nightmares others don't.

> >   Autoconf also exists because computer architectures are different.
> > For instance, some architectures may be little-endian while others are
> > big-endian. Some architectures may be 32-bit while others are 64-bit.

> Shouldn't the compiler be dealing with those issues?

  There are some cases were endianess matters, especially if you are trying
to write low-level efficient code.

  A concrete example which I remember where the program has to behave
differently depending on endianess is mplayer. The source code has to
know the endianess of the target system in order to be able to write
bytes in the proper order.
  (Sure, the code could have been written so that endianess doesn't matter,
but then it wouldn't have been so efficient.)

-- 
                                                          - Warp

Post a reply to this message

>> I just prefer being able to add new drivers without having to recompile 
>> the kernel and reboot the machine - but that's just me...
> 
>   I have never had to recompile the kernel or reboot the machine because
> of requiring a new driver.
> 
>   man modprobe

No - but it *is* fun if you try to install some device driver that needs 
to be compiled from source and you don't have the kernel headers 
installed. (Whereas on Windoze you just install the driver - and hope to 
God that PnP actually does what it's meant to...)

I had great fun trying to get the nVidia graphics drivers to actually 
blinking work...

>> OOC, what are the benefits?
> 
>   For example, the interfaces and protocols between the kernel and the
> drivers can be modified easily without having to worry about backwards
> compatibility.

Mmm, OK. I can see how that would be useful...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Mon, 10 Mar 2008 10:07:04 +0000, Invisible wrote:

> The trouble with Linux is that everything is 50,000 utterly *tiny*
> pieces, each of which does almost nothing useful by itself, and you have
> to put thousands of these tiny pieces together to do anything useful.

Well, that's a fallacy right there.  I'm running a monolithic application 
at the moment called "pan", which is a newsreader.

I've got another fairly monolithic application called "firefox" running 
in the background, and another called "OpenOffice" that's at the 
standby.  Also one called "Pidgin" which is an IM client.

None of these apps particularly *requires* any of the standard command-
line utilities on my OS for anything short of building it (if I should 
desire to do so).

Jim

Post a reply to this message