Forgot your password?
typodupeerror

+ - Sir Patrick Moore dies aged 89-> 3

Submitted by Tastecicles
Tastecicles (1153671) writes "Patrick Moore was the monocled surveyor of the sky who awakened in millions of people an interest in galactic goings on.

His love of astronomy began at the age of six and that childhood curiosity developed into a lifelong passion.

It was a passion he shared through his programme, The Sky at Night, which he presented for more than 50 years, only ever missing one episode due to illness.

Patrick Alfred Caldwell-Moore was born at Pinner, Middlesex on 4 Mar 1923.

Heart problems meant he spent much of his childhood being educated at home and he became an avid reader.

His mother gave him a copy of GF Chambers' book, The Story of the Solar System, and this sparked his lifelong passion for astronomy.

He was soon publishing papers about the moon's surface, based on observations made with his first three-inch telescope. His 1908 vintage typewriter enabled him to publish more than a thousand books on subjects ranging from astronomy, his first love, to cricket, golf, and music."

Link to Original Source
Space

+ - Death of Sir Patrick Moore-> 1

Submitted by Coisiche
Coisiche (2000870) writes "Breaking news on the BBC news site reports the death of Sir Patrick Moore, renowned broadcaster and astronomer who will probably be most familiar to UK readers. He might be known outside of the UK for being the presenter of the long running TV show, "The Sky at Night".



When I was growing up just about every space related news I saw was presented by him. As well some of his books on astronomy I also read a series of fictional books he wrote for a juvenile audience that featured some travels around the solar system."

Link to Original Source
Book Reviews

+ - Book Review: Software Build Systems

Submitted by MassDosage
MassDosage (1967508) writes "Software Build Systems Review by Mass Dosage

Software Build Systems by Peter Smith is a well written, albeit rather lengthy book that covers the intricacies of systems used to build software. It tries to do this in a technology-neutral manner where possible but covers existing tools like Ant, Make and Scons as a means of illustrating the various concepts covered instead of just focusing on theory. The real world examples illustrate building Java, C/C++, C# and Python software and cover scaling up from small builds with tens of source files up to massive builds with tens of thousands. All of the technologies used are introduced in some depth which newcomers should find useful but experienced build developers may want to skim over.

Software Build Systems weighs in at a hefty 580 odd pages and covers a lot of ground. It is targeted at developers, managers and build engineers and while there is definitely something for all of these groups, each of them will most likely find themselves skipping sections which are either not of interest to them or are too basic. It is also important to note that this book is not a hands-on tutorial of how to set up a build system from scratch but instead uses a variety of detailed examples to illustrate its concepts with pointers to external documentation for those wanting to actually implement a complete build system of their own.

The book is clearly divided into parts which move from "The Basics" to "The Build Tools" and then on to "Advanced Topics" and finally "Scaling Up". "The Basics" really is basic and most build engineers and developers worth their salt can probably skim read most of this. The fundamentals of C/C++, Java and C# are also covered illustrating a major theme in this book in that it tries to be programming language neutral and just use the different languages as examples to explain various concepts. While this is an inclusive, worthwhile aim it does mean that someone only interested in say, building Java software, will find large parts of the book irrelevant. This applies particularly to the chapters on the various build tools where Make, Ant, SCons, CMake and Eclipse are all covered in painstaking detail. The pros and cons of each of these tools are discussed in a non-biased manner using real world examples where possible. Anyone who has actually written a build system using one of these tools probably won't find much they don't already know but for a manager or someone new to any of these technologies the author provides a a good introduction with mentions of similar tools and pointers for finding out more about each of them.

"Advanced Topics" is where things start to get interesting as concepts like dependency graphs, change detection and version management that the build tools rely on to function are discussed in depth. A lot of the advice in these chapters feels like it comes from practical experience and the best parts are where tool-neutral tips are provided. There is a bit too much detail here as well as the odd digression which feels unnecessary in a book of this length. Do we really need to know the details of lex and yacc in order to create a build system? The author clearly has an understanding of open source development and competently discusses the wild world of building software that may run on a plethora of machines and platforms that the developers have little or no control over as well as software that is built in a more clinical manner for a limited set of environments.

Build systems for massive software projects are covered in "Scaling Up" and the author acknowledges that this probably isn't relevant for everyone. I however think that the first chapter in this section ("Reducing complexity for end users") is the best in the whole book and applies to all build systems, regardless of size or technology. A better title for this chapter would have been "Best practices for build systems" as it doles out plenty of good tips such as how to automatically detect dependencies, what not to keep in a source control system, when to abort a build (early), why to ensure there is always a way to clean up all build-generated artefacts and so on. The gist here is to try to reduce complexity wherever possible and the advice is all very well reasoned and practical. The book wraps up by covering methods for reducing the size of a build and ways to speed up and optimise builds.

