As the Internet of Things becomes a ubiquitous idea and a fact of life, what happens to all the aging and increasingly insecure Things? According to Wired's Robert Mcmillan, responding to a recent question on the security of IoT from Dan Geer, this may be a serious problem [1][2]. The solution, Mcmillan suggests, is to design these devices with an expiration date. In other words: they need to be programmed to die. The problem may not be too severe now, but the future of the Internet of Things will look different than it does now. Security will likely loosen, because software will be a part of everything, and it tends to be the case that things mass produced to that degree experience a bit of a drop in quality. That, Mcmillan argues, presents a problem: ...all code has bugs, and in the course of time, these bugs are going to be found and then exploited by a determined attacker. As we build more and more devices like thermostats and lightbulbs and smart trashcans that are expected to last much longer than a PC or a phone, maybe we need to design them to sign off at the point where they’re no longer supported with software patches. Otherwise, we’re in for a security nightmare. A similar argument came from Bruce Schneier's interview with Scott Berinato about how future bugs like Heartbleed could impact IoT [3]. Schneier's conclusion is that processes must be built into IoT devices and development to allow for regular patching and securing of embedded systems. How practical is that, though? Mcmillan points to some recent scenarios where these fears have already come true: the lack of support for Linksys routers infected with Moon Worm, for example. Long-term patching would solve these issues, but will the increasing number of organizations developing IoT products be forward-thinking enough to care? It's also not as if the problem will fade as the products become less popular, Mcmillan says: Researchers have studied the way that security vulnerabilities are discovered, and what they’ve found is that security bugs will keep cropping up, long after most software is released... in fact, they’ll only get worse. Open sourcing technology as it ages may also be a solution, Mcmillan says. However, even that is imperfect and requires a lot of cooperation from companies who may not be enthusiastic about such cooperation, as well as a base of developers interested enough in the technology to maintain it. So, creating devices with an expiration date may be one of the most practical solutions. Otherwise, what happens when IoT is everywhere? What happens when we stop taking care of the things that we build? [1] http://www.wired.com/2014/05/iot-death/ [2] http://geer.tinho.net/geer.secot.7v14.txt [3] https://dzone.com/articles/heartbleed-iot-how-much-worse

In this article, we will discuss the advantages of using AWS and Terraform and provide an example of this collaboration for better understanding.

The article covers time series analysis, discusses unique cross-validation methods, data decomposition and transformation, and more.

Using Java and Marqeta, we’ll build out a fully functioning card payment system your users can use for payments anywhere that a debit or credit card is accepted.

Make the most of your backpacking adventure by creating customized weather alerts using Tomorrow.io weather API. Stay safe with critical alerts tailored to your needs.

Istio has released a sidecar-less data plane called ambient mode. Explore its architecture and the benefits it can bring to enterprises.

This article briefs about the impact of spam and how it can be addressed with emerging machine-learning technology based on our journey in this domain.

We know traditional security practices can’t support this scale, so how do modern practices allow us to scale security with these architectures?

This article will give you a better understanding of data quality testing, monitoring, and observability. So let's explore these concepts together.

Learn how to avoid traps with Java Optional and how to use it efficiently by taking the best of this API to make a readable code.

DevOps pipelines automate software development workflow for continuous integration, delivery, and deployment.

This article delves into different system components, from the client and DNS, to the load balancer server, firewall, service instances, and other core elements.

Kubernetes security is more important than ever and should be top-of-mind for most teams. Walk through the latest in k8s security solutions from KubeCon 2023.

