🚀 go-pugleaf

On 2018-04-24, Charles Richmond <nume...@aquaporin4.com> wrote:

> The Tahoe architecture and the DEC Alpha architecture both are much 
> nicer on the assembly level than the x86 architecture.  Not many here 
> would disagree with that. Why does Intel *not* produce modern versions 
> of those architectures and PC makers use those???
>
> Most of modern software can be re-compiled for the new instruction sets.
>
> Tell me why Intel should *not* adopt these architectures; not really why 
> Intel does not...

I suspect that the answer begins with a dollar sign.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

If some PC maker used a different architecture chip for its new 
computer, then I would have to buy new copies of software for it. 
Software is not usually sold as source code. That would be too easy to pirate.

On 24 Apr 2018 19:52:13 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
wrote:

>On 2018-04-24, Charles Richmond <nume...@aquaporin4.com> wrote:
>
>> The Tahoe architecture and the DEC Alpha architecture both are much 
>> nicer on the assembly level than the x86 architecture.  Not many here 
>> would disagree with that. Why does Intel *not* produce modern versions 
>> of those architectures and PC makers use those???
>>
>> Most of modern software can be re-compiled for the new instruction sets.
>>
>> Tell me why Intel should *not* adopt these architectures; not really why 
>> Intel does not...
>
>I suspect that the answer begins with a dollar sign.

It does but not the way you mean.  Windows NT runs on Alpha,  i860,
MIPS R4000, PowerPC, Itanium, and SPARC.  None of them except x86
developed enough sales to pay for continued development.  So the
dollar sign is in the cost of continuing to develop for a dead
platform.

On 04/24/2018 07:53 PM, J. Clarke wrote:
> It does but not the way you mean.  Windows NT runs on Alpha,  i860,
> MIPS R4000, PowerPC, Itanium, and SPARC.

Windows NT is from Microsoft, not Intel.

You also missed x86 and x86_64 (or x64 if you prefer).

Note:  Intel makes three of those architectures:  x86 (x64), i860 
(i960), and Itanium.



-- 
Grant. . . .
unix || die

On 04/24/2018 02:13 PM, Quadibloc wrote:
> If some PC maker used a different architecture chip for its new computer, 
> then I would have to buy new copies of software for it.  Software is 
> not usually sold as source code. That would be too easy to pirate.

DEC released FX!32 to run x86 (Win32) programs on Windows NT on alpha.

Windows NT 4.x shipped with binaries for multiple architectures on the 
same CD-ROM and used the same CD-KEY.



-- 
Grant. . . .
unix || die

On Tue, 24 Apr 2018 21:27:28 -0600, Grant Taylor
<gta...@tnetconsulting.net> wrote:

>On 04/24/2018 07:53 PM, J. Clarke wrote:
>> It does but not the way you mean.  Windows NT runs on Alpha,  i860,
>> MIPS R4000, PowerPC, Itanium, and SPARC.
>
>Windows NT is from Microsoft, not Intel.
>
>You also missed x86 and x86_64 (or x64 if you prefer).

They are assumed.

>Note:  Intel makes three of those architectures:  x86 (x64), i860 
>(i960), and Itanium.

And of those the only one that sells is x86.  So come up with a
convincing argument that some other architecture will actually sell
enough units to be worth the cost of development.

On 04/24/2018 01:43 PM, Charles Richmond wrote:
> The Tahoe architecture and the DEC Alpha architecture both are much 
> nicer on the assembly level than the x86 architecture.  Not many here 
> would disagree with that. Why does Intel *not* produce modern versions 
> of those architectures and PC makers use those???

I'm not familiar with Tahoe and can't comment.

Alpha was developed by DEC, purchased by Compaq and subsequently HP. 
Thus HP owns the Intellectual Property of the Alpha CPUs.  —  At least 
the portion that did not get sold off to other companies.  —  I would be 
somewhat surprised if there aren't pieces of Alpha architecture deep in 
the bowels of other CPU architectures.

I'm not a programmer myself, much less an assembly programmer, so I 
can't say with confidence.  But it is my understanding that the PDP / 
VAX were meant to be nice to the assembly programmers.  x86, not so much so.

IMHO, x86 is the Ethernet of CPU architectures, cheap, easy, (made to 
be) fast, prolific.  None of those things mean that they are superior. 
(Speed is debatable.)

Intel does not own the Intellectual Property nor are they likely to 
license it.

Also, what would a modern version of the aforementioned CPUs be.  I 
suspect the x86 architecture is quite a bit different now compared to 
what it was in the mid '90s.

All of the systems I ever saw that used the other architectures were at 
least one order of magnitude more expensive than the x86 machine, if not 
multiples there of.  So why would PC manufacturers who habitually target 
SOHO users that won't pay for more expensive systems want to try to 
peddle more expensive systems?

