You haven't heard? I'm sorry... My condolences, but the writing had been on the wall for a while though. Netcraft even confirmed it years ago...

*BSD is dying.

The problem isn't the initial connection really. Sure, there's an attack window there, but if it weren't for the actual problem it wouldn't have been as easily exploitable as it appears to be. The problem is that it is trivial once the Chromecast is connected to the WLAN to force it to reconfigure.

The Youtube video of his presentation (no transcript, sorry, go listen to it in the background while doing something else) makes it clear that it's trivially simple to get the device looking for a suitable partner again. If I understand it correctly the attacker sends one (or several) deauth frame(s) to the network and within 5 seconds the Chromecast will start looking for a new network at which point the attacker can take over control of the device.

The thing is, this was a userfriendly feature for when you're using your Chromecast device on other networks. If the developers had required a physical button press (on that nice reset button would've been fine), the attack window would've been just during the pairing, which is a much smaller attack window. While it doesn't take away the pairing issues you mentioned, but the beauty of this attack really lies in how easy it is to make Chromecast hop onto another network.

Which is the case as far as I understand it. The chromecast is vulnerable until it is configured. The attack just makes reconfiguration trivial because there's no physical intervention required.

Oh, are you one of those people who reads the Onion and is outraged at how factually incorrect their articles are? I'm sorry... For the record, I don't think there's a JihadBot 3000 prototype either. So don't spread that as truth either...

It's a matter of cost-cutting. Those virgins every holy warrior gets in the end cost a lot of money and aren't really contributing much to the cause themselves. The holy warriors themselves could unionize, but their union membership is rather short lived by nature. Aside from the membership problems, what exactly would they do? Threaten to blow themselves up? I'd explain into detail on the soon to be introduced JihadBot 3000, but the projects development costs have gone through the roof, and the prototypes have all blown up for some reason.

Pardon my stereotyping...

Well, at some point Perl was a rising star...

No matter what you're going to pick, it won't stand the test of time in the end.

• Perl? Dead, done for, the perl community invited to the funeral but the refused to come since they were too busy organizing their next YAPC and having fun.
• PHP? Waiting to be killed off. CVE-2015-0001 will classify the entire PHP codebase as exploitable, and in a desperate attempt to fix things, the developers will just delete the entire repository except for the mysql_real_escape() function.
• Ruby? Dead because of scalability issues. The Ruby community collapses onto itself trying to attent Perls funeral, but somehow get lost and finds itself at YAPC wondering why the Perl community didn't even bother showing up at the funeral.
• Python? Dead because of GIL, and it's either running Jython or IronPython, and nobody wants to sleep with Oracle or Microsoft that badly.
• Java? Death by 3 and 4 letter acronyms and frameworks of frameworks. Research has shown that long term webdevelopment in Java is considered harmful to your sanity.

Kidding aside, look for a set of qualities in whatever language/framework you want to use:

• Does it make it easy to do what you want to do?
• Is there an active developer and user community?
• Is there decent documentation?
• Does it offer a SIGNIFICANT advantage to port your existing stuff to this language/framework over the currently used language/framework? (Time being money, and all that)
• After starting a (small) test-project with it, do you feel confident that it meets your standards for doing real work with it?

I know that it's probably generic bullshit you're getting from me, but you're going to get a thousand answers all screaming at once "Pyramid" "Django" "CakePHP" "CodeIgniter" and what not and unless you take a look at the languages and frameworks and see what people are / have been building with it you'll be none the wiser. Pick something you see yourself maintaining without pulling out all of your hair in the next couple of years.

I moderated in this article, but this is something that I'd like to talk about for a bit, even if only anecdotal...

Over the past 8 years my own usage of Perl in writing code has declined to zero. There has been a mentality change over the years in the shop I work in, and where we used to grab for Perl by default as a quick'n'dirty duct-tape & MacGuyver language, we now exclusively rely on Python. I think there are several reasons for this shift.

The most prominent one to me personally is that other languages have adopted CPAN-like repositories. I don't know about the statistics of numbers of modules, active development, number of commits, etc etc, and put bluntly I really don't care. Although these statistics are interesting into disseminating how active a language is to its developers, to me as a user of the language it only matters if a module is maintained and does what its supposed to do. The thing is, for most of the things I used to use Perl modules for, I now use Python modules, and can say "Well, it's good enough".

