Raspberry brings out 5 dollar computer

Hi all,

On 27-11-15 02:32, John Larkin wrote: >>

>> They say it's 6x faster, but can a user actually take advantage of the multiple >> cores? Last I looked (around the Transputer days), no one really knew what >> to do with multiple CPUs in general-purpose applications. Only array/matrix >> apps seemed to really benefit.

Anybody any here experience with bare-metal programming on a Raspi? Or some RTOS?

At that price, it would make a good pair with some some cheap MCU-based board (STM32F4 or something): use the STM for I/O and real-time stuff, DSP-stuff and the Pi0 for networking, visualisation, computation, ...

The only thing question I have at this point. Is this 5 of 3.3 volt? (or "can it be run at 3.3 volt?")

Cheerio! Kr. Bonne.

Hi,

These days, they try to hack EVERYTHING, including home-automation systems (provides information when somebody is at home, camera pictures of the bedroom, ...) , IoT water kettles (who happen to leak the wifi password of the network on which they are connected), car info-tainment systems (gives access to other software in the car, e.g. to follow somebody remotely), mobile phones (to read your messages, keeptrack where you are, ...) ...

User-workstations and come-PCs are quite interesting provide they are used to access to documents, are used for online payments with credit-cards, etc

I was in a security-conference two days ago. The message was simply this: In essence, hackers are interested in money, people and information, and whatever tool they can be used to access that is OK, but (of course) badly protected devices are prefered. Nowdays, that are usually embedded device you have at home or in the office running some stripped down version of linux that has never been updated/patched in the last 3 years but DOES is accessable from the net.

Cheerio! Kr. Bonne.

Our instruments currently use a single-core CPU and, usually, and FPGA. The main loop, communications and control, is a combination of interrupt handlers (ethernet, serial, some slow i/o) and a central stste machine. Fast realtime stuff, like PID loops, is done in periodic interrupt routines and, if we use an FPGA, in FPGA hardware. It would be nice to have multiple CPU cores so we could scatter these things and not care so much about competition for CPU cycles.

We did a couple of microZed projects, dual-core ARM plus FPGA (Xilinx ZYNQ), but we used Linux so we can only suggest to the OS that one CPU do the fast stuff. That actually worked well, and we have some timing measurements on that. I think the "realtime" CPU was never suspended for more than 20 us, something like that.

There is a microZed appnote for running Linux on one core and true bare metal on the other, which would be cool if no suspension of the realtime process could be tolerated...

Once you have an FPGA on the board you can add as many soft core CPUs as you wish. This is a great way to do things like PID loops. Complex processors like the ARM take up significant silicon even when done as a hard core. But a simple CPU can be done in a relative handful of LUTs. Unless your real time stuff need a whole lot of memory it can be harder to configure one of the ARM CPUs than it is to invoke a soft core CPU.

If your programmers can break out of their C language rut I would recommend the J1 CPU. It is a stack based design intended to run fast and take up little space. At 100 MHz it can do video compression (what it was designed for) so it should be able to run a number of PID loops or anything else you are likely to need in software. This should greatly improve on your design unit reuse.

--

Rick

The "famous line" is "Given enough eyeballs, all bugs are shallow".

The problem though, and specifically the problem with Windows, is that people become inured to the prevalence of bugs. So I present Heath's revision of the adage:

"Given enough bugs, all eyeballs are shallow:.

Clifford Heath.

I built a lock-free library in C++ (even had inlined asm() calls in C++ templates!) and a multi-threaded peer-to-peer file distribution system which has a number of large-scale deployments operating in critical enterprise environments. So yeah, I know a bit about lock-free coding.

Some problems parallelize easily - for example vector processing. My P2P app was medium complexity. A DBMS or O/S kernel on the other hand has an enormous amount of overlapping dependencies from global scale down to very fine-grained, and it takes a very special kind of mind to do that and get it even close to right.

So Phil, the problem with threaded coding isn't the very small number of people who can do it well, or the small number of problems for which it is easy and works well. The problem is the large number of people who do it, but do it badly - and don't even know. You can't find all problems with such software by testing. Problems emerge even after a decade of real-world deployment. Do we want to build our civilization around such software?

Or should we be building languages that can be automatically parallelized and cannot in principle have this kind of problem?

That's what Ericson did with Erlang. You just can't Ctrl-Alt-Delete a telephone exchange on a whim.

It's also possible with Haskell - the compiler can prepare the program to run on as many cores as available at runtime.

Clifford Heath.

I'm glad you have only had to parallelize simple things.

For the class of problems like DBMS solve, 1% is almost certainly optimistic.

:)

We found an unexplained SSH cert in roots account, and changes made to several system binaries during autopsy of one of our VMs last week. It was deteccted because it was taking up all the "bandwidth", shut down, and the desired services migrated. we suspect the exploit was deployed via a disused magento or wordpress install on that server.

--
  \_(?)_

"FREAK" "POODLE" and "Heartbleed" are three examples from the last 12 months.

--
  \_(?)_

My guess is It'd be close to $5 PI foundation seems to be a well run not-for-profit.

--
  \_(?)_

The problems are locking, contention, non-atomicity, and other ways that one thread can mess up another. I wrote a threaded HTTP server that would crash for unexplained reasons (project was abandonned) and a threaded oceanic seizmic survey streamer solver that seemed stable enough on linux, but didn't play nicely with VB on windows, but the single threaded version was fast enough.

