InfoWorld described the move as a "breakthrough": As expected, Python has climbed into the Top 3 of the Tiobe index of language popularity, achieving that milestone for the first time ever in the September 2018 edition of the index. With a rating of 7.653 percent, Python placed third behind first-place Java, which had a rating of 17.436 percent, and second-place C, rated at 15.447. Python displaced C++, which finished third last month and took fourth place this month, with a rating of 7.394 percent...

Python also has been scoring high in two other language rankings:

- The PyPL Popularity of Programming Language index, where it ranked No. 1 this month, as it has done before, and has had the most growth in the past five years.

- The RedMonk Programming Language Rankings, where Python again placed third.
Tiobe notes that Python's arrival in the top 3 "really took a long time," since it first entered their chart at the beginning of the 1990s. But today, "It is already the first choice at universities (for all kinds of subjects for which programming is demanded) and is now also conquering the industrial world." In February Tiobe also added a new programming language to their index: SQL. (Since "SQL appears to be Turing complete.")

"Other interesting moves this month are: Rust jumps from #36 to #31, Groovy from #44 to #34 and Julia from #50 to #39."

"The JavaScript world could use a bit of classification," reads this year's announcement at StateofJS.com: In 2017 this survey helped us do just that, by collecting data from over 20,000 developers to identify current and upcoming trends. This year, we're asking for your help once more to find out which libraries developers want to learn next, which have the best satisfaction ratings, and much more.
The survey launched in 2016 "mostly to scratch my own itch," its founder explained in a Medium essay. "I wanted to know what libraries were worth learning, and which ones were on the way out." Last year's survey discovered that React was the dominant framework, though the second most-popular framework was "none," with 9,493 JavaScript developers saying they didn't use one. Vue had increased in popularity while Angular lost steam, and developers collectively rating their overall happiness with front-end tools at 3.8 (on a scale up to five).

And more than 28% of the survey's respondent's said they'd used TypeScript, Microsoft's typed superset of JavaScript, and that they'd use it again.

"Feeling like a hack is more common than you might think," writes CNET: In fact, 58 percent of people with technology-focused careers suffer from Impostor Syndrome, according to a new informal study from workplace social media site Blind... Blind's user base includes 44,000 Microsoft employees, 29,000 from Amazon, 11,000 from Google, 8,000 from Uber, 7,000 from Facebook, and 6,000 from Apple, just to name a few. From Aug. 27, 2018 through Sept. 5, 2018, Blind asked its users one question in a survey -- "Do you suffer from Impostor Syndrome?" A total of 10,402 users on Blind responded.

Blind found that 57.55 percent surveyed experienced Impostor Syndrome. Seventy-two percent of Expedia employees say they experienced Impostor Syndrome, the highest among companies with at least 100 employee responses. On the lower end of the spectrum, only 44.45 percent of Apple employees experienced impostor syndrome.

OSNews reports: Terrence Andrew Davis, sole creator and developer of TempleOS (née LoseThos), has passed away at age 48. Davis suffered from mental illness -- schizophrenia -- which had a severe impact on his life. He claimed he created his operating system after having spoken with and receiving instructions from god, and he was a controversial figure, also here on OSNews, for his incomprehensible rants and abrasive style towards OSNews readers and staff. We eventually had to ban him, but our then-editor Kroc Kamen worked with him in 2010 to publish an article about his operating system despite his ban.... I hope he found peace -- wherever he may be.
Davis spent 10 years building "an operating system to talk to God," according to a 2014 profile in Motherboard, which described its welcome screen as "a riot of 16-color, scrolling, blinking text" resembling early DOS-based GUIs. (Wikipedia describes its interface as "a mixture of DOS and Turbo C.") To build his operating system, Terry wrote 121,176 lines of code.

