Tech News - Programming

Last Sunday, the team behind Neovim, a project that refactors Vim source code released NVIM v0.4.0. This release received approximately 2700 commits since v0.3.4, which was a non-maintenance release. It comes with improvements to documentation, test/CI infrastructure, internal subsystems and 700+ patches that are merged from Vim. What’s new in NVIM v0.4.0? API functions This release comes with a new function, nvim_create_buf that is used for creating various types of buffers including nvim_get_context and nvim_load_context. The nvim_input_mouse function is used for performing mouse actions. Users can create floating windows with nvim_open_win. UI events The new UI events including redraw.grid_destroy, redraw.hl_group_set, redraw.msg_clear, and much more are included. Lua library NVIM v0.4.0 introduces "Nvim-Lua standard library" that comes with string functions and generates documentation from docstrings. Multigrid windows It now features windows that are isolated internally and can be drawn on separate grids. These windows are sent as distinct objects to UIs so that UIs can control the layout.   Support for sign columns It comes with support for multiple auto-adjusted sign columns, so users will  be shown extra columns to automatically accommodate all the existing signs. Major changes It has improved Lua error messages and fixed menu_get(). In NVIM v0.4.0, jemalloc, general purpose malloc implementation has been removed. In this release, the 'scrollback' option is more consistent and future-proof.  To know more about this news, check out the release notes. Other interesting news in programming A recap of the Linux Plumbers Conference 2019 GNU community announces ‘Parallel GCC’ for parallelism in real-world compilers TextMate 2.0, the text editor for macOS releases  

Yesterday, the RISC-V Foundation announced that the RISC-V base Instruction Set Architecture (ISA) and privileged architecture specifications have been ratified.  The RISC-V Foundation drives the adoption and implementation of the free and open RISC-V ISA. The RISC-V base architecture acts as the interface between application software and hardware.  Krste Asanović, chairman of the RISC-V Foundation Board of Directors says, “The RISC-V ecosystem has already demonstrated a large degree of interoperability among various implementations. Now that the base architecture has been ratified, developers can be assured that their software written for RISC-V will run on all similar RISC-V cores forever.” The RISC-V privileged architecture covers all aspects of RISC-V systems including privileged instructions, additional functionality required for running operating systems and attaching external devices. Privilege levels are used to provide protection between different components of the software stack, such that it has a core set of privileged ISA extensions. The ISA extensions have optional extensions and variants, including the machine ISA, supervisor ISA and hypervisor ISA. “The RISC-V privileged architecture serves as a contract between RISC-V hardware and software such as Linux and FreeBSD. Ratifying these standards is a milestone for RISC-V,” said Andrew Waterman, chair of the RISC-V Privileged Architecture Task Group.  To know more about this announcement in detail, head over to RISC-V blog. Debian GNU/Linux port for RISC-V 64-bits: Why it matters and roadmap AdaCore joins the RISC-V Foundation, adds support for C and Ada compilation Western Digital RISC-V SweRV Core is now on GitHub

Since the past couple of years, Microsoft has been supporting open source projects, it even joined the Open Invention Network. Last year, Microsoft had announced the general availability of its Windows 3.0 File Manager code. Yesterday, the team at Microsoft made an announcement regarding releasing its Windows Calculator program as an open source project on GitHub under the MIT License. Microsoft is making the source code, build system, unit tests, and product roadmap available to the community. It would be interesting for the developers to explore how different parts of the Calculator app work and further getting to know the Calculator logic. Microsoft is also encouraging developers to participate in their projects by bringing in new perspectives on the Calculator code. The company highlighted that developers can contribute by participating in discussions, fixing or reporting issues, prototyping new features and by addressing design flows. By reviewing the Calculator code, developers can explore the latest Microsoft technologies like XAML, Universal Windows Platform, and Azure Pipelines. They can also learn about Microsoft’s full development lifecycle and can even reuse the code to build their own projects. Microsoft will be also contributing custom controls and API extensions used in Calculator and projects like the Windows UI Library and Windows Community Toolkit. The official announcement reads, “Our goal is to build an even better user experience in partnership with the community.” With the recent updates from Microsoft, it seems that the company is becoming more and more developer friendly. Just two days ago, the company updated its App Developer Agreement. As per the new policy, the developers will now get up to 95% share. According to a few users, Microsoft might collect user information via this new project and even the section below telemetry (on the GitHub post) states the same. The post reads, "This project collects usage data and sends it to Microsoft to help improve our products and services. Read our privacy statement to learn more. Telemetry is disabled in development builds by default, and can be enabled with the SEND_TELEMETRY build flag." One of the users commented on HackerNews, “Well it must include your IP address too, and they know the time and date it was received. And then it gets bundled with the rest of the data they collected. I don't even want them knowing when I'm using my computer. What gets measured gets managed.” Few users have different perspectives regarding this. Another comment reads, “Separately, I question whether anyone looking at the telemetry on the backend. In my experience, developers add this stuff because they think it will be useful, then it never or rarely gets looked at. A telemetry event here, a telemetry event there, pretty soon you're talking real bandwidth.” Check out Microsoft’s blog post for more details on this news. Microsoft @MWC (Mobile World Congress) Day 1: HoloLens 2, Azure-powered Kinect camera and more! Microsoft workers protest the lethal use of Hololens2 in the $480m deal with US military Microsoft adds new features to Microsoft Office 365: Microsoft threat experts, priority notifications, Desktop App Assure, and more

