Because there is a right well to tell fictional stories?

There isn't a single right way because there are infinite possible futures, and it's reasonable to assume that inventive SciFi authors would want to explore that huge space of possibilities. There are unlimited right ways.

Nor is there a single wrong way, but if all authors narrow their horizons to describing only simplistic futures in which most cultural elements remain unchanged then clearly there is a problem of deliberate myopia which will inevitably lead to a poverty of novel material.

It's a bit like surrounding oneself with yes-men --- it doesn't promote pushing the envelope and expanding the mind in new directions. In the context of SciFi, if cultural elements are shackled to present-day norms then it creates a literary monoculture with very few interesting elements. Even worse, it's factually incorrect, since we know that cultures change strongly with time.

It is acceptable to be factually incorrect in fiction, but when a whole genre that is predicated on gazing into the future knowingly avoids addressing cultural change then there is indeed a problem, and a very big one. SciFi readers deserve better than just present day stories adorned with spaceships.

The Permaculture community and advocates of companion planting have been around for decades preaching this same message, that plants grow better in messy complimentary families instead of in tidy rows of monoculture in which everything else is considered "weeds" and exterminated.

It's great to see youngsters getting rewards for bringing this message to the public eye, countering Monsanto's advocacy for broad-spectrum herbicides that are effectively killing off the biosphere with each passing year. Nature is amazingly productive when allowed to do her thing, instead of undermined by highly destructive profit-led myopia.

One of my favorites out there today is the A10-OLinuXino-LIME. ...

The Beagle Bone was good in its day, but it is kind of over the hill. The processor is underpowered compared to other ARMs

Just to be clear, the A10-OLinuXino-LIME, BeagleBone white and BeagleBone Black all contain a single Cortex-A8 core, and the TI AM3359 runs at the same 1GHz speed in the BBB as the Allwinner A10 does in the LIME.

The original BeagleBone (white) ran its AM3359 at 720MHz so its CPU performance is a bit less, but the BeagleBone Black (BBB) superceded it a year ago and at a much lower price. As a result, the reasonable current-day comparison is between A10-OLinuXino-LIME and BBB, and on CPU power their similar speed Cortex-A8 cores make them pretty much identical.

I have all of these boards and many other similar ones, and my assessment is that BBB is much more capable for embedded projects because of its additional dual realtime 200MHz PRU cores (which are quite unrivalled), while the A10-OLinuXino-LIME is more suitable as an extremely low end desktop-style "computer" because of its dual USB2 host sockets and rather more capable MALI-400 GPU.

This assessment doesn't change when the just-released A20-OLinuXino-LIME is brought into the comparison, except that the dual Cortex-A7 cores in the A20 make it a far better general purpose "computer" than its A10 sibling for a mere 3 euro more in price.

It doesn't matter if you SHOULD have right of way.

You misunderstand Idaho Stop, as it never gives right of way to cyclists. The most they get is right of movement when there is no conflicting traffic, in other words when there is no right of way issue. If conflicting traffic is present then that traffic always has right of way over the cyclist at a stop sign or red light.

It certainly doesn't make cyclists "own the road", as you put it, since that's synonymous with having right of way.

You teach core and theory and you apply it to whatever the current fad is.

He's not really saying that CompSci programmes should be tailored for Internet of Things. What he's saying indirectly but perfectly clearly to those who are aware of the appalling state of networking security in recent years is that university-level tuition needs to buck up and face the music, because the people they have been releasing into the field are totally inept at designing secure systems. The hundreds of thousands of security problems spread right across the whole Internet speak for themselves.

It's a very important message, and hopefully it will resonate with more than a few CompSci departments. IoT is just being used as an excuse for releasing a high-profile message from a respected person about the very unsatisfactory state of developer competence in the area of secure systems.

Regarding your second point about education versus vocational training, you are right about that, but secure software design and cryptogtaphy are not subjects for vocational training, but very strongly in the domain of CompSci. You have to understand the fundamentals, not just know which functions to call.

When Facebook or Google mine your data ('you are the product' as people say), you have nothing to fall back on. It's in their ToS

Only in some corporatist's wet dreams are corporations above the law. Whatever it may say on a ToS that they've pulled out of their asses, it does not change the facts one iota. The ToS cannot override the law of the land.

