Tech News - Programming

Two days ago, the Qt team released the technical preview of an open source QML design viewer based on the Qt for WebAssembly. This design viewer will enable the QML application to be run on web browsers like Chrome, Safari, FireFox and Edge. The Qt for WebAssembly is a platform plugin which allows the user to build Qt applications with web page integrations.  For running a custom QML application, a user will have to define the main QML file and the import paths with a .qmlproject file. The project folder then has to be compressed as a ZIP file and uploaded to the design viewer. Users can also generate a resource file out of their project and upload the package. Image source: Qt blog Read More: Qt introduces Qt for MCUs, a graphics toolkit for creating a fluid user interface on microcontrollers The Qt team has tested the design viewer with the latest versions of Chrome, Safari, FireFox and Edge and has found that the QML application runs well on all the web browsers. “The startup and compilation time depends on your browser and configuration, but the actual performance of the application, once it is started, is indistinguishable from the same application running on the desktop,” states the official blog. This design viewer also runs on Android and iOS and is shipped with most QML modules  and is based on a snapshot of Qt 5.14. Many users have liked the web based design viewer A user on Hacker News comments, “One of the most beautiful things I have seen in 2019. Brilliant!” Another comment read, “This looks pretty cool! I am actually shopping for a GUI framework for a new project and WebAssembly support is a potential critical feature.” Qt and LG Electronics partner to make webOS as the platform of choice for embedded smart devices GitLab retracts its privacy invasion policy after backlash from community Are we entering the quantum computing era? Google’s Sycamore achieves ‘quantum supremacy’ while IBM refutes the claim

Eric Vogel follows up on his previous post on getting started with ASP.NET Core security. Now that .NET Core 3.0 is out, he shows how to upgrade the code from Part 1 to ASP.NET Core 3.0, put pages behind login, create user roles, and use existing roles to restrict access to pages.

Last week the team at Electron announced the release of Electron 7.0 in beta. It includes upgrades to Chromium 78, V8 7.8, and Node.js 12.8.1. The team has added a Window on Arm 64 release, faster IPC methods, a new nativeTheme API, and much more. This release is published to npm under the beta tag and can be installed via npm install electron@beta, or npm i electron@7.0.0-beta.7. It is packed with upgrades, fixes, and new features. Notable changes in Electron 7.0 There are stack upgrades in this release, Electron 7.0 will be compatible on Chromium 78, V8 7.8 and Node.js 12.8.1. In this release they have added Windows on Arm (64 bit). The team has added ipcRenderer.invoke() and ipcMain.handle() for asynchronous request/response-style IPC. These are strongly recommended over the remote module. They have added nativeTheme API to read and respond to changes in the OS's theme and color scheme. In this release they have switched to a new TypeScript Definitions generator, which generates more precise definitions files (d.ts) from C# model classes to build strongly typed web application where the server- and client-side models are in sync. Earlier Electron used Doc Linter and Doc Parser but it had a few issues and hence shifted to TypeScript to make definition files better without losing any information on docs. Other breaking changes The team has removed deprecated APIs in this release: Callback-based versions of functions that now use Promises. Tray.setHighlightMode() (macOS). app.enableMixedSandbox() app.getApplicationMenu(), app.setApplicationMenu(), powerMonitor.querySystemIdleState(), powerMonitor.querySystemIdleTime(), webFrame.setIsolatedWorldContentSecurityPolicy(), webFrame.setIsolatedWorldHumanReadableName(), webFrame.setIsolatedWorldSecurityOrigin() Session.clearAuthCache() no longer allows filtering the cleared cache entries. Native interfaces on macOS (menus, dialogs, etc.) now automatically match the dark mode setting on the user's machine. The team has updated the electron module to use @electron/get. Node 8 is the minimum supported node version in this release. The electron.asar file no longer exists. Any packaging scripts that depend on its existence should be updated by the developers. Additionally the team announced that Electron 4.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron. To know more about this release, check out the Electron 7.0 GitHub page and the official blog post. Electron 6.0 releases with improved Promise support, native Touch ID authentication support, and more Electron 5.0 ships with new versions of Chromium, V8, and Node.js The Electron team publicly shares the release timeline for Electron 5.0

