Tech News

By Lance Eliot, the AI Trends Insider   After AI autonomous self-driving cars have been abundantly fielded onto our roadways, one intriguing question that has so far gotten scant attention is how long will those self-driving cars last.    It is easy to simply assume that the endurance of a self-driving car is presumably going to be the same as today’s conventional cars, especially since most of the self-driving cars are currently making use of a conventional car rather than a special-purpose built vehicle.  But there is something to keep in mind about self-driving cars that perhaps does not immediately meet the eye, namely, they are likely to get a lot of miles in a short period. Given that the AI is doing the driving, there is no longer a dampening on the number of miles that a car might be driven in any noted time period, which usually is based on the availability of a human driver. Instead, the AI is a 24 x 7 driver that can be used non-stop and attempts to leverage the self-driving car into a continuously moving and available ride-sharing vehicle.  With all that mileage, the number of years of endurance is going to be lessened in comparison to a comparable conventional car that is driven only intermittently. You could say that the car is still the car, while the difference is that the car might get as many miles of use in a much shorter period of time and thus reach its end-of-life sooner (though nonetheless still racking up the same total number of miles).  Some automotive makers have speculated that self-driving cars might only last about four years.  This comes as quite a shocking revelation that AI-based autonomous cars might merely be usable for a scant four years at a time and then presumably end-up on the scrap heap.  Let’s unpack the matter and explore the ramifications of a presumed four-year life span for self-driving cars.  For my framework about AI autonomous cars, see the link here: https://aitrends.com/ai-insider/framework-ai-self-driving-driverless-cars-big-picture/  Why this is a moonshot effort, see my explanation here: https://aitrends.com/ai-insider/self-driving-car-mother-ai-projects-moonshot/  For more about the levels as a type of Richter scale, see my discussion here: https://aitrends.com/ai-insider/richter-scale-levels-self-driving-cars/  For the argument about bifurcating the levels, see my explanation here: https://aitrends.com/ai-insider/reframing-ai-levels-for-self-driving-cars-bifurcation-of-autonomy/  Life Span Of Cars  According to various stats about today’s cars, the average age of a conventional car in the United States is estimated at 11.6 years old.  Some tend to use the 11.6 years or a rounded 12 years as a surrogate for how long a car lasts in the U.S, though this is somewhat problematic to do since the average age is not the endpoint of a car and encapsulates a range of ages of cars, including a slew of cars that were retired at a much younger age and those that hang-on to a much older age.  Indeed, one of the fastest-growing segments of car ages is the group that is 16 years or older, amounting to an estimated 81 million such cars by the year 2021. Of those 81 million cars, around one-fourth are going to be more than 25 years old.  In short, cars are being kept around longer and longer.  When you buy a new car, the rule-of-thumb often quoted by automakers is that the car should last about 8 years or 150,000 miles.  This is obviously a low-ball kind of posturing, trying to set expectations so that car buyers will be pleased if their cars last longer. One supposes it also perhaps gets buyers into the mental mode of considering buying their next car in about eight years or so.  Continuing the effort to consider various stats about cars, Americans drive their cars for about 11,000 miles per year. If a new car is supposed to last for 150,000 miles, the math then suggests that at 11,000 miles per year you could drive the car for 14 years (that’s 150,000 miles divided by 11,000 miles per year).  Of course, the average everyday driver is using their car for easy driving such as commuting to work and driving to the grocery store. Generally, you wouldn’t expect the average driver to be putting many miles onto a car.  What about those that are pushing their cars to the limit and driving their cars in a much harsher manner?  Various published stats about ridesharing drivers such as Uber and Lyft suggest that they are amassing about 1,000 miles per week on their cars. If so, you could suggest that the number of miles per year would be approximately 50,000 miles. At the pace of 50,000 miles per year, presumably, these on-the-go cars would only last about 3 years, based on the math of 150,000 miles divided by 50,000 miles per year.  In theory, this implies that a ridesharing car being used today will perhaps last about 3 years.  For self-driving cars, most would agree that a driverless car is going to be used in a similar ridesharing manner and be on-the-road quite a lot.  This seems sensible. To make as much money as possible with a driverless car, you would likely seek to maximize the use of it. Put it onto a ridesharing network and let it be used as much as people are willing to book it and pay to use it.  Without the cost and hassle of having to find and use a human driver for a driverless car, the AI will presumably be willing to drive a car whenever and however long is needed. As such, a true self-driving car is being touted as likely to be running 24×7.  In reality, you can’t actually have a self-driving car that is always roaming around, since there needs to be time set aside for ongoing maintenance of the car, along with repairs, and some amount of time for fueling or recharging of the driverless car.  Overall, it would seem logical to postulate that a self-driving car will be used at least as much as today’s human-driven ridesharing cars, plus a lot more so since the self-driving car is not limited by human driving constraints.  In short, if it is the case that today’s ridesharing cars are hitting their boundaries at perhaps three to five years, you could reasonably extend that same thinking to driverless cars and assume therefore that self-driving cars might only last about four years.  The shock that a driverless car might only last four years is not quite as surprising when you consider that a true self-driving car is going to be pushed to its limits in terms of usage and be a ridesharing goldmine (presumably) that will undergo nearly continual driving time.  For why remote piloting or operating of self-driving cars is generally eschewed, see my explanation here: https://aitrends.com/ai-insider/remote-piloting-is-a-self-driving-car-crutch/  To be wary of fake news about self-driving cars, see my tips here: https://aitrends.com/ai-insider/ai-fake-news-about-self-driving-cars/  The ethical implications of AI driving systems are significant, see my indication here: http://aitrends.com/selfdrivingcars/ethically-ambiguous-self-driving-cars/  Be aware of the pitfalls of normalization of deviance when it comes to self-driving cars, here’s my call to arms: https://aitrends.com/ai-insider/normalization-of-deviance-endangers-ai-self-driving-cars/  Factors Of Car Aging  Three key factors determine how long a car will last, namely:  How the car was built  How the car is used  How the car is maintained  Let’s consider how those key factors apply to self-driving cars.  In the case of today’s early versions of what are intended to be driverless cars, by-and-large most of the automakers are using a conventional car as the basis for their driverless car, rather than building an entirely new kind of car.  We will eventually see entirely new kinds of cars being made to fully leverage a driverless car capability, but for right now it is easier and more expedient to use a conventional car as the cornerstone for an autonomous car.  Therefore, for the foreseeable future, we can assume that the manner of how a driverless car was built is in keeping with how a conventional car is built, implying that the car itself will last as long as a conventional car might last.  In terms of car usage, as already mentioned, a driverless car is going to get a lot more usage than the amount of driving by an average everyday driver and be used at least as much as today’s ridesharing efforts. The usage is bound to be much higher.  The ongoing maintenance of a self-driving car will become vital to the owner of a driverless car.  I say this because any shortcomings in the maintenance would tend to mean that the driverless car will be in the shop and not be as available on the streets. The revenue stream from an always-on self-driving car will be a compelling reason for owners to make sure that their self-driving car is getting the proper amount of maintenance.  In that sense, the odds would seem to be the case that a driverless car will likely be better maintained than either an average everyday car or even today’s ridesharing cars.  One additional element to consider for driverless cars consists of the add-ons for the sensory capabilities and the computer processing aspects. Those sensory devices such as cameras, radar, ultrasonic, LIDAR, and so on, need to be factored into the longevity of the overall car, and the same applies to the computer chips and memory on-board too.  Why Retire A Car  The decision to retire a car is based on a trade-off between trying to continue to pour money into a car that is breaking down and excessively costing money to keep afloat, versus ditching the car and opting to get a new or newer car instead.  Thus, when you look at how long a car will last, you are also silently considering the cost of a new or newer car.  We don’t yet know what the cost of a driverless car is going to be.  If the cost is really high to purchase a self-driving car, you would presumably have a greater incentive to try and keep a used self-driving car in sufficient working order.  There is also a safety element that comes to play in deciding whether to retire a self-driving car.  Suppose a driverless car that is being routinely maintained is as safe as a new self-driving car, but eventually, the maintenance can only achieve so much in terms of ensuring that the driverless car remains as safe while driving on the roadways as would be a new or newer self-driving car.  The owner of the used self-driving car would need to ascertain whether the safety degradation means that the used driverless car needs to be retired.  Used Market For Self-Driving Cars  With conventional cars, an owner that first purchased a new car will likely sell the car after a while. We all realize that a conventional car might end-up being passed from one buyer to another over its lifespan.  Will there be an equivalent market for used self-driving cars?  You might be inclined to immediately suggest that once a self-driving car has reached some point of no longer being safe enough, it needs to be retired. We don’t yet know, and no one has established what that safety juncture or threshold might be.  There could be a used self-driving car market that involved selling a used driverless car that was still within some bounds of being safe.  Suppose a driverless car owner that had used their self-driving car extensively in a downtown city setting opted to sell the autonomous car to someone that lived in a suburban community. The logic might be that the self-driving car no longer was sufficient for use in a stop-and-go traffic environment but might be viable in a less stressful suburban locale.  Overall, no one is especially thinking about used self-driving cars, which is admittedly a concern that is far away in the future and therefore not a topic looming over us today.  Retirement Of A Self-Driving Car  Other than becoming a used car, what else might happen to a self-driving car after it’s been in use for a while?  Some have wondered whether it might be feasible to convert a self-driving car into becoming a human-driven car, doing so to place the car into the used market for human-driven cars.  Well, it depends on how the self-driving car was originally made. If the self-driving car has all of the mechanical and electronic guts for human driving controls, you could presumably unplug the autonomy and revert the car into being a human-driven car.  I would assert that this is very unlikely, and you won’t see self-driving cars being transitioned into becoming human-driven cars.  All told, it would seem that once a self-driving car has reached its end of life, the vehicle would become scrapped.  If self-driving cars are being placed into the junk heap every four years, this raises the specter that we are going to have a lot of car junk piling up. For environmentalists, this is certainly disconcerting.  Generally, today’s cars are relatively highly recyclable and reusable. Estimates suggest that around 80% of a car can be recycled or reused.  For driverless cars, assuming they are built like today’s conventional cars, you would be able to potentially attain a similar recycled and reused parts percentage. The add-ons of the sensory devices and computer processors might be recyclable and reusable too, though this is not necessarily the case depending upon how the components were made.  For why remote piloting or operating of self-driving cars is generally eschewed, see my explanation here: https://aitrends.com/ai-insider/remote-piloting-is-a-self-driving-car-crutch/  To be wary of fake news about self-driving cars, see my tips here: https://aitrends.com/ai-insider/ai-fake-news-about-self-driving-cars/  The ethical implications of AI driving systems are significant, see my indication here: http://aitrends.com/selfdrivingcars/ethically-ambiguous-self-driving-cars/  Be aware of the pitfalls of normalization of deviance when it comes to self-driving cars, here’s my call to arms: https://aitrends.com/ai-insider/normalization-of-deviance-endangers-ai-self-driving-cars/  Conclusion  Some critics would be tempted to claim that the automakers would adore having self-driving cars that last only four years.  Presumably, it would mean that the automakers will be churning out new cars hand-over-fist, doing so to try and keep up with the demand for an ongoing supply of new driverless cars.  On the other hand, some pundits have predicted that we won’t need as many cars as we have today, since a smaller number of ridesharing driverless cars will fulfill our driving needs, abetting the need for everyone to have a car.  No one knows.  Another facet to consider involves the pace at which high-tech might advance and thus cause a heightened turnover in self-driving cars. Suppose the sensors and computer processors put into a driverless car are eclipsed in just a few years by faster, cheaper, and better sensors and computer processors.  If the sensors and processors of a self-driving car are built-in, meaning that you can’t just readily swap them out, it could be that another driving force for the quicker life cycle of a driverless car might be as a result of the desire to make use of the latest in high-tech.  The idea of retiring a driverless car in four years doesn’t seem quite as shocking after analyzing the basis for such a belief.  Whether society is better off or not as a result of self-driving cars, and also the matter of those self-driving cars only lasting four years, is a complex question. We’ll need to see how this all plays out.  Copyright 2020 Dr. Lance Eliot   This content is originally posted on AI Trends.  [Ed. Note: For reader’s interested in Dr. Eliot’s ongoing business analyses about the advent of self-driving cars, see his online Forbes column: https://forbes.com/sites/lanceeliot/]       