Security in the Internet of Things is a fairly common concern these days - you know, Heartbleed, toasters, that kind of thing - but you may not even have considered the greatest threat to your connected devices: classic 1990s first person shooters. That's the scenario presented in this recent experiment from Context Information Security. By taking advantage of a web interface that require no user authentication, the Context team managed to get Doom up and running on a Canon Pixma printer. Obviously Doom is not the point in itself, so much as an illustration of the vulnerability, but it definitely gets the idea across. According to Michael Jordon at Context, the vulnerability was fairly serious: At first glance the functionality seems to be relatively benign, you could print out hundreds of test pages and use up all the ink and paper, so what? The issue is with the firmware update process. While you can trigger a firmware update you can also change the web proxy settings and the DNS server. If you can change these then you can redirect where the printer goes to check for a new firmware. So what protection does Canon use to prevent a malicious person from providing a malicious firmware? In a nutshell - nothing... Jordon's post goes into detail on how the encryption was broken. Canon was contacted and informed of the problem, and responded that it would be fixed, but Jordon warns that it's not a unique scenario. While this particular technique is not currently a common concern, it demonstrates the reality of security concerns when it comes to IoT devices. Once everything is connected, how many devices will be vulnerable? How confident can we be that the creators of these devices will be cognizant of these issues? As a potential catch-all solution, Context offers a strange bit of advice: Context recommends that you do not put your wireless printers on the Internet, or any other ‘Internet of Things’ device. So, there you go - one way to be sure. The Internet of Things can't help but be secure if you get rid of that whole "Internet" part.

So, Android Studio exists. While there are a number of fixes for the less-than-graceful aspects of Android development in Eclipse - Genymotion, right? - some are moving to Android Studio for a more stream-lined approach. This recent post from MeetMe's engineering blog details Bill Donahue's switch from Eclipse to Android Studio, and he has some pretty strong feelings about it. He says - and this is his own emphasis - the following: I will never go back to Eclipse Donahue then explains the key differences as he sees them. First he makes a list of complaints about Eclipse - constant refreshing, awkward UI building, hogging RAM, and so on - followed by a list of the improvements found in Android Studio, such as full-program themes, new UI tools, better stability and performance, and more. He does point to a couple of hiccups, such as the switch to a Gradle build, but it's more of a thing you're going to have to learn than an issue with Android Studio. Check out Donahue's full post for more details on the switch and the little things Android Studio does to make it more comfortable.