Our development teams composition has also changed. A lot of our older generation of programmers/admins have retired or switched jobs, and a lot of younger people were hired to replace them. The younger generation is definitely more familiar with Python, Ruby and other scripting languages than it is with Perl. The incentive for learning Perl has become a lot smaller. Perl was the de facto language for many when writing a CGI script, but then RoR and AJAX happened. While over time Perl adapted (think Catalyst and Dancer) other languages have adapted as well. Look at all the wsgi applications and frameworks in Python.

Our investment in Perl itself was more of the kind where we used a set of scripts to change data from format A to B at which point our Java and/or C++ code takes over, or some tools to deal with our logs, etc. The switch to Python for these tools was gradual (but quick) process, and we found ourselves not looking back. I can't really say that we were/are heavily invested in Perl or Python, but for day to day usage Python has completely taken over. Who knows where we end up in another 8 years from now?

Lastly, if you were to go around our shop, asking people what's new about Python 3 you'll get pretty much right answers. If you go around our shop asking people what's happening with Perl 6, you will get a blank stare. I remember clearly how Perl 6 was going to become the best thing since butter on toast, ... There was general excitement about it all, and then there was a whole load of ... well... nothing. We're 11-12 years further and there's still no sign of Perl 6. What the hell happened there?

I don't doubt that Perl will be around for a whole lot longer. It has assembled a group of dedicated die-hard users and developers over the years, and in general it has a great community. There are older, more horrible languages that are still alive today, so I doubt Perl will be gone anytime soon.

However, while my entire post is anecdotal, I do think the Perl community is deluding itself a bit. The talk in the video (I actually listened to it in the background while working on something) mentions a lot of statistics that are interesting to the Perl developers and maintainers, but are hardly and indicator of usage or adoption. The more interesting part of the statistical talk was about the general decline of jobs available for scripting languages in favor of newer technologies, but even those statistics in general don't speak much about usage and adoption.

FWIW, may Perl be around a long long time. Having more tools at your disposal is never a bad thing.

Please, let's not mention Gimp and UI in the same sentence unless you're looking for an internet fight.

At the request of the international community they'll stop sticking harpoons in whales, but the request didn't mention anything about nuking the whales.

Allow to go off on a tangent here, but most of the setups I deal with keep databases and webservers on separate machines. Today we've got virtual machines coming out of our collective asses so even developers start separating their services from each other. What you're talking about is dependencies and how to deal with failure of a service. That goes far beyond the scope of what systemd can provide, since it's so cheap and easy to run stuff on different (virtual) machines these days. However, I realize that you're using this as an example, so I won't really press on the matter other than that this is the poorest example you can choose.

But it does speak to part of the problem. All I continuously hear about systemd as the greatest advantage is solving the "complex boot order" dependency problem, parallelizing boot scripts and decreasing boot-time. To me, as a sysadmin: I DON'T care. I'm pretty sure that 90% of the servers I have running take a longer time in POST than they do in booting. If I reboot something, I'm taking it OFFLINE. I'm not sitting there crossing my fingers "Please come up quickly", but I've got a failover setup and another machine has taken over before the server is rebooting. And "complex boot order" really? Is that really that big of a concern? I really hope you don't have to manage 500+ servers then, because you'll be in for a surprise on complexity.

This brings me to interesting questions that I hear nobody talk about. If you're doing failover type of things, you're bound to end up with heartbeat/corosync/... + pacemaker & co. As a sysadmin, for me those things are extremely important. Last time I checked (and granted, that was a while ago), none of these actually had a proper way to deal with the impact of systemd. I'm sure that the people behind the various failover solutions are working on it, but last time I checked I saw very little in official documentation, and only the occasional headscratching on mailinglists.

To me, systemd presents quite the challenge, with consequences even outside of the technical side of things. For a while I'm going to end up in a mixed environment, forced to write two sets of operational procedures, disaster recovery scenarios, etc etc. I'm going to have to retrain people on how to read system logs, have to deal with systemd's quircks (no offence, all software has its peculiarities, and so will systemd), and will probably have to completely rethink how we do failover scenarios. And all I gain, what I'm really interested in is... cgroups...

Projectors, usb disks and sticks, whatever ... Those things have no place in a serverroom, and I don't care about it. And let's be frank, nobody in a corporate environment gives a shit about linux on the desktop. The few companies that I've been at that have linux on their desktop are small businesses with a near complete tech workforce.