The discussions regarding the Julia release process started last year when it hit Julia 1.0. Yesterday, Stefan Karpinski, one of Julia's core developers shared its finalized release process giving details on the kind of releases, the stages of the release process, the phases of a release, and more. “This information is collected from a small set of posts on discourse and conversations on Slack, so the information exists “out there”, but this blog post brings it all together in a single place. We may turn this post into an official document if it’s well-received,” Stefan wrote. Types of Julia releases As with most programming languages that follow Semantic Versioning (SemVer), Julia has three types of releases: Patch, Minor, and Major. A patch release will be represented by the last digit of Julia’s version number. It will include things like bug fixes, low-risk performance improvements, and documentation updates. The team plans to release a patch every month for the current active release branches, however, this will depend on the number of bug fixes. The team also plans to run PackageEvaluator (PkgEval) on the backports five days prior to the patch release. PkgEval is used to run tests for every registered package, update the web pages of Julia packages, and create status badges. A minor release will be represented by the middle digit of Julia’s version number. Along with some bug fixes and new features, it will include changes that are unlikely to break your code and the package ecosystem. Any significant refactoring of the internals will also be included in the minor release. Since minor releases are branched every four months, developers can expect three minor releases every year. A major release will be represented by the first digit of Julia’s version number. Typically, major releases consist of breaking changes, but the team assures to introduce them only when there is an absolute need, for instance, fixing API design mistakes. It will also include low-level changes that can end up breaking some libraries but are essential for fundamental improvements to the language. Julia’s release process There are three phases in the Julia release process. The development phase takes up 1-4 months where new features are introduced, bugs are fixed, and more. Before the feature freeze, alpha (early preview) and beta (later preview) versions are released for developers to test them and to share their feedback. After the feature freeze, a new unstable release branch is created. In the development phase, the new features will be merged onto the master branch, while the bug fixes will go on the release branch. The second phase, stabilization, also takes up 1-4 months where all known release-blocking bugs are fixed and release candidates are built. Then they are checked for any more release-blocking bugs for one week and if there are none a final release is announced. After this, starts the maintenance phase where bug fixes are backported to the release branch. This continues till a particular release branch is declared to be unmaintained. To ensure the quality of releases and maintaining a predictable release rate the Julia team overlaps the development and stabilization phases. “The development phase of each release is time-boxed at four months and the development phase of x.(y+1) starts as soon as the development phase for x.y is over. Come rain or shine we have a new feature freeze every four months: we pick a day and you’ve got to get your features merged by that day. If new features aren’t merged, they’re not going in the release. But that’s ok, they’ll go in the next one,” explains Karpinski. Talking about long term support, Karpinski wrote that there will be four active branches. The master branch is where all the new features, bug fixes, and breaking changes will go. The unstable release branch will include all the active bug fixing and performance work that happens prior to the next minor release. The stable release branch is where the most recently released minor or major version exists. The fourth one is the long term support (LTS) branch, which is currently Julia 1.0. This branch continues to get applicable bug fixes until it is announced to be unmaintained. Karpinski also shared the different fault tolerance personas in Julia. Check out his post on the Julia blog to get a better understanding of the Julia release process. Julia announces the preview of multi-threaded task parallelism in alpha release v1.3.0 Julia Angwin fired as Editor-in-Chief of The Markup prompting mass resignations in protest Creating a basic Julia project for loading and saving data [Tutorial]  