Yesterday Elm 0.19.1 was released with a new improvements to the compiler that now display syntactical errors in a new fashion that pointing users to their mistakes as well as suggesting them additional resources.  The goal of 0.19.1 is to clean up the rough edges such that we have a really solid foundation for newcomers, professionals, scientists. Evan Czaplicki, the creator of these improved error messages explains in a blog post, “the new error messages points to the spot where it got stuck, but more importantly, it tries to help by (1) giving examples and (2) linking to a page that explains how imports work. It tries to help you learn!” For example, if you miss out on including a curly braces in your JavaScript code, the error message shows up at the very end of the file. Now with the improved Elm compiler, the error message will point out the error where it occurred while also suggesting a viable fix. Source: Elm’s blog Czaplicki hopes that this project can eliminate the survivorship bias present in the programming ecosystem, which he believes is also one of the reasons why it took so long for Elm to prioritize this project. “I hope this work on syntax error messages will help make Elm more friendly and accessible, and I hope it will help make space for other language designers to prioritize this kind of project!”, he adds. Other improvements in Elm 0.19.1 Faster compilation, especially for incremental compiles Uses filelocks so that cached files are not corrupted when plugins run elm make multiple times on the same project at the same time. More intuitive multiline declarations in REPL Various bug fixes (e.g. --debug, x /= 0, type Height = Height Float in --optimize) Developers on Twitter appreciated Elm’s focus on errors. https://twitter.com/vronnie911/status/1186377031015157762 https://twitter.com/domenkozar/status/1163795173022806016 Read more about improved error messages in Elm 0.19.1 on this blog post. What to expect from D programming language in the near future OpenBSD 6.6 comes with GCC disabled in base for ARMv7 and i386, SMP improvements and more. Swift shares diagnostic architecture improvements that will be part of the Swift 5.2 release.

Yesterday, the team behind OpenBSD, a Unix-like operating system, announced the release of OpenBSD 6.6. This release has GNU Compiler Collection (GCC) disabled in its base packages for i386 and ARMv7 and expanded LLVM Clang platform support. OpenBSD 6.6 also features various SMP improvements, improved Linux compatibility with ACPI interfaces, a number of new hardware drivers, and more. It ships with OpenSSH 8.1, LibreSSL 3.0.2, OpenSMTPD 6.6, and other updated packages. Read also: OpenSSH code gets an update to protect against side-channel attacks Key updates in OpenBSD 6.6 Unlocked system calls OpenBSD 6.6 comes with unlocked ‘getrlimit’ and ‘setrlimit’ system calls. These are used for controlling the maximum system resource consumption. There are also unlocked read and write system calls for reading input and writing output respectively. Improved hardware support OpenBSD 6.6 comes with Linux compatible ACPI interfaces. Also, the ACPI support is enabled in ‘radeon’ and ‘amdgpu’. Time Stamp Counter (TSC) is re-enabled as the default AMD64 time source and TSC synchronization is added for multiprocessor machines. This release supports the cryptographic coprocessor found on newer AMD Ryzen CPUs/APUs. IEEE 802.11 wireless stack improvements The ifconfig ‘nwflag’ is now repaired. A new stayauth ‘nwflag’ is added, which you can set to ignore deauth frames to prevent your system from a spoofing attack. Support for 802.11n Tx aggregation is added to net80211 and the ‘iwn’ driver. Starting with OpenBSD 6.6, all wireless drives submit a batch of received packets to the network stack during one interrupt, instead of submitting them individually. Security improvements The unveil command is updated to improve application behavior when encountering hidden filesystem paths. OpenBSD 6.6 has improved mitigations against a number of vulnerabilities including Spectre side-channel vulnerability in Intel CPUs and Intel's Microarchitectural Data Sampling vulnerability. This release introduces 'malloc_conceal' and 'calloc_conceal', which return the memory in pages marked ‘MAP_CONCEAL’ and call ‘freezero’ on ‘free’. Read also: Seven new Spectre and Meltdown attacks found In a discussion on Hacker News, many users expressed their excitement. A user commented, “Just keeps getting better and better every release. I wish they would add an easy encryption option in the installer. You can enable full-disk encryption, but you have to mess with the bioctl settings, which potentially scares off new users.” A few users also had some doubt that why this release has U2F support and Bluetooth disabled for security. A user explained, “I'm not sure why U2F would be "disabled for security". I guess it's just that nobody has implemented all the required things. For the USB tokens, you need userspace USB HID access and hotplug notifications. I did that in Firefox for FreeBSD.” These were some of the updates in OpenBSD 6.6. Check out the official announcement to know more. OpenBSD 6.4 released OpenSSH code gets an update to protect against side-channel attacks OpenSSH 8.0 released; addresses SCP vulnerability and new SSH additions  

