Slashdot Mirror

An anonymous reader writes: Ever since I started coding, I have always loved object-oriented design patterns. I built an HTML preprocessor that adds inheritance, polymorphism, and public methods to this venerable language. It offers more freedom than a templating engine and has a wider variety of use cases. Pull requests appreciated!

Long-time Slashdot reader MarcoPon writes: I created a thing: SeqBox. It's an archive/container format (and corresponding suite of tools) with some interesting and unique features. Basically an SBX file is composed of a series of sector-sized blocks with a small header with a recognizable signature, integrity check, info about the file they belong to, and a sequence number. The results of this encoding is the ability to recover an SBX container even if the file system is corrupted, completely lost or just unknown, no matter how much the file is fragmented.

An anonymous reader writes: "An anonymous security researcher has published details on a vulnerability named "Antbleed," which the author claims is a remote backdoor affecting Bitcoin mining equipment sold by Bitmain, the largest vendor of crypto-currency mining hardware on the market," reports Bleeping Computer. The backdoor code works by reporting mining equipment details to Bitmain servers, who can reply by instructing the customer's equipment to shut down. Supposedly introduced as a crude DRM to control illegal equipment, the company forgot to tell anyone about it, and even ignored a user who reported it last fall. One of the Bitcoin Core developers claims that if such command would ever be sent, it could potentially brick the customer's device for good. Bitmain is today's most popular seller of Bitcoin mining hardware, and its products account for 70% of the entire Bitcoin mining market. If someone hijack's the domain where this backdoor reports, he could be in the position to shut down Bitcoin mining operations all over the world, which are nothing more than the computations that verify Bitcoin transactions, effectively shutting down the entire Bitcoin ecosystem. Fortunately, there's a way to mitigate the backdoor's actions using local hosts files.

An anonymous reader shares a report: Over the weekend, I put together a little tool that scans executable files for PNG images containing useless Adobe Extensible Metadata Platform (XMP) metadata. I ran it against a vanilla Windows 10 image and was surprised that Windows contains a lot of this stuff. Adobe XMP, generally speaking, is an Adobe technology that serializes metadata like titles, internal identifiers, GPS coordinates, and color information into XML and jams it into things, like images. This data can be extremely valuable in some cases but Windows doesn't need or use this stuff. It just eats up disk space and CPU cycles. Thanks to horrible Adobe Photoshop defaults, it's very easy to unknowingly include this metadata in your final image assets. So easy, almost all the images on this site are chock full of it. But you can appreciate my surprise when a bunch of important Windows binaries showed up in my tool.

Slashdot user #1083, downwa, writes: Canonical engineer Simon Fels has publicly released an Alpha version of Anbox. Similar to the method employed for Android apps on ChromeOS, Anbox runs an entire Android system (7.1.1 at present) in an LXC container. Developed over the last year and a half, the software promises to seamlessly bring performant Android apps to the Linux desktop.

After installing Anbox (based on Android 7.1.1) and starting Anbox Application Manager, ten apps are available: Calculator, Calendar, Clock, Contacts, Email, Files, Gallery, Music, Settings, and WebView. Apps run in separate resizeable windows. Additional apps (ARM-native binaries are excluded) can be installed via adb. Installation currently is only supported on a few Linux distributions able to install snaps. Contributions are welcome on Github.
In a blog post Simon describes it as "a side project" that he's worked on for over a year and a half. "There were quite a few problems to solve on the way to a really working implementation but it is now in a state that it makes sense to share it with a wider audience."

An anonymous reader quotes a report from BleepingComputer: GitHub user Zeffy has created a patch that removes a limitation that Microsoft imposed on users of 7th generation processors, a limit that prevents users from receiving Windows updates if they still use Windows 7 and 8.1. This limitation was delivered through Windows Update KB4012218 (March 2017 Patch Tuesday) and has made many owners of Intel Kaby Lake and AMD Bristol Ridge CPUs very angry last week, as they weren't able to install any Windows updates. Microsoft's move was controversial, but the company did its due diligence, and warned customers of its intention since January 2016, giving users enough time to update to Windows 10, move to a new OS, or downgrade their CPU, if they needed to remain on Windows 7 or 8.1 for various reasons. When the April 2017 Patch Tuesday came around last week, GitHub user Zeffy finally had the chance to test four batch scripts he created in March, after the release of KB4012218. His scripts worked as intended by patching Windows DLL files, skipping the CPU version check, and delivering updates to Windows 7 and 8.1 computers running 7th generation CPUs.

An anonymous reader quotes a report from Ars Technica: The Shadow Brokers -- the mysterious person or group that over the past eight months has leaked a gigabyte worth of the National Security Agency's weaponized software exploits -- just published its most significant release yet. Friday's dump contains potent exploits and hacking tools that target most versions of Microsoft Windows and evidence of sophisticated hacks on the SWIFT banking system of several banks across the world. Friday's release -- which came as much of the computing world was planning a long weekend to observe the Easter holiday -- contains close to 300 megabytes of materials the leakers said were stolen from the NSA. The contents (a convenient overview is here) included compiled binaries for exploits that targeted vulnerabilities in a long line of Windows operating systems, including Windows 8 and Windows 2012. It also included a framework dubbed Fuzzbunch, a tool that resembles the Metasploit hacking framework that loads the binaries into targeted networks. Independent security experts who reviewed the contents said it was without question the most damaging Shadow Brokers release to date. One of the Windows zero-days flagged by Hickey is dubbed Eternalblue. It exploits a remote code-execution bug in the latest version of Windows 2008 R2 using the server message block and NetBT protocols. Another hacking tool known as Eternalromance contains an easy-to-use interface and "slick" code. Hickey said it exploits Windows systems over TCP ports 445 and 139. The exact cause of the bug is still being identified. Friday's release contains several tools with the word "eternal" in their name that exploit previously unknown flaws in Windows desktops and servers.

An anonymous reader quotes a report from Ars Technica: The Shadow Brokers -- the mysterious person or group that over the past eight months has leaked a gigabyte worth of the National Security Agency's weaponized software exploits -- just published its most significant release yet. Friday's dump contains potent exploits and hacking tools that target most versions of Microsoft Windows and evidence of sophisticated hacks on the SWIFT banking system of several banks across the world. Friday's release -- which came as much of the computing world was planning a long weekend to observe the Easter holiday -- contains close to 300 megabytes of materials the leakers said were stolen from the NSA. The contents (a convenient overview is here) included compiled binaries for exploits that targeted vulnerabilities in a long line of Windows operating systems, including Windows 8 and Windows 2012. It also included a framework dubbed Fuzzbunch, a tool that resembles the Metasploit hacking framework that loads the binaries into targeted networks. Independent security experts who reviewed the contents said it was without question the most damaging Shadow Brokers release to date. One of the Windows zero-days flagged by Hickey is dubbed Eternalblue. It exploits a remote code-execution bug in the latest version of Windows 2008 R2 using the server message block and NetBT protocols. Another hacking tool known as Eternalromance contains an easy-to-use interface and "slick" code. Hickey said it exploits Windows systems over TCP ports 445 and 139. The exact cause of the bug is still being identified. Friday's release contains several tools with the word "eternal" in their name that exploit previously unknown flaws in Windows desktops and servers.