By John P. Desmond, AI Trends Editor Web applications are the primary focus of many cybercrime gangs engaged in data breaches, a primary security concern to retailers, according to the 2020 Data Breach Investigations Report (DBIR) recently released by Verizon, in its 13th edition of the report. Verizon analyzed a total of 157,525 incidents; 3,950 were confirmed data breaches.  “These data breaches are the most serious type of incident retailers face. Such breaches generally result in the loss of customer data, including, in the worst cases, payment data and log-in and password combinations,” stated Ido Safruti, co-founder and chief technology officer, PerimeterX, a provider of security services for websites, in an account in Digital Commerce 360. Among the reports highlights: Misconfiguration errors, resulting from failure to implement all security controls, top the list of the fastest-growing risk to web applications. Across all industries, misconfiguration errors increased from below 20 percent in the 2017 survey to over 40 percent in the 2020 survey. “The reason for this is simple,” Safruti stated. “Web applications are growing more and more complex. What were formerly websites are now full-blown applications made up of dozens of components and leveraging multiple external services.” Ido Safruti, co-founder and chief technology officer, PerimeterX External code can typically comprise 70 percent or more of web applications, many of them JavaScript calls to external libraries and services. “A misconfigured service or setting for any piece of a web application offers a path to compromise the application and skim sensitive customer data,” Safruti stated. Cybercriminal gangs work to exploit rapid changes on web applications, as development teams build and ship new code faster and faster, often tapping third-party libraries and services. Weaknesses in version control and monitoring of changes to web applications for unauthorized introductions of code, are vulnerabilities. Magecart attacks, from a consortium of malicious hacker groups who target online shopping cart systems especially on large ecommerce sites, insert rogue elements as components of Web applications with the goal of stealing credit card data of shoppers.  “Retailers should consider advanced technology using automated and audited processes to manage configuration changes,” Safruti advises. Vulnerabilities are not patched quickly enough, leaving holes for attacks to exploit. Only half of vulnerabilities are patched within three months of discovery, the 2020 DBIR report found. These attacks offer hackers the potential of  large amounts of valuable customer information with the least amount of effort.   Attacks against web application servers made up nearly 75% of breached assets in 2019, up from roughly 50% in 2017, the DBIR report found. Organized crime groups undertook roughly two-thirds of breaches and 86% of breaches were financially motivated. The global average cost of a data breach is $3.92 million, with an average of over $8 million in the United States, according to a 2019 study from the Ponemon Institute, a research center focused on privacy, data protection and information security. Another analysis of the 2020 DBIT report found that hacking and social attacks have leapfrogged malware as the top attack tactic. “Sophisticated malware is no longer necessary to perform an attack,” stated the report in SecurityBoulevard.  Developers and QA engineers who develop and test web applications would benefit from the use of automated security testing tools and security processes that integrate with their workflow. “We believe developers and DevOps personnel are one of the weakest links in the chain and would benefit the most from remediation techniques,” the authors stated. Credential Stuffing Attack Exploit Users with Same Password Across Sites Credential stuffing is a cyberattack where lists of stolen usernames and/or email addresses are used to gain unauthorized access to user accounts through large-scale automated login requests directed against a web application.  “Threat actors are always conducting credential stuffing attacks,” found a “deep dive” analysis of the 2020 DBIR report from SpyCloud, a security firm focused on preventing online fraud.   The SpyCloud researchers advise users never to reuse passwords across online accounts. “Password reuse is a major factor in credential stuffing attacks,” the authors state. They advise using a password manager and storing a unique complex password for each account. The 2020 DBIR report found this year’s top malware variant to be password dumpers, malware that extracts passwords from infected systems. This malware is aimed at acquiring credentials stored on target computers, or involve keyloggers that acquire credentials as users enter them.  Some 22 percent of breaches found were the result of social attacks, which are cyber attacks that involve social engineering and phishing. Phishing – making fake websites, emails, text messages, and social media messages to impersonate trusted entities – is still a major way that sensitive authentication credentials are acquired illicitly, SpyCloud researchers found. Average consumers are each paying more than $290 in out-of-pocket costs and spending 16 hours to resolve the effects of this data loss and the resultant account takeover, SpyCloud found.  Business Increasing Investment in AI for Cybersecurity, Capgemini Finds To defend against the new generation of cyberattacks, businesses are increasing their investment in AI systems to help. Two-thirds of organizations surveyed by Capgemini Research last year said they will not be able to respond to critical threats without AI. Capgemini surveyed 850 senior IT executives from IT information security, cybersecurity and IT operations across 10 countries and seven business sectors. Among the highlights was that AI-enabled cybersecurity is now an imperative: Over half (56%) of executives say their cybersecurity analysts are overwhelmed by the vast array of data points they need to monitor to detect and prevent intrusion. In addition, the type of cyberattacks that require immediate intervention, or that cannot be remediated quickly enough by cyber analysts, have notably increased, including: cyberattacks affecting time-sensitive applications (42% saying they had gone up, by an average of 16%). automated, machine-speed attacks that mutate at a pace that cannot be neutralized through traditional response systems (43% reported an increase, by an average of 15%). Executives interviewed cited benefits of using AI in cybersecurity:  64% said it lowers the cost of detecting breaches and responding to them – by an average of 12%. 74% said it enables a faster response time: reducing time taken to detect threats, remedy breaches and implement patches by 12%. 69% also said AI improves the accuracy of detecting breaches, and 60% said it increases the efficiency of cybersecurity analysts, reducing the time they spend analyzing false positives and improving productivity. Budgets for AI in cybersecurity are projected to rise, with almost half (48%) of respondents said they are planning 29 percent increases in FY2020; some 73 percent were testing uses cases for AI in cybersecurity; only one in five organizations reported using AI in cybersecurity before 2019. “AI offers huge opportunities for cybersecurity,” stated Oliver Scherer, CISO of Europe’s leading consumer electronics retailer, MediaMarktSaturn Retail Group, in the Capgemini report. “This is because you move from detection, manual reaction and remediation towards an automated remediation, which organizations would like to achieve in the next three or five years.” Geert van der Linden, Cybersecurity Business Lead, Capgemini Group Barriers remain, including a lack of understanding in how to scale use cases from proof of concept to full-scale deployment.   “Organizations are facing an unparalleled volume and complexity of cyber threats and have woken up to the importance of AI as the first line of defense,” stated Geert van der Linden, Cybersecurity Business Lead at Capgemini Group. “As cybersecurity analysts are overwhelmed, close to a quarter of them declaring they are not able to successfully investigate all identified incidents, it is critical for organizations to increase investment and focus on the business benefits that AI can bring in terms of bolstering their cybersecurity.” Read the source articles in the 2020 Data Breach Investigations Report from Verizon,  in Digital Commerce 360, in SecurityBoulevard, from SpyCloud and from Capgemini Research.  

