Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!



Ask Slashdot: Linux-Friendly Desktop x86 Motherboard Manufacturers?

gnalre 1980's calling (294 comments)

They want their post back.

Seriously Linux motherboard compatibility nowadays is a good if not better(more legacy support) than the latest Microsoft OS.

about 4 months ago

Grand Ayatollah Says High Speed Internet Is "Against Moral Standards"

gnalre In a new development (542 comments)

The Grand Ayatollah announced that High Speed Internet is immoral via youtube yesterday, followed quickly by the Internets 1st selfie beheading..

about 4 months ago

John McAfee Airs His Beefs About Privacy In Def Con Surprise Talk

gnalre Maybe wait a little till judgement (124 comments)

He may well be right...However John McAfee has a well earned reputation of drugged out paranoia, so I think I will reserve judgement for now

about 4 months ago

Do Embedded Systems Need a Time To Die?

gnalre Sympathy, but no go (187 comments)

As someone who has to support legacy systems, there is nothing more I would like to see old embedded systems die (and in some cases, incinerated and the embers crushed into the ground).

But we have to be realistic.

The main effort in systems like SCADA is the commissioning time required. You cannot just rip out a system, plug in a new box and expect everything to work as before.

Secondly who pays for this? The customer will not be happy if we say every 5 years we say you have to close your factory down for 2 weeks while we rip out all your old boxes and replace with new ones.

Finally what is the guarantee that the new box has not introduced a new security hole?

The real solution is the segmentation of the security and application code. Use Trusted boot technologies to verify the running code and ring fence the code with your security management application. Then if a new threat is introduced you only need to update the security app, leaving the hardware and application untouched.

Unfortunately at present industrial application either have no security or are very closely coupled meaning that updates are difficult and costly.

about 7 months ago

AMD Beema and Mullins Low Power 2014 APUs Tested, Faster Than Bay Trail

gnalre Re:Bluestacks? (66 comments)

The chip is specifically for security. It runs a embedded secure environment that the main processor can use to verify executables before they are run. It has nothing to do with android apart from the fact the same technology can be used to secure mobile devices(stop your phone being rooted etc)

Being part of the main processor means it should be harder to break into unlike the intel TPM solution which requires a separate off-chip device

about 8 months ago

AMD Beema and Mullins Low Power 2014 APUs Tested, Faster Than Bay Trail

gnalre Also with ARM (66 comments)

The summary missed the most interesting part of this chip in that it contains a ARM core running trusted zones Trusted Execution Environment.

This makes them quite interesting for highly secure applications such as industrial embedded controllers

about 8 months ago

Erik Meijer: The Curse of the Excluded Middle

gnalre Re:Sounds like my old comp-sci professor. (237 comments)

Sounds more like a loss of faith rather than a language problem. I have sympathy, but if you are not an expert in a domain, whenever a problem arises the 1st reaction is to go back to safe ground.

Unfortunately while all programmers know imperative languages, few are taught functional techniques when first programming. Until that happens it is unlikely that functional languages will ever be much more than a sideshow despite there obvious advantages because there are very few problem domains that can only be solved in functional languages.

about 8 months ago

Nate Silver's FiveThirtyEight Relaunches As Data Journalism Website

gnalre Well that was quick (60 comments)

Errr, it's just disappeared. What's the statistical chances of that happening after being highligted on /.?

about 9 months ago

The Higgs Boson Re-Explained By the Mick Jagger of Physics

gnalre Re:Stil waiting. (94 comments)

I would recommend the particle at the end of the universe by Sean Carroll.
It covers a lot of the same material as the comic but in more detail and also puts it in historical context.

The only bad thing about it is that when you realise that what we call matter is nothing more than the manipulation of energy fields it do end up worrying about your personal concept of reality.

about 10 months ago

N. Korea Could Face Prosecution For 'Crimes Against Humanity'

gnalre Re:And how will they bring him to justice? (325 comments)

Send a fleet of C-130 Hercules filled with lawyers and drop them on Pyongyang at 10000 ft.

If that doesn't work send another fleet and drop more lawyers, but this time give them parachutes

about 10 months ago

Why Improbable Things Really Aren't

gnalre Re: The day before Fukashima happened (166 comments)

There are well defined techniques for measuring the probability of events happening in industrial safety. Safety Integrity Levels or SIL are used to categorize the possibility of a life threatening event occurring.