Yesterday, Linus Torvalds, the principal developer of the Linux kernel announced the release of Linux 5.1 in a mailing list announcement. This release provides users with an open source operating system with lots of great additions, as well as improvements to existing features. The previous version, Linux 5.0 was released two months ago. “On the whole, 5.1 looks very normal with just over 13k commits (plus another 1k+ if you count merges). Which is pretty much our normal size these days. No way to boil that down to a sane shortlog, with work all over.”, said Linus Torvalds in the official announcement. What’s new in Linux 5.1? Io_uring: New Linux IO interface Linux 5.1 introduces a new high-performance interface called io_uring. It’s easy to use and hard to misuse user/application interface. Io_uring has an efficient buffered asynchronous I/O support, the ability to do I/O without even performing a system call via polled I/O, and other efficiency enhancements. This will help deliver fast and efficient I/O for Linux. Io_uring permits safe signal delivery in the presence of PID reuse which will improve power management without affecting power consumption. Liburing is used as the user-space library which will make the usage simpler. Axboe's FIO benchmark has also been adapted already to support io_uring. Security In Linux 5.1, the SafeSetID LSM module has been added which will provide administrators with security and policy controls. It will restrict UID/GID transitions from a given UID/GID to only those approved by system-wide acceptable lists. This will also help in stopping to receive the auxiliary privileges associated with CAP_SET{U/G}ID, which will allow the user to set up user namespace UID mappings. Storage Along with physical RAM, users can now use persistent memory as RAM (system memory), allowing them to boot the system to a device-mapper device without using initramfs, as well as support for cumulative patches for the live kernel patching feature. This persistent memory can also be used as a cost-effective RAM replacement. Live patching improvements With Linux 5.1 a new capability is being added to live patching, it’s called Atomic Replace. It includes all wanted changes from all older live patches and can completely replace them in one transition. Live patching enables a running system to be patched without the need for a full system reboot. This will allow new drivers compatible with new hardware. Users are quite happy with this update. A user on Reddit commented, “Finally! I think this one fixes problems with Elantech's touchpads spamming the dmesg log. Can't wait to install it!” Another user added, “Thank you and congratulations for the developers!” To download the Linux kernel 5.1 sources, head over to kernel.org. To know more about the release, check out the official mailing announcement. Ubuntu 19.04 Disco Dingo Beta releases with support for Linux 5.0 and GNOME 3.32 Announcing Linux 5.0! Bodhi Linux 5.0.0 released with updated Ubuntu core 18.04 and a modern look  

Yesterday, the Rust team shared that a Cargo vulnerability confuses the older versions of Cargo making them ignore the new package rename feature and download a wrong dependency. This vulnerability, tracked as CVE-2019-16760, affects Rust 1.0 through Rust 1.25. The vulnerability was first reported to the Rust team by Elichai Turkel: https://twitter.com/Elichai2/status/1178681807170101248 Details of Cargo vulnerability Rust 1.31 introduced the package configuration key for renaming dependencies in the ‘Cargo.toml’ manifest file. In Rust 1.25 and prior, Cargo ignores its usage to rename dependencies and may end up downloading a wrong dependency. It affects not only manifests that are written locally, but also those that are published to crates.io. “If you published a crate, for example, that depends on `serde1` to crates.io then users who depend on you may also be vulnerable if they use Rust 1.25.0 and prior. Rust 1.0.0 through Rust 1.25.0 is affected by this advisory because Cargo will ignore the `package` key in manifests,” the team wrote. This vulnerability does not affect Rust 1.26 through Rust 1.30 versions and will throw an error as the package key is unstable in these versions. Rust 1.31 and later are not affected because Cargo understands the package key. Mitigation steps to prevent this Cargo vulnerability The team has already audited the existing crates using the package key published to crates.io and have not detected any exploit of this vulnerability. However, they have recommended users of the affected versions to update their compiler to either 1.26 or later. The team further wrote, “We will not be issuing a patch release for Rust versions prior to 1.26.0. Users of Rust 1.19.0 to Rust 1.25.0 can instead apply the provided patches to mitigate the issue.” This news sparked a discussion on Reddit where developers discussed how this could have been avoided. A user commented, “What do we learn from this? Always throw an error if you encounter an unknown key inside a known configuration object.” Another user suggested, “It would be better to have the config contain a "minimum allowed cargo version", and if you want to use new features you have to bump this version number to at least the version which added the feature. Old versions of cargo can detect the version number and automatically refuse to compile the crate if the minimum version is newer than the cargo version.” Read the official announcement by the Rust team to know more about this vulnerability in detail. 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 Introducing Weld, a runtime written in Rust and LLVM for cross-library optimizations  