Yesterday, Canonical announced the release of Ubuntu 19.10 which is the fastest Ubuntu release with significant performance improvements to accelerate developer productivity in AI/ML. This release brings enhanced edge computing capabilities with the addition of strict confinement to MicroK8s, which will safeguard the complete isolation and presents a secured production-grade Kubernetes environment. This allows MicroK8s add-ons like Istio, Knative, CoreDNS, Prometheus, and Jaeger to be deployed securely at the edge with a single command. Ubuntu 19.10 also delivers other features like NVIDIA drivers which are embedded in the ISO image to improve the performance of gamers and AI/ML users. The CEO of Canonical, Mark Shuttleworth says, “With the 19.10 release, Ubuntu continues to deliver strong support, security and superior economics to enterprises, developers and the wider community.” The Ubuntu team has notified users that Ubuntu 19.10 will be only supported for 9 months, until July 2020. Users are also advised to use Ubuntu 18.04 for Long Term Support. What’s new in Ubuntu 19.10? Updated Packages Linux kernel: The new release is based on the Linux 5.3 series and will support AMD Navi GPUs, ARM SoCs, ARM Komeda display, and Intel speed select on Xeon servers. In order to improve the boot speed, the default kernel compression algorithm is moved to lz4 on most architectures. The default initramfs compression algorithm has also changed to lz4 on all architectures. Toolchain Upgrades: It also brings new upstream releases of glibc 2.30, OpenJDK 11, Rust 1.37, GCC 9.2, updated Python 3.7.5, Python 3.8.0 (interpreter only), ruby 2.5.5, php 7.3.8, perl 5.28.1, golang 1.12.10. Read More: Ubuntu has decided to drop i386 (32-bit) architecture from Ubuntu 19.10 onwards Security Improvements Ubuntu 19.10 explores additional default hardening options that are enabled in GGC like support for both stack clash protection and control-flow integrity protection. Ubuntu Desktop GNOME 3.34 desktop: Ubuntu 19.10 includes GNOME 3.34 which includes a lot of bug fixes, some new features and a significant improvement in responsiveness and speed. It allows to group icons in the Activities overview, has improved wallpaper and wi-fi settings. ZFS on root: This feature is included as an experimental feature in this release. Users can create the ZFS file system and also partition the layout from the installer directly. Read More: Ubuntu 19.10 will now support experimental ZFS root file-system install option NVIDIA-specific improvements: The driver is now included in the ISO and has improved startup reliability when the NVIDIA driver is in use.  Ubuntu 19.10 also brings improved smoothness and frame rates for NVIDIA. Other new features in Ubuntu 19.10 A USB drive can be plugged in and accessed directly from the dock. New themes like Yaru light and dark variants are now available. Support for DLNA sharing is now available by default. Ubuntu Server Images: Ubuntu 19.10 prefers the production-ready ppc64el and arm64 live-server ISO images to install Ubuntu Server on bare metal on the two architectures. Raspberry Pi: The Raspberry Pi 32-bit and 64-bit preinstalled images (raspi3) are supported in this release. Also, Ubuntu images will now support almost all the devices of the Raspberry family Pi 2, Pi 3B, Pi 3B+, CM3, CM3+, Pi 4. Users have appreciated the new features in Ubuntu 19.10. https://twitter.com/dont39350/status/1184902506238926850 https://twitter.com/ImpWarfare/status/1184844081576456193 https://twitter.com/robinjuste/status/1183891524242857986 These are some of the selected updates in Ubuntu 19.10, read the release notes for more information. You can also check out the Ubuntu blog for more details on the release. Swift shares diagnostic architecture improvements that will be part of the Swift 5.2 release Microsoft launches Open Application Model (OAM) and Dapr to ease developments in Kubernetes and microservices What to expect from D programming language in the near future Canonical, the company behind the Ubuntu Linux distribution, was hacked; Ubuntu source code unaffected Xubuntu 19.04 releases with latest Xfce package releases, new wallpapers and more

The team behind Swift shared a new blog post yesterday detailing their new diagnostic architecture which is being implemented as a part of the upcoming Swift 5.2 release (expected early November). This new architecture aims to improve the diagnostics from the compiler. It will make it easier to improve/port existing diagnostics to be used by new feature implementors. The Swift compiler uses type checker to ensure the correctness of a program. Type checker enforces rules about how types are used in source code and show when those rules are violated. However, it guesses the exact location of an error which is not helpful in certain scenarios because it is not specific or actionable. With the new diagnostic infrastructure, the team is trying to implement a new type checker that attempts to “fix” problems right at the point where they occur while remembering the fixes it has applied. This way, type checker can pinpoint errors in more kinds of programs. New constraint fix resolves inconsistent situations The type checker converts the source code into a constraint system, which represents relationships among the types in the code. The Constraint System first generates the constraint and then solves them. The process of constraint generation produces a constraint system that relates the types of various subexpressions within an expression. The constraint solver takes a given set of constraints and determines the most specific type binding for each of the type variables in the constraint system. To improve the constraint solving mechanism, the new diagnostic infrastructure employs a constraint fix that tries to resolve inconsistent situations where the solver gets stuck with no other types to attempt. This fix captures all useful information about the error location from the solver and uses that later for diagnostics. While the former approach guesses where the error is located, the new approach has a symbiotic relationship with the solver which provides all of the error locations to it. How constraint fix works A constraint fix is created whenever a constraint failure is detected. The constraint fix captures three crucial pieces of information about a failure: kind of failure that occurred, location in the source code where the failure came from, and types and declarations involved in the failure. The constraint solver then accumulates these fixes. Once it arrives at a solution, it looks at the fixes that were part of a solution and produces actionable errors or warnings. The Swift team has shared examples of improved diagnostics and SwiftUI examples to better demonstrate the workings of this new diagnostic infrastructure. People are quite excited about these error improvements in Swift and shared their views on the associated thread in Swift Forums. “Omg better error messages! That's so awesome! Right now error messages are the worst part of swift, I'm excited. I hope it will be the end of types called _ in error messages” “Awesome work @xedin! The blog post is highly informative and I thoroughly enjoyed reading it. I very much look forward to seeing the new diagnostic architecture in action.” Developers from the Swift for TensorFlow project propose adding first-class differentiable programming to Swift Apple releases the native SwiftUI framework with declarative syntax, live editing, and support of Xcode and more. Swift is improving the UI of its generics model with the “reverse generics” system

