On Sun, 2014-09-28 at 18:42:24 +0800, Thomas Goirand wrote:
> On 09/27/2014 05:36 PM, Adam Borowski wrote:
> > Except that the endianness war has been won by little-endian and thus your
> > code would optimize for an already tiny part of the population that is going
> > to only decrease: arm, mips
On Sun, 2014-09-28 at 18:42 +0800, Thomas Goirand wrote:
> Just to be sure: is ppc64el also using little endian?
Yes; that's why the name ends in "el".
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
Hi,
Quoting Thomas Goirand (2014-09-28 12:42:24)
> Just to be sure: is ppc64el also using little endian?
yes it is.
Here is a great overview which answers that question and others:
https://wiki.debian.org/ArchitectureSpecificsMemo
cheers, josch
--
To UNSUBSCRIBE, email to debian-devel-requ..
On 09/27/2014 05:36 PM, Adam Borowski wrote:
> Except that the endianness war has been won by little-endian and thus your
> code would optimize for an already tiny part of the population that is going
> to only decrease: arm, mips switched from mostly be to almost only le, and
> the newest Debian a
>> That's not what my mail was about. My point is that the issue with the
>> software should be resolved upstream,
> in my case, it cannot be resolved upstream,
Yes, abandoned software is a problem, unfortunately quite common in the
scientific community. (Understandably so, since researchers ge
Hello All,
thanks for your answer.
On 27/09/14 23:37, Juliusz Chroboczek wrote:
>>> Standardising on big-endian is a good idea [...]
>
>> Except that the endianness war has been won by little-endian
>
> That's not what my mail was about. My point is that the issue with the
> software should be
>> Standardising on big-endian is a good idea [...]
> Except that the endianness war has been won by little-endian
That's not what my mail was about. My point is that the issue with the
software should be resolved upstream, rather than implementing yet another
dodgy hack in dpkg.
Which particul
On 2014-09-27 11:18:18 +0100, Jonathan Dowland wrote:
> > On 27 Sep 2014, at 10:36, Adam Borowski wrote:
> >
> > Except that the endianness war has been won by little-endian
>
> And yet, network byte order remains big.
But does this matter in the context of these binary data files?
On 2014-09-
Hi,
Jonathan Dowland:
> It's less important which endian they pick, but that they pick one and use it
> consistently across arches.
>
The advantage of using big-endian data on a little-endian system is that
you actually have a chance of finding mis-swapped and/or mis-sized items.
I do admit th
> On 27 Sep 2014, at 10:36, Adam Borowski wrote:
>
> Except that the endianness war has been won by little-endian
And yet, network byte order remains big.
It's less important which endian they pick, but that they pick one and use it
consistently across arches.
--
To UNSUBSCRIBE, email to
On Sat, Sep 27, 2014 at 04:41:42AM +0200, Juliusz Chroboczek wrote:
> Standardising on big-endian is a good idea, not only because it is the
> canonical byte ordering, but also because little-endian arches tend to
> have more efficient byte-swapping instructions.
Except that the endianness war has
> The mesh files are stored in binary form, and thus endian-ness
> is a worry when moving from one platform to another.
[...]
> What is not clear to me right now is how to [store] those data files:
> is there an endian triplet ?
Jérôme,
Please try to work with upstream to fix the issue. Byte swa
12 matches
Mail list logo