Overall this is a very well written, edited and structured book but it does suffer from attempting to cover too much and going into detail on topics which aren't going to be of interest to everyone. A prime example of this is the section on packaging technologies where I doubt that someone concerned with creating Debian packages will find the information on the Nullsoft Scriptable Install System very useful, or vice versa. The same applies to the varying levels of technical detail in the book — a manager may find the introductions to concepts like compiled versus scripted languages enlightening but to most developers this will be old hat. Conversely the intricacies of how Make calculates its dependency graph is probably interesting to a build engineer but most managers will be out of their depth.

This isn't the kind of book most people will read from cover to cover. Instead I recommend skimming through the sections that aren't immediately applicable and just focusing on the parts that discuss the particular build technologies the reader is interested in as well as the more technology neutral parts towards the end. It is obvious that years (if not decades) of real world experience have been distilled in Software Build Systems. It is just a shame that this process wasn't a bit more focused as this could have been a great book, instead of just a good book with some great sections and some sections that most readers will find themselves skimming over.

Full disclosure: I was given a copy of this book free of charge by the publisher for review purposes. They placed no restrictions on what I could say and left me to be as critical as I wanted so the above review is my own honest opinion."

+ - Nokia announces MeeGo 1.2 for Developers w/ N900->

Submitted by operator_error
operator_error (1363139) writes "Jukka Eklund at Nokia writes to the Meego Dev list: "I am thrilled to announce a little thing we started at Nokia. Basically we want to have MeeGo running in N900 device, so that it's really usable as your daily development device. Basic Handset UX should work, phone calls, SMS, web browsing. So we are concentrating on a few selected features and polish those to be "perfect". It might mean that we leave out some things in MeeGo 1.2 trunk for this edition, but that is not the default intention.

We are doing this fully on the open, and I hope this is an interesting project where we all in the community work towards the same goal: have a great MeeGo edition in the N900. This work is naturally based on the great work done already by N900 adaptation team lead by Harri and Carsten.

The wiki is up here: http://wiki.meego.com/ARM/N900/DeveloperEdition. It will populated with more information as we go, thanks for the patience.

Br,
Jukka
Developer Edition product manager" ...Also folks, be sure to stay tuned for the new Nokia N950 meant only as a (likely) unsubsidized Developer's hardware refresh of the N900. Only rumor has it that it will not arrive with a slide-out keyboard. How important is having a N900-style keyboard to you, along with the new Meego Love Nokia software continues to offer?"

Link to Original Source

Comment: Re:Action Bar seems dangerously close to desktop.. (Score 1) 129

by satellite17 (#35025954) Attached to: Android 3.0 Platform Preview and SDK Is Here

The 'Action Bar' isn't static, it's is customizable by the application

In what way is that not a menu bar as on a desktop. It's the very definition of a menu bar...

It's meant to be context sensitive within the application, as opposed to a menu bar which is generally static per application. It is very menu-bar like but unlike iOS it gives the application a standard place to put controls when - and if - it needs to display them.

So more like some kind of "Ribbon" then?

Comment: Re:VSS All the Way (Score 2, Informative) 244

by satellite17 (#34262124) Attached to: An Illustrated Version Control Timeline

If only PHB's had a clue, we're forced to use Visual Source Safe at work. I would claim it a legacy system but they just put it in a couple of monthes ago. I think any version control is better than nothing, but I'm not sure Visual Source Safe beats the file system's snap shots that are automatically created.

For the love of god, if you have to use MS software, show the PHB Team Foundation Server. It does a lot more than source control and is superior in every way to VSS. If you have MSDN then it might even be free (beer).

Microsoft

+ - Windows 8 wish list ->

Submitted by Barence
Barence (1228440) writes "PC Pro has a compiled a 20-point wish list of features its writers would like to see in Windows 8. Suggestions include instant on/off, proper virtualisation so that you "could maintain a virtual clone of your machine that you could use to test out unknown software without messing up important settings", and Linux-style multiple desktops. The site also reveals how to get many of these features in Windows now."
Link to Original Source

+ - A New Global IPv6 Backbone->

Submitted by Anonymous Coward
An anonymous reader writes "Still waiting for your Internet provider to support IPv6? Apparently one provider gave up waiting for other ISPs and deployed a free global IPv6 backbone with tunnel end points around the world. Most Microsoft users are now automatically using this IPv6 infrastructure. As a result, IPv6 reachability no longer sucks (i.e. loss / latency) and one blog claims IPv6 traffic has jumped by 1400% (http://asert.arbornetworks.com/2009/09/who-put-the-ipv6-in-my-internet/)."
Link to Original Source

+ - Large scale Mac deployment. 1

Submitted by
UncleRage
UncleRage writes "I've been asked to research and ultimately recommend a deployment procedure for Macs across a rather large network.

I'm not a stranger to OS X; however, the last time I worked on deployment NetRestore was still king of the mountain. Considering the current options, what methodology do admin adhere to? Given the current selection of tools available, what would you recommend when planning, prototyping and rolling out a robust, modular deployment scenario?

For the record, I'm not asking for a spoon fed solution; I'm more interested in a discussion concerning the current tools and what may (or may not) have worked for you. There are a lot of options available for modular system deployment... what are your opinions?"

"No problem is so formidable that you can't walk away from it." -- C. Schulz

Working...