Earlier this month, Microsoft locked Windows 7 and Windows 8.1 PCs running on select Intel and AMD processors from receiving future security updates. Now, a developer has found a workaround. From a report on ZDNet: The new patch, from a developer using the name 'Zeffy' on GitHub, may help people caught by Microsoft's update policy for PCs running older versions of Windows on hardware with Intel's seventh-generation Kaby Lake processors and AMD's recently released Bristol Ridge Ryzen chips. [...] Zeffy's patch promises to get around this situation, which stems from non-security updates released in March that added a function to detect the hardware's CPU generation. The developer notes that Microsoft's March 16 rollup updates for Windows 7 and Windows 8.1 contained one particularly offensive changelog entry. As reported by Ghacks at the time, the two preview updates stated: "Enabled detection of processor generation and hardware support when PC tries to scan or download updates through Windows Update."

According to an announcement made earlier today, Microsoft has acquired Deis, "the company behind some of the most popular tools for building and managing applications on top of the Google-incubated Kubernetes container orchestration service," writes Frederic Lardinois via TechCrunch. From the report: "At Microsoft, we've seen explosive growth in both interest and deployment of containerized workloads on Azure, and we're committed to ensuring Azure is the best place to run them," Microsoft's executive VP for its cloud and enterprise group Scott Guthrie writes today. "To support this vision, we're pleased to announce that Microsoft has signed an agreement to acquire Deis -- a company that has been at the center of the container transformation." Deis provides three core open-source tools for managing Kubernetes deployments: Workflow, a platform for developers and operations teams to easily deploy and manage containerized apps; the Kubernetes package manager Helm; and Steward, a Kubernetes-native service broker (which basically allows applications to talk to each other). Like similar companies, its business model relies on providing paid support and training for these applications. The team will continue to work on these open-source tools, which are currently in use by the likes of Mozilla, CloudMine and SocialRadar.

"We are very excited about contributions from the community," announced Alphabet's DeepMind, open sourcing a new library to make it easier to build complex TensorFlow neural networks. An anonymous reader writes: "DeepMind foresees Sonnet to be used by the community as a research propellant," reports FossBytes. "Also, it would allow easy sharing of other models created by DeepMind with the community." Sonnet uses an object-oriented approach, a recent blog post explained, pointing to more details on GitHub. "The main principle of 'Sonnet' is to first construct Python objects which represent some part of a neural network, and then separately connect these objects into the TensorFlow computation graph."

DeepMind sees this as part of their broader commitment to open source AI research. "In recent months we've also open-sourced our flagship platform DeepMind Lab, and are currently working with Blizzard to develop an open source API that supports AI research in StarCraft II."

An anonymous reader quotes a report from Ars Technica: Rensenware" forces players to get a high score in a difficult PC shoot-em-up to decrypt their files. As Malware Hunter Team noted yesterday, users on systems infected with Rensenware are faced with the usual ransomware-style warning that "your precious data like documents, musics, pictures, and some kinda project files" have been "encrypted with highly strong encryption algorithm." The only way to break the encryption lock, according to the warning, is to "score 0.2 billion in LUNATIC level" on TH12 ~ Undefined Fantastic Object. That's easier said than done, as this gameplay video of the "bullet hell" style Japanese shooter shows. As you may have guessed from the specifics here, the Rensenware bug was created more in the spirit of fun than maliciousness. After Rensenware was publicized on Twitter, its creator, who goes by Tvple Eraser on Twitter and often posts in Korean, released an apology for releasing what he admitted was "a kind of highly-fatal malware." The apology is embedded in a Rensenware "forcer" tool that Tvple Eraser has released to manipulate the game's memory directly, getting around the malware's encryption without the need to play the game (assuming you have a copy installed, that is). While the original Rensenware source code has been taken down from the creator's Github page, a new "cut" version has taken its place, showing off the original joke without any actually malicious forced encryption.

An anonymous reader quotes a report from Ars Technica: Rensenware" forces players to get a high score in a difficult PC shoot-em-up to decrypt their files. As Malware Hunter Team noted yesterday, users on systems infected with Rensenware are faced with the usual ransomware-style warning that "your precious data like documents, musics, pictures, and some kinda project files" have been "encrypted with highly strong encryption algorithm." The only way to break the encryption lock, according to the warning, is to "score 0.2 billion in LUNATIC level" on TH12 ~ Undefined Fantastic Object. That's easier said than done, as this gameplay video of the "bullet hell" style Japanese shooter shows. As you may have guessed from the specifics here, the Rensenware bug was created more in the spirit of fun than maliciousness. After Rensenware was publicized on Twitter, its creator, who goes by Tvple Eraser on Twitter and often posts in Korean, released an apology for releasing what he admitted was "a kind of highly-fatal malware." The apology is embedded in a Rensenware "forcer" tool that Tvple Eraser has released to manipulate the game's memory directly, getting around the malware's encryption without the need to play the game (assuming you have a copy installed, that is). While the original Rensenware source code has been taken down from the creator's Github page, a new "cut" version has taken its place, showing off the original joke without any actually malicious forced encryption.

An anonymous reader quotes a report from Ars Technica: Rensenware" forces players to get a high score in a difficult PC shoot-em-up to decrypt their files. As Malware Hunter Team noted yesterday, users on systems infected with Rensenware are faced with the usual ransomware-style warning that "your precious data like documents, musics, pictures, and some kinda project files" have been "encrypted with highly strong encryption algorithm." The only way to break the encryption lock, according to the warning, is to "score 0.2 billion in LUNATIC level" on TH12 ~ Undefined Fantastic Object. That's easier said than done, as this gameplay video of the "bullet hell" style Japanese shooter shows. As you may have guessed from the specifics here, the Rensenware bug was created more in the spirit of fun than maliciousness. After Rensenware was publicized on Twitter, its creator, who goes by Tvple Eraser on Twitter and often posts in Korean, released an apology for releasing what he admitted was "a kind of highly-fatal malware." The apology is embedded in a Rensenware "forcer" tool that Tvple Eraser has released to manipulate the game's memory directly, getting around the malware's encryption without the need to play the game (assuming you have a copy installed, that is). While the original Rensenware source code has been taken down from the creator's Github page, a new "cut" version has taken its place, showing off the original joke without any actually malicious forced encryption.

An anonymous reader quotes a report from BleepingComputer: A new tool released on GitHub last week can help paranoid sysadmins keep track of whenever someone plugs in or disconnects an USB-based device from high-value workstations. Called USB Canary, this tool is coded in Python and currently, works only on Linux (versions for Windows and Mac are in the works). The tool works by watching USB ports for any activity while the computer is locked, which generally means the owner has left his desk. If an USB device is plugged in or unplugged, USB Canary can perform one of two actions, or both. It can alert the owner by sending an SMS message via the Twilio API, or it can post a message in a Slack channel, which can be monitored by other co-workers. USB Canary can prove to be a very useful tool for large organizations that feature strict PC policies. For example, if you really want to enforce a "No USB drives" at work, this could be the tool for the job. Further, with modifications, it could be used for logging USB activity on air-gapped systems.

Orome1 quotes a report from Help Net Security: Google Nest's Dropcam, Dropcam Pro, Nest Cam Outdoor and Nest Cam Indoor security cameras can be easily disabled by an attacker that's in their Bluetooth range. The vulnerabilities are present in the latest firmware version running on the devices (v5.2.1). They were discovered by researcher Jason Doyle last fall, and their existence responsibly disclosed to Google, but have still not been patched. The first two flaws can be triggered and lead to a buffer overflow condition if the attacker sends to the camera a too-long Wi-Fi SSID parameter or a long encrypted password parameter, respectively. Triggering one of these flaws will make the devices crash and reboot. The third flaw is a bit more serious, as it allows the attacker to force the camera to temporarily disconnect from the wireless network to which it is connected by supplying it a new SSID to connect to. If that particular SSID does not exist, the camera drops its attempt to associate with it and return to the original Wi-Fi network, but the whole process can last from 60 to 90 seconds, during which the camera won't be recording. Nest has apparently already prepared a patch but hasn't pushed it out yet. (It should be rolling out "in the coming days.")