On Tuesday, Atila Neves the Deputy leader for D programming language posted about his vision for D and what he would like to do with D lang in the near future. Make D programming language default for web dev and mobile applications D’s static reflection and code generation capabilities make it an ideal candidate to implement a codebase that needs to be called from several different languages and environments (e.g. Python, Java, R). Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it. With D, none of that is necessary. One can write the production code in D and have libraries automatically making the code callable from other languages. Hence it will be easy to write D code that runs as fast or faster than the alternatives, and it will be a win on all fronts. Memory Safety for D lang Atila believes that D is a systems programming language with value types and pointers, it isn’t memory safe. He says that DIP1000 is in the right direction, but it still needs to be memory safe unless programmers opt-out via @trusted block or function. The DIP1000 proposal includes a scope mechanism that will know when the lifetime of a reference is over by providing a mechanism to guarantee that a reference cannot escape lexical scope. Thus it can safely implement memory management schemes rather than tracing the garbage collection. Safe and easy concurrency in D programming language As per Atila safe and easy concurrency in D is mostly achieved through actor models, but they still need to finalize shards and make everything @safe as well. Centralizing all reflection needs with an API Atila says instead of disparate ways of getting things done with fragmented APIs like (__traits, std.traits, custom code), he would like there to be a library that centralizes all reflection needs with a great API. Easy interoperability for C++ developers C++ has been successful so far in making the transition from C virtually seamless. Atila wants current C++ programmers with legacy codebases to just as easily be able to start writing D code. Faster development times D needs a fast interpreter so that developers can skip machine code generation and linking. This should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. String interpolation in D programming language Code generation is one of D’s greatest strengths, and token strings enable visually pleasing blocks of code that are actually “just strings”. Hence, String interpolation would make it vastly easier to use. To know more about D programming language, check out the official post by Atila Neves. “Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett The V programming language is now open source – is it too good to be true? Rust’s original creator, Graydon Hoare on the current state of system programming and safety

Two days ago, Immo Landwerth, a program manager on the .NET team announced that the community is concluding the .NET Framework API Porting project. They also plan to release more of the .NET Framework codebase under the MIT license on GitHub to allow the community to create OSS projects for technologies that will not be brought to .NET Core. For example, there already are community projects for CoreWF and CoreWCF. https://twitter.com/shanselman/status/1184214679779864576 In May, this year, Microsoft announced that the future of .NET will be based on .NET Core. At Build 2019, Scott Hunter stated that AppDomains, remoting, Web Forms, WCF server, and Windows Workflow won’t be ported to .NET Core. “With .NET Core 3.0, we’re at the point where we’ve ported all technologies that are required for modern workloads, be it desktop apps, mobile apps, console apps, web sites, or cloud services,” Landwerth writes. .NET Core 3.0 released last month includes added WPF and WinForms, which increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs. Also, about 62K APIs to .NET Core that doesn’t exist in the .NET Framework. On comparing the total number of APIs, .NET Core has about 80% of the API surface of .NET Framework. “Since we generally no longer plan to bring existing technologies from .NET Framework to .NET Core we’ll be closing all issues that are labeled with port-to-core,” Landwerth further mentions. Post this announcement on GitHub, a lot of GitHub users enquired more about this change in the .NET community. A user asked, “Is CSharpCodeProvider ever going to happen in Core? The CodeDom API arrived somewhere in the 2.x timeframe, but it's a runtime fail even under 3.0 - are we going to need to re-write for some kind of explicitly Roslyn scripting?” To this, Landwerth replied, “CSharpCodeProvider is supported on .NET Core, but only the portions that deal with CodeDOM creation. You can't compile because this would require a compiler and the .NET Core runtime doesn't include a compiler (i.e. Roslyn). However, we might be able to do some gymnastics, like reflection, where the app can pull that in. Still tracked under #12180.” https://twitter.com/terrajobst/status/1183832593197744129 To know more about this announcement in detail, read the official GitHub post. .NET 5 arriving in 2020! Docker announces collaboration with Microsoft’s .NET at DockerCon 2019 .NET Core 3.0 is now available with C# 8, F# 4.7, ASP.NET Core 3.0 and EF 6.3