There is no means by which a person can sell themselves into slavery to a company by clicking on a web page. And by the same token, a company cannot decide that your personal data is theirs for them to do as they please just because it says so in the ToS they've written.

You seem to think that corporations are sovereign countries and are in their total right to own you. Sorry, but it doesn't work that way. You are NOT a product of a company, no matter how much some people like that cute phrase. You are, funnily enough, a person, and your rights as a person extend to the personal data that you entrust to third parties.

The patents in question describe nothing more than perfectly normal combinations of Internet services that any software engineer who knows basic networking would be expected to create as a matter of course. Combining such services into higher protocols is simply algorithmic construction in network programming.

This patent suit illustrates well the chilling effect that software patents have on our ability to use computers and the Internet to best effect. When you allow software algorithms to be locked away in patents, the ability of engineers to use computers and networks as an enabling technology decreases dramatically, to the extreme detriment of our ability to improve our systems.

Each new software patent just adds further bars to the prison. If this disease isn't stopped soon, the profession is going to be worthless except as a feeding pit for lawyers.

This is a really awesome example of dedication to science and engineering by enthusiasts.

They don't mention it (much), but these guys are risking their lives. It's certainly possible for all the tech safeguards and personal attention to safety to go wrong and for someone to die.

I bet the professionals will call this "unnecessarily risk", but that's not really accurate. Sure, it's money-limited, but that doesn't mean that the people involved aren't just as strongly concerned with safety as the professionals. As said in the video, "We have only one life". They do realize what's at risk.

Looking ahead, we will soon be a space-faring species, and that means that we will be going into space not only as a science experiment, which all NASA endeavors have been so far, but simply to go out there for whatever reasons we have. People need to make this technology their own, and that's what these enthusiasts are doing.

Client-side Javascript is already a security disaster because the unvetted JS code bypasses your perimeter defenses (firewall and proxies) and executes deep inside your privacy domain. And it's not only unvetted code but also unvettable, because it changes with every page.

15 years ago, everyone knew that only the clueless download untrusted 3rd party executable code and run it. Now with JS, all that sensible security advice has been forgotten, and everyone is required to behave clueless with their security. (Software sandboxes are no solution, because all non-trivial software like JS and the browser is riddled with bugs, this is inescapable with large software systems.) Add-ons like NoScript and Ghostery help control it a little, but technically unaware people can't be expected to use them, and more and more websites don't work at all without JS.

And now, Google wants to make it especially easy for remote 3rd parties to access other people's desktops, as if JS didn't make it easy enough already (just ask any security pen-tester). It adds to the already hopeless security in Android, where users are disallowed from blocking the wide access typically demanded by an app on installation. Google doesn't want you to be in control.

The whole Google scene is a security disaster by design. It beats me how a company with so many PhDs can be so cavalier with people's security and hostile to their privacy.

For more immediate visual gratification appreciated by a wider audience, the Mars Reconnaissance Orbiter provides wonderfully detailed images of Phobos.

That was the instrument that caught this mind-numbing image of the Phoenix lander as it was descending on its parachute. Words are really quite superfluous.

On our primitive planet with its petty preoccupations over power and money, you showed us a vision of the future in which Mankind has managed to transcend the narrow blinkers of its youth, and reaches out to the stars without material greed nor lust for power.

The Culture gave millions of us hope for the future, at a time when government, business and fanaticism seem intent on moving us back towards the barbarism of earlier ages. Your vision will live on in our hearts, come what may.

Thank you.

to expect EVERYONE to switch over to IPv6 immediately is a bit naive.

"Switch over to IPv6" is a concept that detractors have pulled out of thin air, as it bears no relationship to how IPv6 rollout was planned and expected. Adding the word "immediately" just makes the misconception worse.

IPv6 was always intended to run alongside IPv4 for the foreseeable future, because old IPv4-only equipment will be around for decades until it rots and it will need to be reachable until it is replaced. So, please don't talk about needing to "switch over" to IPv6. Wherever you got that idea from, it's wrong. Talking about it is propagating an invalid concept, and calling the expectation "naive" is just knocking down a straw man.