The problem is how low a risk do you need and how much will it cost you to get there. Fukashima would probably not have happened if the sea wall had been higher, but the designers had to make the judgement that it was not worth the millions of cost required to build a bigger wall compared to risk of it being breached. Unfortunately decisions like that in hindsight always look flawed.,

about 10 months ago

What Are the Weirdest Places You've Spotted Linux?

gnalre 30000 ft (322 comments)

At 30000 feet on a united 767 on the entertainment system. It had to be rebooted so i could tell it was red hat and a lot more info too

about 10 months ago

Death Hovers Politely For Americans' Swipe-and-Sign Credit Cards

gnalre Re:I guess they have never heard of two factor aut (731 comments)


The point is that yes you can get the pin. But without the physical card it is useless because you need both to complete a transaction.

If your card was skimmed the more likely explanation was that the magnetic strip was skimmed and then used at a place that did not use chip and pin verification. Until we can remove the mag strip this will happen.

Places like the States resisting going to chip+pin means that the rest of use are paying

about 10 months ago

Death Hovers Politely For Americans' Swipe-and-Sign Credit Cards

gnalre Re:Sorry, it's horribly insecure, (731 comments)

You cannot skim the chip on a chip and pin device. They maybe able to intercept the pin, but without the card that information is useless. More likely the magnetic strip was skimmed and that information used where chip+pin is not used such as the states.

about 10 months ago

Death Hovers Politely For Americans' Swipe-and-Sign Credit Cards

gnalre Re:It's about time. (731 comments)

One rule - YOU NEVER GIVE YOUR PIN OVER THE PHONE. or in fact any personal details. especially if they ring you.

Web and Phone verification is different. Web can be via CVS number at the back of the card plus previously defined password. Some companies provide a one time key system. Over the phone is more difficult. Again they ask you part of a password such as the 3 and 7th letter or ring/text back to your mobile phone

The important point in this is that the Pin itself is useless without the card. Unlike magnetic strips there has never been any example of a chip being skimmed and duplicated. Unfortunately cards still retain magnetic strips so that they will work in places like the states. This means cards can still be skimmed, copied and used. but if the card is skimmed in Europe and then used in the States it is is pretty easy to prove that it was not you.

Card security is like any other security. It is as strong as the weakest link. Unfortunately that is the USA at present

about 10 months ago

Death Hovers Politely For Americans' Swipe-and-Sign Credit Cards

gnalre Re:It's about time. (731 comments)

Not if you don't want to. You are able to change your Pins at a ATM

about 10 months ago

Death Hovers Politely For Americans' Swipe-and-Sign Credit Cards

gnalre Re:Questions (731 comments)

If the network hardware was compromised, what would've stopped the hackers from collecting the PINs as well?

The pin is useless without the card and unlike magnetic strip cards the card cannot be easily duplicated

With this increase in security encourage hackers to go after debit cards more - which would be worse for consumers (fewer fraud protections there)?

Not if credit and debitt cards have the same chip+pin system

Will there even really be a difference between credit and debit cards anymore?

It terms of security they will be equally secure

How will this affect online transactions (especially for web developers)?

It won't. Chip and pin does not work online, so other security mechanism's have to be used such as quoting the 3 fig number on the back of the card or a extra verification step involving a password or a one time key.
This sounds like a bigger change than some people realize.

about 10 months ago

A Corporate War Against a Scientist, and How He Fought Back

gnalre Unfortunately nothing new here (253 comments)

This is nothing new. When big business and science collide, big business know no bounds as to what they will do to protect there profit margin

Examples include

Industry attacks against Clair Patterson from the leaded fuel industry.
The tobacco lobby against health professionals
The CFC industry against climate scientists

They continue today with attacks against climate scientists from big oil and coal concerns.

The worry is that the public seem more minded to side with the vested interests against the scientific voice and the fact that many of the attacks come from scientists working within the industry showing a severe lack of morality by the people in those areas. All industry seem to have to do is raise the spectre of potential economic harm and the public go along with them.

about 10 months ago

More Bad News For the F-35

gnalre Funding Crisis (401 comments)

Cost of 1 F-35 $300 million
Cost to keep Mars Rover operating 1 year $14 million

I know where my money would go...

about a year ago

Redesigned Seats Let Airlines Squeeze In More Passengers

gnalre Re:How many people buy a ticket based on leg room? (466 comments)

I could sit on a bicycle seat in almost standing position if it'd pass safety regulations and brought decent savings.

Please do not give RyanAir any ideas. They are doing perfectly well in making flying the travel equivalent of water boarding themselves without any extra input