Especially when web scale companies have proven that thousands of lower 
end architectures (compared to the aforementioned alternatives) can 
scale and be quite economical for massive computation.

> Most of modern software can be re-compiled for the new instruction sets.

Recompiling is a possibility.  But it's not a likely path.

> Tell me why Intel should *not* adopt these architectures; not really why 
> Intel does not...

Because Intel can't do it legally.  Not without buying / licensing 
intellectual property.

There is another CPU architecture that is actually similar to the 
aforementioned architectures that is in fact revolutionizing the 
industry.  ARM.<CPU drop>



-- 
Grant. . . .
unix || die

On 04/24/2018 09:33 PM, J. Clarke wrote:
> And of those the only one that sells is x86.  So come up with a
> convincing argument that some other architecture will actually sell
> enough units to be worth the cost of development.

ARM

It's my understanding that Windows will run on a Raspberry Pi 3 which 
has an ARM v8 CPU.



-- 
Grant. . . .
unix || die

Grant Taylor wrote:

> Alpha was developed by DEC, purchased by Compaq and subsequently HP.
> Thus HP owns the Intellectual Property of the Alpha CPUs.

Which it subsequently sold to Intel

> I would be somewhat surprised if there aren't pieces of Alpha
> architecture deep in the bowels of other CPU architectures.

AMD licensed the alpha's EV6 bus

On 25/04/2018 04:43, Grant Taylor wrote:
> On 04/24/2018 01:43 PM, Charles Richmond wrote:
>> The Tahoe architecture and the DEC Alpha architecture both are much 
>> nicer on the assembly level than the x86 architecture.  Not many here 
>> would disagree with that. Why does Intel *not* produce modern versions 
>> of those architectures and PC makers use those???
> 
> I'm not familiar with Tahoe and can't comment.
> 
> Alpha was developed by DEC, purchased by Compaq and subsequently HP. 
> Thus HP owns the Intellectual Property of the Alpha CPUs.  —  At least 
> the portion that did not get sold off to other companies.  —  I would be 
> somewhat surprised if there aren't pieces of Alpha architecture deep in 
> the bowels of other CPU architectures.
> 
> I'm not a programmer myself, much less an assembly programmer, so I 
> can't say with confidence.  But it is my understanding that the PDP / 
> VAX were meant to be nice to the assembly programmers.  x86, not so much 
> so.
> 
> IMHO, x86 is the Ethernet of CPU architectures, cheap, easy, (made to 
> be) fast, prolific.  None of those things mean that they are superior. 
> (Speed is debatable.)
> 
> Intel does not own the Intellectual Property nor are they likely to 
> license it.
> 
> Also, what would a modern version of the aforementioned CPUs be.  I 
> suspect the x86 architecture is quite a bit different now compared to 
> what it was in the mid '90s.
> 
> All of the systems I ever saw that used the other architectures were at 
> least one order of magnitude more expensive than the x86 machine, if not 
> multiples there of.  So why would PC manufacturers who habitually target 
> SOHO users that won't pay for more expensive systems want to try to 
> peddle more expensive systems?
> 
> Especially when web scale companies have proven that thousands of lower 
> end architectures (compared to the aforementioned alternatives) can 
> scale and be quite economical for massive computation.
> 
>> Most of modern software can be re-compiled for the new instruction sets.
> 
> Recompiling is a possibility.  But it's not a likely path.
> 
>> Tell me why Intel should *not* adopt these architectures; not really 
>> why Intel does not...
> 
> Because Intel can't do it legally.  Not without buying / licensing 
> intellectual property.
> 
> There is another CPU architecture that is actually similar to the 
> aforementioned architectures that is in fact revolutionizing the 
> industry.  ARM.<CPU drop>
> 
> 
> 
ARM is to me interesting. I recently attended a talk on the history of 
the ARM by Steve Furber who was along with Sophie Wilson one of the 
co-developers of the ARM chips.

He says ARM was developed to be fast and as a consequence was not easy 
to program in assembler. Steve Furber says this makes sense because good 
compilers remove the need for programmers to understand the chip, and if 
the chip is fast the code will be fast.

I suspect many on here will not agree.

Its also interesting to note that ARM does not make CPU's. It licences 
the IP to other companies to make the CPU's

Dave

It is true that today we have just-in-time compilation techniques that 
reduce the overhead of simulating other architectures in software.

It's not true that they're 100% efficient or 100% guaranteed to work 
perfectly with every piece of existing shrink-wrapped software. 
Which is the reason almost nobody would want to bother with a computer 
with a different CPU.

On Tue, 24 Apr 2018 21:45:32 -0600, Grant Taylor
<gta...@tnetconsulting.net> wrote:

>On 04/24/2018 09:33 PM, J. Clarke wrote:
>> And of those the only one that sells is x86.  So come up with a
>> convincing argument that some other architecture will actually sell
>> enough units to be worth the cost of development.
>
>ARM
>
>It's my understanding that Windows will run on a Raspberry Pi 3 which 
>has an ARM v8 CPU.

ARM hit a niche in low power applications.  Windows exists for it.
Nobody uses Windows on it.  Compare real world performance between ARM
and x86 and you'll know why.

On Wed, 25 Apr 2018 03:36:01 -0700 (PDT), Quadibloc
<jsa...@ecn.ab.ca> wrote:

>It is true that today we have just-in-time compilation techniques that 
>reduce the overhead of simulating other architectures in software.
>
>It's not true that they're 100% efficient or 100% guaranteed to work 
>perfectly with every piece of existing shrink-wrapped software. 
>Which is the reason almost nobody would want to bother with a computer 
>with a different CPU.

They're a lot less than 100% efficient--everybody is releasing "metal"
compilers that run on the native architecture rather than an emulation
layer.

J. Clarke <jclarke...@gmail.com> wrote:
> On Tue, 24 Apr 2018 21:27:28 -0600, Grant Taylor
> <gta...@tnetconsulting.net> wrote:
> 
>> On 04/24/2018 07:53 PM, J. Clarke wrote:
>>> It does but not the way you mean.  Windows NT runs on Alpha,  i860,
>>> MIPS R4000, PowerPC, Itanium, and SPARC.
>> 
>> Windows NT is from Microsoft, not Intel.
>> 
>> You also missed x86 and x86_64 (or x64 if you prefer).
> 
> They are assumed.
> 
>> Note:  Intel makes three of those architectures:  x86 (x64), i860 
>> (i960), and Itanium.
> 
> And of those the only one that sells is x86.  So come up with a
> convincing argument that some other architecture will actually sell
> enough units to be worth the cost of development.
> 

Chicken-and-egg problem. No matter how excellent the architecture it isn't
going to sell unless the software is there for it. Conversely, no one is
going to develop the software for something that people aren't going to
buy. Linux short-circuits this; as mentioned, just re-compile your programs
for the new architecture (and hope for no compatibility problems)

The other problem is that the architecture is only part of the chip.
Microcode does lots of things behind the scenes to make the chips faster,
less power-hungry, etc., and lots of effort goes into this. Apple said as
much when they switched from PPC to Intel (a mistake in MO, but what do I
know). They couldn't see getting the performance improvements they wanted
out of the PPC over time.

-- 
Pete

On 04/25/2018 05:13 AM, J. Clarke wrote:
> ARM hit a niche in low power applications.  Windows exists for it.
> Nobody uses Windows on it.  Compare real world performance between ARM
> and x86 and you'll know why.

That's what has been done.

I've seen a number of things where people are experimenting with scaling 
ARM architecture up to be higher power / capability CPUs.



-- 
Grant. . . .
unix || die

On Wed, 25 Apr 2018 11:16:37 -0600
Grant Taylor <gta...@tnetconsulting.net> wrote:

> On 04/25/2018 05:13 AM, J. Clarke wrote:
> > ARM hit a niche in low power applications.  Windows exists for it.
> > Nobody uses Windows on it.  Compare real world performance between ARM
> > and x86 and you'll know why.
> 
> That's what has been done.
> 
> I've seen a number of things where people are experimenting with scaling 
> ARM architecture up to be higher power / capability CPUs.

	What you mean things like the Cavium ThunderX - 48 cores running at
2.5GHz with a stack of high bandwith I/O (PCI-e, 40 Gig Ethernet, ...).

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Wed, 25 Apr 2018 11:16:37 -0600, Grant Taylor
<gta...@tnetconsulting.net> wrote:

>On 04/25/2018 05:13 AM, J. Clarke wrote:
>> ARM hit a niche in low power applications.  Windows exists for it.
>> Nobody uses Windows on it.  Compare real world performance between ARM
>> and x86 and you'll know why.
>
>That's what has been done.
>
>I've seen a number of things where people are experimenting with scaling 
>ARM architecture up to be higher power / capability CPUs.

And when they do and it's cost effective get back to us.

Charles Richmond <nume...@aquaporin4.com> writes:
>The Tahoe architecture and the DEC Alpha architecture both are much 
>nicer on the assembly level than the x86 architecture.  Not many here 
>would disagree with that. Why does Intel *not* produce modern versions 
>of those architectures and PC makers use those???

Because others have.   ARMv8 and PowerPC are two examples.

>
>Most of modern software can be re-compiled for the new instruction sets.

At enormous expense.