IPv6 service merely needs to be enabled (without touching IPv4) on an IPv6-capable dual stack home router, and ISPs who offer IPv6 provide routers with it already enabled so you just need to plug them in. (If it's an old router then you'll have to enter the new IPv6 address info that the ISP gives you of course.) Simple home systems don't even need user configuration for IPv6, because IPv6 router advertisements then handle everything. It's as simple as USB for the home user, totally plug'n'play, which IPv4 never was.

And once enabled, IPv6 works totally happily and transparently alongside IPv4 in the home network and at the server end, so there are no "switch over" issues. IPv4 continues to work exactly as it did prior to enabling IPv6. Browsers in particular just use IPv6 by default on a site that has it, and IPv4 if not. It's completely seamless for the end user.

The pain and angst of "switch over" that you describe simply doesn't exist, because switching over was never planned, expected, nor even desired.

The sites that are calling for better password choice need to step back a bit and consider whether their design concept of storing user passwords centrally is a good one. It's not, so they should get rid of it instead of applying band aids to a bad scheme.

It doesn't matter what encryption scheme is used, if authentication secrets are stored centrally on a website then they are at risk. Good sites make it hard to crack, and poor sites make it easy, but they are all at risk, from internal employee corruption if nothing else. Those secrets will leak because when stored at a single point then they are all accessible to the attacker at a single point. Leakage is just a matter of time.

A vastly more secure approach that's been well known for decades is for the user to store their secret locally as a private key, one half of a {private,public} key pair. The server only gets to know the public key (PK), and it's pointless for an attacker to crack that because the PK is public information that can be distributed freely through keyservers. (The PGP/GnuPG keyserver network has been doing this for decades.)

When a user creates an account on some website, she provides the identifier of her chosen PK (she may have lots of them). When logging in to the account subsequently, the server looks up her PK identifier in the info for this account, fetches her PK from the keyservers, then it sends her a random string encrypted with her PK. She decrypts it with her private key (which is only held locally by the user, nowhere else) and sends the decrypted string back. The server accepts the login if the returned string matches the random string that it picked, which is not stored and varies on every login, and rejects the fraudulent login attempt if the match failed.

That's strong distributed security, and it's resistant to MITM attacks and does not store any authentication secrets on the central service so those secrets cannot leak when the service is compromised.

It's not rocket science. Why this old but secure scheme isn't used by websites is quite a mystery.

Our solar system resides in an area of our galaxy called the "Local Bubble", roughly a few hundred lightyears across. This region is very empty compared to the average interstellar medium in the galaxy, as a result of a large number of supernovae that blew out a sort of cavity in our interstellar neck of the woods long ago. In actual structure it's more of an irregular "Local Chimney" going right through the galactic disc rather than a spherical bubble.

As a result, pinning the cause of TFA's observations to a single supernova is not all that simple, as supernovae were very common in the Sun's general neighborhood in our galactic past..

Here's a nice graphic of the larger features in and around our local bubble. It's a fascinating subject if you enjoy understanding our location in a galactic context.

It's clear what lightweight means just from examining its two parts: "light" and "weight" both allude to there not being much there, little mass or volume. The words are of course a physical metaphor when applied to software.

When something has little physical mass and volume then it tends to move fast for any given force, and so as a consequence we tend to associate "lightweight" also with higher speed, but it's only a consequence, not the primary meaning.

In software, being lightweight and being fast are properties that do not always track each other. As a first rule of thumb, smaller code tends to have more locality simply through being smaller, and hence it can run faster through producing fewer cache misses. However, small code is often somewhat dumb code, and a large and complex beast of a program can be designed to have greater locality in its innermost loops and hence to be more cache friendly and run faster. As a result it is hard to generalize whether lightweight also means fast. You have to examine each case separately.

As a counter-example to "lightweight == fast", the browser Midori is extremely lightweight (very small), consisting of little more than a simple graphic Gtk+ wrapper around webkit. Firefox in contrast is a huge monster of a program and could never ever be called lightweight. However, Firefox runs much faster than Midori, because its designers have used its complexity very productively to make its performance top notch.

So, you really can't generalize beyond observing that smaller programs load faster from disk and, everything else being equal, tend to have better cache locality and hence higher speed. However. heavier programs can buck this general rule by using more complex designs and algorithms to boost their runspeed.