about a year ago



Erlang Programming

gnalre gnalre writes  |  more than 5 years ago

gnalre writes "Some time ago I reviewed Programming Erlang. My opinion was that it was good beginner's book, but I set the challenge for a book for the more advanced Erlang developer. It shows the power of a Slashdot review that only after a two scant years a new set of Erlang books are about to be published.The first of these new books is the imaginatively tiled "Erlang Programming" (ISBN 978-0-596-51818-9) published by O'Reilly therefore exhausting the possibility of any other books using the words 'Erlang' and 'Programming'. So does this book answer my challenge? And just as importantly is it any good? To find out these answers read on.....

The book is written by Francesco Cesarini and Simon Thompson. Before I begin the review, a public confession is needed. Many years ago Francesco and I worked together. I first met him when he was hired to provide training and support in Erlang. Wearing me down over many long lunches, he got me to appreciate Erlang's beauty, simplicity. In fact whenever people ask (or beg) me to stop telling them how Erlang is better than the language they are currently using, I often think of Francesco's enthusiasm for the language. Since then he has gone on to create his own company erlang training and consulting, which has allowed him to consult with many of the main Erlang users, as well as maintain his involvement in the development of the language. Of course you are quite within your rights to ask how I can remain unbiased in this review, but I can assure you that while I have made it known that I am open to bribes; none so far have been forthcoming. The Review

I am always intrigued by what metaphor O'Reilly books is trying to convey with there choice of animal covers(the warty toad for windows XP unleashed instantly comes to mind). In this case the bush tailed rat kangaroo image is used and I am struggling to see the connection with Erlang. Especially when (considering Erlang's Swedish roots) something like a moose would seem more appropriate (you may add your own Holy Grail moose jokes here).

The book itself is in the usual clear O'Reilly style and consists of 20 chapters split over 450 pages. The introduction starts out by setting out why you should be interested in Erlang by emphasising it strengths. It does indicates that some programming experience is expected, but the book does not make to many demands in that area (however an open mind is useful unless you have met functional languages before).

One interesting nugget of information is how many well known web and software development companies currently utilise Erlang in some way. Erlang has come a long way from its telecom's roots, with companies such as Amazon, Yahoo and Facebook routinely developing applications in it. In many ways it rivals Lua as the most popular computer language that no one has heard of (Please debate). If nothing else at least you know where to send your C.V. after reading the book.

As you start reading the book it quickly becomes apparent that the book is not intended purely as a language reference, but also a tutorial on how to create Erlang applications. The author's industrial and consulting experience shine through here, with information at every stage on the best development approaches and possible pitfalls. One of the things I consistently liked about the book is that when the authors felt there is a weakness in Erlang they did not gloss over it, but instead highlighted it and described the best methods to overcome them.

The simplicity of the language means that the basic syntax of the language is covered in less time than most languages takes to explain their data types. By the time Chapters 2 and 3 are finished a reader should know enough to create their first Erlang program. Chapter 3 also provides a good description of recursion, which is of fundamental importance when programming Erlang, and a considerable headache to those of us born without in-built stack pointers.

However using Erlang as a sequential language would be like using a mobile phone to hammer in a nail. Erlang is about parallel programming and in Chapter 4 we get to Erlang's real strengths. This chapter takes the reader through the primitives available to write parallel programs. It also makes a good attempt at explaining the misconceptions about Erlang's light weight processes, especially to programmers formerly only aware of threads and normal processes. It explains how you must move away from the idea of processes being heavy weight objects to be used sparingly, to the Erlang philosophy of using processes as almost disposable objects.

In Chapter 5 the book starts getting more adventurous by describing common Erlang process design patterns. These patterns are intended to simplify many of the type of programming situations that you are likely to come across such as Client/Server. This is a good starting point for your first Erlang application. Chapter 6 goes onto explain what to do when Erlang programs go bad by describing the handling of faults and the recognition of process failures.

The functionality that most impressed me when I met Erlang was its capability to "hot swap" its code. Would'nt it be great if all languages had the same capability. Of course Erlang's much vaunted "high availability" moniker would not be achievable without this feature and Chapter 8 provides a good overview on how to achieve it in your own programs.

It is in chapter 9 that the book makes a stunning admission — Erlang is a functional language. Presumably the authors took so long to come clean about this in the hope of seducing programmers who hold a prejudice against such languages. After this shock admission, the chapter goes on to state Erlang's functional programming credentials