The team behind Xubuntu, have released a new update for the lightweight, GTK-based desktop environment built around Ubuntu. Xubuntu 19.04 is available since yesterday as a part of the Ubuntu 19.04 "Disco Dingo" launch. New features include latest Xfce package releases, new wallpapers/artwork, re-addition of GIMP to ISO, and various other changes. Xubuntu 19.04 also halts the production of x86 32-bit install images. New additions in Xubuntu 19.04 AptURL is now included in the latest release. It provides an easy way to link to and install packages from the repositories. It supports most browsers and works without any additional configuration when installed. GIMP (GNU Image Manipulating Program), a feature-packed image editor also ships with this release. It was notably absent from Xubuntu since 15.04 “Vivid Vervet”. The addition of LibreOffice Impress completes the Xubuntu office suite. Impress makes it possible for users to quickly and easily produce and present high-quality presentations. It comes with a number of great templates already installed, and hundreds more at the LibreOffice Extensions website. Updates to existing Xfce settings Xfce Application Finder The application Finder is ported to GTK 3 and searches are now fuzzy Menu items without a name are no longer displayed Applications can now be launched by pressing Enter once The Application Finder will no longer crash when toggling bookmarks A new preference was added to hide the category panel and it has improved application sorting and keyboard navigation Xfce Desktop Orientation option is added for icon arrangement Support for the RandR primary monitor is added Integration for the AccountsService wallpaper is added The crash with monitor changes is fixed. Also the icon size in the “Open With” submenu is fixed. Xfce Dictionary Crashes related to invalid URLs were resolved Web search links are only displayed when URLs are valid The link tooltip is now escaped, fixing display issues Xfce Panel Maximum icon size can be specified for improved control. Per-panel icon size preferences are added Numerous improvements are made to plugin display and sizing issues Support for alternative menu editors, with MenuLibre as default is added Fixed issues with clicking panel items at the top or left of the screen Fixed space reservation on the bottom and right of the screen Fixed crashes in the Directory Menu plugin and when removing certain plugins Fixed alignment of various plugin menus and the display of the binary clock Xfce Screenshooter Added width and height to the region select overlay Fixed delay functionality in the panel plugin and saving screenshots from the panel plugin Improved Imgur upload results dialog Improved support when XInput is not available and for HiDPI displays Xfce Session Replaced packaging recommendation on Xscreensaver with Light Locker Added support for MATE Screensaver and Xfce Screensaver Xfce System Load Plugin Reworked preferences dialog The default update interval was updated to 0.5 seconds Xfce Task Manager Builds now default to GTK 3, with GTK 2 being removed in the next release Improved UTF-8 normalization Fixed crash when closing processes Xubuntu Artwork New desktop wallpaper for 19.04 New release-agnostic wallpaper for Plymouth These are just a select few updates. For a more exhaustive version, head over to the blog post by Bluesabre. If you want to contribute, check out the Xubuntu contributor documentation to learn how to get started. Ubuntu 19.04 Disco Dingo Beta releases with support for Linux 5.0 and GNOME 3.32 Chromium blacklists nouveau graphics device driver for Linux and Ubuntu users Ubuntu 18.10 ‘Cosmic Cuttlefish’ releases with focus on AI development, multi-cloud and edge deployments, and much more