An anonymous reader writes: Davis learned assembly language on a Commodore 64 before he'd graduated from high school. He eventually got a master's degree in electrical engineering from Arizona State University, and as an undergrad he worked briefly at Ticketmaster, programming operating systems. His later life included time in mental hospitals and some homelessness, as well as living at home with his parents after his schizophrenia was diagnosed and treated.

In 2014 Motherboard pieced together his lifestyle from emailed updates Terry sent from his Ubuntu desktop. They concluded he was living on disability, and spent most of his time coding, surfing the web, "or using the output from the National Institute of Standards and Technology randomness beacon to talk to God -- he posts the results on his webpage as 'Terry Davis' Rants.'" Their article describes him as "God's lonely programmer," saying Davis "offered the world a temple to a God who speaks only to him, and is still waiting for everyone else to listen."
Terry's death was confirmed by a local Oregon newspaper, and the official web site for TempleOS now also includes this death notice:

In the wake of Terry A. Davis' passing his family has requested supporters of his donate to "organizations working to ease the pain and suffering caused by mental illness" such as

• The Brain & Behavior Research Foundation
• National Alliance on Mental Illness

An anonymous reader quotes a report from Motherboard: Wednesday, Valve, the company that operates the huge online video game store Steam, shared more details about how it plans to control and moderate the ever-increasing number of games published on its platform. In the post published Wednesday, Valve shared more details about how it determines what it considers "outright trolling." "It is vague and we'll tell you why," Valve wrote. "You're a denizen of the internet so you know that trolls come in all forms. On Steam, some are simply trying to rile people up with something we call 'a game shaped object' (ie: a crudely made piece of software that technically and just barely passes our bar as a functioning video game but isn't what 99.9% of folks would say is "good.")

Valve goes on to explain that some trolls are trying to scam folks out of their Steam inventory items (digital items that can be traded for real money), while others are trying to generate a small amount of money through a variety of schemes that have to do with how developers use keys to unlock Steam games, while others are trying to "incite and sow discord." "Trolls are figuring out new ways to be loathsome as we write this," Valve said. "But the thing these folks have in common is that they aren't actually interested in good faith efforts to make and sell games to you or anyone. When a developer's motives aren't that, they're probably a troll." One interesting observation Valve shares in the blog post is that it rarely bans individual games from Steam, and more often bans developers and/or publishers entirely. [...] Valve said that its review process for determining that something may be a "troll game" is a "deep assessment" that involves investigating who the developer is, what they've done in the past, their behavior on Steam as a developer, as a customer, their banking information, developers they associate with, and more.

An anonymous reader quotes a report from CNBC: As our global economy increasingly comes to run on technology-enabled rails and every company becomes a tech company, demand for high-quality software engineers is at an all-time high. A recent study from Stripe and Harris Poll found that 61 percent of C-suite executives believe access to developer talent is a threat to the success of their business. Perhaps more surprisingly -- as we mark a decade after the financial crisis -- this threat was even ranked above capital constraints. And yet, despite being many corporations' most precious resource, developer talents are all too often squandered. Collectively, companies today lose upward of $300 billion a year paying down "technical debt," as developers pour time into maintaining legacy systems or dealing with the ramifications of bad software. This is especially worrisome, given the outsized impact developers have on companies' chances of success. Software developers don't have a monopoly on good ideas, but their skill set makes them a uniquely deep source of innovation, productivity and new economic connections. When deployed correctly, developers can be economic multipliers -- coefficients that dramatically ratchet up the output of the teams and companies of which they're a part.

Long time reader theodp writes: According to a Microsoft-commissioned survey, 50% of parents in the U.S. with children aged 18 and under believed coding and computer programming to be the most beneficial subject to their child's future employability ("compared to foreign language skills at 28%"). From the Microsoft Education blog post: "When asked about the technology industry's involvement, 75 percent of parents said they believe big tech companies should be involved in helping schools build kids' digital skills. Many companies, including Microsoft and organizations like Code.org, are working to do just that. Programs like TEALS, which is supported by Microsoft Philanthropies, pairs trained Computer Science professionals from across the technology industry with classroom teachers to team-teach the subject." In 2016, Microsoft partnered with Rhode Island Gov. Gina Raimondo to help bring computer science education to every public K-12 school across the state, an initiative that Raimondo is now touting in her 2018 bid for re-election (political ad).