On Monday, Neil Williams a software developer from Linux CodeHelp raised severity issues for Python 2 leaf packages in Debian which do not support Python 3. Neil has urged Debian maintainers to remove Python 2 from all the Debian packages. He specifically mentions one of the packages, Calibre, an e-book management software which is completely open source and licensed under the GNU GPL v3. Calibre is written primarily in Python with some C/C++ code for speed and system interfacing. But it is not yet compatible with Python 3 as it requires at least Python 2.7.9. In 2017, an issue was raised on the Calibre platform by a user, “Python 2 is retiring in thirty months. Calibre needs to convert to Python 3.” Kovid Goyal, author of the Calibre platform responded saying, “No, it doesn't. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.” Now the latest Calibre version requires Python modules which are no longer available for Python 2. Gregor Riepl, a systems engineer in response to Neil says, “As of now, calibre is not of sufficient quality to be part of a Debian release and until it drops all Python2 requirements, it must be considered RC buggy.” This means that Calibre >= 4.0 for the foreseeable future will not be available in Debian. Calibre version 3.48 will be the last version that can run on Debian until the upstream Calibre switches to Python 3. Riepl further asked Neil if his quality argument is due to the Calibre authors resistance to migrate to Python 3. Neil responded, “No, it is based just on the removal of Python2 from Debian and avoiding special cases. Right now, any and every package in Debian testing which requires Python2 and has no Python3 alternative in Debian or ready for upload is of poor quality for no other reason than that. All such packages are of such poor quality that the package should be removed from testing - in an orderly manner, leaf packages first. That is in the best interests of all users, despite what may or may not happen to any particular subset(s) of users.  The decision flow is easy - if the answer in each case is "no", then move on to the next and if you get to the bottom, the bug should be RC. * Has the package already been removed from testing? * Is a Python3-only version already in Debian? * Is a Python3-only version available upstream? * Does the package have any reverse dependencies? * If you get here, it is already too late, there have already been   enough warnings. Upgrade the bug to RC and get the package   auto-removed from testing.” Neil said he was aware of the history of Calibre and understood what would happen if it is no longer a part of Debian. But that did not matter as removal of Python 2 is more important for the next Debian release. He also believes that Calibre has a relatively large user base that doesn't know much or care about the Python 2 deprecation. User will simply perceive dropping Calibre as a bad move on Debian's side and rush towards other packages of significantly lower quality. He further concluded, “Calibre is nothing special - it's a Python2 leaf package like vland and tftpy and any one of far too many others. Calibre can stay in unstable - it will go FTBFS, of course, but that isn't a problem either, IMHO. It's calibre's problem - not Debian's problem. There's always the option of users installing the old Python2 stuff from Buster to keep calibre hobbling along. Debian is the higher priority here. Calibre would be nice to have but it does not deserve to cause delays on anybody else's voluntary effort. No package has that right.” Community feels Python 2 will result in unmaintained runtime and libraries in packages On Hacker News, users are discussing how Python foundation is pushing in packages to migrate to Python 3 that will result in Python 2 having an entire set of unmaintained runtime and libraries in the package repository. One user comments, “Historically, Debian hasn't particularly objected to packaging obsolete versions of programming languages without upstream support. I doubt anyone is checking for potential security problems in Algol 68 and Fortran 77 implementations that Debian ships, and I don't think the people using those packages are particularly inconvenienced by that. It seems a shame that the social pressure to persuade people to port their code to Python 3 means that Debian is going to have weaker support for 10-year-old Python than 40-year-old Fortran. In particular, there are ongoing efforts to try to make it the normal thing for scientists to make the programs they ran on their data available so that their results can be reproduced; aggressively dropping older programming language implementations rather gets in the way of that.” Another user responded, “This isn't about "languages". It's about software! Algol 68 and Fortran 77 may have stale (but maintained) compilers or interpreters in the package repository. Starting very soon - Python 2 will have an entire set of unmaintained runtime and libraries in the package repository. You know - actual, officially, unmaintained software! Unmaintained software that other packages, including Calibre in this example, further build on. Of course they're throwing this out.” Python 3.8 is now available with walrus operator, positional-only parameters support for Vectorcall, and more Core Python team confirms sunsetting Python 2 on January 1, 2020 PyPy will continue to support Python 2.7, even as major Python projects migrate to Python 3

