Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #100369 > unrolled thread

Pine 64

Back to article view | Back to comp.lang.c

Contents

  Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-27 23:44 +0100
    Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-27 22:54 +0000
      Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:41 +0100
        Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:14 +0000
      Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 13:39 +0100
        Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:45 +0000
          Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 14:02 +0100
            Re: Pine 64 Keith Thompson <kst-u@mib.org> - 2016-12-28 10:11 -0800
              Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 10:50 -0800
              Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 22:55 +0100
                Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 12:21 +0100
                  Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-29 21:38 +0100
                    Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-30 10:10 +0100
              Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 21:53 +0100
              Re: Pine 64 raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:54 +0000
    Re: Pine 64 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-27 18:03 -0500
      Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:36 +0100
        Re: Pine 64 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-27 18:44 -0500
          Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 00:54 +0100
    Re: Pine 64 Noob <root@127.0.0.1> - 2016-12-28 11:27 +0100
      Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 12:10 +0100
        Re: Pine 64 Noob <root@127.0.0.1> - 2016-12-28 12:59 +0100
    Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 10:10 -0800
      Re: Pine 64 supercat@casperkitty.com - 2016-12-29 08:30 -0800
      Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 13:22 +0100
        Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 07:47 -0800
          Re: Pine 64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 17:03 +0000
        Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 04:50 -0800
          Re: Pine 64 Reinhardt Behm <rbehm@hushmail.com> - 2016-12-29 21:25 +0800
        Re: Pine 64 Keith Thompson <kst-u@mib.org> - 2016-12-29 09:28 -0800
        Re: Pine 64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 14:22 +0000
      Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-29 13:28 +0100
      Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 14:12 -0800
        Re: Pine 64 BartC <bc@freeuk.com> - 2016-12-28 22:23 +0000
        Re: Pine 64 Gareth Owen <gwowen@gmail.com> - 2016-12-29 18:43 +0000
      Re: Pine 64 David Brown <david.brown@hesbynett.no> - 2016-12-28 21:59 +0100
      Re: Pine 64 jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-28 23:43 +0100
      Re: Pine 64 jt@toerring.de (Jens Thoms Toerring) - 2016-12-28 22:56 +0000
        Re: Pine 64 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-28 16:00 -0800
          Re: A programming language called 'B64' Noob <root@127.0.0.1> - 2016-12-30 16:08 +0100

Page 1 of 2  [1] 2  Next page →

#100369 — Pine 64

Look, the chinese are clever.

Clever people.

I bought one of their marvels, a small circuit, not much bigger than a 
phone, with an arm64 quad core CPU, 2GB Ram, Linux, ethernet, and 
everything you would need to ssh into it from my mac. The circuits 
starts at 15 US$, but I invested more, and for around 30$ I bought a 
transparent case, and the high end model with the 2Gigs.

Incredible, the circuit has no moving parts, no spinning hard disk, no 
ventilator, no noise. The mass storage unit is a micro sd card, smaller 
than a fingernail. It packs 64 GB of storage, more than enough to host 
the 1.5 MB of lcc's source code and I find myself developing with the 
old combination of vi, grep, and your mind.

Unix.

It is a full fledged Unix system, with all the bells and whistles, git, 
gcc, and all that included.

Cron works, vi too, and git makes for a great replacement of cvs. I 
synchronize the development system in the circuit with the git server I 
installed in the mac and it works like a charm.

And it is still fun. And that nostalgic look of the console output, I 
like it. The circuit can do of course GUI, and "parted" the partition 
editor, is written in GUI so I made it work anyway, but with awful 
problems.

At the end the only thing that really worked was RDP of microsoft, using 
the emulated windows installation on the macintosh. Directly, either 
with VNC or with windows RDP no direct connection between the mac and 
the circuit could be established. In the end the connection using 
windows VM worked and I can access the GUI from there.

But this baroque setup is probably more due to my ignorance of the ssh 
arcanes to get it to talk x windows, and the mac, that needs an x 
windows emulator to be able to receive the screen.

Too much GUI soup, the console works now. Yes, GREP (global regular 
expression parser, if memory serves) is no replacement for a "goto 
definition" button, but it works, if you know what you are doing and use 
a bit of brain.