Last week, Microsoft open-sourced its implementation of the C++ Standard Library, also known as STL. The library is shipped along with MSVC (Microsoft Visual C++ compiler) toolset and the Visual Studio IDE. This announcement was made by MSVC team at the CppCon 2019 conference, two days ago. Users can use the C++ library repo for participating in the STL's development by reporting issues and commenting on pull requests. The MSVC team is still working on migrating the C++ Standard Library to GitHub. Currently, the Github repository contains all of MSVC's product source code including a new CMake build system and a README. The team also plans to use the GitHub issues to track C++20 features, LWG issues, conformance bugs, performance improvements, and other todos. The roadmap and iteration plans of the C++ Standard Library is also under progress. Why Microsoft open-sourced the C++ Standard Library? Microsoft has open-sourced STL to allow it’s users easy access to all the latest developments in C++ by trying out latest changes and improving pull requests by reviewing them. The MSVC team hopes that as C++ standardization accelerates, it will be easier for users to accept the major features. Microsoft chose to open-source STL particularly due to its unique design and fast-evolving nature when compared to other MSVC libraries and compiler. It is also “easy to contribute to, and somewhat loosely coupled, unlike the compiler.” The official blog post adds, “We also want to contribute back to the C++ community by making it possible to take our implementations of major features.” What are the primary goals of the C++ Standard Library? Microsoft is implementing the latest C++ Working Draft, which will eventually become the next C++ International Standard. The goals of the Microsoft C++ Standard Library are to be conformant to spec, extremely fast, usable, and extensive compatibility. Speed being the core strength of C++, STL needs to be extremely fast at runtime. Thus, the MSVC team spends more time on the optimization of the C++ Standard Library than the most general-purpose libraries. They are also working on parts of the programming experience like compiler throughput, diagnostic messages, and debugging checks. They are also keeping VS 2019 binary-compatible with VS 2017 and VS 2015. They consider source compatibility to be important, but not all-important; breaking source compatibility can be an acceptable cost if done for the right reasons in the right way. The blog post states that MSVC’s STL is distributed under the Apache License v2.0 with LLVM Exceptions and is distinct from the libc++ library. However, if any libc++’s maintainers are interested in taking feature implementations from MSVC’s STL or in collaborating on the development of new features in both libraries simultaneously, the MSVC team will help irrespective of the licensing. Users have welcomed Microsoft’s move to open-source it’s C++ Standard Library (STL). A Redditor says, “Thank you! Absolutely amazing. It's been one of my guilty pleasures ever since I started with C++ to prod about in your internals to see how stuff works so this is like being taken to the magical chocolate factory for me.” Another user comments, “thank you for giving back to the open source world. ❤🤘” Interested readers can learn how to build with the Native Tools Command Prompt and a Visual Studio IDE on Github. Latest news in Tech Open AI researchers advance multi-agent competition by training AI agents in a simple hide and seek environment As Kickstarter reels in the aftermath of its alleged union-busting move, is the tech industry at a tipping point? Linux 5.3 releases with support for AMD Navi GPUs, Zhaoxin x86 CPUs and power usage improvements