On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles, writes programmer Martin Fowler. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects), he added. An anonymous reader shares his post: Now agile is everywhere, it's popular, but there's been an important shift. It was summed up quite nicely by a colleague of mine who said, "In the old days when we talked about doing agile, there was always this pushback right from the beginning from a client, and that would bring out some important conversations that we would have. Now, they say, 'Oh, yeah, we're doing agile already,' but you go in there and you suddenly find there's some very big differences to what we expect to be doing. As ThoughtWorks, we like to think we're very deeply steeped in agile notions, and yet we're going to a company that says, "Yeah, we're doing agile, it's no problem," and we find a very different world to what we expect.

Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile," or specifically "Dark Scrum." This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird. So that's our current battle. It's not about getting agile respectable enough to have a crowd like this come to a conference like this, it's realizing that a lot of what people are doing and calling agile, just isn't. We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile,' we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for.

Hewlett-Packard's Enterprise blog summarizes a talk by Linux kernel developer Kees Cook at the North America edition of the 2018 Linux Security Summit. Its title? "Making C Less Dangerous." "C is a fancy assembler. It's almost machine code," said Cook, speaking to an audience of several hundred peers, who understood and appreciated the application speed resulting from C... Over time, Cook and the people he worked with discovered numerous native C problems. To deal with these weaknesses, the Kernel Self Protection Project has worked slowly and steadily on protecting the Linux kernel from attack. In the process, it has worked to remove troublesome code from Linux....

With its operational baggage and weak standard libraries, C contains a great deal of undefined behavior. Cook cited -- and agreed with -- Raph Levien's blog post "With Undefined Behavior, Anything Is Possible." Cook gave concrete examples. "What are the contents of 'uninitialized' variables? Whatever was in memory from before! Void pointers have no type, yet we can call typed functions through them? Sure! Assembly doesn't care: Everything can be an address to call! Why does memcpy() have no 'max destination length' argument? Just do what I say; memory areas are all the same!" Some of these idiosyncracies are relatively easy to deal with. Cook commented, "Linus [Torvalds] likes the idea of always initializing local variables. So, you should 'just do it....'"

The long-term solution? More security-savvy open source developers... While at times, the idea of coming up with a Linux C dialect has been attractive, that's not going to happen. The real issue behind the problem of dangerous code is "people don't want to do the work to clean up code -- not just bad code, but C itself," he said. As with all open source projects, "we need more dedicated developers, reviewers, testers, and backporters."
LWN.net has its own run-down of Cook's talk, as well as a link to a PDF file of his slides.

"Sound good," posted one of their commenters, "though ultimately I'd like kernel devs to adopt Rust as their main Linux kernel development language. Beats the crap out of C and C++ combined."