This is a good development system for the little c compiler (lcc).

And the ARM 64 is an interesting machine. Legend tells that apple bought 
that semiconductor maker to rewrite the arm 64 in a faster, much better 
version. But Apple doesn't sell those CPUs, only the chinese understood 
the possibility.

This machine can replace PCs, since it is a better personal computer. A 
simpler CPU with no cooling required, solid state storage that 
eliminates battery drain, it needs only a fast i/o disk driver that 
hasn't been written. I/O is the big bottleneck. It can do full hd, so it 
is not that the raw power is not there. Maybe somebody understand the 
potential and creates something better. This machine is cheaper than the 
Raspberry pi, and full 64 bits. It has a great potential.

Imagine a small cube with no screen, keyboard, mouse that you just put 
into your pocket. You can branch your phone to provide human input and a 
keyboard and a screen at home.

A personal computer: PC. Using a current linux distribution, I think 
that my personal data is far more sure than in a phone where the OS and 
all hardware is completely owned by who knows who.

[toc] | [next] | [standalone]

#100372

jacobnavia <jacob@jacob.remcomp.fr> wrote:

> Look, the chinese are clever.

> A personal computer: PC. Using a current linux distribution, I think 
> that my personal data is far more sure than in a phone where the OS and 
> all hardware is completely owned by who knows who.

You don't see a contradiction between those two?

*Shakes head*

Richard

[toc] | [prev] | [next] | [standalone]

#100377

Le 27/12/2016 à 23:54, Richard Bos a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>
>> Look, the chinese are clever.
>
>> A personal computer: PC. Using a current linux distribution, I think
>> that my personal data is far more sure than in a phone where the OS and
>> all hardware is completely owned by who knows who.
>
> You don't see a contradiction between those two?
>
> *Shakes head*
>
> Richard
>

When I say that the chinese are clever, that doesn't mean that I am a 
stupid Mr Bos.

I made x times an nmap looking for the backdoor but none were to be 
found till now. Yes, I haven't taken the device apart but since I do not 
connect the bluetooth nor do I use the wifi, any connection should have 
appeared by now in the regular scans I do from the mac.

None have appeared. That is not a guarantee, I know.

[toc] | [prev] | [next] | [standalone]

#100418

jacobnavia <jacob@jacob.remcomp.fr> wrote:

> Le 27/12/2016 à 23:54, Richard Bos a écrit :
> > jacobnavia <jacob@jacob.remcomp.fr> wrote:
> >
> >> Look, the chinese are clever.
> >
> >> A personal computer: PC. Using a current linux distribution, I think
> >> that my personal data is far more sure than in a phone where the OS and
> >> all hardware is completely owned by who knows who.
> >
> > You don't see a contradiction between those two?
> >
> > *Shakes head*
> 
> When I say that the chinese are clever, that doesn't mean that I am a 
> stupid Mr Bos.

Nope; the main stupid Mr. Bos is Wouter, and you are certainly not him.

But you are not even a stupid M. navia, and I never said or implied that
you are. What I _did_ imply is that you're being rather naive in this
specific case.

I wouldn't trust my personal data to a Chinese or Russian company if I
could possibly help it. Hell, I would even try to avoid USA-based
companies if it weren't so completely impossible, though in that case
it's more because I don't trust their Big Business. If at all possible,
go European or non-superpower.

Richard

[toc] | [prev] | [next] | [standalone]

#100422

On 27/12/16 23:54, Richard Bos wrote:
> jacobnavia <jacob@jacob.remcomp.fr> wrote:
> 
>> Look, the chinese are clever.
> 
>> A personal computer: PC. Using a current linux distribution, I think 
>> that my personal data is far more sure than in a phone where the OS and 
>> all hardware is completely owned by who knows who.
> 
> You don't see a contradiction between those two?
> 
> *Shakes head*
> 
> Richard
> 

It is not hard to put your own Linux build on most of these embedded
Linux cards.  If you are really keen, you can compile it all yourself,
but usually you can use a variant of Debian, Ubuntu, or other common
distributions on the more powerful ARM cards.

