[Interest] Interest Digest, Vol 79, Issue 21
Roland Hughes
roland at logikalsolutions.com
Tue May 1 16:38:52 CEST 2018
On 05/01/2018 08:29 AM, Jason H wrote:
> 1. You're still yellow. (Message backgrounds anyway)
I never said I would change. I simply told you why I use yellow. If it
bothers you subscribe in digest mode where all formatting is stripped.
> 2. I think you're too hung up on the size of your computer. :-)
It's not a fascination with size. It has to do with the tiered structure
of the industry. You move up or are consumed. Both storage and computer
systems are tiered. Specific brands of computers are designed for
specific market segments.
For decades the x86 defined the absolute bottom of the IT universe. When
you didn't care about it you put it on x86.
Wang staked out word processing, in particular collaborative word
processing, and refused to expand its focus. Word processors became
incredibly useful on the PC when WordPerfect came out. People gave up on
collaboration to get a cheaper word processing solution. Wang didn't
move up, so now it doesn't exist. Guess what? Now all of the rage in the
word processing world is being able to collaborate in real time. There
really was a reason for it.
Tandem exists for computers which are one way or other, "in harms way."
There used to be some marketing material showing someone emptying a .45
into the computer and it still kept running. Tandem is still around and
marketed as Non-Stop now. Why? The need never went away and the x86
hasn't risen that high.
https://www.hpe.com/us/en/servers/nonstop.html
OpenVMS systems were the first which could talk to everybody. They are
still, to date, the only system which well and truly clusters, despite
the false claims of many others. The OpenVMS platform also has up-times
measured in decades.
http://h41379.www4.hpe.com/news/compworld.pdf
Rather than building a hardened box, OpenVMS systems (which are little
endian) cluster over a large geographic range in such a way that as long
as one survives you remain operational. This is why some of the trading
firms in the Twin Towers were able to keep trading without losing a
single transaction until close of business despite catastrophic loss of
life and systems.
Cray computers focused on massive calculation speed. They suffered a bit
on the throughput front, but, could perform unbelievable calculations at
blinding speed. They have since stopped making their own CPUs, focusing
on how to best utilize AMD in their designs, but, still serve their segment.
https://www.cray.com
You will also note they have begun using ARM in their designs. Why? Heat
and power consumption were always serious issues for Cray. If memory
serves, they were the first to re-introduce liquid cooling because a
"standard" computer room HVAC system could not begin to keep up.
IBM was always about massive throughput. Sometimes they were the best at
compute speed, but more often not. Nothing could touch them with data
I/O though. That niche/segment continues to grow in size. In large part
IBM achieved this throughput by being a batch oriented block I/O system.
When you develop a terminal application for IBM you used CICS which
transmitted a block of information from the smart terminal to an
application running in batch. They did not support TTY or for that
matter, interrupt driven types of development. Even their support for
serial communications/modems, at least on the AS/400 where I last
encountered them, was a block I/O driver. You defined a packet and
received a block once a packet had been accumulated by the driver.
The bottom of the market is now defined by ARM. When it comes to sensors
and other low end things it is a great chip. These devices need to feed
back to real computers though to serve a purpose.
> 3. I agree network byte order is the lingua franca, but you're
> spending CPU cycles to swap bytes around. However this only wastes
> instructions on enciding and decoding information stored and read back
> by the same architecture.
> 4. Whatever is done needs to be biendian. Defaults shouldn't matter
> because you shouldn't be assuming defaults are the same between machines.
While defaults "shouldn't" matter, changing defaults do matter because
it will break existing code.
> 5. CBOR specifies big-endian. "All multi-byte values are encoded in
> network byte order (that is, most significant byte first, also known
> as "big-endian")."
Because of all the existing systems feeding high end systems operating
in big-endian.
> *Sent:* Monday, April 30, 2018 at 6:01 PM
> *From:* "Roland Hughes" <roland at logikalsolutions.com>
> *To:* interest at qt-project.org
> *Subject:* Re: [Interest] Interest Digest, Vol 79, Issue 21
>
> On 04/30/2018 10:57 AM, Thiago Macieira wrote:
>
> At this point, I'm thinking long-term we should think of whether we should
> deprecate QDataStream or whether the discussion we had on basing it on CBOR
> makes more sense.
>
> Whatever replaces/continues QDataStream must continue big-endian.
>
> If you want to create a class for little computers which never
> transmit data to real computers, that's fine. Just don't destroy
> something for the simple reason it isn't the default behavior of hobby
> computers. It was created the way it is for a reason and that reason
> still exists today.
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
>
> http://www.theminimumyouneedtoknow.com
> http://www.infiniteexposure.net
> http://www.johnsmith-book.com
> http://www.logikalblog.com
> http://www.interestingauthors.com/blog
> http://lesedi.us/
> http://onedollarcontentstore.com
> _______________________________________________ Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180501/d2532847/attachment.html>
More information about the Interest
mailing list