Zorro (Slashdot reader #15,797) summarizes a new article in the Guardian: The death of a woman hit by a self-driving car highlights an unfolding technological crisis, as code piled on code creates "a universe no one fully understands."

"In some ways we've lost agency. When programs pass into code and code passes into algorithms and then algorithms start to create new algorithms, it gets farther and farther from human agency. Software is released into a code universe which no one can fully understand."
The author dubs these man-made monsters "franken-algos," since "After a time in the wild, we no longer know what they are: they have the potential to become erratic." Self-learning algorithms are already part of the "new all-machine phase" of Wall Street trading, leading to what science historian George Dyson believes are rules "where nobody knows what the rules are: the algorithms create their own rules -- you let them evolve the same way nature evolves organisms."

Where does it end? There's already a robotic sharpshooter policing the demilitarized zone between North and South Korea, and "swarms of coordinated, weaponized drones" already being developed by three different countries. The article suggests re-thinking our legal system to assign blame for any badly malfunctioning algorithms, noting that the Association for Computing Machinery recently updated its code of ethics "along the lines of medicine's Hippocratic oath, to instruct computing professionals to do no harm and consider the wider impacts of their work.... Solutions exist or can be found for most of the problems described here, but not without incentivizing big tech to place the health of society on a par with their bottom lines.

"More serious in the long term is growing conjecture that current programming methods are no longer fit for purpose given the size, complexity and interdependency of the algorithmic systems we increasingly rely on." Toby Walsh, a professor of artificial intelligence at the University of New South Wales, even says "We will eventually give up writing algorithms altogether... "because the machines will be able to do it far better than we ever could. Software engineering is in that sense perhaps a dying profession."

This week in Vancouver, Linux kernel developer Greg Kroah-Hartman criticized Intel's slow initial response to the Spectre and Meltdown bugs in a talk at the Open Source Summit North America. An anonymous reader quotes eWeek: Kroah-Hartman said that when Intel finally decided to tell Linux developers, the disclosure was siloed.... "Intel siloed SUSE, they siloed Red Hat, they siloed Canonical. They never told Oracle, and they wouldn't let us talk to each other." For an initial set of vulnerabilities, Kroah-Hartman said the different Linux vendors typically work together. However, in this case they ended up working on their own, and each came up with different solutions. "It really wasn't working, and a number of us kernel developers yelled at [Intel] and pleaded, and we finally got them to allow us to talk to each other the last week of December [2017]," he said. "All of our Christmas vacations were ruined. This was not good. Intel really messed up on this," Kroah-Hartman said...

"The majority of the world runs Debian or they run their own kernel," Kroah-Hartman said. "Debian was not allowed to be part of the disclosure, so the majority of the world was caught with their pants down, and that's not good." To Intel's credit, Kroah-Hartman said that after Linux kernel developers complained loudly to the company in December 2017 and into January 2018, it fixed its disclosure process for future Meltdown- and Spectre-related vulnerabilities... "Intel has gotten better at this," he said.

An interesting side effect of the Meltdown and Spectre vulnerabilities is that Linux and Windows developers are now working together, since both operating systems face similar risks from the CPU vulnerabilities. "Windows and Linux kernel developers now have this wonderful back channel. We're talking to each other and we're fixing bugs for each other," Kroah-Hartman said. "We are working well together. We have always wanted that."

darthcamaro writes: In a wide-ranging conversation at the Open Source Summit, Linus Torvalds admitted that he no longer knows everything that's in LInux. "Nobody knows the whole kernel anymore," Torvalds said. "Having looked at patches for many years, I know the big picture of all the areas in the kernel and I can look at a patch and know if it's right or wrong." Overall, he emphasized that being open source has enabled Linux to attract new developers that can pick up code and maintain all the various systems in Linux. In his view, the only way to deal with complexity is to be open. "When you have complexity you can't manage it in a closed environment, you need to have the people that actually find problems and give them the ability to get involved and help you to fix them," Torvalds said. "It's a complicated world and the only way to deal with complexity is the open exchange of ideas."

The Pentagon is no longer taking questions on its controversial cloud contract after making last-minute amendments to the deal -- and has received another complaint from disgruntled prospective bidder Oracle. The Register adds: The Joint Enterprise Defense Infrastructure (JEDI) contract has a massive scope, covering different levels of secrecy and classification across all branches of the US military, and a massive budget, being worth a potential $10bn for a maximum of 10 years. Unsurprisingly, it has garnered similar levels of interest and complaint. Most criticism focused on the decision to hand the deal to a single vendor amid speculation that AWS would be a shoo-in. Would-be bidder -- and longtime AWS rival -- Oracle filed an official complaint with US government at the start of the month, arguing a single vendor would lock the Department of Defense into "legacy cloud" and went against its purported commitment to innovation and competition. It has now filed a supplementary protest with the Government Accountability Office (GAO), which is not yet public but is likely to be an exchange of information and documents. The filing coincided with the Pentagon updating the terms of the JEDI deal, which it said came after engagement with industry after the previous request for proposals (RFP) was published.

dmoberhaus writes: Yesterday, a writer for SB Nation named Natalie Weiner posted a screenshot of a rejection form she received when she tried to sign up for a website. Her submission was rejected because a spam algorithm considered her last name "offensive." After she posted about this, hundreds of other people with similarly "offensive" last names sounded off about how they had experienced similar issues. As it turns out, this phenomenon is so widespread that it has a name among computer scientists. It's called the Scunthorpe problem and it's been a scourge of the internet since the beginning. Motherboard spoke to content moderation experts about its origins and why it's such a hard problem to solve 20 years later. A big reason why the problem has yet to be solved is "because creating effective obscenity filters depends on the filter's ability to understand a word in context," reports Motherboard. "Despite advances in [AI], this is something that even the most advanced machine-learning algorithms still struggle with today."

"This works both ways around," Michael Veale, a researcher studying responsible machine learning at University College London, told Motherboard. "Cock (a bird) and Dick (the given name) are both harmless in certain contexts, even in children's settings online, but in other cases parents might not want them used. Equally, those wanting to abuse a system can find ways around it."

More than a dozen people who work near Waymo's office in Chandler, Arizona, have complained about the self-driving cars to The Information. "One women said that she almost hit one of the company's minivans because it suddenly stopped while trying to make a right turn, while another man said that he gets so frustrated waiting for the cars to cross the intersection that he has illegally driven around them," reports CNBC. From the report: The anecdotes highlight how challenging it can be for self-driving cars, which are programmed to drive conservatively, to master situations that human drivers can handle with relative ease -- like merging or finding a gap in traffic to make a turn. Waymo has been testing its vehicles in the Phoenix suburbs for little more than a year and is widely seen as the furthest along in the self-driving car space, but its safety drivers have to take control of the vehicles regularly, people with direct knowledge of the issues tell The Information.

A Waymo spokesperson said its cars are "continually learning" and that "safety remains its highest priority" during testing. The spokesperson also said that Waymo is using feedback from its early rider program to improve its technology, though it declined to comment specifically on the intersection complaints mentioned in The Information story. The company has previously said that it plans to launch a commercial self-driving taxi service before the end of the year, but that its service will still include a Waymo employee in each car as a "chaperone."

Julia, the MIT-created programming language for developers "who want it all", hit its milestone 1.0 release this month -- with MIT highlighting its rapid adoption in the six short years since its launch. From a report: Released in 2012, Julia is designed to combine the speed of C with the usability of Python, the dynamism of Ruby, the mathematical prowess of MatLab, and the statistical chops of R. "The release of Julia 1.0 signals that Julia is now ready to change the technical world by combining the high-level productivity and ease of use of Python and R with the lightning-fast speed of C++," says MIT professor Alan Edelman. The breadth of Julia's capabilities and ability to spread workloads across hundreds of thousands of processing cores have led to its use for everything from machine learning to large-scale supercomputer simulation. MIT says Julia is the only high-level dynamic programming language in the "petaflop club," having been used to simulate 188 million stars, galaxies, and other astronomical objects on Cori, the world's 10th-most powerful supercomputer. The simulation ran in just 14.6 minutes, using 650,000 Intel Knights Landing Xeon Phi cores to handle 1.5 petaflops (quadrillion floating-point operations per second).

Jack Wallen, writing for TechRepublic: For a company to support Linux, they have to consider supporting: Multiple file systems, multiple distributions, multiple desktops, multiple init systems, multiple kernels. If you're an open source developer, focusing on a single distribution, that's not a problem. If you're a company that produces a product (and you stake your living on that product), those multiple points of entry do become a problem. Let's consider Adobe (and Photoshop). If Adobe wanted to port their industry-leading product to Linux, how do they do that? Do they spend the time developing support for ext4, btrfs, Ubuntu, Fedora, GNOME, Mate, KDE, systemd? You see how that might look from the eyes of any given company?

It becomes even more complicated when companies consider how accustomed to the idea of "free" (as in beer) Linux users are. Although I am very willing to pay for software on Linux, it's a rare occasion that I do (mostly because I haven't found a piece of must-have software that has an associated cost). Few companies will support the Linux desktop when the act of supporting means putting that much time and effort into a product that a large cross-section of users might wind up unwilling to pay the price of admission. That's not to say every Linux user is unwilling to shell out the cost for a piece of software. But many won't.