Usually the Chinese manufacturers of boards like this do what everyone
else does - use as much off-the-shelf software and ready-made Linux
software as they can.  I don't know this particular card or the company
behind it, but often the folks putting these cards together understand
the economies of large-scale PCB manufacturing, a little electronics
design (enough to copy and modify reference designs), and only the very
basics of getting the software installed.  The Chinese government is not
interested in monitoring the sort of people that buy these cards, and
the people making and selling them have no economic interest in it, so
why should they bother with hidden backdoors and the like?  It is a very
different situation from phones, where the data can be valuable.

[toc] | [prev] | [next] | [standalone]

#100423

David Brown <david.brown@hesbynett.no> wrote:

> The Chinese government is not interested in monitoring the sort of
> people that buy these cards,

*Shakes head even more sadly*

Richard

[toc] | [prev] | [next] | [standalone]

#100425

On 28/12/16 13:45, Richard Bos wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> The Chinese government is not interested in monitoring the sort of
>> people that buy these cards,
> 
> *Shakes head even more sadly*
> 

Do you even know who typically buys these cards, and what they do with
them?  Anyone doing something serious - that could conceivably be of
interest to the Chinese authorities - is likely to put a Linux
distribution on them themselves.  And a fair proportion of people buying
these sorts of cards are geeks who would have a good chance of spotting
spyware.  So that would mean putting spyware on the cards would be high
risk, have low chance of working, and provide very little data of
interest at best.  Do you think the Chinese government really cares how
often Jacob tests his compiler on the card?

In comparison, it is a relatively simple matter to put backdoors and
spyware on cheap Chinese mobiles, with a potential for providing a lot
of useful spy data or making a zombie device army.  The same goes for
things like home routers.  So feel free to be paranoid about that sort
of thing.  (Though to be fair, you should be equally paranoid about the
USA and the UK authorities - and of course good old fashioned
incompetence and security holes all round.)

So Jacob is perfectly correct that his data would be more likely to be
safe and secure on such a board than on a phone.

[toc] | [prev] | [next] | [standalone]

#100453

David Brown <david.brown@hesbynett.no> writes:
> On 28/12/16 13:45, Richard Bos wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> The Chinese government is not interested in monitoring the sort of
>>> people that buy these cards,
>> 
>> *Shakes head even more sadly*
>> 
>
> Do you even know who typically buys these cards, and what they do with
> them?
[...]

Does anyone else remember when this was a C newsgroup?  Good times.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#100460

On Wednesday, December 28, 2016 at 6:10:41 PM UTC, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> > On 28/12/16 13:45, Richard Bos wrote:
> >> David Brown <david.brown@hesbynett.no> wrote:
> >>> The Chinese government is not interested in monitoring the sort of
> >>> people that buy these cards,
> >> 
> >> *Shakes head even more sadly*
> >> 
> >
> > Do you even know who typically buys these cards, and what they do with
> > them?
> [...]
> 
> Does anyone else remember when this was a C newsgroup?  Good times.
> 
It's important for context.

At least some C code will probably be run on practically all of these devices. As I gather it, they run embedded Linux, then a user program written in any language (C, C++, Python, even MiniBasic). But exactly
where they will find their niche I don't know. When microcomputers 
first came out, everyone said you'd use them for controlling the central
heating (way too cumbersome), or for educational use (there were a few
good educational programs, but basically the machines were too limited),
in fact they were used for playing video games.

These cards will likely be similar. There will be a niche for them.
 

[toc] | [prev] | [next] | [standalone]

#100498

Le 28/12/2016 à 21:53, David Brown a écrit :
> And Jacob was talking about compiling C on it, and even compiling his C
> compiler on it, before we got side-tracked.

Yeah, I got to the link phase. I compiled lcc wit gcc, and that compiler 
was used to compile the same code again producing (at last) a bloated 
executable, full of bad code, but an executable nevertheless.

Normal for the first iteration. This process is called boot strapping, 
and it is a PITA, as it is commonly called...

The fact that all the code was translated with a correct assembler 
syntax was a big step. Now, there is a big problem with the debug info.

If I link with the debug info, the linker tells me

stabs index error.

And doesn't produce an executable.