Prior to news of Linus Torvalds self-imposed leave from the project, Linux leaders - including Torvalds - revised its Code of Conflict, moving instead to a Code of Conduct. A new Linux Code of Conduct was submitted by Greg Kroah-Hartman on Saturday 15 September. Kroah-Hartman wrote that "the Code of Conflict is not achieving its implicit goal of fostering civility and the spirit of 'be excellent to each other.'" Read the new Linux Code of Conduct here. The change was committed yesterday (16 September) by Torvalds. Other leading figures in the Linux project also put their names behind the move, including Olof Johansson and Steve Rostedt. It's not immediately clear to what extent the new Code of Conduct has something to do with Torvalds' hiatus, but it's impossible to avoid making a connection between the two. What's new in the Linux Code of Conduct? Linux's Code of Conflict has always felt combative. The naming makes clear that disagreement is part and parcel of open source development. It was always clear that "critique and criticism" were simply a part of what it means to be in the Linux community. "The Linux kernel development effort is a very personal process compared to "traditional" ways of developing software. Your code and ideas behind it will be carefully reviewed, often resulting in critique and criticism. The review will almost always require improvements to the code before it can be included in the kernel. Know that this happens because everyone involved wants to see the best possible solution for the overall success of Linux." By switching to a Code of Conduct, Linux is immediately placing emphasis on how contributors and maintainers work together to cultivate an open and safe community that people want to be involved in. Contrast this with the section from the Code of Conflict above: "In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation." The Code of Conduct then goes on to outline specific examples of what is and isn't acceptable. "Using welcoming and accepting language" and "showing empathy to other community members" are just two examples of how the code suggests community members can help to create a positive working environment. The new Code of Conduct then goes on to detail the responsibilities of Linux maintainers. They are presented as custodians or stewards for Linux. They are responsible for "clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior." The reaction to the new Linux Code of Conduct Reaction to the news - coupled with Linus Torvalds apology today - has caused considerable reaction on Twitter and across the open source community. For some, this is an example of politics entering into open source code - with some suggesting that it could be detrimental to the Linux project overall. Of course, the link between a more positive, inclusive and respectful community environment to a weaker project does seem strange to say the least. Taken alongside news last week that Python is dumping 'master' and 'slave' in its documentation, it would seem that we're starting to see open source projects take inclusivity and accessibility seriously. Some in the community might see that as a threat to them - but, if we really do think 'be excellent to each other' is the philosophy we should live by, shouldn't we do everything to make sure we're always held to that standard?

Earlier this month, the Hacker News community got into a heated debate on whether “Go is Google’s language, and not the community’s”. The thread was first started by Chris Siebenmann who works at the Department of Computer Science, University of Toronto. His blog post reads, “Go has community contributions but it is not a community project. It is Google’s project.” In response to his statements, last Thursday, Ian Lance Taylor, a googler and member of the Golang team added his own views on a Google group mailing list, that don't necessarily contradict Chris’s blog post but add some nuance. Ian begins with a disclaimer: “I'm speaking exclusively for myself here, not for Google nor for the Go team.” He then reminds us that Go is an open source language considering all the source code, including for all the infrastructure support, is freely available and may be reused and changed by anyone. Go provides all developers the freedom to fork and take an existing project in a new direction.  He further explains how there are 59 Googlers and 51 non-Googlers on the committers list which includes the set of people who can commit changes to the project. He says, “so while Google is the majority, it's not an overwhelming one.” Golang has a small core committee which makes decisions Contradicting Chris’s opinion of how Golang is only run by a small set of people which prevents it from becoming the community’s language, he says, “All successful languages have a small set of people who make the final decisions. Successful languages pay attention to what people want, but to change the language according to what most people want is, I believe, a recipe for chaos and incoherence.  I believe that every successful language must have a coherent vision that is shared by a relatively small group of people.” He then adds, “Since Go is a successful language, and hopes to remain successful, it too must be open to community input but must have a small number of people who make final decisions about how the language will change over time.” This makes sense. The core team’s full-time job is to take care of the language instead of taking errant decisions based on community backlash. Google will not make or block a change in a way that kills an entire project. But this does not mean they should sit idly, ignoring the community response. Ideally, the more than a project genuinely belongs to its community, the more it will reflect what the community wants and needs. Ian defends Google as a company being a member of the Golang team, saying they are doing more work with Go at a higher level, supporting efforts like the Go Cloud Development Kit and support for Go in Google Cloud projects like Kubernetes. He also assures that executives, and upper management in general, have never made any attempt to affect how the Go language and tools and standard library are developed. “Google, apart from the core Go team, does not make decisions about the language.” What if Golang is killed? He is unsure of what will happen if someone on the core Go team decides to leave Google but wants to continue working on Go. He says, “many people who want to work on Go full time wind up being hired by Google,  so it would not be particularly surprising if the core Go team continues to be primarily or exclusively Google employees.” This reaffirms our original argument of Google having a propensity to kill its own products. While Google’s history shows that many of their dead products are actually an important step towards something better and more successful, why and how much of that logic would be directly relevant to an open source project is something worth thinking about. He further adds, “ It's also possible that someday it will become appropriate to create some sort of separate Go Foundation to manage the language.”  But did not specify what such a foundation would look like, who its members will be, and how the governance model will be like. Will Google leave it to the community to figure out the governance model suddenly by pulling off the original authors into some other exciting new project? Or would they let the authors only work on Golang in their spare time at home or at the weekends? Another common argument is on what Google has invested to keep Go thriving and if, the so-called Go foundation will be able to sustain a healthy development cycle with low monetary investments (although GitHub sponsors can, maybe, change that). A comment on Hacker News reads, “ Like it or not, Google is probably paying around $10 million a year to keep senior full-time developers around that want to work on the language. That could be used as a benchmark to calculate how much of an investment is required to have a healthy development cycle. If a community-maintained fork is created, it would need time and monetary investment similar to what Google is doing just to maintain and develop non-controversial features. Question is: Is this assessment sensible and if so, is the community able or willing to make this kind of investment?” In general, though, most people/developers agreed with Ian. Here are a few responses from the same mailing list: “I just want to thank Ian for taking the time to write this. I've already got the idea that it worked that way, but my own deduction process, but it's good to have a confirmation from inside.” “Thank you for writing your reply Ian. Since it's a rather long post I don't want to go through it point by point, but suffice it to say that I agree with most of what you've written.” Read Ian’s post on Google Forums. Is Golang truly community driven and does it really matter? Go User Survey 2018 results: Golang goes from strength to strength, as more engineers than ever are using it at work. GitHub releases Vulcanizer, a new Golang Library for operating Elasticsearch

