Text 15748, 64 rader
Skriven 2012-05-07 16:39:04 av Maurice Kinal (1:261/38.9)
  Kommentar till text 15746 av Markus Reschke (2:244/1661)
Ärende: silence is golden
=========================
Hey Markus!

 MR> In that documentary you'll see a lot of 8 bit machines.

I have seen them.  The reason I've never used one is that I have yet to find a
use for one other than the ones that are found in hardware I've used over the
years.  However those have already been preprogrammed to provide the
functionality it was meant to offer the end user and requires a computer to
make use of them.

What you are talking about is different I know.  However I can already do all
that without it so it has less appeal for me.  I've been tempted before but
have yet to convince myself.

 MR> The next major step is an ARM based mainboard.

32 bit.  Now they are talking.  Tempting but I'd sooner have a 32 bit x86 based
board given that I already have a native gcc and freind enviroment for it and
it could take care of itself, which is my number one requirement for purchacing
any board in the first place no mattter how lean it is.  I don't like cross
compiling but Have been known to do it occasionally.  I lose interest in too
quickly.  However a 32 bit ARM based system does carry some appeal to me
especially if I could build a native gcc enviroment for it.  Definetly
possible.

 MR> you asked for it :-)

Heh, heh.  I suppose I did.  However all the jiggery-pokery you described to
derive a pktHeader and the binary bits of each msgHeader are of no consequence
to the end user and the machine will still have to produce all the text anyhow
which if you look as a human you'll notice has all the information - and then
some - required to reply to that text, such as I am doing right now.  I see no
binary although I have looked at it from time to time.  There are exactly zero
bytes there that provide anything meaningful to man or machine.  Only to
abandonware is your scenerio true or perhaps for machines that only process
information.  I can do the same using cp, mv, etc. without binary headers
though and it is faster.  I do understand your argument though but in this
particular case of text messaging it doesn't apply.  Processing binary data for
manipulation and math I can readily understand your logic and have been known
to apply it.  However I still don't require binary headers to accomplish that.

 MR> Dmitry Grinbergs ARMv5 emulator for the Atmel ATmega1284p

Interesting except that the ARMv5 is a 32 bit cpu and not an 8 bit bit one.  In
the past I emulated 16 bit on a x86 machine.  Not sure why I needed to do that
but at the time I thought I did.  It didn't last very long.

Speaking for myself, I am most interested in the human part of text messaging
and recently utf-8.  I've already got what I need to pull this off and doesn't
require Java, only basic file and text operations (eg cat and echo).  For
editting (replying and new messages) I am currently using vim simply because of
utf-8 and vim handles the encoding/decoding the best so far.  If I am looking
to code anything that would be the targetted application; editting.  Speaking
of which, haven't we discussed this before?  I believe it involved msged.  I
think that has the best shot at success on a utf-8 'linux' terminal given that
it has the least amount of DOS-think code in it than comparable apps such as
golded.

Life is good,
Maurice

... A Møøse once bit my sister ...
--- GNU bash, version 4.2.24(3)-release (x86_64-core2-linux-gnu)
 * Origin: Pointy Stick Society (1:261/38.9)