--
  \_(?)_

On a sunny day (30 Nov 2015 11:10:01 GMT) it happened Jasen Betts wrote in :

libpthread (Linux) has a whole bunch of useful functions for locking etc. In my applications usually a simple flag as handshake is enough to tell the main GUI soft that new data has been collected by a thread. I am at an advantage there because I use libforms (xforms GUI library) and it has already full support, and an idle_thread so that takes care of GUI. Also it is a GUI library with only a few kB size ~ # l /usr/lib/libforms.so lrwxrwxrwx 1 root root 15 Jul 13 2012 /usr/lib/libforms.so -> libforms.so.1.0* ~ # l /usr/lib/libforms.so.1.0

-rwxr-xr-x 1 root root 1844127 Jul 13 2012 /usr/lib/libforms.so.1.0*

~1.8 MB, not bad !

quite different from what I think is time-slot oriented crap like Qt. Qt 4 took hours to compile on my system, well I have reported about hat fiasco here, Nokia bought it, Nokia is gone.

MS windows? There seem to be more versions than I know about, old win32 code does it still run? Why bother, MS is dead.

A whole load of GUI based stuff and not GUI based stuff I wrote for Raspberry (Linux) runs fine with threads, some loading it to just the absolute maximum as far as processor goes.

OTOH there is thing like mplayer (Linux) that has no threads IIRC (does not want threaded code in it) and plays just great, and xine (media player) that is threads based and takes a while to figure out what you mean when exiting.... threads to terminate I think. So it depends, depends on how it is written, both are great media players and I use both, plus ffmpeg ffplay...

Architecture, takes some doing (before you start coding) to figure out the best way.

On 30 Nov 2015 10:25:13 GMT, Jasen Betts Gave us:

All EXPLOITS of the same singular original bug. List the plural bugs, not the plural exploit attempts.

Events in different threads can happen in any order. Writing thread-safe code isn't any harder than making it exception-safe and async-signal safe. It's easier in C++ than most, because you can use RAII (resource acquisition is initialization) to make sure you acquire and free resources in the right order, and don't sit on one waiting for the other, when another thread is doing the reverse.

Duplication of thread-interaction code is a major no-no for all the above reasons.

I haven't looked much at lock-free coding, but AIUI it's faster and equally reliable under some situations.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net

Nope. Poodle is a design flaw in SSL 3, Heartbleed is an implementation bug in the heartbeat code, and Freak is a MITM attack on servers that permit legacy "export-grade" encryption keys. Completely unrelated. Just climb off it, dlu1--most of us are fond of Linux, but it has its security problems just like any other giant code base. It isn't as bad as Windows, but these days most of the exploits are against apps rather than the OS, even on Windows. (That is, if you discount the fact that Windows itself is now malware, courtesy of 'telemetry' etc.)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net

On Mon, 30 Nov 2015 10:02:45 -0500, Phil Hobbs Gave us:

Linux is not SSL and SSL is not Linux. It is not a "code base", it is a compilation of applets.

The most secure systems in the world are indeed Linux based and that is a fact. Just because some lame ass calling himself an admin uses some off the shelf boilerplate setup that has been hacked and attacked, doesn't meant the entire gamut is at fault.

Phil, all,

The keyword in this all is not "linux" or "windows", it is about "code-quality" and -to be more precise- "code-quality of open source projects".

Everybody know it: the idea that OS is more secure has been that

-because open-source software is ... well "open"- everybody can look at the code, find bugs and correct it.

The famous line: "giving enough eyeball, all bugs will be swallowed"

However, it has become clear that things are note that simple.

The reality is different. Althou the source-code of open-source projects may be accessable, very few people actually do that.

Most open-source projects are have very few people (two, three, four, ...) at their core. The reason is simple: vey few people have both the coding-skills and the background knowledge to really understand how a complex Opensource project works and know how all the different pieces fit together.

And THIS is the reason why bugs like "heartbleed" got unnoticed for so long. OpenSSL -at its core- is maintained by (if I remember correctly) three people.

I am not saying that closed-source is -by definition- better; and also the open-source community it reorganising itself to try to fix this (e.g. by crowed-debugging, bugbounties, etc.).

For me, the question wether open-source or closed-source is more security does not have a black-our-white answer.

I think the best idea is that ALL software has bugs and that some of these bugs do result in security flaws, no matter how the code is produced.

Cheerio! Kr. Bonne.

On Mon, 30 Nov 2015 19:13:27 +0100, kristoff Gave us:

Ooops!

Bwuahahahaha! BRL!

Sure thing. But you overstated your case very badly. 1% of 1% is far from the truth.

I'm not against language support for that sort of stuff. I wouldn't want to write all my own vtables either.

I imagine it is. Doesn't fix the hyperbole though. I wouldn't want to build a civilization on random people tossing out random statistics. (No, wait, we already did. Never mind.) ;(

We'll call it the nutritionists' approach to programming.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
ElectroOptical Innovations LLC 
Optics, Electro-optics, Photonics, Analog Electronics 

160 North State Road #203 
Briarcliff Manor NY 10510 

hobbs at electrooptical dot net 
http://electrooptical.net