Of course, I would be rather keenly interested in knowing where in the 
1.5 MB of code full of stab statements the error could be???

But the linker will not tell me, why should it?

If you are the developer of the linker and you know only gcc is around 
why bother specifying the module and line number or index of the stab or 
whatever. A sensible error message is too much asking here.

Another problem (solved this one) was the c library. I could not compile 
the headers of gcc, full of strange stuff with __attribute__ whatever. 
But making appropiate #defines solved that problem and I could link, 
albeit without the debug info.

Problem is, I am generating stabs and gcc has changed to dwarf. Do they 
correctly support stabs any more?

If that is the case I would have to rewrite the debugger and use my own 
format. I remember that I had a debugger using the ptrace interface back 
then.

[toc] | [prev] | [next] | [standalone]

#100610

On 28/12/16 22:55, jacobnavia wrote:
> Le 28/12/2016 à 21:53, David Brown a écrit :
>> And Jacob was talking about compiling C on it, and even compiling his C
>> compiler on it, before we got side-tracked.
> 

This is way off topic, and I don't know all the details, but I can try
to offer you a little help.  After that, you might find more direct help
on the binutils or gcc mailing lists.

> Yeah, I got to the link phase. I compiled lcc wit gcc, and that compiler
> was used to compile the same code again producing (at last) a bloated
> executable, full of bad code, but an executable nevertheless.

If you compiled without optimisation and/or with debug information,
executables will be big.  Debugging information can be several times as
big as the code itself.

> 
> Normal for the first iteration. This process is called boot strapping,
> and it is a PITA, as it is commonly called...
> 
> The fact that all the code was translated with a correct assembler
> syntax was a big step. Now, there is a big problem with the debug info.
> 
> If I link with the debug info, the linker tells me
> 
> stabs index error.
> 
> And doesn't produce an executable.

Stabs has been out of date for about a decade on most platforms that use
elf format executables (such as Linux).  I believe it is still used on
BSD (which is notoriously conservative - for good and for bad), for some
other "real" Unix systems, and sometimes with coff format executables.

For Linux, you should generate elf files with dwarf debugging.  Dwarf is
a bit more complex than stabs, but has a lot more features and
flexibility, and is better documented.

> 
> Of course, I would be rather keenly interested in knowing where in the
> 1.5 MB of code full of stab statements the error could be???

Ask the linker to generate a map file.  And learn about objdump.

(I don't mean to be rude here - it's just that once you have these
pointers, it is easy to find tutorials and references on the net that
are a lot more useful than anything I could write in this newsgroup.)

> 
> But the linker will not tell me, why should it?
> 
> If you are the developer of the linker and you know only gcc is around
> why bother specifying the module and line number or index of the stab or
> whatever. A sensible error message is too much asking here.

The linker is from a different project from gcc - it is part of the
binutils project that also contains the assembler and the librarian
"ar", and some other utilities.  The gcc developers and the binutils
developers talk to each other, and are under the same GNU umbrella, but
they are not directly connected.  People use the gnu linker with other
compilers and other languages, they also use gcc along with different
linkers and assemblers.


> 
> Another problem (solved this one) was the c library. I could not compile
> the headers of gcc, full of strange stuff with __attribute__ whatever.
> But making appropiate #defines solved that problem and I could link,
> albeit without the debug info.

The "strange" __attribute__ "stuff" is all documented in gcc's manual,
to at least some extent.  And I don't think you mean "the headers of
gcc" - I think you mean "the Linux headers" and/or "the glibc headers".
 Both of these are projects that are independent of gcc, but make use of
many of gcc's extensions.

> 
> Problem is, I am generating stabs and gcc has changed to dwarf. Do they
> correctly support stabs any more?

If you want to make code suitable for Linux, generate elf files with dwarf.

> 
> If that is the case I would have to rewrite the debugger and use my own
> format. I remember that I had a debugger using the ptrace interface back
> then.
> 

[toc] | [prev] | [next] | [standalone]

#100621

Le 29/12/2016 à 12:21, David Brown a écrit :
> If you compiled without optimisation and/or with debug information,
> executables will be big.  Debugging information can be several times as
> big as the code itself.