Yesterday, AWS announced that it is sponsoring the popular Rust programming language. Rust has seen a lot of developments in AWS as it is used for various performance-sensitive components in its popular services such as Lambda, EC2, and S3. Tech giants such as Google, Microsoft, and Mozilla also use Rust for writing and maintaining fast, reliable, and efficient code. Alex Crichton, Rust Core Team Member says, “We’re thrilled that AWS, which the Rust project has used for years, is helping to sponsor Rust’s infrastructure. This sponsorship enables Rust to sustainably host infrastructure on AWS to ship compiler artifacts, provide crates.io crate downloads, and house automation required to glue all our processes together. These services span a myriad of AWS offerings from CloudFront to EC2 to S3. Diversifying the sponsorship of the Rust project is also critical to its long-term success, and we’re excited that AWS is directly aiding this goal.” Why AWS chose Rust Rust project maintainers say the reason AWS chose Rust is due to its blazingly fast and memory-efficient performance; its rich type system and ownership model guarantee memory-safety and thread-safety; its great documentation, its friendly compiler with useful error messages, and top-notch tooling; and many other amazing features. Rust has also been voted as the “Most Loved Language” in Stack Overflow’s survey for the past four years. Rust also has an inclusive community along with top-notch libraries such as: Serde, for serializing and deserializing data. Rayon, for writing parallel & data race-free code. Tokio/async-std, for writing non-blocking, low-latency network services. tracing, for instrumenting Rust programs to collect structured, event-based diagnostic information. Rust too uses AWS services Rust project uses AWS services to: Store release artifacts such as compilers, libraries, tools, and source code on S3. Run ecosystem-wide regression tests with Crater on EC2. Operate docs.rs, a website that hosts documentation for all packages published to the central crates.io package registry. The AWS community is excited to include Rust in their community. It would be interesting to see the combination of Rust and AWS in their future implementations. Few users are confused about the nature of this sponsorship. A Redditor commented, “It's not clear exactly what this means - is it about how AWS provides S3/EC2 services for free to the Rust project already (which IIRC has been ongoing for some time), or is it an announcement of something new ($$$ or developer time being contributed?)?” To know about this announcement in detail, read AWS’ official blog post. Amazon announces improved VPC networking for AWS Lambda functions Reddit experienced an outage due to an issue in its hosting provider, AWS Rust 1.38 releases with pipelined compilation for better parallelism while building a multi-crate project Mozilla introduces Neqo, Rust implementation for QUIC, new http protocol

The Bazel team announced the release of Bazel 1.0, last week. The team calls this version a “stability milestone” as it tries to address the stability concerns associated with Bazel by switching to semantic versioning. Along with this change, Bazel 1.0 features new genrule support, C++ and Java-related improvements, gRPC connections with default TLS enabled, and more. Bazel is the open-source version of the Blaze tool that Google uses internally. It is a polyglot build system that enables you to automate software building and testing. It provides features like reproducibility via sandboxing, distributed caching, static analysis of build dependencies, uniform CLI for builds and tests, and more. Key updates in Bazel 1.0 Windows A genrule generates one or more files based on a user-defined Bash command. Starting with Bazel 1.0, genrule supports cmd_bash, cmd_ps, and cmd_bat attributes for better integration on Windows. You can now get a new generated DEF file from the def_file output group of cc_library. Execution Previously, tags were not being propagated from a Bazel’s target to the action’s execution requirements. In Bazel 1.0, this is possible with the help of the --experimental_allow_tags_propagation flag. A rule consists of a series of actions that Bazel performs on inputs to produce a set of outputs. Now all rules have a default exec_properties attribute just like the one on a platform rule. Starting with Bazel 1.0, all gRPC connections from Bazel will have TLS enabled by default. You can disable TLS by going to the grpc:// scheme in your URIs. Configurability The config_setting general rule matches an expected configuration state for the purpose of triggering configurable attributes. With Bazel 1.0 release, it can now check multiple values on "--foo=firstVal --foo=secondVal ..."-style flags. This release comes with --enable_platform_specific_config that enable flags in bazelrc according to your host platform. C++ The cc_* rules now support non-transitive defines via a local_defines attribute. This attribute returns the set of defines needed to compile a particular target. Bazel 1.0 comes with support for ThinLTO builds, the new link-time optimization (LTO) compilation type, on Linux for Clang versions 6.0 or above. You can enable ThinLTO via --features=thin_lto. Java The Java-Starlark API, java_common.create_provider is now removed. Also, the JavaInfo() legacy arguments including actions, sources, source_jars, use_ijar, java_toolchain, and host_javabase are removed. Starting with Bazel 1.0, maven_jar and maven_server do not permit the use of plain HTTP URLs without a specified checksum. If you are using maven_jar it recommends switching to rules_jvm_external for transitive dependency management. The team has also advised that developers check the compatibility of their codebase by running bazelisk --migrate or by building their code with Bazel 0.29.1 and a list of flags before they upgrade to Bazel 1.0. These were some of the updates in Bazel 1.0. Check out the official announcement to know what else has shipped in this release. Rust 1.38 releases with pipelined compilation for better parallelism while building a multi-crate project Pivotal open sources kpack, a Kubernetes-native image build service Mozilla releases WebThings Gateway 0.9 experimental builds targeting Turris Omnia and Raspberry Pi 4 Introducing Weld, a runtime written in Rust and LLVM for cross-library optimizations LLVM 9 releases with official RISC-V target support, asm goto, Clang 9, and more