At the first re:MARS event early this month Amazon proposed its plans to further digitize its delivery services by making the AI-powered drones deliver orders. Amazon was recently granted a US patent on June 4 for these ‘unmanned aerial vehicles (UAV) or drones’ to provide “surveillance as a service.” The patent which was filed on June 12, 2015, mentions how Amazon’s UAVs could keep an eye on customers’ property between deliveries while supposedly maintaining their privacy. “The property may be defined by a geo-fence, which may be a virtual perimeter or boundary around a real-world geographic area. The UAV may image the property to generate surveillance images, and the surveillance images may include image data of objects inside the geo-fence and image data of objects outside the geo-fence,” the patent states. A diagram from the patent shows how delivery drones could be diverted to survey a location. Source: USPTO According to The Telegraph, “The drones would look for signs of break-ins, such as smashed windows, doors left open, and intruders lurking on people’s property. Anything unusual could then be photographed and passed on to the customer and the police”. “Drones have long been used for surveillance, particularly by the military, but companies are now beginning to explore how they might be used for home security”, The Verge reports. Amazon’s competitor, Alphabet Inc.’s Wing, became the first drone to win an FAA approval to operate as a small airline, in April. However, Amazon received an approval to start making drone deliveries only in remote parts of the United States. Amazon says it hopes to launch a commercial service “in a matter of months.” The drones could be programmed to trigger automated text or phone alerts if the system’s computer-vision algorithms spot something that could be a concern. Those alerts might go to the subscriber, or directly to the authorities. “For example, if the surveillance event is the determination that a garage door was left open, an alert may be a text message to a user, while if the surveillance event is a fire, an alert may be a text message or telephone call to a security provider or fire department,” the inventors write. But this raises a lot of data privacy concerns as this may allow drones to peep into people’s houses and collect information they are not supposed to. However, Amazon’s patent stating that, “Geo-clipped surveillance images may be generated by physically constraining a sensor of the UAV, by performing pre-image capture processing, or post-image capture processing. Geo-clipped surveillance images may be limited to authorized property, so privacy is ensured for private persons and property.” Amazon has been curating a lot of user data using various products including the smart doorbell made by Ring, which Amazon bought for more than $1 billion in February last year. This smart doorbell sends a video feed customers can check and answer from their smartphone. Amazon launched Neighbors, a crime-reporting social network that encourages users to upload videos straight from their Ring security cameras and tag posts with labels like “Crime,” “Safety,” and “Suspicious.” Over 50 local US police departments have partnered with Ring to gain access to its owners’ security footage. Amazon’s Key allows Prime members to have packages delivered straight into their homes—if they install its smart lock on their door and Amazon security cameras inside their homes. Last month, the US House Oversight and Reform Committee held its first hearing on examining the use of ‘Facial Recognition Technology’. The hearing included discussion on the use of facial recognition by government and commercial entities, flaws in the technology, lack of regulation and its impact on citizen’s civil rights and liberties. Joy Buolamwini, founder of Algorithmic Justice League highlighted one of the major pressing points for the failure of this technology as ‘misidentification’, that can lead to false arrests and accusations, a risk especially for marginalized communities. Earlier this year in January, activist shareholders proposed a resolution to limit the sale of Amazon’s facial recognition tech called Rekognition to law enforcement and government agencies. Rekognition was found to be biased and inaccurate and is regarded as an enabler of racial discrimination of minorities. Rekognition, runs image and video analysis of faces, has been sold to two states; Amazon has also pitched it to Immigration and Customs Enforcement. Last month, Amazon shareholders rejected the proposal on ban of selling its facial recognition tech to governments. Amazon pushed back the claims that the technology is inaccurate, and called on the U.S. Securities and Exchange Commission to block the shareholder proposal prior to its annual shareholder meeting. While ACLU blocked Amazon’s efforts to stop the vote, amid growing scrutiny of its product. According to an Amazon spokeswoman, the resolutions failed by a wide margin. Amazon has defended its work and said all users must follow the law. It also added a web portal for people to report any abuse of the service. The votes were non-binding, thus, allowing the company to reject the outcome of the vote. In April, Bloomberg reported that Amazon workers “listen to voice recordings captured in Echo owners’ homes and offices. The recordings are transcribed, annotated and then fed back into the software as part of an effort to eliminate gaps in Alexa’s understanding of human speech and help it better respond to commands”. Also, this month, two lawsuits were filed in Seattle alleging that Amazon is recording voiceprints of children using its Alexa devices without their consent. This shows Amazon may be secretly collecting user’s data and now, with the surveillance drones they can gain access to user’s home on the whole. What more can a company driven on user data ask for? We’ll have to see if Amazon stays true to what they have stated in their patent. While drones hovering over for surveillance seems interesting, it is actually collecting large volumes of user data, and a lot of private information. Black hat hackers who use their skills to break into systems and access data and programs without the permission of the owners may gain access to this data, which is a risk. They can further sell the data to 3rd party buyers including advertisement companies who may further use it to forward advertisements on particular products they use. Amazon employees managing the data from these drones may also have certain access to this data. As a network administrator or security professional, the rights and privileges allow them access most of the data on the systems of user’s network. Also, one can easily decrypt the data if they have access to the recovery agent account. This creates an alarming state whether this extra private is data safe or not? On what level can intruders misuse this? According to The Verge, “Amazon has patented some pretty eccentric drone technologies over the years that have never made it to market; including a floating airship that could act as a warehouse for delivery drones, a parachute shipping label, and a system that lets a drone understand when you shout or wave at it”. https://twitter.com/drewharwell/status/1141712282184867840 https://twitter.com/drewharwell/status/1141793761283989504 To know more about ‘surveillance as a service’ read the patent. Amazon announces general availability of Amazon Personalize, an AI-based recommendation service US regulators plan to probe Google on anti-trust issues; Facebook, Amazon & Apple also under legal scrutiny Amazon shareholders reject proposals to ban sale of facial recognition tech to govt and to conduct independent review of its human and civil rights impact

Microsoft has good news for all the game developers out there. It launched a new initiative, called Microsoft Game Stack yesterday, which includes an amalgamation of different Microsoft tools and services into a single robust ecosystem to ‘empower game developers’. It doesn’t matter whether you’re a rookie indie developer or an AAA studio, this developer-focused platform will make the game development process ten times easier for you. The main goal of Game Stack is to help developers easily find different tools and services required for game development at one spot. These tools range from Azure, PlayFab, DirectX, Visual Studio, to  Xbox Live, App Center, and Havok. Cloud plays a major role in Game Stack and it makes use of Azure to fulfill this requirement. Source: Microsoft Azure is globally available in 54 regions will help scale its Project xCloud (a service that streams games to PCs, consoles, and mobile devices) to provide an uninterrupted gaming experience for players worldwide. Not to forget, companies like Rare, Ubisoft and Wizards of the Coast are already hosting multiplayer game servers and storing their player data on Azure. It is also capable of analyzing game telemetry, protecting games from DDOS attacks, and training AI. Moreover, Microsoft Game Stack is device agnostic which makes it really convenient for the gamers. Another great component of Game Stack is a backend service for operating and building new games, called PlayFab. PlayFab offers game development services, real-time analytics, and LiveOps capabilities to Game Stack. PlayFab is also device agnostic. It supports iOS, Android, PC, Web, Xbox, Sony PlayStation, Nintendo Switch and all the other major game engines such as Unity and Unreal. Microsoft has also released a preview for five new PlayFab services. Out of these five, one, called, PlayFab Matchmaking is open for public preview, while other four including PlayFab Party, PlayFab Insights, PlayFab PubSub, and PlayFab user-generated Content are in private preview. Game Stack also comes with Xbox Live, one of the most engaging and interactive gaming communities in the world. Xbox Live will be providing identity and community services in the Game Stack. Microsoft has also expanded the cross-platform capabilities of Xbox Live under Game Stack with a new SDK for iOS and Android devices. Mobile developers will be able to easily connect with some of the most highly engaged and passionate gamers on the planet using Xbox Live. Other benefits of the Xbox Live SDK includes more focus on building games and leveraging Microsoft‘s trusted identity network to offer support for log-in, privacy, online safety and child accounts. Apart from that, there are features like gamerscore, and “hero” stats, that help keep the gamers engaged. Also, components such as Visual Studio, Mixer, DirectX, Azure App Center, Visual Studio, Visual Studio Code, and Havok are all a part of Game Stack. For more information, check out the official Microsoft Game Stack blog post. Microsoft open sources the Windows Calculator code on GitHub Microsoft open sources ‘Accessibility Insights for Web’, a chrome extension to help web developers fix their accessibility issue Microsoft researchers introduce a new climate forecasting model and a public dataset to train these models