I think I know the answer to that question. Some environments need to archive their logs, for a long long time. Some things are more complex than a "simple" local syslog setup, and with that complexity comes a set of tools that often organically grows over the years or follows certain administrative procedures inside a company. In such environments, change is a difficult process, not because of people but because of corporate inertia and red tape bullshit. And it's great that systemd provides a syslog fallback for us text-junkies, at the very least it buys time...

The other side of the medal however is, nobody is really having a problem with text logfiles. The examples I continuously see are so contrived, or focussed on "the linux newbie" that it just reeks of a developer looking for something to do. My biggest frustration with logging on unix isn't "I don't know where to look" or "I don't know what to look for", but "This logmessage is meaningless without several Google queries". Any person who knows about /var/log can relatively effortless find the errors they're looking for, but an error message like "Connection reset : read() returned 5 bytes" says very little about what is wrong unless you're a developer of that particular daemon. No matter what abstraction you put into place for logging, it doesn't really solve the issues I'm dealing with.

service apache stop. And when all else fails : kill -KILL .

Don't get me wrong, but if you've got rails or pyramid, django stuff you should either be using the correct apache modules, or documenting how the two communicate with eachother (like with fcgi or some proxy solution or whatever). If I stop apache, I expect apache to stop. If apache is spawning stuff it's not supposed to, I get off my chair and walk over to the developer that wrote crappy code, or poorly documented how to start and stop his stuff and find a way to fix it. If it becomes the default behaviour of your apache deployment, clearly it's nowhere NEAR production ready.

Having said that, sure stuff goes wrong. I'm well aware of that, on a daily basis. But I've never been unable to solve these kinds of small issues before. There are bigger issues that haunt me than process management, and systemd isn't going to help me with those. If process management on a single machine is a sysadmins worst concern, I fear for his career in a real environment.

Give it some time. Let the distributions do fun and neat things by wrapping systemd's tools with their own scripts and you'll have the same fragmentation that you have now. This is like that story where there are 10 standards, and a guy says "I'm making a standard that unifies all these standards!". Result: you now have 11 standards. Again, don't get me wrong, I like the idea of having a standard way of doing things, but there have been so many efforts in that regard, without all too much success, or relatively quickly heading into different directions.

Linux in the end doesn't have a single set of developers, but hundreds of distributions, each with their own developers, each with their own collective ideas, so it's guaranteed to happen.

I haven't used slackware in ages, but I think you're underestimating their core audience and developers, and their resilience to change they deem unnecessary.

Finally, I'd like to make a couple of remarks in general about this whole topic. I hardly ever comment on systemd, and since I've written all of this I might as well add that.

First of all, I'll admit, I'm actually really interested in it. I haven't had the time to play with it, break it, customize it, and do my thing with it, but I definitely aim to do so relatively soonish. To say the very least, it is an ambitious project and it certainly is making waves. However, I am somewhat concerned with the scope of systemd far outgrowing what seems to me to be reasonable for an init system. These discussions have been going on for a while now, and my concerns aren't being reassured by the arguments in favor of it, simply because I have no need for these features or find them to be non-issues in my use of Linux.

For me professionally, I'll have to deal with it at some point in the future, so it's one of those things where I'll (albeit somewhat grudgingly) adapt. I do however think that when the major distributions have released their new systemd based versions, what you're seeing today will only be a fraction of the criticism the project will have to deal with. People are averse to change, especially if it's change for something they've been used to for years. If systemd breaks in unexpected and interesting/fun ways, I expect quite a bit of backlash. If systemd should fail hard, I kind of fear for the consequences. The feedback I'm seeing from a lot of Fedora users is not the most flattering either, although I suppose some of it is blatant trolling.

I've seen sysvinit replacements come and go, including such wonderful examples as DJBs attempt at reinventing the wheel, which had the wonderful side effect of making sysadmins having an unexplainable urge to bang their heads against a wall at random intervals. Each had their set of problems, imperfections and fun and interesting new ways to break. While past experience shouldn't be an excuse not to try out new things, I do tend to be guided by that experience. Systemd seems like a system that is far more complex and encompassing than any of the other sysvinit replacements I've used in the past, and considering that complexity goes hand in hand with bugs and looking back at my previous experiences with sysvinit replacements, allow me to be somewhat skeptical and not the first to take the plunge in an operational environment.