I expressed myself badly. The compiler generated by gcc was OK, but 
then, I started this compiler to compile again the code and for the 
first time, lcc was compiling code. The generated code (lcc's NOT gcc's) 
was bloated but an executable nevertheless.

C is translated into assembly using often an intermediate language that 
is adapted to a machine description.

Rewriting the machine description implies choosing the right 
instructions of the machine for doing the elemntary tasks that the 
language supports (adding, multiplying, whatever).

[toc] | [prev] | [next] | [standalone]

#100634

On 29/12/16 21:38, jacobnavia wrote:
> Le 29/12/2016 à 12:21, David Brown a écrit :
>> If you compiled without optimisation and/or with debug information,
>> executables will be big.  Debugging information can be several times as
>> big as the code itself.
> 
> I expressed myself badly. The compiler generated by gcc was OK, but
> then, I started this compiler to compile again the code and for the
> first time, lcc was compiling code. The generated code (lcc's NOT gcc's)
> was bloated but an executable nevertheless.
> 
> C is translated into assembly using often an intermediate language that
> is adapted to a machine description.
> 
> Rewriting the machine description implies choosing the right
> instructions of the machine for doing the elemntary tasks that the
> language supports (adding, multiplying, whatever).

Ah, you mean the ARM backend code generator in your compiler is not very
efficient?  Fair enough - you start with a simple and inefficient
generator, then improve it as you further develop the tool.

Good luck with the project.

[toc] | [prev] | [next] | [standalone]

#100500

On 28/12/16 19:11, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/12/16 13:45, Richard Bos wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> The Chinese government is not interested in monitoring the sort of
>>>> people that buy these cards,
>>>
>>> *Shakes head even more sadly*
>>>
>>
>> Do you even know who typically buys these cards, and what they do with
>> them?
> [...]
>
> Does anyone else remember when this was a C newsgroup?  Good times.
>

To try to bring the thread a little back on topic, these sorts of cards 
are good for C programming.  They are big enough (memory, cpu, etc.) to 
use C without worrying about resource constraints, and with 
full-featured compilers and whatever libraries you might wish for.  At 
the same time, they are often used in control applications and are small 
enough that the efficiency of C makes it a common choice of programming 
language.

And Jacob was talking about compiling C on it, and even compiling his C 
compiler on it, before we got side-tracked.

[toc] | [prev] | [next] | [standalone]

#100544

Keith Thompson <kst-u@mib.org> wrote:

> David Brown <david.brown@hesbynett.no> writes:
> > On 28/12/16 13:45, Richard Bos wrote:
> >> David Brown <david.brown@hesbynett.no> wrote:
> >>> The Chinese government is not interested in monitoring the sort of
> >>> people that buy these cards,
> >> 
> >> *Shakes head even more sadly*
> >
> > Do you even know who typically buys these cards, and what they do with
> > them?
> 
> Does anyone else remember when this was a C newsgroup?  Good times.

Yeah, all those years ago, when people didn't consistently take the
trolls seriously... good times indeed. Sadly, they're long gone.

Richard

[toc] | [prev] | [next] | [standalone]

#100373

On Tuesday December 27 2016 17:44, in comp.lang.c, "jacobnavia"
<jacob@jacob.remcomp.fr> wrote:

> Look, the chinese are clever.
> 
> Clever people.
> 
> I bought one of their marvels, a small circuit, not much bigger than a
> phone, with an arm64 quad core CPU, 2GB Ram, Linux, ethernet, and
> everything you would need to ssh into it from my mac. The circuits
> starts at 15 US$, but I invested more, and for around 30$ I bought a
> transparent case, and the high end model with the 2Gigs.

Jacob, I'm glad that you find this sort of device interesting.

But, it is not unique. There are quite a few different cheap, small,
single-board computers out there, all matching or exceeding the specs you
showed. And all in the $15 range.

Some names to look up:
  Raspberry Pi
  BeagleBoard
  Gumstix
  Orange Pi

And, since you have an interest in Microsoft Windows computers, you should
know that many of these devices can run Windows, of various flavours
(including Windows 10 for Arm).

Just so you know  :-)
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#100376