On Friday, Libc++ version 9 was released; libc++ is an implementation of the C++ standard library, targeting C++11, C++14 and above. Libc++ 9 is a part of the LLVM Compiler Infrastructure, release 9.0.0 which was made available in September. Libc++ 9 adds explicit support for WebAssembly System Interface (WASI) along with major improvements from the previous release and new feature work. Libc++ has also dropped support for GCC 4.9; they now support GCC 5.1 and above. WASI is a system interface for the WebAssembly platform. Currently, it supports sandboxed access to the filesystem via a POSIX-like API, as well as other basic interfaces like argv, environment variables, random numbers, and timers. There are three popular implementations of WASI: wasmtime, Mozilla’s WebAssembly runtime, Lucet, Fastly’s WebAssembly runtime, and a browser polyfill. Improvements in Libc ++ 9 Minor fixes to std::chrono operators. libc++ now correctly handles Objective-C++ ARC qualifiers in std::is_pointer. Front and back methods are added to std::span std::to_chars now adds leading zeros. Ensure std::tuple is trivially constructible. std::aligned_union now works in C++03. Output of nullptr to std::basic_ostream is formatted properly. P0608 is now implemented as a sane variant converting constructor. std::is_unbounded_array and std::is_bounded_array added to type traits. std::atomic now includes many new features and specialization Added std::midpoint and std::lerp math functions and std::is_constant_evaluated function Erase-like algorithms now return size type. Added contains method to container types. std::swap is now a constant expression. std::move and std::forward now both work in C++03 mode. People on Twitter were quite happy with WASI support in libc ++ https://twitter.com/Stephen_d2005/status/1178489876070535168 https://twitter.com/iwillrunoutofsp/status/1182702301062008832 You can also see the release notes for additional information. Introducing Weld, a runtime written in Rust and LLVM for cross-library optimizations LLVM 9 releases with official RISC-V target support, asm goto, Clang 9, and more LLVM’s Clang 9.0 to ship with experimental support for OpenCL C++17, asm goto initial support and more. LLVMs Arm stack protection feature turns ineffective when the stack is re-allocated

Yesterday, Apple released MacOS Catalina, its latest update for Macs and MacBooks. The new operating system can be installed from the homepage of its App Store. Catalina brings a host of new features, including the option to use apps from the iPad as well as turn the tablet into an additional display for computers. But this new update kills iTunes and faces some major issues. Apple has confirmed that there are some serious issues in MacOS Catalina, and affected consumers should refrain from updating the OS until these issues are addressed. Catalina is finally the download that kills iTunes, which is nowhere to be found in the new update. Instead, Apple has moved the features of iTunes into their own separate Music app, the new update also includes separate apps for Podcasts and TV. MacOS Catalina update is a big problem for DJs who rely on iTunes The Mac platform is especially popular with DJs, who cart around MacBook Pro machines jam-packed with music, playlists, mixes and specialist software to allow them to perform every evening. These have been tied to iTunes’ underlying XML database. But after nearly 2 decades, iTunes are discontinued in macOS Catalina, and the XML file no longer exists to index a local music collection. This has broken popular and niche music tools alike, including some of the major titles such as Traktor and Rekordbox. The Verge reports that Apple has confirmed that this issue is down to its removal of the XML file, but is handing responsibility to the third-party developers behind each app. Unfortunately, for Apple’s reputation, those developers have been expecting the ability for the new standalone Music app to explore an XML file, a feature Apple suggested would be available until they could code around the lack of XML. Fact Mag also reported, “this news contradicts Apple’s earlier assertion that there would be a way to manually export the XML file from the new Music app, though Catalina’s launch yesterday now proves this isn’t the case at all.” Apple advice DJs that, if you rely on a software that needs this XML file to function, then do not update to Catalina until individual developers have issued compatibility updates for the new operating system. Catalina drops support for 32-bit applications and faces other issues as well Catalina also drops support for 32-bit applications. The 32-bit applications will simply not run under the new system, this version of macOS is a 64-bit only. If you are a Mac user that is reliant on a 32-bit app, then you have just a single dialog on installation that warns of the loss of support. And with these there are other questions which a user will need answers to like, you would need to know which of your apps are 32-bit and which are 64-bit? And if they are mission-critical in your role and is a 64-bit alternative available? It's not just this, a number of creative tools, including Apple Aperture, Microsoft Office 2011 and Adobe CS6 are also experiencing issues with Catalina. Additionally, there are issues with font in MacOS Catalina, as per the Chromium blog, the macOS system font appears "off" -- too light / tight kerning. It is clear that Apple wants to push forward with its platforms, but it needs to remember that the hardware has to work in the real world today. Apple should be consistent in what features it offers, it should provide clear and accurate information to developers and users, and it should ensure the very least that its own store is in order. TextMate 2.0, the text editor for macOS releases MacOS terminal emulator, iTerm2 3.3.0 is here with new Python scripting API, a scriptable status bar, Minimal theme, and more Apple previews macOS Catalina 10.15 beta, featuring Apple music, TV apps, security, zsh shell, driverKit, and much more! WWDC 2019 highlights: Apple introduces SwiftUI, new privacy-focused sign in, updates to iOS, macOS, and iPad and more Apple plans to make notarization a default requirement in all future macOS updates