J. Clarke <jclarke...@gmail.com> writes:
>On 24 Apr 2018 19:52:13 GMT, Charlie Gibbs <cgibbs@kltpzyxm.invalid>
>wrote:
>
>>On 2018-04-24, Charles Richmond <nume...@aquaporin4.com> wrote:
>>
>>> The Tahoe architecture and the DEC Alpha architecture both are much 
>>> nicer on the assembly level than the x86 architecture.  Not many here 
>>> would disagree with that. Why does Intel *not* produce modern versions 
>>> of those architectures and PC makers use those???
>>>
>>> Most of modern software can be re-compiled for the new instruction sets.
>>>
>>> Tell me why Intel should *not* adopt these architectures; not really why 
>>> Intel does not...
>>
>>I suspect that the answer begins with a dollar sign.
>
>It does but not the way you mean.  Windows NT runs on Alpha,  i860,
>MIPS R4000, PowerPC, Itanium, and SPARC. 

Windows 10 runs on x86 and ARMv8.   Not any of the aforementioned
dead processor architectures.

Grant Taylor <gta...@tnetconsulting.net> writes:
>On 04/24/2018 01:43 PM, Charles Richmond wrote:
>> The Tahoe architecture and the DEC Alpha architecture both are much 
>> nicer on the assembly level than the x86 architecture.  Not many here 
>> would disagree with that. Why does Intel *not* produce modern versions 
>> of those architectures and PC makers use those???
>
>I'm not familiar with Tahoe and can't comment.
>
>Alpha was developed by DEC, purchased by Compaq and subsequently HP. 
>Thus HP owns the Intellectual Property of the Alpha CPUs.  —  At least 
>the portion that did not get sold off to other companies.  —  I would be 
>somewhat surprised if there aren't pieces of Alpha architecture deep in 
>the bowels of other CPU architectures.

Many of the Alpha folks ended up at Cavium.

Most programmers didn't like alpha at all.   The weakly-ordered
memory model and non-coherent DMA caused too many problems,
especially for kernel people.

And nobody cares about the underlying instruction set anymore
because nobody (relative to the entire mass of programmers in
existence) programs in assembler in modern times.

David Wade <g4ugm@dave.invalid> writes:
>On 25/04/2018 04:43, Grant Taylor wrote:
>
>> There is another CPU architecture that is actually similar to the 
>> aforementioned architectures that is in fact revolutionizing the 
>> industry.  ARM.<CPU drop>
>> 
>> 
>> 
>ARM is to me interesting. I recently attended a talk on the history of 
>the ARM by Steve Furber who was along with Sophie Wilson one of the 
>co-developers of the ARM chips.
>
>He says ARM was developed to be fast and as a consequence was not easy 
>to program in assembler. Steve Furber says this makes sense because good 
>compilers remove the need for programmers to understand the chip, and if 
>the chip is fast the code will be fast.
>
>I suspect many on here will not agree.

Actually, ARM removed all the goofy predication stuff when
they developed the 64-bit ARM version 8 ISA.   It turned out
that the predication stuff (i.e. conditionally executing instructions
based on the condition flags from the prior instruction) makes both
speculation and out-of-order much more difficult and less performant.

As it is, the ARMv8 architecture manual is currently a 6,666 page
PDF with hundreds of instructions (hardly a 'reduced' instruction set
computer any more).   Add the coresight, interrupt controller and
IOMMU documentation and you're pushing 10,000 pages.

On 4/25/2018 5:36 AM, Quadibloc wrote:
> It is true that today we have just-in-time compilation techniques that
> reduce the overhead of simulating other architectures in software.
> 
> It's not true that they're 100% efficient or 100% guaranteed to work
> perfectly with every piece of existing shrink-wrapped software.
> Which is the reason almost nobody would want to bother with a computer
> with a different CPU.
> 

Name one program sold by Microsoft that is "100% guaranteed to work 
perfectly".  Seems to me this is a specious argument...

-- 
numerist at aquaporin4 dot com

On 4/24/2018 10:43 PM, Grant Taylor wrote:
> On 04/24/2018 01:43 PM, Charles Richmond wrote:
>> The Tahoe architecture and the DEC Alpha architecture both are much 
>> nicer on the assembly level than the x86 architecture.  Not many here 
>> would disagree with that. Why does Intel *not* produce modern versions 
>> of those architectures and PC makers use those???
> 
> I'm not familiar with Tahoe and can't comment.
> 
> Alpha was developed by DEC, purchased by Compaq and subsequently HP. 
> Thus HP owns the Intellectual Property of the Alpha CPUs.  —  At least 
> the portion that did not get sold off to other companies.  —  I would be 
> somewhat surprised if there aren't pieces of Alpha architecture deep in 
> the bowels of other CPU architectures.
> 

According to the Wikipedia artilce on Alpha:  "On June 25, 2001, Compaq 
announced that Alpha would be phased out by 2004 in favor of Intel's 
Itanium, canceled the planned EV8 chip, and sold all Alpha intellectual 
property to Intel."  See the following <zdnet.com> article:

https://tinyurl.com/y8m4kqtm


-- 
numerist at aquaporin4 dot com

On Thu, 26 Apr 2018 09:05:20 -0500, Charles Richmond
<nume...@aquaporin4.com> wrote:

>On 4/25/2018 5:36 AM, Quadibloc wrote:
>> It is true that today we have just-in-time compilation techniques that
>> reduce the overhead of simulating other architectures in software.
>> 
>> It's not true that they're 100% efficient or 100% guaranteed to work
>> perfectly with every piece of existing shrink-wrapped software.
>> Which is the reason almost nobody would want to bother with a computer
>> with a different CPU.
>> 
>
>Name one program sold by Microsoft that is "100% guaranteed to work 
>perfectly".  Seems to me this is a specious argument...

Name one program sold by _anybody_ that is "100% guaranteed to work
pefectly".

On Thu, 26 Apr 2018 19:49:29 -0400
J. Clarke <jclarke...@gmail.com> wrote:

> Name one program sold by _anybody_ that is "100% guaranteed to work
> pefectly".

	/bin/true

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On 4/26/2018 6:49 PM, J. Clarke wrote:
> On Thu, 26 Apr 2018 09:05:20 -0500, Charles Richmond
> <nume...@aquaporin4.com> wrote:
> 
>> On 4/25/2018 5:36 AM, Quadibloc wrote:
>>> It is true that today we have just-in-time compilation techniques that
>>> reduce the overhead of simulating other architectures in software.
>>>
>>> It's not true that they're 100% efficient or 100% guaranteed to work
>>> perfectly with every piece of existing shrink-wrapped software.
>>> Which is the reason almost nobody would want to bother with a computer
>>> with a different CPU.
>>>
>>
>> Name one program sold by Microsoft that is "100% guaranteed to work
>> perfectly".  Seems to me this is a specious argument...
> 
> Name one program sold by _anybody_ that is "100% guaranteed to work
> pefectly".
> 

So working perfectly is a red herring in both these regards...

-- 
numerist at aquaporin4 dot com

 > > Name one program sold by _anybody_ that is "100% guaranteed to work
 > > pefectly".

 >         /bin/true

The common linux version of /bin/true these days uses locale,
.po files, parses command line arguments, ...

I sincerely doubt all of that comes anywhere near 100%.

#include <iefbr14>

De

d...@ihatespam.msu.edu (Dennis Boone) writes:

>  > > Name one program sold by _anybody_ that is "100% guaranteed to work
>  > > pefectly".
>
>  >         /bin/true
>
> The common linux version of /bin/true these days uses locale,
> .po files, parses command line arguments, ...
>
> I sincerely doubt all of that comes anywhere near 100%.

Looks like just the basic stuff:

 \> ldd /bin/true
        linux-vdso.so.1 (0x00007ffcc69d3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)

"true" is a bash builtin so the "linux version" is NOT /bin/true.

-- 
Dan Espen

On Fri, 27 Apr 2018 09:27:16 -0500
d...@ihatespam.msu.edu (Dennis Boone) wrote:

>  > > Name one program sold by _anybody_ that is "100% guaranteed to work
>  > > pefectly".
> 
>  >         /bin/true
> 
> The common linux version of /bin/true these days uses locale,
> .po files, parses command line arguments, ...

	Wow! Why ?

	Apart from comments the BSD version of true is:

int
main(void)
{
    return 0;
}

	It used to be an executable empty file but this is lighter than
invoking a shell just to return 0.

> I sincerely doubt all of that comes anywhere near 100%.

	I think the BSD one does.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

Dan Espen <dan1...@gmail.com> writes:
>d...@ihatespam.msu.edu (Dennis Boone) writes:
>
>>  > > Name one program sold by _anybody_ that is "100% guaranteed to work
>>  > > pefectly".
>>
>>  >         /bin/true
>>
>> The common linux version of /bin/true these days uses locale,
>> .po files, parses command line arguments, ...
>>
>> I sincerely doubt all of that comes anywhere near 100%.
>
>Looks like just the basic stuff:
>
> \> ldd /bin/true
>        linux-vdso.so.1 (0x00007ffcc69d3000)
>        libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
>        /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
>
>"true" is a bash builtin so the "linux version" is NOT /bin/true.

Bin true does nothing more than exit.