The release of Julia 1.0 has been eagerly anticipated - but it's finally here. At JuliaCon2018 in London the team got together to mark the project's landmark step. Take a look at the video below: It's taken more than six years for Julia to hit this milestone. The language was first launched in February 2012, and since then it has grown slowly to become a popular high-level dynamic programming language. The projects aims for Julia have been hugely ambitious since the start. As the team said in this post back in 2012: "We want a language that’s open source, with a liberal license. We want the speed of C with the dynamism of Ruby. We want a language that’s homoiconic, with true macros like Lisp, but with obvious, familiar mathematical notation like Matlab. We want something as usable for general programming as Python, as easy for statistics as R, as natural for string processing as Perl, as powerful for linear algebra as Matlab, as good at gluing programs together as the shell. Something that is dirt simple to learn, yet keeps the most serious hackers happy. We want it interactive and we want it compiled." However, despite the level of ambition it hasn't quite yet managed to expand beyond its core strength: numerical computing. However, that could change with version 1.0. What new features are in Julia 1.0? The team behind Julia are keen to stress that Julia 1.0 offers greater stability than the language ever has. They explain in a blog post announcing the new release: "The single most significant new feature in Julia 1.0, of course, is a commitment to language API stability: code you write for Julia 1.0 will continue to work in Julia 1.1, 1.2, etc. The language is “fully baked.” The core language devs and community alike can focus on packages, tools, and new features built upon this solid foundation." There are also many other new features, including: A new built in package manager Simplified scope rules Improved consistency in all of Julia's APIs A new canonical representation for missing values You can find out more about the new features here. Hang on... wasn't Julia 0.7 just released? Yes, Julia 0.7 has been released alongside version 1.0. This was done "to provide an upgrade path for packages and code that predates the 1.0 release." Version 0.7 simply includes deprecation warnings that aren't included in version 1.0. How to get started with Julia 1.0 If you're ready to get started on Julia 1.0 you can download it here. It's advised that if you're currently using Julia 0.6 or earlier, you should start with the 0.7 release - the deprecation warnings in Julia 0.7 act as a guide through the upgrade process.

The team at Qt has been coming with a lot of developments lately. This week, the Qt team released the Qt Design Studio 1.1 and yesterday the team announced the release of Qt Creator 4.9 Beta. What’s new in Qt Creator 4.9 Beta? Generic programming language support In this release, the team has added support for the document outline and for code actions, which allow the language server to suggest fixes or refactoring actions at a specified place in the code. The Qt highlighter is now based on the KSyntaxHighlighting library, which is the library used in KDE. Projects `Expand All` has been added to context menu. The `Close All Files in Project` action is now supported in this release. It’s now possible to close all the files of the project once the project is closed. C++ Support The UI for diagnostics from the Clang analyzer tools has been improved as they are grouped by file now. Diagnostics from the project’s headers files are also included. This release comes with a guard against applying Fix-its to files that have changed in the meantime. In the Clazy configuration, it is now possible to enable or disable individual checks. QML Support The QML parser has been updated to Qt 5.12. This release comes with an added support for ECMAScript 7. Support for Python This release comes with added project templates for Qt for Python. Nim Support The code completion has been added in this release based on NimSuggest. Profiling This release comes with Perf, which is a powerful performance profiling tool for software running on a Linux system. Operating systems For Windows, this release comes with an added support for MSVC 2019. On macOS, there is an added Touch Bar for running Qt Creator. For remote Linux targets, the Botan-based SSH backend has been exchanged by the use of OpenSSH tools. Major Fixes The dragging file from the `Projects` view has been fixed.   The crash on `Find Usages` has been fixed. To know more about this news, check out Qt’s official blog post. Qt Design Studio 1.1 released with Qt Photoshop bridge, updated timeline and more Qt for Python 5.12 released with PySide2, Qt GUI and more Qt team releases Qt Creator 4.8.0 and Qt 5.12 LTS