A post on Irish technology news blog, which criticizes the recent works of the world's second largest smartphone maker Huawei, is being widely circulated across several Android communities, with most people agreeing with the concerns raised in the post. From the story: Huawei is the second largest smartphone manufacturer in the world, falling second only to Samsung having recently overtaken Apple. They're huge in Ireland and across the globe. As a company, they have done a number of great things for both the enthusiast and the general user alike, but amidst privacy concerns the company has started to lash out at the community which helped get it (and especially its sub-brand Honor) off of the ground. Not only have they begun to block users from unlocking the devices which they've paid for, they are now looking to make users return their already unlocked devices to their normal state, according to numerous reports on the forums of XDA-Developers and well known Magisk developer topjohnwu. "I am informed that a new Huawei OTA will render Magisk-installed devices from booting," the developer wrote. Magisk is a popular "root" solution used which gives a user access to their device's system files.

Huawei was huge with the development community for a number of reasons, no less because their devices were some of the easiest to unlock out of all of the major manufacturers. You simply applied for your key online and promptly received it. It was a rather painless system, which allowed you to then install what's known as a "custom ROM". A custom ROM is simply just a custom version of Android, free from all of the included pre-installed applications from Huawei. They often run better too, again because of the lack of bloat.

NPM Inc. added a feature to JavaScript's package manager this spring letting users type npm audit fix to replace old, insecure project modules -- and the Register asked them how it's going? Since April, according to the company, npm users have run 50 million automatic scans and have deliberately invoked the command 3.1 million times. And they're running 3.4 million security audits a week. Across all audits, 51 per cent found at least one vulnerability and 11 per cent identified a critical vulnerability. In a phone interview with The Register, Adam Baldwin, head of security at NPM, said he didn't have data on how many people are choosing to fix flagged flaws. "But what we've seen from pull requests suggests it's gaining traction," he said.