Yesterday, reports from 9to5 Google says that as per the updated Google Mobile Services (GMS) agreement. Per the new terms, OEMs who utilize their own gesture navigation systems cannot have those available in the device's initial setup if it ships with Android 10. Google has struggled to devise a new navigation system for Android over the last few releases. The two-button design from Pie is not liked much in the market, and the new full-gesture setup in Android 10 also has its critics. However, with the new agreement, you will see a lot of Google's gestures in the upcoming new Android 10 devices. At this year’s Google I/O 2019, the company announced that it would support the new gestures and the three-button navbar going forward. It didn't rule out OEMs having their own custom gesture navigation and will indeed let them keep those, but there will be some restrictions. Notably, devices shipping with Android 10 will need to have either classic three-button nav or Google's gesture navigation enabled out of the box. This makes it sound like the two-button "pill" setup will be effectively dead. Android 10 devices will not offer custom navigation in the initial setup Phones often let users choose their navigation options during setup, but Android 10 will not offer custom gesture navigation as an option in the setup wizard at all. So, you'll probably be able to turn on Google's gestures, but something like Samsung's swipe-up targets (see below image) will only be available if you dig into the settings. Source: 9to5 Google Hence, the updated Google Mobile Services agreement puts into perspective what Google really wants for Android users. Manufacturers can still include their own navigation solutions, but those solutions aren’t to be immediately available to the users during the setup wizard. Users must go into the device settings to toggle alternative navigation systems after the initial setup. Not only are OEM-specific navigation systems not allowed during setup, but manufacturers can’t even prompt users to use them in any way. No notifications. No pop-ups or any other way. Also, Google also requires OEMs to hide their custom navigation systems deeper into the settings. Manufacturers can put these settings under new sections like “advanced” or something similar, not easily accessible to the user. This isn’t necessarily a bad call by Google. More uniformity throughout the Android ecosystem can only be a good thing. The gestures will mature quicker, apps will be forced to adhere to the new navigation systems, and users will get used to it more easily. Google Mobile Services requires new Android devices compatible with Type-C ports The new Google Mobile Services agreement also outlines the technical requirements that smartphone device makers must meet in order to preload Google Mobile Services. Nearly every Android smartphone or tablet sold internationally have met these requirements because having access to Google apps is critical for sales outside of China. A subsection 13.6 of this document is titled “USB Type-C Compatibility” which states: “New DEVICES launching from 2019 onwards, with a USB Type-C port MUST ensure full interoperability with chargers that are compliant with the USB specifications and have the USB Type-C plug.” On Reddit, this news has got significant traction and Android users are discussing that this move by Google is good only if the gesture usage works well. Here are some of the comments, “Im sure people will hate this, but im for easier usage for the general public.” Another user responds, “Sure. As long as the gesture usage works really, really well. If it doesn't, this is a bad move.” Google Project Zero discloses a zero-day Android exploit in Pixel, Huawei, Xiaomi and Samsung devices Google’s DNS over HTTPS encryption plan faces scrutiny from ISPs and the Congress Google Chrome Keystone update can render your Mac system unbootable Google’s V8 JavaScript engine adds support for top-level await Google announces two new attribute links, Sponsored and UGC and updates “nofollow”