Can you guess what is common between, Bill Gates, Steve Jobs, Michael Dell, Larry Ellison? Yes they are very successful trendsetters in tech, some being co-founders and founders of top tech companies. But what else? They are also college dropouts. The point here I want to highlight is that real skills are more important than acquired college degrees. If you do not have a college degree, but have the skill set a company wants, you are in! In today’s economy it is important to have hands-on experience instead of being only book smart. Last week, the job searching website, Glassdoor compiled a list of Top companies that do not require a 4 year college degree as long as you have the skills required. The list includes some of the top tech companies as well such as Google, Apple, and IBM. Google has clearly mentioned on their web page: Source: Google If no degrees, then what? Now, you must be thinking that if these companies are not looking at your GPAs then how are they going to shortlist n number of applications coming their way. Remember the names I called out in the beginning? They have something more in common. They believed in self-learning, were passionate and innovative, and had clear goals. Sam Ladah, IBM’s head of talent organization, calls these type of jobs, “new-collar jobs.” He told the Marketplace in an interview that IBM consider the applicants based on their skills. This includes applicants who didn’t get a four-year degree but have proven their technical knowledge in other ways. Some have technical certifications, and others have enrolled in other skills programs. They have also been finding talents from coding bootcamps. A very good example of finding talent beyond traditional educational boundaries is Tanmay Bakshi, one of the youngest software programmers in the world. At the age of 11, he came across a documentary on the IBM Watson and how it played Jeopardy. He was immediately hooked to IBM Watson and AI and found inspiration to build his own first Watson app called “Ask Tanmay”. Later he was able to find a bug in the Document Conversion service by IBM and posted that on his Twitter. IBMers who were working on this service took a note of this and contacted Tanmay. Two of those initial contacts eventually became his mentors and assisted him in collaborating with IBM. Even if you have a degree in any other background but are keen on learning software development and bagging a job in top-tech companies, you can start anytime. Margaret Hamilton, the Director of the Software Engineer Division of the MIT Instrumentation Laboratory in 1960 and later the CEO of Hamilton Technologies, Inc, was actually a Mathematics graduate. Angela Taylor, who was working as an HR person in Google, with her hardwork and can-do attitude became a Google engineer. She fell in love with programming when she volunteered to fix a spreadsheet and learned Visual Basic for it. These were a few examples of the people who were able to challenge the current education system and became successful. Here is a great Medium post which could give you some amazing tips to further your career, if you are a coder but not an engineer. 1k+ Google employees frustrated with continued betrayal, protest against Censored Search engine project for China 16 year old hacked into Apple’s servers, accessed ‘extremely secure’ customer accounts for over a year undetected Facebook, Apple, Spotify pull Alex Jones content

A team from Federal University of Minas Gerais (UFMG) created a Code City metaphor for visualizing Golang source code called GoCity. You simply paste the IRL to a GitHub repository and GoCity plots it out as a city with districts and buildings. It allows you to visualize your code as a neat three-dimensional city. GoCity represents a program written in Go as a city: The folders are represented as districts Files in the program are shown as buildings of varying heights, shapes, and sizes The structs are represented as buildings stacked on the top of their files Characteristics of the structures The Number of Lines of Source Code (LOC) represents the building color. Higher values make the building dark. The Number of Variables (NOV) in the program affects the building's base size. The Number of methods (NOM) in the program affects the height of the. The UI/front-end The UI for GoCIty is built with React and uses babylon.js to plot the 3D structures. The source code for the front-end is available in the front-end branch on GitHub. What the users are saying A comment on Hacker news by user napsterbr reads: “Cool! Interestingly I always use a similar metaphor on my own projects. For instance, the event system may be seen as the roads linking different blocks (domains), each with their own building (module).” The Kubernetes repository does seem to take a toll as it forms a lot of buildings spaced out. “The granddaddy of them all, Kubernetes, takes quite a toll performance-wise. https://go-city.github.io/#/github.com/kubernetes/kubernetes.” But like another user jackwilsdon pointed out on Reddit: “Try github.com/golang/go if you want some real browser-hanging action!” For more details, visit the GitHub repository. For an interactive live demonstration, visit the Go City website. Golang plans to add a core implementation of an internal language server protocol Why Golang is the fastest growing language on GitHub GoMobile: GoLang’s Foray into the Mobile World