Open AI researchers have built a simple hide and seek game environment for multi-agent competition where they observed that AI agents can learn complex strategies and skills on their own as the game progresses. In fact, these AI agents built six distinct strategies and counterstrategies, some of which were not even supported by the training environment. The researchers concluded that such multi-agent co-adaptation may one day produce extremely complex and intelligent behavior. The Hide and Seek training environment AI agents play a team-based hide-and-seek game in a physics-based environment. Hiders (blue) avoid the line of sight from the seekers, and the seekers keep the vision of the hiders. The environment has various objects (walls, ramps, blocks) that agents can grab and also lock in place. There are also randomly generated immovable rooms and walls that the agents must learn to navigate. Before the game, hiders are given a preparation time to run away or change their environment and the seekers are immobilized. Agents are given a team-based reward; hiders are given a reward of +1 if all hiders are hidden and -1 if any hider is seen by a seeker. Seekers are given the opposite reward, -1 if all hiders are hidden and +1 otherwise. There are no explicit incentives for agents to interact with objects in the environment; they are penalized if they go too far outside the play area. Agent characteristics The agents can move by setting a force on themselves in the x and y directions as well as rotate along the z-axis. The agents can see objects in their line of sight and within a frontal cone. The agents can sense the distance to objects, walls, and other agents around them using a lidar-like sensor. The agents can grab and move objects in front of them. The agents can lock objects in place. Only the team that locked an object can unlock it. AI agents develop six distinct strategies Agents are trained using self-play and agent policies are composed of two separate networks with different parameters. This includes a policy network that produces an action distribution and a critic network that predicts the discounted future returns. Policies are optimized using Proximal Policy Optimization (PPO) and Generalized Advantage Estimation (GAE); training is performed using OpenAI’s rapid, it’s general-purpose RL training system. The researchers noticed that as agents train against each other in hide-and-seek, six distinct strategies emerge. Initially, hiders and seekers learn to crudely run away and chase. After approximately 25 million episodes of hide-and-seek, the hiders learn to use the tools at their disposal and intentionally modify their environment. After another 75 million episodes, the seekers also learn rudimentary tool use; they learn to move and use ramps to jump over obstacles, etc. 10 million episodes later, the hiders learn to defend against this strategy; the hiders learn to bring the ramps to the edge of the play area and lock them in place, seemingly removing the only tool the seekers have at their disposal. After 380 million total episodes of training, the seekers learn to bring a box to the edge of the play area where the hiders have locked the ramps. The seekers then jump on top of the box and surf it to the hiders’ shelter In response, the hiders learn to lock all of the boxes in place before building their shelter. https://youtu.be/kopoLzvh5jY They also found some surprising behavior by these AI agents. Box surfing: Since agents move by applying forces to themselves, they can grab a box while on top of it and “surf” it to the hider’s location. Endless running: Without adding explicit negative rewards for agents leaving the play area, in rare cases, hiders will learn to take a box and endlessly run with it. Ramp exploitation (hiders): Hiders abuse contact physics and remove ramps from the play area. Ramp exploitation (seekers): Seekers learn that if they run at a wall with a ramp at the right angle, they can launch themselves upward. The researchers concluded that complex human-relevant strategies and skills can emerge from multi-agent competition and standard reinforcement learning algorithms at scale. They state, “our results with hide-and-seek should be viewed as a proof of concept showing that multi-agent auto-curricula can lead to physically grounded and human-relevant behavior.” This research was well appreciated by readers. Many people took to Hacker News to congratulate the researchers. Here are a few comments. “Amazing. Very cool to see this sort of multi-agent emergent behavior. Along with the videos, I can't help but get a very 'Portal' vibe from it all. "Thank you for helping us help you help us all." “This is incredible. The various emergent behaviors are fascinating. It seems that OpenAI has a great little game simulated for their agents to play in. The next step to make this even cooler would be to use physical, robotic agents learning to overcome challenges in real meatspace!” “I'm completely amazed by that. The hint of a simulated world seems so matrix-like as well, imagine some intelligent thing evolving out of that. Wow.” Read the research paper for a deeper analysis. The code is available on GitHub. More news in Artificial Intelligence Google researchers present Weight Agnostic Neural Networks (WANNs) that perform tasks without learning weight parameters DeepMind introduces OpenSpiel, a reinforcement learning-based framework for video games Google open sources an on-device, real-time hand gesture recognition algorithm built with MediaPipe

After releasing the RC0 version of React Native 0.59, the team announced its stable release yesterday. This release comes with some of the most awaited features including React Hooks, updated JavaScriptCore, and more. Support for React Hooks React Hooks were introduced to solve a wide variety of problems in React. It enables you to reuse stateful logic across components without having to restructure your components hierarchy. With React Hooks, you can split a component into smaller functions, based on what pieces are related rather than forcing a split based on lifecycle methods. It also lets you use more of React’s features without classes. Updated JavaScriptCore The JavaScriptCore (JSC) is an engine that allows Android developers to use JavaScript natively in their apps. React Native 0.59 comes with an updated JSC for Android, and hence supports a lot of modern JavaScript features. These features include 64-bit support, JavaScript support, and big performance improvements. Improved app startup time with inline requires Applications now load resources as and when required to prevent slowing down the app launch. This feature is known as “inline requires”, which delay the requiring of a module or file until that module or file is actually needed. Using inline requires can result in startup time improvements. CLI improvements Earlier, React Native CLI improvements had long-standing issues and lacked official support. The CLI tools are now moved to a new repository and come with exciting improvements. Now, logs are formatted better and commands run almost instantly. Breaking changes React Native 0.59 has been cleaned up following Google's latest recommendations, which could result in potential breakage of existing apps. You might experience a runtime crash and see a message like this, “You need to use a Theme.AppCompat theme (or descendant) with this activity." Developers are recommended to update their project’s AndroidManifest.xml file to make sure that “android:theme” value is an AppCompat theme. Also, in this release, the “react-native-git-upgrade” command has been replaced with the newly improved “react-native upgrade” command. To read the official announcement, check out React Native’s website. React Native community announce March updates, post sharing the roadmap for Q4 React Native Vs Ionic: Which one is the better mobile app development framework? How to create a native mobile app with React Native [Tutorial]

