If you're building services that still require "regular maintenance windows" in 2014, you're doing it wrong.
This is a really nice sentiment but is in fact somewhat disconnected from reality.
In the web world, building zero downtime services that don't require maintenance is doable. In many enterprise IT environments with legacy or bloated software (hospitals, education, government) it's a non-starter. The staff do not have the skill, the applications don't have the support, and the political will within the organization is not there. Database migrations alone can be a major source of downtime, and that's largely true even for web services.
Puppet is a great tool for automation but does not solve problems like patching and rebooting systems without downtime.
Yup. Very dependent on the business, the application, the usage patterns, etc.
The right answer to this is to have redundant systems so you can do the work during the day without impacting business operations.
Many of the newer phones from T-Mobile (the US version, anyway) are configured out of the box to use native IPv6. A third of their data traffic is now terminating on IPv6. They're using NAT64 for reaching hosts that don't have a native IPv6 address.
IPv6 rollout is happening, just not in the places some of us are looking.
Ive been working on a platform that is Linux running on a 1 GHz, 32 bit ARM, where we want to run an already existing Qt Quick 2 application. We have run mockup applications with X using the virtual framebuffer and the mesa software renderer, and found performance to be really bad. On the order of 1 FPS or so. Any suggestions on ways to make the software renderer more usable? My understanding is that LLVM would help here, but only works on x86 and x64.
Yep, pretty much this. For me it was a bit later - 1980 - but we had a C64 in the house and my Dad was in a club that talked about them. He showed me some simple BASIC and set me on the track at an early age.
On hardware from circa 2001, BeOS had an audio latency of about 3 msec from input to output. I don't know the x86 / x64 number, but in 2014 running on the best ARM hardware available, by default, the Linux scheduler runs every 10 msec, so audio latency of 40-80 msec is pretty common. In many applications, that is quite a significant difference. There are good reasons why Linux has this latency, but it is a question of optimizing for different use cases. BeOS had a laser focused use case of Desktop performance. Linux is used on servers, desktops, embedded, super computers, and all kinds of wierd places.
If they were "just enforcing the law", then why did the FBI/ATF enter with masks on and no visible identification? That's what terrorists do, not government or police agencies. There is evidence that the federal agents fired the first shots as well.
This article is yet another confirmation that Slashdot just gets worse and worse. I hate to troll, but come on guys, up the quality some.
Heh, unless you work for a GM dealership, you have NO idea how bad GM is at IT. Their dealer-side website still does not officially support anything other than IE8. Business reporting relies on ActiveX integration with Excel, and only works properly with Excel 2000 and 2003. It can be made to work under 2007, but they don't support anything higher. Parts of the service-related workbenches still use VBScript. It used to be accessible only over a super-slow satellite link, but they changed that a few years ago, thank god.
To be fair, though, Toyota's web back-end, Dealer Daily, is even worse. IE-only, accessible only through a dedicated T1 which may not be used for anything else (but which you still pay full price for, of course). Blank page under anything other than IE.
Come to think of it, a lot of dealership stuff is locked on IE. Dealertrack (intentionally locks out non-IE browsers), Dealersocket CRM (featured-limited under non-IE browsers). ADP is the biggest supplier of dealership management software in the US and most of their stuff is entirely reliant on IE.
It's a pathetic state of affairs.
Come up with a few simple programming projects that students can run through. There's something magical about writing code and seeing the computer execute exactly what you told it to do. Write a Ruby Sinatra or Python Flask app and show how to access it from the command line. This will teach them what a web server is and how to write simple code at the same time.
My BS is a BSCmpE, but my MS is an MSEE with specialization in Computer Engineering. I have often wondered "Am I a EE?". I don't feel like one....I write embedded software, but I participate in schematic reviews, and debug hardware problems.