$ ltrace true
__libc_start_main(0x401260, 1, 0x7fff32d19f28, 0x403420, 0x403410 <unfinished ...>
exit(0 <unfinished ...>
+++ exited (status 0) +++

On 2018-04-26, J  Clarke <jclarke...@gmail.com> wrote:

> Name one program sold by _anybody_ that is "100% guaranteed to work
> pefectly".

It depends on who you're talking to.  If it's a salesman, they're everywhere.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

Dan Espen <dan1...@gmail.com> wrote:
> d...@ihatespam.msu.edu (Dennis Boone) writes:
> 
>>>> Name one program sold by _anybody_ that is "100% guaranteed to work
>>>> pefectly".
>> 
>>> /bin/true
>> 
>> The common linux version of /bin/true these days uses locale,
>> .po files, parses command line arguments, ...
>> 
>> I sincerely doubt all of that comes anywhere near 100%.
> 
> Looks like just the basic stuff:
> 
>  \> ldd /bin/true
>         linux-vdso.so.1 (0x00007ffcc69d3000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
> 
> "true" is a bash builtin so the "linux version" is NOT /bin/true.
> 

IEFBR14 (after last APAR).

-- 
Pete

On 4/27/2018 9:46 AM, Ahem A Rivet's Shot wrote:
> On Fri, 27 Apr 2018 09:27:16 -0500
> d...@ihatespam.msu.edu (Dennis Boone) wrote:
> 
>>   > > Name one program sold by _anybody_ that is "100% guaranteed to work
>>   > > pefectly".
>>
>>   >         /bin/true
>>
>> The common linux version of /bin/true these days uses locale,
>> .po files, parses command line arguments, ...
> 
> 	Wow! Why ?
> 
> 	Apart from comments the BSD version of true is:
> 
> int
> main(void)
> {
>      return 0;
> }
> 
> 	It used to be an executable empty file but this is lighter than
> invoking a shell just to return 0.
> 
>> I sincerely doubt all of that comes anywhere near 100%.
> 
> 	I think the BSD one does.
> 

True should return *one*...  zero is false.

-- 
numerist at aquaporin4 dot com

On Fri, 27 Apr 2018 16:33:29 -0500
Charles Richmond <nume...@aquaporin4.com> wrote:

> On 4/27/2018 9:46 AM, Ahem A Rivet's Shot wrote:
> > On Fri, 27 Apr 2018 09:27:16 -0500
> > d...@ihatespam.msu.edu (Dennis Boone) wrote:
> > 
> >>   > > Name one program sold by _anybody_ that is "100% guaranteed to
> >>   > > work pefectly".
> >>
> >>   >         /bin/true
> >>
> >> The common linux version of /bin/true these days uses locale,
> >> .po files, parses command line arguments, ...
> > 
> > 	Wow! Why ?
> > 
> > 	Apart from comments the BSD version of true is:
> > 
> > int
> > main(void)
> > {
> >      return 0;
> > }
> > 
> > 	It used to be an executable empty file but this is lighter than
> > invoking a shell just to return 0.
> > 
> >> I sincerely doubt all of that comes anywhere near 100%.
> > 
> > 	I think the BSD one does.
> > 
> 
> True should return *one*...  zero is false.

	In C yes, but the value returned by main is handed to the execution
environment, in this case a shell where 0 is true and any non-zero value
false.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On 04/27/2018 08:39 AM, Dan Espen wrote:
> "true" is a bash builtin so the "linux version" is NOT /bin/true.

"true" may be a built in, but "/bin/true" is not.  ;-)

It depends how you call the command.

alias true='/bin/false'  }:-)



-- 
Grant. . . .
unix || die

On 04/27/2018 12:41 PM, Peter Flass wrote:
> IEFBR14 (after last APAR).

I find it hilarious that IEFBR14 took multiple versions (APARs) to get 
reasonably accurate.



-- 
Grant. . . .
unix || die

 >  \> ldd /bin/true
 >         linux-vdso.so.1 (0x00007ffcc69d3000)
 >         libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
 >         /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)

 > "true" is a bash builtin so the "linux version" is NOT /bin/true.

Skipping over the people that don't use bash, and the scripts that
use /bin/true rather than the builtin, ...

int
main (int argc, char **argv)
{
  /* Recognize --help or --version only if it's the only command-line
     argument.  */
  if (argc == 2)
    {
      initialize_main (&argc, &argv);
      set_program_name (argv[0]);
      setlocale (LC_ALL, "");
      bindtextdomain (PACKAGE, LOCALEDIR);
      textdomain (PACKAGE);

      /* Note true(1) will return EXIT_FAILURE in the
         edge case where writes fail with GNU specific options.  */
      atexit (close_stdout);

      if (STREQ (argv[1], "--help"))
        usage (EXIT_STATUS);

      if (STREQ (argv[1], "--version"))
        version_etc (stdout, PROGRAM_NAME, PACKAGE_NAME, Version, AUTHORS,
                     (char *) NULL);
    }

  return EXIT_STATUS;
}

On Fri, 27 Apr 2018 23:10:41 -0500
d...@ihatespam.msu.edu (Dennis Boone) wrote:

>  >  \> ldd /bin/true
>  >         linux-vdso.so.1 (0x00007ffcc69d3000)
>  >         libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
>  >         /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
> 
>  > "true" is a bash builtin so the "linux version" is NOT /bin/true.
> 
> Skipping over the people that don't use bash, and the scripts that
> use /bin/true rather than the builtin, ...
> 
> int
> main (int argc, char **argv)
> {
>   /* Recognize --help or --version only if it's the only command-line
>      argument.  */
>   if (argc == 2)
>     {
>       initialize_main (&argc, &argv);
>       set_program_name (argv[0]);
>       setlocale (LC_ALL, "");
>       bindtextdomain (PACKAGE, LOCALEDIR);
>       textdomain (PACKAGE);
> 
>       /* Note true(1) will return EXIT_FAILURE in the
>          edge case where writes fail with GNU specific options.  */
>       atexit (close_stdout);
> 
>       if (STREQ (argv[1], "--help"))
>         usage (EXIT_STATUS);
> 
>       if (STREQ (argv[1], "--version"))
>         version_etc (stdout, PROGRAM_NAME, PACKAGE_NAME, Version, AUTHORS,
>                      (char *) NULL);
>     }
> 
>   return EXIT_STATUS;
> }

	I far prefer the BSD version.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Fri, 27 Apr 2018 23:39:27 GMT, Ahem A Rivet's Shot <ste...@eircom.net> 
wrote:

> On Fri, 27 Apr 2018 16:33:29 -0500
> Charles Richmond <nume...@aquaporin4.com> wrote:
> 
>> On 4/27/2018 9:46 AM, Ahem A Rivet's Shot wrote:
>> > On Fri, 27 Apr 2018 09:27:16 -0500
>> > d...@ihatespam.msu.edu (Dennis Boone) wrote:
>> > 
>> >>   > > Name one program sold by _anybody_ that is "100% guaranteed 
to
>> >>   > > work pefectly".
>> >>
>> >>   >         /bin/true
>> >>
>> >> The common linux version of /bin/true these days uses locale,
>> >> .po files, parses command line arguments, ...
>> > 
>> >      Wow! Why ?
>> > 
>> >      Apart from comments the BSD version of true is:
>> > 
>> > int
>> > main(void)
>> > {
>> >      return 0;
>> > }
>> > 
>> >      It used to be an executable empty file but this is lighter than
>> > invoking a shell just to return 0.
>> > 
>> >> I sincerely doubt all of that comes anywhere near 100%.
>> > 
>> >      I think the BSD one does.
>> > 
>> 
>> True should return *one*...  zero is false.
> 
>      In C yes, but the value returned by main is handed to the 
execution
> environment, in this case a shell where 0 is true and any non-zero 
value
> false.
> 

-1 is true all else is false. Bring back ones complement! </loony 
heretic>

-- 
Bah, and indeed, Humbug.

On 27/04/2018 22:33, Charles Richmond wrote:
> True should return *one*...  zero is false.
> 

Nah ... -1 otherwise NOT TRUE will not be the same
as FALSE, unless only a single bit is used as the
logic representation.

On Sat, 28 Apr 2018 12:10:03 +0100
Gareth's Downstairs Computer
<headstone255.but.n...@yahoo.com> wrote:

> On 27/04/2018 22:33, Charles Richmond wrote:
> > True should return *one*...  zero is false.
> > 
> 
> Nah ... -1 otherwise NOT TRUE will not be the same
> as FALSE, unless only a single bit is used as the
> logic representation.

	In C the convention is 0 false, non=zero true, in shell it is the
other way round. Strange considering that both conventions come from the
same place and approximate time.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

Ahem A Rivet's Shot <ste...@eircom.net> writes:
>On Sat, 28 Apr 2018 12:10:03 +0100
>Gareth's Downstairs Computer
><headstone255.but.n...@yahoo.com> wrote:
>
>> On 27/04/2018 22:33, Charles Richmond wrote:
>> > True should return *one*...  zero is false.
>> > 
>> 
>> Nah ... -1 otherwise NOT TRUE will not be the same
>> as FALSE, unless only a single bit is used as the
>> logic representation.
>
>	In C the convention is 0 false, non=zero true, in shell it is the
>other way round. Strange considering that both conventions come from the
>same place and approximate time.

Not so bad when you consider '0' as success, rather than true.  The
utility named 'true' returns success to the shell by returning 0.