(This article is the second in a two-part series leading up to the AMD Fusion Developer Summit, the only developer conference dedicated specifically to heterogeneous computing. Check out the first article for a conceptual overview, with extensive resource links.) Recently Anand Lai Shimpi hosted a community Q&A with Manju Hegde, Corporate VP of Heterogeneous Applications and Developer Solutions at AMD. The topic: Heterogeneous Systems Architecture, the standards-based, AMD-led effort to ease development of heterogeneous systems, especially CPU+GPU systems. Normally I'd just send you over to that most excellent Q&A -- but in this case the questions are so good, and Manju's answers so thorough, that you might not have a chance to read everything. So here's a detailed summary, with links to more in-depth resources: Differences between Fusion and HSA: Goals: Fusion: let developers use GPU along with CPU HSA: make the GPU a first-class programmable processor Specific HSA improvements: C++ support for GPU computing All system memory accessible by both CPU and GPU Unified address space (hence no separate CPU/GPU memory pointers) GPU uses pageable system memory (hence accesses data directly in CPU domain) GPU and CPU can reference caches of both GPU tasks are context-switchable (esp. important to avoid touch interface lag -- contexts switch rapidly in heterogeneous environments) (GP)GPU versatility: Non-UI use of the GPU is currently active at a basic level in security, voice recognition, face detection, biometrics, gesture recognition, authentication, and database functionality. But each task is currently GPU-routed. HSA will make GPU use in all these non-UI domains much easier in the next few years. C++ AMP and HSA: C++ Accelerated Massive Parallelism (AMP) is the Microsoft alternative to OpenCL. Both are excellent, and will fill similar roles within the larger HSA. Because C++ AMP does not represent a huge departure from C++, the AMP development learning curve will be relatively shallow. Gaming vs. compute performance: GPU architecture and production costs mean that there is usually an inverse performance relationship between gaming and pure compute performance. This means, in turn, that desktop (i.e., non-specialized) GPU design involves a careful balancing-act between gaming and compute performance (see for a technical overview of some reasons why -- it's more than just GPUs' excellent floating-point performance). AMD and developers: In the past, AMD tended to engineer products, and stop there. Now, because HSA involves a much more serious attempt to encourage heterogeneous systems development, AMD will be working more closely with developers to help them take advantage of (especially GPU) powers they might not have been able to use in the past. The advance of the APU: AMD has no grand strategy to promote APUs, even though they already make numerous different kinds of APUs. Every APU is designed as a response to a specific use-case. The advance of OpenCL:AMD is deeply interested in strengthening OpenCL itself, and to that end has recently driven these OpenCL initiatives: improved debugger and profiler: Visual Studio blogun, standalone Eclipse, Linux static C++ interface extended tools by close collaboration with MulticoreWare (PPA, GMAC, TM) OpenCL book and programming guide university course kit (for use with aforementioned book and programming guide) webinars self-training material online hands-on tutorials at the Developer Summit (select 'Hands On Lab' under 'Session Type') moderated OpenCL forum OpenCL training and service partners OpenCL acceleration of major open-source codebases Aparapi to make Java coders use OpenCL more easily The continuing (but receding) importance of device-specific GPU optimization: Roughly speaking, as GPUs become more General Purpose (GPGPU), the need to optimize for specific GPUs will approach the (real but relatively low) need to optimize for specific CPUs. The CPU-GPU bottleneck (or, whether to use PCIe 3.0 or on-die CPU/GPU integration): The impact of the bottleneck depends hugely on the algorithm. The problem of GPU physics: Simple techniques (resolution, antialiasing, texture resolution) scale graphics easily across many levels of hardware capability -- and this is how game developers have used GPUs in the past. Physics does not scale across hardware nearly as easily, so most developers handle GPU physics at the lowest (console) level. But HSA will make cross-hardware physics scaling much easier. HSA's benefits to small but parallel workloads (versus earlier GPGPU acceleration, which had disproportionately large effect on workloads with lots of data): HSA does not require cache flushing and copying between CPU and GPU, so the quantity of data shared matters much less than previous GPGPU acceleration attempts. HSA availability and AMD's long-term commitment to developers taking advantage of heterogeneous computing: AMD will continue to hold Fusion Developer Summits annually; is already partnering with Adobe, Cloudera, Penguin Computing, Gaikai, and SRS, and working closely with Sony, Adobe, Arcsoft, Winzip, Cyberlink, Corel, Roxio, and many more; and will continute to help make OpenCL development much easier. But the open-standard HSA is where AMD's major, highly ambitious effort in heterogeneous computing will lie, beginning in 2013-2014. HSA and HPC (high-performance computing): AMD is designing HSA-based APUs for both consumer and HPC markets. Penguin Computing will explain some of their HPC applications in detail during the upcoming Fusion Developer Summit (June 11-14). How software stacks will catch up with heterogeneous hardware: The HSA Intermediate Layer (HSAIL) will help facilitate this by insulating software stacks from individual ISAs. Why use graphics shading languages (OpenCL, DirectX) at all: Radical change must be evolutionary, not revolutionary (e.g., assembly -> C -> C++ -> Java). Existing codebases must be used effectively, not abandoned for code written in a theoretically perfect language (the 'software side' of heterogeneous computing). HSA is designed to help developers take advantage of their own skills and existing codebases at the same time. As several of these questions noted, the annual AMD Fusion Developer Summit is an essential component in the eventual rollout of the open-standard Heterogeneous Systems Architecture. No other conference covers heterogeneous computing specifically. The track list is amazingly broad, and the schedule incredibly ambitious. To GPGPU-wrestlers and non-wrestlers alike, heterogeneous computing is a thrilling, emerging technology. Learn more and consider attending the conference on June 11-14.

One crucial aspect of ensuring a secure Kubernetes infrastructure is the effective management of secrets, such as API keys, passwords, and tokens.

Explore how flexibility in ACE allows the progression of independent unit testing, without needing to wait for a larger organization to move to containers.

In this interview, learn more about what kind of data Foursquare deals with, what it does with that data, and how using a knowledge graph is going to help.

Learn how cloud-native JuiceFS empowers quantitative hedge funds to enhance AI training and achieve elastic throughput in the cloud.