Last week, the Scala team announced the release of Scala 2.13. This release brings a number of improvements including overhauled standard library collections, a 5-10% faster compiler, and more. Overhauled standard library collections The major highlight of Scala 2.13 is standard library collections that are now better in simplicity, performance, and safety departments as compared to previous versions.  Some of the important changes made in collections include: Simpler method signatures The implicit CanBuildFrom parameter was one of the most powerful abstractions in the collections library. However, it used to make method signatures too difficult to understand. Beginning this release, transformation methods will no longer take an implicit ‘CanBuildFrom’ parameter making the resulting code simpler and easier to understand. Simpler type hierarchy The package scala.collection.parallel is now a part of the Scala standard module. This module will now come as a separate JAR that you can omit from your project if it does not uses parallel collections. Additionally, Traversable and TraversableOnce are now deprecated. New concrete collections The Stream collection is now replaced by LazyList that evaluates elements in order and only when needed. A new mutable.CollisionProofHashMap collection is introduced that implements mutable maps using a hashtable with red-black trees in the buckets. This provides good performance even in worst-case scenarios on hash collisions. The mutable.ArrayDeque collection is added, which is a double-ended queue that internally uses a resizable circular buffer. Improved Concurrency In Scala 2.13, Futures are “internally redesigned” to ensure it provides expected behavior in a broader set of failures. The updated Futures will also provide a foundation for increased performance and support more robust applications. Changes in the language The updates in language include the introduction of literal-based singleton types, partial unification on by default, and by-name method arguments extended to support both implicit and explicit parameters. Compiler updates The compiler will now be able to perform a deterministic and reproducible compilation. This essentially means that it will be able to generate identical output for identical input in more cases. Also, operations on collections and arrays are now optimized making the compiler 5-10% better compared to Scala 2.12. These were some of the exciting updates in Scala 2.13. For a detailed list, check out the official release notes. How to set up the Scala Plugin in IntelliJ IDE [Tutorial] Understanding functional reactive programming in Scala [Tutorial] Classifying flowers in Iris Dataset using Scala [Tutorial]

Earlier this week, Siva Chandra, Google LLVM contributor asked all LLVM developers on their opinion about starting a libc in LLVM. He mentioned a list of high-level goals and guiding principles, that they are intending to pursue. Three days ago, Rich Felker the creator of musl libc, made his thoughts about libc very clear by saying that “this is a very bad idea.” In his post, Chandra has said that he believes that a libc in LLVM will be beneficial and usable for the broader LLVM community, and may serve as a starting point for others in the community to flesh out an increasingly complete set of libc functionality.  Read More: Introducing LLVM Intermediate Representation One of the goals, mentioned by Chandra, states that the libc project would mesh with the “as a library” philosophy of the LLVM and would help in making the “the C Standard Library” more flexible. Another goal for libc states that it will support both static non-PIE and static-PIE linking. This means enabling the C runtime and the PIE loader for static non-PIE and static-PIE linked executables. Rich Felker posted his thoughts on the libc in LLVM as follows: Writing and maintaining a correct, compatible, high-quality libc is a monumental task. Though the amount of code needed is not that large, but “the subtleties of how it behaves and the difficulties of implementing various interfaces that have no capacity to fail or report failure, and the astronomical "compatibility surface" of interfacing with all C and C++ software ever written as well as a large amount of software written in other languages whose runtimes "pass through" the behavior of libc to the applications they host,”. Felkar believes that this will make libc not even of decent quality.  A corporate-led project is not answerable to the community, and hence they will leave whatever bugs it introduces, for the sake of compatibility with their own software, rather than fixing them. This is the main reason that Felkar thinks that if at all, a libc is created, it should not be a Google project.  Lastly Felkar states that avoiding monoculture preserves the motivation for consensus-based standard processes rather than single-party control. This will prove to be a motivation for people writing software, so they will write it according to proper standards, rather than according to a particular implementation.   Many users agree with Rich Felkar’s views.  A user on Hacker News states that “This speaks volumes very clearly. This highlights an immense hazard. Enterprise scale companies contributing to open-source is a fantastic thing, but enterprise scale companies thrusting their own proprietary libraries onto the open-source world is not. I'm already actively avoiding becoming beholden to Google in my work as it is already, let alone in the world where important software uses a libc written by Google. If you're not concerned by this, refer to the immense power that Google already wields over the extremely ubiquitous web-standards through the market dominance that Chrome has.” Another user says that, “In the beginning of Google's letter they let us understand they are going to create a simplified version for their own needs. It does mean they don't care about compatibility and bugs, if it doesn't affect their software. That's not how this kind of libraries should be implemented.” Another comment reads, “If Google wants their own libc that’s their business. But LLVM should not be part of their “manifest destiny”. The corporatization of OSS is a scary prospect, and should be called out loud and clear like this every time it’s attempted” While there are few others who think that Siva Chandra’s idea of a libc in LLVM might be a good thing. A user on Hacker News comments that “That is a good point, but I'm in no way disputing that Google could do a great job of creating their own libc. I would never be foolish enough to challenge the merit of Google's engineers, the proof of this is clear in the tasting of the pudding that is Google's software. My concerns lie in the open-source community becoming further beholden to Google, or even worse with Google dictating the direction of development on what could become a cornerstone of the architecture of many critical pieces of software.” For more details, head over to Rich Felkar’s pipermail.  Introducing InNative, an AOT compiler that runs WebAssembly using LLVM outside the Sandbox at 95% native speed LLVM 8.0.0 releases! LLVM officially migrating to GitHub from Apache SVN