Yesterday, Red Hat introduced the open source Project Quay container registry, which is the upstream project representing the code that powers Red Hat Quay and Quay.io. Open-sourced as a Red Hat commitment, Project Quay “represents the culmination of years of work around the Quay container registry since 2013 by CoreOS, and now Red Hat,” the official post reads. Red Hat Quay container image registry provides storage and enables users to build, distribute, and deploy containers. It will also help users to gain more security over their image repositories with automation, authentication, and authorization systems. It is compatible with most container environments and orchestration platforms and is also available as a hosted service or on-premises. Launched in 2013, Quay grew in popularity due to its focus on developer experience and highly responsive support and added capabilities such as image rollback and zero-downtime garbage collection. Quay was acquired by CoreOS in 2014 with a mission to secure the internet through automated operations. Shortly after the acquisition, the company released the on-premise offering of Quay, which is presently known as Red Hat Quay. The Quay team also created and integrated the Clair open source container security scanning project since 2015. It is directly built into Project Quay. Clair enables the container security scanning feature in Red Hat Quay, which helps users identify known vulnerabilities in their container registries. Open-sourced as part of Project Quay, both Quay, and Clair code bases will help cloud-native communities to lower the barrier to innovation around containers, helping them to make containers more secure and accessible. Project Quay contains a collection of open-source software licensed under Apache 2.0 and other open-source licenses. It follows an open-source governance model, with a maintainer committee. With an open community, Red Hat Quay and Quay.io users can benefit from being able to work together on the upstream code. Project Quay will be officially launched at the OpenShift Commons Gathering on November 18 in San Diego at KubeCon 2019. To know more about this announcement, you can read Red Hat’s official blog post. Red Hat announces CentOS Stream, a “developer-forward distribution” jointly with the CentOS Project Expanding Web Assembly beyond the browser with Bytecode Alliance, a Mozilla, Fastly, Intel and Red Hat partnership After Red Hat, Homebrew removes MongoDB from core formulas due to its Server Side Public License adoption

Multiple Google Pixel phones experienced an automatic activation of the ‘Battery Saver mode’ today when their phone was almost fully charged. Reddit saw a surge of comments on how users were taken by surprise due to the automatic turning on of the Battery Saver mode. The Pixel team responded to these comments clarifying that ‘an internal experiment to test battery saving features was mistakenly rolled out to more users than intended.’. Even though the settings have been reverted back to the default on their end, the amount of control that Google has on a user’s phone without their knowledge is scary. In most devices, the battery saver mode automatically kicks in when the phone’s charge level reaches a certain threshold. Users can change the percentage at which the battery saver activates. Apparently, Google manipulated the percentage for the users remotely. Reddit saw multiple users responding to Google’s claims of the “mistakenly deployed experiment”   Source: Reddit This is not the first time that users have felt a loss of control over Google-operated services. In October 2017, Google locked out users from Google docs for a violation of their TOS. While many users affirmed that their content nowhere violated the TOS, Google responded saying that they “mistakenly blocked access” to some of their users’ files, including Google Docs. This was due to a short-lived bug that incorrectly flagged some files as violating their terms of service (TOS). The bug was soon removed and the team restored affected users access to all affected files. In both these cases, the changes took place without any prior notification to the users. These ‘accidental mistakes’ on Google’s part raises concerns of the level of control Google has over user devices and data that users aren’t yet aware of. Incidentally, AndroidPolice also reported yesterday that android handsets running Pie or a Pie beta (like Pixel models, the Essential Phone, Nokia 7 Plus, and the OnePlus 6) also experienced the Battery saver issue. Bloomberg says Google, Mastercard covertly track customers’ offline retail habits via a secret million dollar ad deal Like newspapers, Google algorithms are protected by the First amendment making them hard to legally regulate them Google slams Trump’s accusations, asserts its search engine algorithms do not favor any political ideology  

Theo de Raadt and the OpenBSD developers who maintain the OpenSSH, today released the latest version OpenSSH 8.0. OpenSSH 8.0 has an important security fix for a weakness in the scp(1) tool when you use scp for copying files to/from remote systems. Till now when copying files from remote systems to a local directory, SCP was not verifying the filenames of what was being sent from the server to client. This allowed a hostile server to create or clobber unexpected local files with attack-controlled data regardless of what file(s) were actually requested for copying from the remote server. OpenSSH 8.0 adds client-side checking that the filenames sent from the server match the command-line request. While this client-side checking added to SCP, the OpenSSH developers recommend against using it and instead use sftp, rsync, or other alternatives. "The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead.", mention OpenSSH developers. New to OpenSSH 8.0 meanwhile is support for ECDSA keys in PKCS#11 tokens, experimental quantum-computing resistant key exchange method. Also, the default RSA key size from ssh-keygen has been increased to 3072 bits and more SSH utilities supporting a "-v" flag for greater verbosity are added. It also comes with a wide range of fixes throughout including a number of portability fixes. More details on OpenSSH 8.0 is available on OpenSSH.com. OpenSSH, now a part of the Windows Server 2019 OpenSSH 7.8 released! OpenSSH 7.9 released

For the past several years, Microsoft and Red Hat have worked together to co-develop hybrid cloud solutions intended to enable greater customer innovation. In 2019, we launched Azure Red Hat OpenShift as a fully managed, jointly engineered implementation of Red Hat OpenShift running on Red Hat OpenShift 3.11 that is deeply integrated into the Azure control plane. With the release of Red Hat OpenShift 4, we announced the general availability of Azure Red Hat OpenShift on OpenShift 4 in April 2020. Today we’re sharing that in collaboration with Red Hat, we are dropping the price of Red Hat OpenShift licenses on Azure Red Hat OpenShift worker nodes by up to 77 percent. We’re also adding the choice of a three-year term for Reserved Instances (RIs) on top of the existing one year RI and pay as you go options, with a reduction in the minimum number of virtual machines required. The new pricing is effective immediately. Finally, as part of the ongoing improvements, we are increasing the Service Level Agreement (SLA) to be 99.95 percent. With these new price reductions, Azure Red Hat OpenShift provides even more value with a fully managed, highly-available enterprise Kubernetes offering that manages the upgrades, patches, and integration for the components that are required to make a platform. This allows your teams to focus on building business value, not operating technology platforms. How can Red Hat OpenShift help you? As a developer Kubernetes was built for the needs of IT Operations, not developers. Red Hat OpenShift is designed so developers can deploy apps on Kubernetes without needing to learn Kubernetes. With built-in Continuous Integration (CI) and Continuous Delivery (CD) pipelines, you can code and push to a repository and have your application up and running in minutes. Azure Red Hat OpenShift includes everything you need to manage your development lifecycle; standardized workflows, support for multiple environments, continuous integration, release management, and more. Also included is the provision self-service, on-demand application stacks, and deploy solutions from the Developer Catalog such as OpenShift Service Mesh, OpenShift Serverless, Knative, and more. Red Hat OpenShift provides commercial support for the languages, databases, and tooling you already use, while providing easy access to Azure services such as Azure Database for PostgreSQL and Azure Cosmos DB, to enable you create resilient and scalable cloud native applications. As an IT operator Adopting a container platform lets you keep up with application scale and complexity requirements. Azure Red Hat OpenShift is designed to make deploying and managing the container platform easier, with automated maintenance operations and upgrades built right in, integrated platform monitoring—including Azure Monitor for Containers, and a support experience directly from the Azure support portal. With Azure Red Hat OpenShift, your developers can be up and running in minutes. You can scale on your terms, from ten containers to thousands, and only pay for what you need. With one-click updates for platform, services, and applications, Azure Red Hat OpenShift monitors security throughout the software supply chain to make applications more stable without reducing developer productivity. You can also leverage built-in vulnerability assessment and management tools in Azure Security Center to scan images that are pushed to, imported, or pulled from an Azure Container Registry. Discover Operators from the Kubernetes community and Red Hat partners, curated by Red Hat. You can install Operators on your clusters to provide optional add-ons and shared services to your developers, such as AI and machine learning, application runtimes, data, document stores, monitoring logging and insights, security, and messaging services. Regional availability Azure Red Hat OpenShift is available in 27 regions worldwide, and we’re continuing to expand that list. Over the past few months, we have added support for Azure Red Hat OpenShift in a number of regions, including West US, Central US, North Central US, Canada Central, Canada East, Brazil South, UK West, Norway East, France Central, Germany West Central, Central India, UAE North, Korea Central, East Asia, and Japan East. Industry compliance certifications To help you meet your compliance obligations across regulated industries and markets worldwide, Azure Red Hat OpenShift is PCI DSS, FedRAMP High, SOC 1/2/3, ISO 27001 and HITRUST certified. Azure maintains the largest compliance portfolio in the industry, both in terms of the total number of offerings and also the number of customer-facing services in assessment scope. For more details, check the Microsoft Azure Compliance Offerings, as well as the number of customer-facing services in the assessment scope. Next steps Try Azure Red Hat OpenShift now. We are excited about these new lower prices and how this helps our customers build their business on a platform that enables IT operations and developers to collaborate effectively, develop, and deploy containerized applications rapidly with strong security capabilities.