BrianFagioli writes: Today, Google released yet another open source project. Called "Guetzli," it is a JPEG encoder that aims to produce even smaller image file sizes. In fact, the search giant claims a whopping 35 percent improvement over existing JPEG compression. If you are wondering why smaller file sizes are important, it is quite simple -- the web. If websites can embed smaller images, users can experience faster load times while using less data. While Google didn't aim to improve JPEG image quality with Guetzli, it seems it has arguably done so. It is subjective, but the search giant surveyed human beings and found they preferred Google's open source offering 75 percent of the time. Smaller file sizes and better image quality? Wow! Google has done something amazing here.

A developer has created the USG, "a small, portable hardware USB firewall...to prevent malicious USB sticks and devices laden with malware from infecting your computer." An anonymous reader quotes ZDNet: The problem is that most computers automatically trust every USB device that's plugged in, which means malicious code can run without warning... Cars, cash registers, and some ATMs also come with USB ports, all of which can be vulnerable to cyberattacks from a single USB stick. That's where the USG firewall comes in...a simple hardware serial link that only accepts a very few select number of safe commands, which prevents the device from executing system commands or intercepting network traffic. That means the data can flow from the USB device, but [it] effectively blocks other USB exploits.
The firmware has been open sourced, and the technical specifications have also been released online "to allow anyone to build their own from readily available development boards."

A developer has created the USG, "a small, portable hardware USB firewall...to prevent malicious USB sticks and devices laden with malware from infecting your computer." An anonymous reader quotes ZDNet: The problem is that most computers automatically trust every USB device that's plugged in, which means malicious code can run without warning... Cars, cash registers, and some ATMs also come with USB ports, all of which can be vulnerable to cyberattacks from a single USB stick. That's where the USG firewall comes in...a simple hardware serial link that only accepts a very few select number of safe commands, which prevents the device from executing system commands or intercepting network traffic. That means the data can flow from the USB device, but [it] effectively blocks other USB exploits.
The firmware has been open sourced, and the technical specifications have also been released online "to allow anyone to build their own from readily available development boards."

After WikiLeaks revealed data exposing information about the CIA's arsenal of hacking tools, Intel Security has released a tool that allows users to check if their computer's low-level system firmware has been modified and contains unauthorized code. PCWorld reports: The release comes after CIA documents leaked Tuesday revealed that the agency has developed EFI (Extensible Firmware Interface) rootkits for Apple's Macbooks. The documents from CIA's Embedded Development Branch (EDB) mention an OS X "implant" called DerStarke that includes a kernel code injection module dubbed Bokor and an EFI persistence module called DarkMatter. In addition to DarkMatter, there is a second project in the CIA EDB documents called QuarkMatter that is also described as a "Mac OS X EFI implant which uses an EFI driver stored on the EFI system partition to provide persistence to an arbitrary kernel implant." The Advanced Threat Research team at Intel Security has created a new module for its existing CHIPSEC open-source framework to detect rogue EFI binaries. CHIPSEC consists of a set of command-line tools that use low-level interfaces to analyze a system's hardware, firmware, and platform components. It can be run from Windows, Linux, macOS, and even from an EFI shell. The new CHIPSEC module allows the user to take a clean EFI image from the computer manufacturer, extract its contents and build a whitelist of the binary files inside. It can then compare that list against the system's current EFI or against an EFI image previously extracted from a system.

Last week Google released E2EMail, "a Gmail client that exchanges OpenPGP mail." Google's documentation promises that "Any email sent from the app is also automatically signed and encrypted... The target is a simple user experience -- install app, approve permissions, start reading or send sending messages." Trailrunner7 quotes On The Wire: People have been trying to find a replacement for PGP almost since the day it was released, and with limited success. Encrypted email is still difficult to use and painful to implement in most cases, but Google has just released a Chrome plugin designed to address those problems. The new E2EMail extension doesn't turn a user's Gmail inbox into an encrypted mail client. Rather, it is a replacement that gives users a separate inbox for encrypted messages. The system is built on Google's end-to-end encryption library, and the company has released E2EMail as an open-source project.
Wired quotes a web security researcher who calls the open sourcing "a telltale sign the project isn't going anywhere. This is a way for them to get their work out there but to absolve themselves of future obligations." But Google's privacy and security product manager responds that they're tackling some very thorny issues like secure key handling, and "The reason we want to put this into the open source community is precisely because everyone cares about this so much. We don't want everyone waiting for Google to get something done."

An anonymous reader writes: "A researcher has discovered what he calls a "logic vulnerability" that allowed him to create a Python script that is fully capable of bypassing Google's reCAPTCHA fields using another Google service, the Speech Recognition API," reports BleepingComputer. The attack is incredibly simple and works by downloading a version of the reCAPTCHA audio challenge, feeding it into Google's Speech Recognition API, getting the text-version of the audio challenge, and feeding it back into the reCAPTCHA field. Proof-of-concept code is available on GitHub, and the researcher says Google has failed to patch the issue, albeit it's unclear if he ever notified the company. The attack also only works against reCAPTCHA v2, not other versions like v1, or the upcoming Invisible reCAPTCHA (v3). Because the source code for the exploit is available online, security experts expect to see it ported to JavaScript and used to create browser extensions that bypass reCAPTCHA fields, especially when using the Tor Browser.

"The Pentagon is the latest government entity to join the open-source movement," writes NextGov. An anonymous reader quotes their report: The Defense Department this week launched Code.mil, a public site that will eventually showcase unclassified code written by federal employees. Citizens will be able to use that code for personal and public projects... The Defense Department's Digital Service team, whose members are recruited for short-term stints from companies including Google and Netflix, will be the first to host its code on the site once the agreement is finalized... "This is a direct avenue for the department to tap into a worldwide community of developers to collectively speed up and strengthen the software development process," a DOD post announcing the initiative said. The Pentagon also aims to find software developers and "make connections in support of DOD programs that ultimately service our national security."
Interestingly, there's no copyright protections on code written by federal employees, according to U.S. (and some international) laws, according to the site. "This can make it hard to attach an open source license to our code, and our team here at Defense Digital Service wants to find a solution. You can submit a public comment by opening a GitHub issue on this repository before we finalize the agreement at the end of March."

"The Pentagon is the latest government entity to join the open-source movement," writes NextGov. An anonymous reader quotes their report: The Defense Department this week launched Code.mil, a public site that will eventually showcase unclassified code written by federal employees. Citizens will be able to use that code for personal and public projects... The Defense Department's Digital Service team, whose members are recruited for short-term stints from companies including Google and Netflix, will be the first to host its code on the site once the agreement is finalized... "This is a direct avenue for the department to tap into a worldwide community of developers to collectively speed up and strengthen the software development process," a DOD post announcing the initiative said. The Pentagon also aims to find software developers and "make connections in support of DOD programs that ultimately service our national security."
Interestingly, there's no copyright protections on code written by federal employees, according to U.S. (and some international) laws, according to the site. "This can make it hard to attach an open source license to our code, and our team here at Defense Digital Service wants to find a solution. You can submit a public comment by opening a GitHub issue on this repository before we finalize the agreement at the end of March."