No you don't. You get plenty of feedback on the beta site in the initial announcement of it coming online, and for the most part the comments were ignored. Ever since the beta came online, there's been people mocking it.

Saying it's not ready is the understatement of the year so far. The comment section is on fire so far, and this is actually the first time that I've seen people spend their modpoints to promote offtopic discussion of this nature on this scale.

What? Is this the website equivalent of "We want the Call of Duty audience" ? This statement right here, goes to show how much you're out of touch with your core audience: News for NERDS... Slashdot will never be reddit, or some fancy ITBiz magazine. Reddit already exists and won't be going anywhere, and the ITBiz audience doesn't give a shit about this place since it's just another site that scrapes headlines from other places.

The writing has been on the wall for a while now, ever since the advent of SlashBIcurious and the other nonsense you've been trying to push. Your "core audience" has been telling you this for quite a while now, but you've adamantly refused to listen, stuck your fingers in your ears and gone ahead as if nothing was wrong. And now you're surprised the comments section is ablaze?

Experimenting with an established platform can come at a high cost. I don't mind the changes to the layout, and I don't give a damn that you want to polish the look, but in all fairness you broke the damn commenting system. It's the only thing that keeps this place worth visiting. Beta just makes we want to look for another home.

Oh fuck off... You know when people start talking about communication? It's the excuse the network engineer makes to the IT Coordinator/Manager when his network melted while users have been making tickets about problems for weeks. It's the pseudo-managers way of saying "I'm not aware of any issues" despite his mailbox being a festering pit of complaints and misery.

You communicated well enough. You communicated when the beta came online, and you get plenty of feedback which you chose to ignore. Now you've got 25% of users getting an iteration of your shitty beta, and boy oh boy is your comment section a cesspool of complaints right now. And the message you send now is obvious: "It's coming, wether you like it or not. Suck it.". Yeah, the art of communicating is not lost on you guys at all.

That's like the time I heard someone from management say "In hindsight, I feel that despite the negative outcome I've made the correct choice. We'll just have to adapt and move on".

Well, guess what... We'll adapt, and move on. Enjoy turning slashdot into ITBizz2.0 or whatever pipe dream you guys at Dice have.

Slashdot always lags behind the facts a few days, or more...

I dunno, he might just use the phone, or a videoconference tool over the internet (not like he's discussing state secrets (well, not anymore really)). You might not be that dumb of an "amerikkkan", but you're not the most practical person in the US of A either. I'd urge you to become more practical before turning into an enemy of the state, should the thought ever cross your (or your governments) mind.

Right there in the article even.

Anyway, we'll see what happens. The article mentions that people are divided about having him talk, keeping US-EU relations in mind, which by itself in my opinion speaks tales about "how concerned" these people really are by the whole ordeal. In the end it remains politics, and even if most people were terribly upset they'll still shake hands and sign agreements as if there isn't a care in the world. I can see the merit of asking Snowden a few questions or clarifications, but if I understand it correctly he's already released his documents he had to share. I also vaguely remember his terms for his asylum being "not to further embarrass our American partners", and I would be extremely cautious if I were him about what those terms exactly mean. Putin may enjoy his little prank on the US, but he doesn't like it when people don't dance to his tune.

I think that if you read between the lines of all of this, the EU isn't even all that concerned about its citizens, but rather about its political and economical agenda. I wouldn't be surprised at all if many countries in the EU currently have their intelligence services cooperatively lobbying their politicians to do the very same. Hell, I would be surprised if they already haven't done such a thing on a smaller scale in the first place, considering how much some of the EU nations are investing in their own "anti-terror" efforts, although much more low profile and with considerably less impact. In reality, all nations across the globe are engaged in political and economical espionage, but it's their efficiency that you should be concerned about.

I would say this is nothing but a lot of grandstanding for political reasons, but I am a cynic when it comes to politics. Many European politicians although they emit an air of indifference when it comes to the US, are very big fans of the US as has been made obvious by the cable leaks released by wikileaks in the past. There's decades of treaties and agreements between most EU nations and the US, and few are willing to risk the long-term benefits of those.

In before the great bra-burning of 2014.

At least fix the damn typo while you're improving the content.