At the Cloud Native Computing Foundation’s flagship conference, KubeCon + CloudNativeCon + Open Source Summit China 2019, Linus Torvalds, creator of Linux and Git was in a conversation with Dirk Hohndel, VP and Chief Open Source Officer, VMware on the past, present, and future of Linux. The cloud Native conference gathers technologists from leading open source and cloud native communities scheduled to take place in San Diego, California from November 18-21, 2019. When I think about Linux, Linus says, I worry about the technology and not care about the market. In a lot of areas of technology, being first is more important than being best because if you get a huge community around yourself you have already won. Linus says he and the Linux community and maintainers don’t focus on individual features; what they focus on is the process of getting those features out and making releases. He doesn’t believe in long term planning; there are no plans that span more than roughly six months. Top questions on security, gaming and Linux’s future, learnings and expectations Is the interest in Linux from people outside of the core Linux community declining? Linus opposes this statement stating that it’s still growing albeit not at quite the same rate it used to be. He says that people outside the Linux kernel community should care about Linux’s consistency and the fact that there are people to make sure that when you move to a new kernel your processes will not break. Where is the major focus for security in IT infrastructure? Is it in the kernel, or in the user space? When it comes to security you should not focus on one particular area alone. You need to have secure hardware, software, kernels, and libraries at every stage. The true path to security is to have multiple layers of security where even if one layer gets compromised there is another layer that picks up that problem. The kernel, he says, is one of the more security conscious projects because if the kernel has a security problem it's a problem for everybody. What are some learnings that other projects like Kubernetes and the whole cloud native world can take from the kernel? Linus acknowledges that he is not sure how much the kernel development model really translates to other projects. Linux has a different approach to maintenance as compared to other projects as well as a unified picture of where it is headed. However other projects can take up two learnings from Linux: Don't break your users: Linus says, this has been a mantra for the kernel for a long time and it's something that a lot of other projects seem to not have learned. If you want your project to flourish long term you shouldn’t let your users worry about upgrades and versions and instead make them aware of the fact that you are a stable platform. Create a common culture: In order to have a long life for a platform/project, you should create a community and have a common culture, a common goal to work together for a long term. Is gaming a platform where open source is going to be relevant? When you take up a new technology, Linus states,  you want to take as much existing infrastructure as possible to make it easy to get to your goals. Linux has obviously been a huge part of that in almost every setting. So the only places where Linux isn't completely taking over are those where there was a very strong established market and code base already. If you do something new, exciting and interesting you will almost inevitably use Linux as the base and that includes new platforms for gaming. What can we expect for Linux for the second thirty years? Will it continue just as today or where do you think we're going? Realistically if you look at what Linux does today, it's not that different from what operating systems did 50-60 years ago. What has changed is the hardware and the use. Linux is right in between those two things. What an operating system fundamentally does is act as a resource manager and as the interface between software and hardware. Linus says, “ I don't know what software and hardware will look like in 30 years but I do know we'll still have an operating system and that will probably be called Linux. I may not be around in 30 years but I will be around in 2021 for the 30 year Linux anniversary.” Go through the full conversation here. Linus Torvalds is sorry for his ‘hurtful behavior’, is taking ‘a break (from the Linux community) to get help’. Linux 5.1 out with Io_uring IO interface, persistent memory, new patching improvements and more! Microsoft is seeking membership to Linux-distros mailing list for early access to security vulnerabilities