An anonymous IT geek writes: Cloudflare-hosted web sites have been leaking data as far back as September, according to Gizmodo, which reports that at least Cloudflare "acted fast" when the leak was discovered, closing the hole within 44 minutes, and working with search engines to purge their caches. (Though apparently some of it is still lingering...) Cloudflare CEO Matthew Prince "claims that there was no detectable uptick in requests to Cloudflare-powered websites from September of last year...until today. That means the company is fairly confident hackers didn't discover the vulnerability before Google's researchers did."

And the company's CTO also told Reuters that "We've seen absolutely no evidence that this has been exploited. It's very unlikely that someone has got this information... We do not know of anybody who has had a security problem as a result of this." Nevertheless, Fortune warns that "So many sites were vulnerable that it doesn't make sense to review the list and change passwords on a case-by-case basis." Some sites are now even resetting every user's password as a precaution, while site operators "are also being advised to wipe their sites' cookies and security certificates, and perform their own web searches to see if site data leaked." But I'd like to know what security precautions are being taken by Slashdot's readers?
Leave your own answers in the comments. How did you respond to Cloudbleed?

New submitter JustNiz quotes a report from GamingOnLinux: Valve has launched SteamVR for Linux officially in beta form and they are keen to stress that this is a development release. You will need to run the latest Steam Beta Client for it to work at all, so be sure to opt-in if you want to play around with it. VR on Linux will exclusively use Vulkan, so it's going to be a pretty good push for Vulkan if VR becomes more popular. Those who are interested can head over to GitHub for more information.

holy_calamity writes: University of Nebraska student Brevan Jorgenson swapped the rear-view mirror in his 2016 Honda Civic for a home-built device called a Neo, which can steer the vehicle and follow traffic on the highway. Jorgenson used hardware designs and open-source software released by Comma, a self-driving car startup that decided to give away its technology for free last year after receiving a letter asking questions about its functionality from the National Highway Traffic Safety Administration (NHTSA). Jorgenson is just one person in a new hacker community trying to upgrade their cars using Comma's technology. "A Neo is built from a OnePlus 3 smartphone equipped with Comma's now-free Openpilot software, a circuit board that connects the device to the car's electronics, and a 3-D-printed case," reports MIT Technology Review. The report notes that Neodriven, a startup based in Los Angeles, has recently started selling a pre-built Neo device that works with Comma's Openpilot software, but it costs $1,495.

holy_calamity writes: University of Nebraska student Brevan Jorgenson swapped the rear-view mirror in his 2016 Honda Civic for a home-built device called a Neo, which can steer the vehicle and follow traffic on the highway. Jorgenson used hardware designs and open-source software released by Comma, a self-driving car startup that decided to give away its technology for free last year after receiving a letter asking questions about its functionality from the National Highway Traffic Safety Administration (NHTSA). Jorgenson is just one person in a new hacker community trying to upgrade their cars using Comma's technology. "A Neo is built from a OnePlus 3 smartphone equipped with Comma's now-free Openpilot software, a circuit board that connects the device to the car's electronics, and a 3-D-printed case," reports MIT Technology Review. The report notes that Neodriven, a startup based in Los Angeles, has recently started selling a pre-built Neo device that works with Comma's Openpilot software, but it costs $1,495.

An anonymous reader quotes a report from InfoWorld: Sometimes the relationships between the data you've gathered are more important than the data itself. That's when a graph processing system comes in handy. It's an important but often poorly understood method for exploring how items in a data set are interrelated. Microsoft's been exploring this area since at least 2013, when it published a paper describing the Trinity project, a cloud-based, in-memory graph engine. The fruits of the effort, known as the Microsoft Graph Engine, are now available as an MIT-licensed open source project as an alternative to the likes of Neo4j or the Linux Foundation's recently announced JanusGraph. Microsoft calls Graph Engine (GE) as "both a RAM store and a computation engine." Data can be inserted into GE and retrieved at high speed since it's kept in-memory and only written back to disk as needed. It can work as a simple key-value store like Memcached, but Redis may be the better comparison, since GE stores data in strongly typed schemas (string, integer, and so on). How does all this shape up against the leading open source graph database, Neo4j? For one, Neo4j has been in the market longer and has an existing user base. It's also available in both an open source community edition and a commercial product, whereas GE is only an open source project right now.

The Metropolitan Museum of Art announced Tuesday that more than 375,000 of its "public-domain artworks" are now available for unrestricted use. "We have been working toward the goal of sharing our images with the public for a number of years," said Thomas P. Campbell, director and CEO of the Met, in a statement. "Our comprehensive and diverse museum collection spans 5,000 years of world culture and our core mission is to be open and accessible for all who wish to study and enjoy the works of art in our care." Fortune reports: The image collection covers photographs, paintings, and sculptures, among other works. Images now available for both scholarly and commercial purposes include Emanuel Leutze's famous painting Washington Crossing the Delaware; photographs by Walker Evans, Alfred Steiglitz, and Dorothea Lange; and even some Vincent van Gogh paintings. The Met has teamed up with Creative Commons, Wikimedia, Artstor, Digital Public Library of America, Art Resource, and Pinterest to host and maximize the reach of their enormous collection. There is also a public GitHub repository of the images.

The Verge's Paul Miller has some harsh words for the $242 open source DIY laptop kit TERES-I from Olimex. Instead of buying one hyper-integrated board that has all of the laptop's brains and I/O on it, you buy several little boards and wire them together. Then you put them inside a mostly finished case built by Olimex -- although if you want to go ultra DIY you can 3D print your own case, too. Everything, from the shell's CAD design to the motherboard's wiring, is available on GitHub for perusal or modification, and the modular nature of the internals means you can add a more powerful chipset or modify just about anything you find unsatisfying about the computer if you have the know-how or if Olimex or others offer compatible parts.

But, unfortunately, almost everything about this laptop is unsatisfying right now. It runs a quad-core ARM64 chip, though x86 and MIPS chips might be offered later on. It has a tiny 11.6-inch screen, a huge bezel, a tiny trackpad, a cramped-looking keyboard, and a whole lot of plastic. The OS (Linux, naturally) runs off a microSD card. At least the LCD comes in a 1080p variant, because the default 1366 x 768 resolution is a real throwback. There's even 802.11n Wi-Fi, which has me questioning what decade it is.
But are there any better alternatives? In the comments share your own thoughts about open source laptop kits.

Orome1 quotes a report from Help Net Security: A zero-day bug affecting Windows 10, 8.1, Windows Server 2012 and 2016 can be exploited to crash a vulnerable system and possibly even to compromise it. It is a memory corruption bug in the handling of SMB traffic that could be easily exploited by forcing a Windows system to connect to a malicious SMB share. Tricking a user to connect to such a server should be an easy feat if clever social engineering is employed. The vulnerability was discovered by a researcher that goes by PythonResponder on Twitter, and who published proof-of-exploit code for it on GitHub on Wednesday. The researcher says that he shared knowledge of the flaw with Microsoft, and claims that "they had a patch ready 3 months ago but decided to push it back." Supposedly, the patch will be released next Tuesday. The PoC exploit has been tested by SANS ISC CTO Johannes Ullrich, and works on a fully patched Windows 10. "To be vulnerable, a client needs to support SMBv3, which was introduced in Windows 8 for clients and Windows 2012 on servers," he noted, and added that "it isn't clear if this is exploitable beyond a denial of service." Until a patch is released, administrators can prevent it from being exploited by blocking outbound SMB connections (TCP ports 139 and 445, UDP ports 137 and 138) from the local network to the WAN, as advised by CERT/CC. "The tweet originally announcing this issue stated that Windows 2012 and 2016 is vulnerable," the researcher said. "I tested it with a fully patched Windows 10, and it got an immediate blue screen of death."