A language more often than not succeeds or falls because of its libraries. In Erlang this is provided by OTP (OTP stands for Open Telecom Platform. The name itself is a hangover from Erlang' days as a language for writing telephone exchange switches). In Chapter 10 the book starts describing some parts of the OTP, starting with ETS, the memory based database and its disk based cousin DETS. In fact (D)ETS are a important part of Erlang providing an efficient way to store and retrieve large amounts of data shared between processes.

Chapter 11 and 12 expand on previous chapters describing how to extend Erlang concurrency to distributed systems, and explains how the the design patterns described in chapter 5 are formalised by the OTP behaviours library.

In chapter 13 we meet Mnesia. Mnesia is probably one of the most powerful components of the Erlang OTP library, a database system written in Erlang and taking advantage of Erlang's concurrency and robustness. As the book itself admits, Mnesia may not be the right tool for every situation. Even so Mnesia is an essential application to learn if you wish to understand Erlang and the subject is probably worthy of a book itself, so one chapter, however well written, can only scratch the surface.

In chapter 14 the book describes how to attach a GUI to Erlang using the Erlang binding to the wxWidgets C++ Library. To someone who learned the old TK GUI wrapper that made your applications look like they were designed in the 60's this is definitely an improvement. Chapter 15 explains how to utilise the OTP network libraries, while Chapter 16 looks at how to interface with other "lesser" programming languages, such as Java and C.

The book finishes off by describing some of the Erlang development tools for documentation and automated testing which we all intend to use but never quite get round to investigating (all our code is self-documented and perfect, right?)

Chapter 20 finishes the book off with timely a reminder on writing Erlang in a good coding style. Conclusion

So is this the ultimate book for the advanced Erlang programmer? The answer is not quite. For example there are areas that I would have liked more detail on. As I have already mentioned, Mnesia is worthy of a book to itself, so a solitary chapter was never going to cover it in enough depth. Also while certain areas of the OTP library are discussed, the majority is only lightly touched on and anyone who is serious about Erlang development will eventually need to gain a better understanding of this area. Finally at some point the problem to be solved becomes as important as which language is used. A description of how Erlang is used in some of its flagship applications would be welcomed. However this is probably just my feeling since I was indoctrinated by Erlang years ago (and own an Erlang tee shirt and mug to prove it). Anyone who has not investigated Erlang before will find plenty of advanced concepts throughout the book.

It also is worth considering what has changed since the last Erlang book was released. Since that time, Erlang is no longer alone in its niche(highly reliable concurrent systems.) with languages such Scala also being promoted. On the opposite side of the coin, Erlang has increasingly found new applications in supporting many of the new Web 2.0 and cloud architectures arising today, a usage the Erlang language inventors could not of foreseen when they designed it. Any new book therefore needs to address these new usages. This book fulfills that function very well, bringing Erlang documentation into line with its current usage.

Most importantly is the book any good? The answer to this has to be an unreserved yes. The training and industrial experience of the authors is always apparent and combined with the O'Reilly style it has produced an excellent up-to-date book for any person starting their Erlang development or for someone who is just interested in dipping in their toe for the first time.

Tony Pedley is a senior engineer specialising in real-time embedded systems. In his spare time he likes to arrange his O'Reilly books in a taxonomic hierarchy."

Programming Erlang Book

gnalre gnalre writes  |  more than 7 years ago

gnalre writes "Every day it seems there is a new publication of a book on perl/python/ruby. Some languages however do not seem to get that sort of attention. One of those under-represented languages is Erlang, however for the first time in 10 years a new Erlang book has been published!

As someone who had a brief flirtation with Erlang long ago, I was interested to see how the language had evolved in the intervening decade. I was also curious to re-evaluate Erlang to see what solutions it offered to the present day issues of writing reliable distributed applications.

Programming Erlang — Software For A Concurrent World (ISBN 10193435600X) is part of the pragmatic programmer series. As with all the books in this series, it is available in paperback or for a reduced cost you can directly download it in PDF format (which is always useful if you spend a lot of time on the move and you do not like carrying around a dead tree with you). The books format and layout as with all the books of this series are clear and logical.

The book is written by Joe Armstrong, who co-authored the first Erlang book a decade ago. He was also one of the originators of the Erlang language and has been directly connected to its development ever since. We can therefore be assured about the author's knowledge and insight into the language, if not his impartiality.

The book itself can be roughly split into three main sections.
  1. Getting started and Sequential programming
  2. Concurrent Programming
  3. Erlang libraries and advanced Erlang techniques.

In Chapter 1 the author sets out his stall of why Erlang is worthy of your attention. It's clear from this chapter that the author feels Erlang's strength lies in applications requiring an element concurrency and fault tolerance. Another emphasis is made of running Erlang on modern multi-core processors, something that was only a glint in a hardware designer's eye 10 years ago, but is rapidly becoming an issue in all areas of programming. From this chapter you also get a feel on how the author approaches his programming in that he states that he wants the reader to have fun with the language, which is a refreshing change to some language text books whose main purpose appears to be as a cure for insomnia.

Chapter 2 goes through installing Erlang and the Erlang shell (a command line environment similar to ones with languages such as perl). The chapter also starts us into the strange world of functional programming, where variables can only be given a value once (e.g you cannot do i=i+1), recursion replace loops and pattern matching replaces assignments. Fortunately the Erlang language is remarkably concise. For example there are only 4 data types. However to those coming from a purely procedural programming background the learning curve could be a steep one. Saying that the Author does a good job of leading you through the languages intricacies with examples being compared to code from languages such as Java to help keep your feet on solid programming ground.

The next 3 chapters move on to writing simple Erlang programs. As a quick aside, for anyone new to Erlang it is well worth examining the quicksort implementation described in chapter 3. Its conciseness and simplicity was one of the reasons the language won me over when I first met the language.

These chapters also cover error detection and handling. It's worth noting that Erlang has a philosophy of ensuring programs fail hard, so that bugs can be weeded out at an early stage. This idea very much defines how Erlang error handling is defined.

One criticism of the first section is Chapter 6 which describes compiling and running an Erlang program. I would have preferred that this information be covered earlier in the book or be placed in an appendix because it is probably an area you will want to reference repeatedly.

Chapter 7 is where things really get interesting and the true power of Erlang starts to come to the fore. This is where Erlang's concurrency credentials are explained. This chapter begins by providing some useful metaphors of the Erlang concurrent model, but chapter 8 is where the fun begins by describing the Erlang concurrency primitives that allow the creation of processes and the process communication methods. The author here highlights one of the language features, the Erlang light weight process. These are true processes (not threads) but take up very little in the way of resources. Indeed it is not unusual to have 1000's of such processes running in an application.

The next few chapters expand on the available concurrency primitives and how to move from concurrency on your local processor to concurrency utilising the resources of multiple machines either on a local network or across the web. It finishes the section off by showing the example of a simple IRC application.

Chapter 12 starts the next section by looking at how to interact with the world outside the Erlang environment. First it examines how to interface an Erlang program to applications written in other languages such as C. It then goes onto to look at file and socket handling in Erlang. Chapter 15 looks at two important Erlang storage primitives ETS and DETS before we get to the OTP Erlang libraries in Chapter 16.

The OTP libraries are the standard Erlang libraries and tools. In fact the OTP libraries are worthy of a book in itself. The author highlights the section on the generic Server module as the most important section in the whole book and one to be reread until its importance has sunk in. This is because here are encapsulated many of the lessons learned in writing industrial fault-tolerant applications, such the updating of a running applications code without causing that application to miss a beat. The section is finished off by describing the Erlang distributed database (humorously named Mnesia) and then finishing it off with the example of a simple server application.

The book finishes off by looking at Erlang on multicore systems including its support for SMP. As the author states this is the leading edge of present day Erlang and is still under development.


Firstly I would like to thank the pragmatic programmers for publishing this book. Erlang's profile has been in need of highlighting for many years and hopefully this book will help. The book definitely provides a great starting point for anyone who wants to get to grips with the language and takes them to the point where they can start writing useful applications. This book is a worthy successor to the last book published and does a good job of both updating the material and explaining some of the later developments such as SMP. Anyone who has a need for writing fault tolerant applications should at least look at this book. If nothing else you will never be afraid of dealing with recursion ever again.

In many ways the book cuts off just when things are getting interesting. There are hints in the book about real world Erlang's applications and it would have been good if some of these experiences could have been expanded. Hopefully however this book is the start of increased exposure for Erlang. If so then someone may get around to writing another Erlang book describing some of the advanced issues about generating robust applications. I just hope it won't take another 10 years this time.

Tony Pedley is a senior engineer specialising in real-time embedded systems. In his spare time he likes to tease windows programmers and confuse managers by telling them it would be a lot easier if we wrote it in Erlang."


gnalre has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?