d...@ihatespam.msu.edu (Dennis Boone) writes:
> >  \> ldd /bin/true
> >         linux-vdso.so.1 (0x00007ffcc69d3000)
> >         libc.so.6 => /lib64/libc.so.6 (0x00007f5648bd8000)
> >         /lib64/ld-linux-x86-64.so.2 (0x00007f56491b8000)
>
> > "true" is a bash builtin so the "linux version" is NOT /bin/true.
>
>Skipping over the people that don't use bash, and the scripts that
>use /bin/true rather than the builtin, ...
>
>int
>main (int argc, char **argv)
>{
>  /* Recognize --help or --version only if it's the only command-line
>     argument.  */
>  if (argc == 2)
>    {
>      initialize_main (&argc, &argv);
>      set_program_name (argv[0]);
>      setlocale (LC_ALL, "");
>      bindtextdomain (PACKAGE, LOCALEDIR);
>      textdomain (PACKAGE);
>
>      /* Note true(1) will return EXIT_FAILURE in the
>         edge case where writes fail with GNU specific options.  */
>      atexit (close_stdout);
>
>      if (STREQ (argv[1], "--help"))
>        usage (EXIT_STATUS);
>
>      if (STREQ (argv[1], "--version"))
>        version_etc (stdout, PROGRAM_NAME, PACKAGE_NAME, Version, AUTHORS,
>                     (char *) NULL);
>    }
>
>  return EXIT_STATUS;
>}

not on fedora:

$ ltrace true
__libc_start_main(0x401260, 1, 0x7fff32d19f28, 0x403420, 0x403410 <unfinished ...>
exit(0 <unfinished ...>
+++ exited (status 0) +++


Note the lack of a setlocale() call.

On Sat, 28 Apr 2018 15:12:24 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Ahem A Rivet's Shot <ste...@eircom.net> writes:
> >On Sat, 28 Apr 2018 12:10:03 +0100
> >Gareth's Downstairs Computer
> ><headstone255.but.n...@yahoo.com> wrote:
> >
> >> On 27/04/2018 22:33, Charles Richmond wrote:
> >> > True should return *one*...  zero is false.
> >> > 
> >> 
> >> Nah ... -1 otherwise NOT TRUE will not be the same
> >> as FALSE, unless only a single bit is used as the
> >> logic representation.
> >
> >	In C the convention is 0 false, non=zero true, in shell it is the
> >other way round. Strange considering that both conventions come from the
> >same place and approximate time.
> 
> Not so bad when you consider '0' as success, rather than true.  The
> utility named 'true' returns success to the shell by returning 0.

	Oh don't get me wrong both contexts make sense in themselves, it's
just the juxtaposition that makes it seem odd.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Thursday, April 26, 2018 at 7:49:31 PM UTC-4, J. Clarke wrote:

> Name one program sold by _anybody_ that is "100% guaranteed to work
> pefectly".

Everything I wrote.

On Sat, 28 Apr 2018 11:54:47 -0700 (PDT), hanc...@bbs.cpcn.com wrote:

>On Thursday, April 26, 2018 at 7:49:31 PM UTC-4, J. Clarke wrote:
>
>> Name one program sold by _anybody_ that is "100% guaranteed to work
>> pefectly".
>
>Everything I wrote.

And how much of this was actually _sold_ and do you have a copy of
this guarantee that was provided available anywhere?

Scott Lurndal wrote:
> d...@ihatespam.msu.edu (Dennis Boone) writes:

>> Skipping over the people that don't use bash, and the scripts that
>> use /bin/true rather than the builtin, ...
>>
>> int
>> main (int argc, char **argv)
>> {
>>   /* Recognize --help or --version only if it's the only command-line
>>      argument.  */
>>   if (argc == 2)
>>     {
>>       initialize_main (&argc, &argv);
>>       set_program_name (argv[0]);
>>       setlocale (LC_ALL, "");
>>       bindtextdomain (PACKAGE, LOCALEDIR);
>>       textdomain (PACKAGE);
>>
>>       /* Note true(1) will return EXIT_FAILURE in the
>>          edge case where writes fail with GNU specific options.  */
>>       atexit (close_stdout);
>>
>>       if (STREQ (argv[1], "--help"))
>>         usage (EXIT_STATUS);
>>
>>       if (STREQ (argv[1], "--version"))
>>         version_etc (stdout, PROGRAM_NAME, PACKAGE_NAME, Version, AUTHORS,
>>                      (char *) NULL);
>>     }
>>
>>   return EXIT_STATUS;
>> }
>
> not on fedora:
>
> $ ltrace true
> __libc_start_main(0x401260, 1, 0x7fff32d19f28, 0x403420, 0x403410 <unfinished ...>
> exit(0 <unfinished ...>
> +++ exited (status 0) +++
>
>
> Note the lack of a setlocale() call.

I think your test case activated the wrong execution path, causing
setlocale to be absent from the trace even if your executable file
had been compiled from the exact source code that Dennis posted.

-- 
e-mail: the TLD is COM, the subdomain is my surname,
and the local-part is the product of 191773 and 48271.