Here's the problem. "You could download Comma.ai's new open-source Python code from Github, grab the necessary hardware, and follow the company's instructions to add semi-autonomous capabilities to specific Acura and Honda model cars (with more vehicles to follow)," writes IEEE Spectrum. But then who's legally responsible if there's an accident? Long-time Slashdot reader Registered Coward v2 writes: While many legal experts agree OSS is "buyer beware" and that Comma.ai and its CEO Georg Hotz would not be liable, it's a gray area in the law. The software is release under the MIT OSS license and the Read Me contains the disclaimer "This is alpha-quality software for research purposes only... You are responsible for complying with local laws and regulatons." The U.S. Supreme Court, in a series of court cases in the 1990s, ruled open source code as free speech protected under the First Amendment of the U.S. Constitution.

The question is does that release the author(s) from liability. The EU has no EU wide rules on liability in such cases. One open question is even if the person who used the software could not sue, a third party injured by it might be able to since they are not a party to the license agreement.
An EFF attorney told HotHardware "Prosecutors and plaintiffs often urge courts to disregard traditional First Amendment protections in the case of software." But not everyone agrees. "Most legal experts that spoke with IEEE Spectrum -- and Hotz himself -- believe that if you use the company's code and something goes wrong, then it isn't liable for damages. You are."

Here's the problem. "You could download Comma.ai's new open-source Python code from Github, grab the necessary hardware, and follow the company's instructions to add semi-autonomous capabilities to specific Acura and Honda model cars (with more vehicles to follow)," writes IEEE Spectrum. But then who's legally responsible if there's an accident? Long-time Slashdot reader Registered Coward v2 writes: While many legal experts agree OSS is "buyer beware" and that Comma.ai and its CEO Georg Hotz would not be liable, it's a gray area in the law. The software is release under the MIT OSS license and the Read Me contains the disclaimer "This is alpha-quality software for research purposes only... You are responsible for complying with local laws and regulatons." The U.S. Supreme Court, in a series of court cases in the 1990s, ruled open source code as free speech protected under the First Amendment of the U.S. Constitution.

The question is does that release the author(s) from liability. The EU has no EU wide rules on liability in such cases. One open question is even if the person who used the software could not sue, a third party injured by it might be able to since they are not a party to the license agreement.
An EFF attorney told HotHardware "Prosecutors and plaintiffs often urge courts to disregard traditional First Amendment protections in the case of software." But not everyone agrees. "Most legal experts that spoke with IEEE Spectrum -- and Hotz himself -- believe that if you use the company's code and something goes wrong, then it isn't liable for damages. You are."

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

You asked, he answered! The creator of Apple's Swift programming language (and a self-described "long-time reader/fan of Slashdot") stopped by on his way to a new job at Tesla just to field questions from Slashdot readers. Read on for Chris's answers... Questions, and my best wishes.
by Volanin