Le 28/12/2016 à 00:03, Lew Pitcher a écrit :
> On Tuesday December 27 2016 17:44, in comp.lang.c, "jacobnavia"
> <jacob@jacob.remcomp.fr> wrote:
>
>> Look, the chinese are clever.
>>
>> Clever people.
>>
>> I bought one of their marvels, a small circuit, not much bigger than a
>> phone, with an arm64 quad core CPU, 2GB Ram, Linux, ethernet, and
>> everything you would need to ssh into it from my mac. The circuits
>> starts at 15 US$, but I invested more, and for around 30$ I bought a
>> transparent case, and the high end model with the 2Gigs.
>
> Jacob, I'm glad that you find this sort of device interesting.
>
> But, it is not unique. There are quite a few different cheap, small,
> single-board computers out there, all matching or exceeding the specs you
> showed. And all in the $15 range.
>
> Some names to look up:
>   Raspberry Pi

That is a 32 bit system. The hardware is 64 bit but the software is all 
32 bit with no plans to upgrade. They say 32 bit is enough for what they 
want to do. They do not want to do a PC;

>   BeagleBoard

Looks too small to me, just 512K RAM and 4Gig mass storage
>   Gumstix

Way to expensive at US$ 200...

>   Orange Pi

WOW! an SATA interface, but only 1GB RAM and in some models that RAM is 
shared with the GPU... Difficult to say.

>
> And, since you have an interest in Microsoft Windows computers, you should
> know that many of these devices can run Windows, of various flavours
> (including Windows 10 for Arm).
>

Yes, I know, but I like Unix, I am in a nostalgic trip. Maybe I should 
develop for the Microsoft version, the pine 64 also has a Windows 10 
solution.

> Just so you know  :-)
>

Thanks. Good info.

[toc] | [prev] | [next] | [standalone]

#100378

On Tuesday December 27 2016 18:36, in comp.lang.c, "jacobnavia"
<jacob@jacob.remcomp.fr> wrote:

> Le 28/12/2016 à 00:03, Lew Pitcher a écrit :
>> On Tuesday December 27 2016 17:44, in comp.lang.c, "jacobnavia"
>> <jacob@jacob.remcomp.fr> wrote:
>>
>>> Look, the chinese are clever.
>>>
>>> Clever people.
>>>
>>> I bought one of their marvels, a small circuit, not much bigger than a
>>> phone, with an arm64 quad core CPU, 2GB Ram, Linux, ethernet, and
>>> everything you would need to ssh into it from my mac. The circuits
>>> starts at 15 US$, but I invested more, and for around 30$ I bought a
>>> transparent case, and the high end model with the 2Gigs.
>>
>> Jacob, I'm glad that you find this sort of device interesting.
>>
>> But, it is not unique. There are quite a few different cheap, small,
>> single-board computers out there, all matching or exceeding the specs you
>> showed. And all in the $15 range.
>>
>> Some names to look up:
>>   Raspberry Pi
> 
> That is a 32 bit system. The hardware is 64 bit but the software is all
> 32 bit with no plans to upgrade.

Apparently, SuSe has released a 64-bit Raspberry Pi 3B distribution of their
Enterprise Server. So, the current versions of the Raspberry Pi aren't
necessarily 32bit systems; they are 64bit CPUs with a choice of 32bit or
64bit operating system.

[snip]

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#100379

Le 28/12/2016 à 00:44, Lew Pitcher a écrit :

>
> Apparently, SuSe has released a 64-bit Raspberry Pi 3B distribution of their
> Enterprise Server. So, the current versions of the Raspberry Pi aren't
> necessarily 32bit systems; they are 64bit CPUs with a choice of 32bit or
> 64bit operating system.
>

Ahh, that's news to me. Did not know about that. I bought a Pi in 
September but after trying desperately to get a working amd 64 machine 
with linux, I gave up and bought the pine 64.

I am downloading the Suse server now. Let's see. I have still the R. Pi 
there!

[toc] | [prev] | [next] | [standalone]

#100404

On 27/12/2016 23:44, jacobnavia wrote: [snip thoughts on arm64 SoC]

Why don't you post these thoughts to your personal blog?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web