Incidentally, npm's thinking about security is finding similar expression elsewhere in the industry. Earlier this year, GitHub began alerting developers when their code contains insecure libraries. During a recent media briefing, GitHub's head of platform Sam Lambert said he hoped that the process could be made more automated through the mechanized submission of git pull requests that developers could simply accept to replace flawed code.

Baldwin said NPM might implement something similar, an intervention rather than a simple notification. "Currently it's not proactive policy enforcement," he said. "But it's something we're considering." That would appeal to NPM's growing enterprise constituency. "Enterprises for sure want the compliance and control," said Baldwin. "They want that ability to know the open source they're bringing in is safe or meets a certain set of criteria."
Wednesday NPM added "Report a Vulnerability" buttons to every NPM package web page, and also started checking new passwords against the "Have I Been Pwned?" database to spot already-compromised passwords. "The tools for avoiding problems and fixing them are getting better," writes the Register. But it'd be interesting to hear from Slashdot readers.

How do you feel about code repositories automatically offering replacements for insecure libraries?

An anonymous reader writes: I know PHP isn't to some devs liking, but chances are you know people who work with PHP or have sites that are built with it. PHP 5.6 and 7.0 are shortly coming to the end of the support period for security patches, so what plans have you made to migrate code and sites to newer platforms? With apparently huge numbers (80%) of sites still running PHP 5.6, there appears to be little industry acknowledgement of the issue. Is there a ticking PHP Time Bomb waiting to go off?