Since you're the creator of LLVM, I'd like to know, in your opinion what's the greatest advantage of LLVM/Clang over the traditional and established GNU GCC compiler. Also, what's the greatest advantage of GNU GCC (or if you'd prefer, any other compiler) over LLVM/Clang, something that you'd like to "port" someday?

CL: GCC and LLVM/Clang have had a mutually beneficial relationship for years. Clang's early lead in terms of compiler error message expressivity has led the GCC developers to improve their error messages, and obviously GCC provides a very high bar to meet when LLVM and Clang were being brought up. It is important to keep in mind that GCC doesn't have to lose for Clang to win (or visa versa). Also, I haven't used GCC for many years, that said, since you asked I'll try to answer to the best of my knowledge:

From my understanding, for a C or C++ programmer on Linux, the code generated by GCC and Clang is comparable (each win some cases and lose other cases). Both compilers have a similar feature set (e.g. OpenMP is supported by both). Clang compiles code significantly faster than GCC in many cases, still generates slightly better errors and warning messages than GCC, and is usually a bit ahead in terms of support for the C++ standard. That said, the most significant benefit is improved compile time.

Going one level deeper, the most significant benefit I see of the LLVM optimizer and code generator over GCC is its architecture and design. LLVM is built with a modular library-based design, which has allowed it to be used in a variety of ways that we didn't anticipate. For example, it has been used by movie studios to JIT compile and optimize shaders used in special effects, has been used to optimize database queries, and LLVM is used as the code generator for a much wider range of source languages than GCC.

Similarly, the most significant benefit of Clang is that it is also modular. It specifically tackles problems related to IDE integration (including code completion, syntax highlighting, etc) and has a mature and vibrant tooling ecosystem build around it. Clang's design (e.g. lack of pervasive global variables) also allows it to be used at runtime, for example in OpenCL and CUDA implementations.

The greatest advantage I can see of GCC over LLVM/Clang is that it is the default compiler on almost all Linux distributions, and of course Linux is an incredibly important for developers. I'd love to see more Linux distributions start shipping Clang by default. Finally, GCC provides an Ada frontend, and I'm not aware of a supported solution for Ada + LLVM.

Future of LLVM?
by mveloso

Where do you see LLVM going?

CL: There are lots of things going on, driven by the amazing community of developers (which is growing like crazy) driving forward the llvm.org projects. LLVM is now used pervasively across the industry, by companies like Apple, Intel, AMD, Nvidia, Qualcomm, Google, Sony, Facebook, ARM, Microsoft, FreeBSD, and more. I'd love for it to be used more widely on Windows and Linux.

At the same time, I expect to see LLVM to continue to improve in a ton of different ways. For example, ThinLTO is an extremely promising approach that promises to bring scalable link time optimization to everyone, potentially replacing the default for -O3 builds. Similarly, there is work going on to speed up compile times, add support for the Microsoft PDB debug information format, and too many other things to mention here. It is an incredibly exciting time. If you're interested in a taste of what is happening, take a look at the proceedings from the recent 2016 LLVM Developer Meeting.

Finally, the LLVM Project continues to expand. Relatively recent additions include llgo (a Go frontend) and lld (a faster linker than "Gold"), and there are rumors that a Fortran frontend may soon join the fold.

The Mythical Compiler -VLIW
by Anonymous Coward

Is there any hope for VLIW architectures? The general consensus seems to be that Itanium tanked because the compiler technology wasn't able to make the leap needed. Linus complained about the Itanium ISA exposing the pipelines to assembly developers. What are the challenges from a compiler writers perspective with VLIW?

CL: I can't speak to why Itanium failed (I suspect that many non-technical issues like business decisions and schedule impacted it), but VLIW is hardly dead. VLIW designs are actively used in some modern GPUs and is widely used in DSPs - one example supported by LLVM is the Qualcomm Hexagon chip. The major challenge when compiling for a VLIW architecture is that the compiler needs good profile information, so it has an accurate idea of the dynamic behavior of the program.

How much of Swift is Based on Groovy?
by Anonymous Coward

So how much of Swift was inspired by Groovy? Both come from more high-end languages and look and act almost identical.

CL: It is an intentional design point of Swift that it look and feel "familiar" to folks coming from many other languages: not just Groovy. Feeling familiar and eliminating unnecessary differences from other programming languages is a way of reducing barriers of entry to start programming in Swift. It is also clearly true that many other languages syntactically influence each other, so you see convergence of ideas coming from many different places.

That said, I think it is a stretch to say that Swift and Groovy look and act "identical", except in some very narrow cases. The goal of Swift is simply to be as great as possible, it is not trying to imitate some other programming language.

C#
by Anonymous Coward

What do you think about Microsoft and C# versus the merits of Swift?

CL: I have a ton of respect for C#, Rust, and many other languages, and Swift certainly benefited by being able to observe their evolution over time. As such, there are a lot of similarities between these languages, and it isn't an accident.

Comparing languages is difficult in this format, because a lot of the answers come down to "it depends on what you're trying to do", but I'll give it a shot. C# has the obvious benefit of working with the .NET ecosystem, whereas Swift is stronger at working in existing C and Objective-C ecosystems like Cocoa and POSIX.

From a language level, Swift has a more general type system than C# does, offers more advanced value types, protocol extensions, etc. Swift also has advantages in mobile use cases because ARC requires significantly less memory than garbage collected languages for a given workload. On the other hand, C# has a number of cool features that Swift lacks, like async/await, LINQ, etc.

Rust
by Anonymous Coward

Chris, what are your general thoughts about Rust as a programming language?

CL: I'm a huge Rust fan: I think that it is a great language and its community is amazing. Rust has a clear lead over Swift in the system programming space (e.g. for writing kernels and device drivers) and I consider it one of the very few candidates that could lead to displacing C and C++ with a more safe programming language.

That said, Swift has advantages in terms of more developers using it, a more mature IDE story, and offers a much shallower learning curve for new developers. It is also very likely that a future version of Swift will introduce move-only types and a full ownership model, which will make Swift a lot more interesting in the system programming space.

BASIC
by jo7hs2

As someone who has been involved with the development of programming languages, do you think it is still possible to come up with a modern-day replacement for BASIC that can operate in modern GUI environments?

It seems like all attempts since we went GUI (aside from maybe early VisualBASIC and Hypercard) have been too complicated, and all attempts have been platform-specific or abandoned. With the emphasis on coding in schools, it seems like it would be helpful to have a good, simple, introductory language like we had in BASIC.

CL: It's probably a huge shock, but I think Swift could be this language. If you have an iPad, you should try out the free Swift Playgrounds app, which is aimed to teach people about programming, assuming no prior experience. I think it would be great for Swift to expand to provide a VisualBASIC-like scripting solution for GUI apps as well.

Cross-platform
by psergiu

How cross-platform is Swift? Are the GUI libraries platform-dependent or independent? I.E.: Can I write a single Swift program with a GUI that will compile, work the same and look similar on multiple platforms: Linux, Mac OS, Real Unix-es & BSDs, AIX, Windows?

CL: Swift is Open Source, has a vibrant community with hundreds of contributors, and builds on the proven LLVM and Clang technology stack. The Swift community has ported Swift itself to many different platforms beyond Apple platforms: it runs on various Linux distros and work is underway by various people to port it to Android, Windows, various BSDs, and even IBM mainframes.

That said, Swift does not provide a GUI layer, so you need to use native technologies to do so. Swift helps by providing great support for interoperating with existing C code (and will hopefully expand to support C++ and other languages in the future). It is possible for someone to design and build a cross platform GUI layer, but I'm not aware of any serious efforts to do so.

Exception Handling
by andywest

Why did Swift NOT have exception handling in the first couple of versions?

CL: Swift 1 (released in 2014) didn't include an error handling model simply because it wasn't ready in time: it was added in Swift 2 (2015). Swift 2 included a number of great improvements that weren't ready for Swift 1, including protocol extensions. Protocol extensions dramatically expanded the design space of what you can do with Swift, bringing a new era of "protocol oriented programming". That said, even Swift 3 (2016) is still missing a ton of great things we hope to add over the coming years: there is a long and exciting road ahead! See questions below for more details.

Why are strings passed by value?
by Anonymous Coward

Strings are immutable pass-by-reference objects in most modern languages. Why did you make this decision?

CL: Swift uses value semantics for all of its "built in" collections, including String, Array, Dictionary, etc. This provides a number of great advantages by improving efficiency (permitting in-place updating instead of requiring reallocation), eliminating large classes of bugs related to unanticipated sharing (someone mutates your collection when you are using it), and defines away a class of concurrency issues. Strings are perhaps the simplest of any of these cases, but they get the efficiency and other benefits.

If you're interested in more detail, there is a wealth of good information about the benefits of value vs reference types online. One great place to start is the "Building Better Apps with Value Types in Swift" talk from WWDC 2015.

As a language designer
by superwiz

Since you have been involved with 2 lauded languages, you are in a good position to answer the following question: "are modern languages forced to rely on language run-time to compensate for the facilities lacking in modern operating systems?" In other words, have the languages tried to compensate for the fact that there are no new OS-level light-weight paradigms to take advantage of multi-core processors?

CL: I'm not sure exactly what you mean here, but yes: if an OS provides functionality, there is no reason for a language runtime to replicate it, so runtimes really only exist to supplement what the OS provides. That said, the line between the OS and libraries is a very blurry one: Grand Central Dispatch (GCD) is a great example, because it is a combination of user space code, kernel primitives, and more all designed together.

Parallelism
by bill_mcgonigle

Say, about fifteen years ago, there was huge buzz about how languages and compilers were going to take care of the "Moore's Law Problem" by automating the parallelism of every task that could be broken up. With single-static assignment trees and the like the programmer was going to be freed from manually doing the parallelism.

With manufacturers starting to turn out 32- and 64-core chips, I'm wondering how well did we did on that front. I don't see a ton of software automatically not pegging a core on my CPU's. The ones that aren't quite as bad are mostly just doing a fork() in 2017. Did we get anywhere? Are we almost there? Is software just not compiled right now? Did it turn out to be harder than expected? Were languages not up to the task? Is hardware (e.g. memory access architectures) insufficient? Was the possibility oversold in the first place?

CL: I can't provide a global answer, but clearly parallelism is being well utilized in some "easy" cases (e.g. speeding up build time of large software, speed of 3d rendering, etc). Also, while large machines are available, most computers are only running machines with 1-4 cores (e.g. mobile phones and laptops), which means that most software doesn't have to cope with the prospects of 32-core machines⦠yet.

Looking forward, I am skeptical of the promises of overly magic solutions like compiler auto-parallelization of single threaded code. These "heroic" approaches can work on specific benchmarks and other narrow situations, but don't lead to a predictable and reliable programmer model. For example, a good result would be for you to use one of these systems and get a 32x speedup on your codebase. A really bad result would be to then make a minor change or bug fix to your code, and find out that it caused a 32x slowdown by defeating the prior compiler optimization. Magic solutions are problematic because they don't provide programmer control.

As such, my preferred approach is for the programming language to provide expressive ways for the programmer to describe their parallelism, and then allow the compiler and runtime to efficiently optimize it. Things like actor models, OpenMP, C++ AMP, and goroutines seem like the best approach. I expect concurrency to be an active area of development in the Swift language, and hope that the first pieces of the story will land in Swift 5 (2018).

Any insight into language design choices?
by EMB Numbers

I am a 25+ year Objective-C programmer and among other topics, I teach "Mobile App Development" and "Comparative Languages" at a university. I confess to being perplexed by some Swift language design decisions. For example,

• Swift is intended to be a "Systems Programming Language", is it not? Yet, there is no support for "volatile" variables needed to support fundamental "system" features like direct memory access from peripheral hardware.
• Why not support "dynamic runtime features" like the ones provided by the Objective-C language and runtime? It's partly a trick question because Swift is remarkably "dynamic" through use of closures and other features, but why not go "all the way?"

CL: These two questions get to the root of Swift "current and future". In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead. Recall that Swift is only a bit over two years old at this point: Swift 1.0 was released in September 2014.

If you compare Swift to other popular contemporary programming languages (e.g. Python, Java/C#, C/C++, Javascript, Objective-C, etc) a major difference is that Swift was designed for generality: these languages were initially designed for a specific niche and use case and then organically growing out.

In contrast, Swift was designed from the start to eventually span the gamut from scripting language to systems programming, and its underlying design choices anticipate the day when all the pieces come together. This is no small feat, because it requires pulling together the strengths of each of these languages into a single coherent whole, while balancing out the tradeoffs forced by each of them.

For example, if you compare Swift 3 to scripting languages like Python, Perl, and Ruby, I think that Swift is already as expressive, teachable, and easy to learn as a scripting language, and it includes a REPL and support for #! scripts. That said, there are obvious missing holes, like no regular expression literals, no multi-line string literals, and poor support for functionality like command line argument processing - Swift needs to be more "batteries included".

If you compare Swift 3 to systems programming languages with C/C++ or Rust, then I think there is a lot to like: Swift provides full low-level memory control through its "unsafe" APIs (e.g. you can directly call malloc and free with no overhead from Swift, if that is what you want to do). Swift also has a much lighter weight runtime than many other high level languages (e.g. no tracing Garbage Collector or threading runtime is required). That said, it has a number of holes in the story: no support for memory mapped I/O, no support for inline assembly, etc. More significantly, getting low-level control of memory requires dropping down to the Unsafe APIs, which provide a very C/C++ level of control, but also provides the C/C++ level lack of memory safety. I'm optimistic that the ongoing work to bring an ownership model to Swift will provide the kinds of safety and performance that Rust offers in this space.

If you compare Swift 3 to general application level languages like Java, I think it is already pretty great (and has been proven by its rapid adoption in the iOS ecosystem). The server space has very similar needs to general app development, but both would really benefit from a concurrency model (which I expect to be an important focus of Swift 5).

Beyond these areas of investment there is no shortage of ideas for other things to add over time. For example, the dynamic reflection capabilities you mention need to be baked out, and many people are interested in things like pre/post-conditions, language support for typestate, further improvements to the generics system, improved submodules/namespacing, a hygienic macro system, tail calls, and so much more.

There is a long and exciting road ahead for Swift development, and one of the most important features was a key part of Swift 3: unlike in the past, we expect Swift to be extremely source compatible going forward. These new capabilities should be addable to the language and runtime without breaking code. If you are interested in following along or getting involved with Swift development, I highly encourage you to check out the swift-evolution mailing list and project on GitHub.

Any hope for more productive programming?
by Kohath

I work in the semiconductor industry and our ASIC designs have seen a few large jumps in productivity:

• Transistors and custom layouts transitioned to standard cell flows and automated P&R.
• Design using logic blocks transitioned to synthesized design using RTL with HDLs.
• Most recently, we are synthesizing circuits directly from C language.

In the same timeframe, programming has remained more or less the same as it always was. New languages offer only incremental productivity improvements, and most of the big problems from 10 or 20 years ago remain big problems.

Do you know of any initiatives that could produce a step-function increase (say 5-10x) in coding productivity for average engineers?

CL: There have been a number of attempts to make a "big leap" in programmer productivity over the years, including visual programming languages, fourth-generation" programming languages, and others. That said, in terms of broad impact on the industry, none of these have been as successful as the widespread rise of "package" ecosystems (like Perl's CPAN, Ruby Gems, NPM in Javascript, and many others), which allow rapid reuse of other people's code. When I compare the productivity of a modern software developer using these systems, I think it is easy to see a 10x improvement in coding productivity, compared to a C or C++ programmer 10 years ago.

Swift embraces this direction with its builtin package manager "SwiftPM". Just as the Swift language learns from other languages, SwiftPM is designed with an awareness of other package ecosystems and attempts to assemble their best ideas into a single coherent vision. SwiftPM also provides a portable build system, allowing development and deployment of cross-platform Swift packages. SwiftPM is still comparatively early on in design, but has some heavy hitters behind it, particularly those involved in the various Swift for the Server initiatives. You might also be interested in the online package catalog hosted by IBM.

Looking ahead, even though a bit cliche, I'd have to say that machine learning techniques (convolutional neural nets and deep neural nets for example) really are changing the world by making formerly impossible things merely "hard". While it currently seems that you need a team of Ph.D's to apply and develop these techniques, when they become better understood and developed, I expect them to be more widely accessible to the rest of us. Another really interesting recent development is the idea of "word vectors," which is a pretty cool area to geek out on.

An anonymous reader quotes InfoWorld: A massive set of changes to the Windows Subsystem for Linux (WSL) was rolled into Windows Insider build 15002... If this is any hint, Microsoft's goal is nothing short of making it a credible alternative to other Linux distributions... Some of the fixes also implement functionality that wasn't available before to Linux apps in WSL, such as support for kernel memory overcommit and previously omitted network stack options. Other changes enhance integration between WSL and the rest of Windows...

[O]ne major issue in build 15002 is that Ctrl-C in a Bash session no longer works. Microsoft provided an uncommon level of detail for how this bug crept in, saying it had to do with synchronization between the Windows and Bash development teams. The next Insider build should have a fix. But for people doing serious work with Linux command-line apps, not having Ctrl-C is a little like driving a car when only the front brakes work.

Drawing on Haskell, Clojure, and ML, the new Lux language first targeted the Java Virtual Machine, but will be a universal, cross-platform language. An anonymous reader quotes JavaWorld: Currently in an 0.5 beta release, Lux claims that while it implements features common to Lisp-like languages, such as macros, they're more flexible and powerful in Lux... [W]hereas Clojure is dynamically typed, as many Lisp-like languages have been, Lux is statically typed to reduce bugs and enhance performance. Lux also lets programmers create new types programmatically, which provides some of the flexibility found in dynamically typed languages. The functional language Haskell has type classes, but Lux is intended to be less constraining. Getting around any constraints can be done natively to the language, not via hacks in the type system.
There's a a 16-chapter book about the language on GitHub.

Long-time Slashdot reader haruchai writes: Canadian company D-Wave has released their qbsolv tool on GitHub to help bolster interest and familiarity with quantum computing. "qbsolv is a metaheuristic or partitioning solver that solves a potentially large QUBO problem by splitting it into pieces that are solved either on a D-Wave system or via a classical tabu solver," they write on GitHub.

This joins the QMASM macro assembler for D-Wave systems, a tool written in Python by Scott Pakin of Los Alamos National Labs. D-Wave president Bo Ewald says "D-Wave is driving the hardware forward but we need more smart people thinking about applications, and another set thinking about software tools."

Long-time Slashdot reader haruchai writes: Canadian company D-Wave has released their qbsolv tool on GitHub to help bolster interest and familiarity with quantum computing. "qbsolv is a metaheuristic or partitioning solver that solves a potentially large QUBO problem by splitting it into pieces that are solved either on a D-Wave system or via a classical tabu solver," they write on GitHub.

This joins the QMASM macro assembler for D-Wave systems, a tool written in Python by Scott Pakin of Los Alamos National Labs. D-Wave president Bo Ewald says "D-Wave is driving the hardware forward but we need more smart people thinking about applications, and another set thinking about software tools."

An anonymous reader quotes Bleeping Computer: Browser autofill profiles are a reliable phishing vector that allow attackers to collect information from users via hidden form fields, which the browser automatically fills with preset personal information and which the user unknowingly sends to the attacker when he submits a form... Finnish web developer Viljami Kuosmanen has published a demo on GitHub... A user looking at this page will only see a Name and Email input field, along with a Submit button. Unless the user looks at the page's source code, he won't know that the form also contains six more fields named Phone, Organization, Address, Postal Code, City, and Country. If the user has an autofill profile set up in his browser, if he decides to autofill the two visible fields, the six hidden fields will be filled in as well, since they're part of the same form, even if invisible to the user's eye.

Browsers that support autofill profiles are Google Chrome, Safari, and Opera. Browsers like Edge, Vivaldi, and Firefox don't support this feature, but Mozilla is currently working on a similar feature.

An anonymous reader writes from a report via BleepingComputer: A security flaw discovered in a common PHP class allows knowledgeable attackers to execute code on a website that uses a vulnerable version of the script, which in turn can allow an attacker to take control over the underlying server. The vulnerable library is PHPMailer, a PHP script that allows developers to automate the task of sending emails using PHP code, also included with WordPress, Drupal, Joomla, and more. The vulnerability was fixed on Christmas with the release of PHPMailer version 5.2.18. Nevertheless, despite the presence of a patched version, it will take some time for the security update to propagate. Judging by past incidents, millions of sites will never be updated, leaving a large chunk of the Internet open to attacks. Even though the security researcher who discovered the flaw didn't publish any in-depth details about his findings, someone reverse-engineered the PHPMailer patch and published their own exploit code online, allowing others to automate attacks using this flaw, which is largely still unpatched due to the holiday season.

An anonymous reader writes from a report via BleepingComputer: A security flaw discovered in a common PHP class allows knowledgeable attackers to execute code on a website that uses a vulnerable version of the script, which in turn can allow an attacker to take control over the underlying server. The vulnerable library is PHPMailer, a PHP script that allows developers to automate the task of sending emails using PHP code, also included with WordPress, Drupal, Joomla, and more. The vulnerability was fixed on Christmas with the release of PHPMailer version 5.2.18. Nevertheless, despite the presence of a patched version, it will take some time for the security update to propagate. Judging by past incidents, millions of sites will never be updated, leaving a large chunk of the Internet open to attacks. Even though the security researcher who discovered the flaw didn't publish any in-depth details about his findings, someone reverse-engineered the PHPMailer patch and published their own exploit code online, allowing others to automate attacks using this flaw, which is largely still unpatched due to the holiday season.

Long-time Slashdot reader kruhft brings news about a new S-Expression based language transpiler that has the feel of C. This structure allows for the creation of code generation macros using the full power of the host Common Lisp environment, a language designed for operating on S-Expressions, also known as Lists. It is unknown exactly what power might come about from this combination of low level processing with high level code generation.
This has prompted some discussion online about other attempts to convert Lisp to C -- raising several more questions. How (and why) would you convert your Lisp code into C, and what would then be the best uses for this capability?

Long-time Slashdot reader kruhft brings news about a new S-Expression based language transpiler that has the feel of C. This structure allows for the creation of code generation macros using the full power of the host Common Lisp environment, a language designed for operating on S-Expressions, also known as Lists. It is unknown exactly what power might come about from this combination of low level processing with high level code generation.
This has prompted some discussion online about other attempts to convert Lisp to C -- raising several more questions. How (and why) would you convert your Lisp code into C, and what would then be the best uses for this capability?

Trailrunner7 quotes a report from On the Wire: Google has released a new set of tests it uses to probe cryptographic libraries for vulnerabilities to known attacks. The tests can be used against most kinds of crypto algorithms and the company already has found 40 new weaknesses in existing algorithms. The tests are called Project Wycheproof, and Google's engineers designed them to help developers implement crypto libraries without having to become experts. Cryptographic libraries can be quite difficult to implement and making errors can lead to serious security problems. Attackers often will look for weak crypto implementations as a means of circumventing strong encryption in a target app. Among the issues that Google's engineers found with the Project Wycheproof tests is one in ECDH that allows an attacker to recover the private key in some circumstances. The bug is the result of some libraries not checking the elliptic curve points that they get from outside sources. "In cryptography, subtle mistakes can have catastrophic consequences, and mistakes in open source cryptographic software libraries repeat too often and remain undiscovered for too long. Good implementation guidelines, however, are hard to come by: understanding how to implement cryptography securely requires digesting decades' worth of academic literature. We recognize that software engineers fix and prevent bugs with unit testing, and we found that many cryptographic issues can be resolved by the same means," Daniel Bleichenbacher and Thai Duong, security engineers at Google, said in a post announcing the tool release. "Encodings of public keys typically contain the curve for the public key point. If such an encoding is used in the key exchange then it is important to check that the public and secret key used to compute the shared ECDH secret are using the same curve. Some libraries fail to do this check," Google's documentation says.

Trailrunner7 quotes a report from On the Wire: Google has released a new set of tests it uses to probe cryptographic libraries for vulnerabilities to known attacks. The tests can be used against most kinds of crypto algorithms and the company already has found 40 new weaknesses in existing algorithms. The tests are called Project Wycheproof, and Google's engineers designed them to help developers implement crypto libraries without having to become experts. Cryptographic libraries can be quite difficult to implement and making errors can lead to serious security problems. Attackers often will look for weak crypto implementations as a means of circumventing strong encryption in a target app. Among the issues that Google's engineers found with the Project Wycheproof tests is one in ECDH that allows an attacker to recover the private key in some circumstances. The bug is the result of some libraries not checking the elliptic curve points that they get from outside sources. "In cryptography, subtle mistakes can have catastrophic consequences, and mistakes in open source cryptographic software libraries repeat too often and remain undiscovered for too long. Good implementation guidelines, however, are hard to come by: understanding how to implement cryptography securely requires digesting decades' worth of academic literature. We recognize that software engineers fix and prevent bugs with unit testing, and we found that many cryptographic issues can be resolved by the same means," Daniel Bleichenbacher and Thai Duong, security engineers at Google, said in a post announcing the tool release. "Encodings of public keys typically contain the curve for the public key point. If such an encoding is used in the key exchange then it is important to check that the public and secret key used to compute the shared ECDH secret are using the same curve. Some libraries fail to do this check," Google's documentation says.

It's the open source web version of the classic Linux strategy game, and now Slashdot reader Andreas(R) -- one of its developers -- has an announcement. Now the developers are working on bringing the game to the modern era with 3D WebGL graphics [and] a beta of the 3D WebGL version of Freeciv has been released today. The game will work on any device with a browser with HTML5 and WebGL support, and three gigabytes of RAM... It's a volunteer community development project and anyone is welcome to contribute to the project. Have fun and remember to sleep!
The developers of Freeciv-web are now also working on a VR version using Google Cardboard, according to the site, while the original Freeciv itself has still been maintained for over 20 years -- and apparently even has its own dedicated port number.

An anonymous reader writes: It's the year of the Linux desktop getting pwned. Chris Evans (not the red white and blue one) has released a number of linux zero day exploits, the most recent of which employs specially crafted audio files to compromise linux desktop machines. Ars Technica reports: "'I like to prove that vulnerabilities are not just theoretical -- that they are actually exploitable to cause real problems,' Evans told Ars when explaining why he developed -- and released -- an exploit for fully patched systems. 'Unfortunately, there's still the occasional vulnerability disclosure that is met with skepticism about exploitability. I'm helping to stamp that out.' Like Evans' previous Linux zero-day, the proof-of-concept attacks released Tuesday exploit a memory-corruption vulnerability closely tied to GStreamer, a media framework that by default ships with many mainstream Linux distributions. This time, the exploit takes aim at a flaw in a software library alternately known as Game Music Emu and libgme, which is used to emulate music from game consoles. The two audio files are encoded in the SPC music format used in the Super Nintendo Entertainment System console from the 1990s. Both take aim at a heap overflow bug contained in code that emulates the console's Sony SPC700 processor. By changing the .spc extension to .flac and .mp3, GSteamer and Game Music Emu automatically open them."