Here at Packt we've always aimed to be ahead of the curve when it comes to new formats for learning, that's why we offer a whole range of eBooks, videos, and even our Mapt subscription service so you can get the best experience no matter what type of learner you are. Sometimes you just want an old-fashioned book though; after all, who doesn't like to actually hold a physical page or have a handy print book to pass around the office when problems start springing up? So if you've bought an eBook directly from us and it wasn't a free download we’re offering an Upgrade to Print, which allows you to save 35% off the print version! No more worries about sharing your new eReader with your colleagues. All you have to do is log into your account from where you have purchased the eBook, go to the product page of that ebook where you will see a 35% discount applied to the 'Print + eBook'. You’ll save 35% off on the list price and a brand new print copy will be on its way to you! Plus when you upgrade to print we'll throw in another copy of the original eBook for you to share out to someone else – all you have to go is go back into My eBooks and just click the Share button, no hassle!

This month, the OpenWrt Community announced the release of OpenWrt 18.06.4, the fourth service release of the stable OpenWrt 18.06 series. This release comes with a number of bug fixes in the network and system and brings updates to the kernel and base packages. The official page reads, “Note that the OpenWrt 18.06.3 release was skipped in favor to 18.06.4 due to a last-minute 4.14 kernel update fixing TCP connectivity problems which were introduced with the first iteration of the Linux SACK (Selective Acknowledgement)vulnerability patches.” What is the OpenWrt project? The OpenWrt Project, a Linux operating system, targets embedded devices and is a replacement for the vendor-supplied firmware consisting of a wide range of wireless routers and non-network devices.  OpenWrt ​is an easily modifiable operating system for routers and is powered by a Linux kernel. It offers a fully writable filesystem with optional package management instead of creating a single, static firmware. It is useful for developers as OpenWrt provides a framework for building an application without having to create a complete firmware image and distribution around it. It also gives freedom of full customization to the users that allows them to use an embedded device in many ways. What’s new in OpenWrt 18.06.4? In this release, Linux kernel has been updated to versions 4.9.184/4.14.131 from 4.9.152/4.14.95 in v18.06.2. It also comes with SACK (Selective Acknowledgement) security fixes for the Linux kernel and WPA3 security fixes in hostapd. It further offers security fixes for Curl and the Linux kernel, and comes with MT76 wireless driver updates. In this release, there are many network and system service fixes. Many users seem to be happy about this news and they choose routers based on the fact if they are supported by OpenWrt or not. A user commented on HackerNews, “I choose my routers based on if they are supported or not by OpenWrt. And for everybody that asks my opinion, too. Because they might not need/want/know/have a desire to install OpenWrt now, but it's good to have the door open for the future.” Users are also happy with OpenWrt’s interface, a user commented, “For people asking about the user interface of OpenWrt. I think it is very well dun. I get a long with it just fine and I am blind and have to use a screen reader. A11y in Luci is grate. All the pages make sence to most people you do not have to be a networking expert.” To know more about this news, check out OpenWrt’s official page. OpenWrt 18.06.2 released with major bug fixes, updated Linux kernel and more! Mozilla re-launches Project Things as WebThings, an open platform for monitoring and controlling devices Linux use-after-free vulnerability found in Linux 2.6 through 4.20.11  

Transportation network giants Uber have developed Michelangelo PyML - a Python-powered platform for rapid prototyping of machine learning models. The aim of this platform is to offer machine learning as a service that democratizes machine learning and makes it possible to scale the AI models to meet business needs efficiently. Michelangelo PyML is an integration of Michelangelo - which Uber developed for large-scale machine learning in 2017. This will make it possible for their data scientists and engineers to build intelligent Python-based models that run at scale for online as well as offline tasks. Why Uber chose PyML for Michelangelo Uber developed Michelangelo in September 2017 with a clear focus of high performance and scalability. It currently enables Uber’s product teams to design, build, deploy and maintain machine learning solutions at scale and powers roughly close to 1 million predictions per second. However, that also came at the cost of flexibility. Users mainly were faced with 2 critical issues: It was possible to train the models using the algorithms that were only natively supported by Michelangelo. To run unsupported algorithms, the platform’s capability had to be extended to include additional training and deployment components. This caused a lot of inconvenience at times. The users could not use any feature transformations apart from those offered by Michelangelo’s DSL (Domain Specific Language) Apart from these constraints, Uber also observed that data scientists usually preferred Python over other programming language, given the rich suite of libraries and frameworks available in Python for effective analytics and machine learning. Also, many data scientists gathered and worked with data locally using tools such as pandas, scikit-learn and Tensorflow, as opposed to Big Data tools such as Apache Spark and Hive, while spending hours in setting them up. How PyML improves Michelangelo Based on the challenges faced in using Michelangelo, Uber decided to revamp the platform by integrating PyML to make it more flexible. PyML provides a concrete framework for data scientists to build and train machine learning models that can be deployed quickly, safely and reliably across different environments. This, without any restriction on the types of data they can use or the algorithms they can choose to build the model, makes it an ideal choice of tool to integrate with a platform like Michelangelo. By integrating Python-based models that can operate at scale with Michelangelo, Uber will now be able to handle online as well as offline queries and give smart predictions quite easily. This could be a potential masterstroke by Uber, as they try to boost their business and revenue growth after it slowed down over the last year. Read more Why did Uber created Hudi, an open source incremental processing framework on Apache Hadoop? Uber’s Head of corporate development, Cameron Poetzscher, resigns following a report on a 2017 investigation into sexual misconduct Uber’s Marmaray, an Open Source Data Ingestion and Dispersal Framework for Apache Hadoop