Christopher Alexander, a British-American architect and design theorist that affected fields including software and sociology, died on Thursday, March 17, after a long illness. He was 86. Christopher Newport University reports: Christopher Alexander, a towering figure in architecture and urbanism -- one of the biggest influences on the New Urbanism movement -- died on Thursday, March 17, after a long illness, it was reported by Michael Mehaffy, a long-time collaborator and protege. Alexander was the author or principal author of many books, including A Pattern Language, one of the best-selling architectural books of all time. He is considered to be the father of the pattern language movement in software, which is the idea behind Wikipedia. In 2006, he was one of the first two recipients, along with Leon Krier, of CNU's Athena Medal, which honors those who laid the groundwork for The New Urbanism movement.

In 1965, Alexander wrote a much-cited essay, A City Is Not a Tree, one of the earliest and most trenchant critiques of the dendritic, sprawl pattern of city planning and development. Other works include The Timeless Way of Building and A New Theory of Urban Design. Alexander was more than a theorist: In 2006, when he was awarded the Athena, it was reported he had designed and built more than 200 buildings around the world. In 2012, his The Battle for the Life and Beauty of the Earth, tells the story of a school campus in Japan that was designed and built using the principles that he articulated (see photo at top).

The developer behind the popular npm package 'node-ipc' released sabotaged versions of the library in protest of the ongoing Russo-Ukrainian War, BleepingComputer reports. From the article: Newer versions of the 'node-ipc' package began deleting all data and overwriting all files on developer's machines, in addition to creating new text files with "peace" messages. With over a million weekly downloads, 'node-ipc' is a prominent package used by major libraries like Vue.js CLI.

Select versions (10.1.1 and 10.1.2) of the massively popular 'node-ipc' package were caught containing malicious code that would overwrite or delete arbitrary files on a system for users based in Russia and Belarus. These versions are tracked under CVE-2022-23812. On March 8th, developer Brandon Nozaki Miller, aka RIAEvangelist released open source software packages called peacenotwar and oneday-test on both npm and GitHub. The packages appear to have been originally created by the developer as a means of peaceful protest, as they mainly add a "message of peace" on the Desktop of any user installing the packages. "This code serves as a non-destructive example of why controlling your node modules is important," explains RIAEvangelist.

In an interview with The Register, Victor Shepelev, a Ruby developer and software architect who lives in Kharkiv, Ukraine, shares his experience living in a country being invaded by Russia. He hopes that his situation will encourage international political action to help Ukraine prevail. Here's an excerpt from the interview: The Register: Has your technical knowledge proven useful in your current situation and if so in what way?

Shepelev: Not directly, unfortunately. I am mostly experienced in writing expressive code, designing architectures of long-living systems, and mentoring people, not the most required abilities in wartime.

The Register: Does the Ruby/open source community provide community and support in wartime? Should it function any differently than it has in the context of a crisis?

Shepelev: Sad to say, but I don't feel much support. There are some people in my social circles in the Ruby community who do a lot, but as for the community as a whole, I think it stays mostly indifferent. My pleas to spread the information are by and large ignored. Maybe I am being selfish here, but I see that even small steps that could be done (like banners on sites of big projects, tweets from prominent Rubyists, mentions in newsletters) -- those steps aren't done even by a lot of people I know personally. I know some of them are sending money or helping in some other private ways, but I really lack the feeling of public support, people still mostly think it is some "politics they shouldn't mix with their everyday life." There are others, of course, and to them, I am eternally grateful.

The Register: Is there anything else you'd want people outside Ukraine to know?

Shepelev: We are standing, and we will not fall. But we need as much help as the world can give: with spreading information, with supporting the Ukrainian army, refugees, and humanitarian causes, and with pressuring Russia with any measures that are available. The more help we get, the sooner it will end, the less innocent people struggle or die.

juul_advocate shares a report from iTWire: A developer who had more than two decades of service in the Debian GNU/Linux project was stripped of his status in December leading to him deciding to leave the project. Norbert Preining told iTWire in response to a query he decided that having been graded down to Debian maintainer was not something he wanted after all these years. He has now joined the Arch Linux project.

Preining said what basically happened was that the [Debian account manager (DAM) team] thought he was bullying members of the project. "I guess they are referring to my run-in with Martina Ferrari where she called me out in very strange and unfounded ways, which started a long lasting disagreement between her and me, and the blog post about Lars [Wirzenius, a project member] which was nothing more than a selection of quotes from Lars' own blogs," he added.

"Anyway, these were all old things, but DAM still prefers to paint me in the light of 'You have been bullying members of the project for years' (quote from Enrico Zini on the debian-private mailing list) and that I cannot communicate with the Community Team, which back then included Martina, and which has again hit me in the back by allowing other members in Debian (I refrain from naming them here, but will do in my blog post) to bully me, even in unrelated forums and on IRC. The bottom line is that Martina, Lars, and those others are close friends of DAM and CT [community team] and the 'leading circle' in Debian, and thus it seems that they are exempted from adhering to the same community standards." Preining said the situation that led to his demotion was "more or less" about political correctness, adding that he'll explain more about the events in a blog post later on.

This week Silicon Valley's Computer History Museum posted a PDF transcript (and video excerpts) from an interview with 81-year-old Margaret Hamilton, the programmer/systems designer who in the 1960s became director of the Software Engineering Division at the MIT Instrumentation Laboratory which developed the on-board flight software for NASA's Apollo program. Prior to that Hamilton had worked on software to detect an airplane's radar signature, but thought, "You know, 'I guess I should delay graduate school again because I'd like to work on this program that puts all these men on the Moon....'"

"There was always one thing that stood out in my mind, being in the onboard flight software, was that it was 'man rated,' meaning if it didn't work a person's life was at stake if not over. That was always uppermost in my mind and probably many others as well."

Interestingly, Hamilton had originally received two job offers from the Apollo Space Program, and had told them to flip a coin to settle it. ("The other job had to do with support systems. It was software, but it wasn't the onboard flight software.") But what's fascinating is the interview's glimpses at some of the earliest days of the programming profession: There was all these engineers, okay? Hardware engineers, aeronautical engineers and all this, a lot of them out of MIT... But the whole idea of software and programming...? Dick Battin, Dr. Battin, when they told him that they were going to be responsible for the software...he went home to his wife and said he was going to be in charge of software and he thought it was some soft clothing...
Hamilton also remembers in college taking a summer job as a student actuary at Travelers Insurance in the mid-1950s, and "all of a sudden one day word was going around Travelers that there were these new things out there called computers that were going to take away all of their jobs... Pretty soon they wouldn't have jobs. And so everybody was talking about it. They were scared they wouldn't have a way to make a living.

"But, of course, it ended up being more jobs were created with the computers than there were...."

Hamilton's story about Apollo 8 is amazing...

Princeton University has a research center studying "digital technologies in public life," which runs a web site with commentary and analysis "from the digital frontier, written by the Center's faculty, students, and friends."

Long-time Slashdot reader theodp summarizes the site's recent warning on the dangers of "philanthrocapitalism," in a piece noting ominously that "The tech industry controls CS conference funding." "Research about the influence of computing technologies, such as artificial intelligence (AI), on society relies heavily upon the financial support of the very companies that produce those technologies," writes Princeton Research Fellow Klaudia Jazwinska of the dangers of 'philanthrocapitalism'. "Corporations like Google, Microsoft, and IBM spend millions of dollars each year to sponsor labs, professorships, PhD programs, and conferences in fields like computer science (CS) and AI ethics at some of the world's top institutions. Industry is the main consumer of academic CS research, and 84% percent of CS professors receive at least some industry funding."

"Relying on large companies and the resources they control can create significant limitations for the kinds of CS research that are proposed, funded and published. The tech industry plays a large hand in deciding what is and isn't worthy of examination, or how issues are framed. [...] The scope of what is reasonable to study is therefore shaped by what is of value to tech companies. There is little incentive for these corporations to fund academic research about issues that they consider more marginal or which don't relate to their priorities."

Jazwinska concludes, "Given the extent of financial entanglement between Big Tech and academia, it might be unrealistic to expect CS scholars to completely resist accepting any industry funding—instead, it may be more practicable to make a concerted effort to establish higher standards for and greater transparency regarding sponsorship.

An interesting tidbit from Mike Melanson's column, "This Week in Programming."

"If a proposal unveiled this week gets its way, JavaScript developers will soon have something that many of them have long been asking for: a type system, of some sort at least." A blog post by TypeScript senior program manager Daniel Rosenwasser lays out the background and reasoning for the proposal for type syntax in JavaScript. He writes that "if we pull this all off, we have the chance to make one of the most impactful improvements to the world of JavaScript."

The proposal, which shares authors from Microsoft, Bloomberg, Igalia, and a number of other sources, suggests that JavaScript developers should be able to "add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker that is external to JavaScript" and then be ignored at runtime. "Because this new syntax wouldn't change how surrounding code runs, it would effectively act as comments," writes Rosenwasser in his blog post, later adding that "JavaScript could carve out a set of syntax for types that engines would entirely ignore, but which tools like TypeScript, Flow, and others could use...."

One noteworthy part of the proposal lays out exactly what is not being proposed:

"Our team isn't proposing putting TypeScript's type-checking in every browser and JavaScript runtime — nor are we proposing any new type-checker to be put in the browser. We think doing that would cause problems for JavaScript and TypeScript users alike due to a range of issues, such as runtime performance, compatibility issues with existing TypeScript code, and the risk of halting innovation in the type-checking space." Similarly, several features from TypeScript that generate code, such as enums, namespaces, and parameter properties, are being explicitly excluded "because they have runtime semantics, generating JavaScript code rather than simply being stripped out and ignored...."

As the proposal's authors note, the proposal itself is presented as a "strawperson proposal".... Thus far, it would appear that there is debate aplenty, alongside a rather robust enthusiasm for the advent of type functionality coming to a JavaScript near you.

TikTok's national security clash with the U.S. government may be nearing its conclusion, without the sort of shareholder overhaul that was previously proposed. From a report: The social media company is in advanced talks with the Committee on Foreign Investment in the United States (CFIUS) to store all of its U.S. user information with Oracle, without Chinese owner ByteDance being able to access it, as first reported by Reuters and confirmed by Axios. Data sovereignty has been the core regulatory concern since this all began in mid-2020, at least for career staff. Certain political appointees of the Trump administration also expressed fears that the Chinese government could use TikTok to influence U.S. political or social sentiment, but content moderation seems outside the scope of current talks.

Niantic is acquiring 8th Wall, a company that helps developers make web-based augmented reality apps, in what it says is its "largest acquisition to date." The Verge reports: The acquisition will help boost Niantic's Lightship developer platform and to help developers "realize their visions for AR in the real-world metaverse," Niantic's Brian McClendon said in a blog post. Terms of the deal weren't disclosed, and when asked, Niantic spokesperson Jen Stratton said the details were confidential. [...] [G]iven the acquisition announced Thursday, it seems that Niantic still believes in the potential for augmented reality apps and is aiming to make it easier for developers to make them.

Business Insider reports: Serhiy Storchaka, a Ukrainian developer, is the second-most prolific recent contributor to Python and tenth-most prolific of all time, according to Lukasz Langa, the Python Software Foundation's developer in residence, based in Poznan, Poland... Storchaka faced an impossible choice as Russia invaded his country. Like many young male programmers in Ukraine, he decided to stay....

Storchaka lives outside of Konotop, a city in northeastern Ukraine which is occupied by Russian forces. He tweeted on February 26, "Russian tanks were on the road 2km from my house, and Russian armored vehicles were passing by my windows. Most likely, I will find myself in the occupied zone, where the law does not apply...."

Insider was unable to contact Storchaka, but spoke with Langa... [A]s the military crisis worsened on Friday and over the weekend, the Python developer community rallied to help Storchaka's younger family members. Communicating with Storchaka's family through Google Translate, Langa managed to secure temporary housing for Storchaka's niece and best friend, aged 11. They crossed the border to Poland via bus with their mother, and met Langa, who drove over 300km to Warsaw to pick up keys and secure basic necessities for the family.
"Two little 11-year-old girls (my niece and her best friend) are now safe thanks to @llanga," Storchaka tweeted last Monday, adding "My sister and I are immensely grateful." (He'd been especially worried because their town was near one of Ukraine's nuclear power plants, "a strategic target".)

Business Insider points out Storchaka is just one of many Python core developers from Ukraine, and one of many Ukrainians working in its tech sector. Andrew Svetlov, another influential Python developer who specializes in asynchronous networking support, also remains in Ukraine.... Svetlov is in Kyiv, where Russian troops have surrounded the city....

"Neither of them wanted to leave their country, even in the face of the great risk this poses for them," Langa told Insider.

"Code generation AI — AI systems that can write in different programming languages given a prompt — promise to cut development costs while allowing coders to focus on creative, less repetitive tasks," writes VentureBeat.

"But while research labs like OpenAI and Alphabet-backed DeepMind have developed powerful code-generating AI, many of the most capable systems aren't available in open source." For example, the training data for OpenAI's Codex, which powers GitHub's Copilot feature, hasn't been made publicly available, preventing researchers from fine-tuning the AI model or studying aspects of it such as interpretability.

To remedy this, researchers at Carnegie Mellon University — Frank Xu, Uri Alon, Graham Neubig, and Vincent Hellendoorn — developed PolyCoder, a model based on OpenAI's GPT-2 language model that was trained on a database of 249 gigabytes of code across 12 programming languages. While PolyCoder doesn't match the performance of top code generators in every task, the researchers claim that PolyCoder is able to write in C with greater accuracy than all known models, including Codex....

"Large tech companies aren't publicly releasing their models, which is really holding back scientific research and democratization of such large language models of code," the researchers said. "To some extent, we hope that our open-sourcing efforts will convince others to do the same. But the bigger picture is that the community should be able to train these models themselves. Our model pushed the limit of what you can train on a single server — anything bigger requires a cluster of servers, which dramatically increases the cost."

CNBC reminds us that Ukraine is also home "to a massive community of software developers who work remotely for companies all over the U.S. and Europe.

"There were 200,000 Ukrainian developers in the country in 2020, according to Amsterdam-based software development outsourcing company Daxx, which says that 20% of Fortune 500 companies have their remote development teams in Ukraine." As major cities across Ukraine endure devastating attacks that have seen buildings reduced to rubble, company leaders in the U.S. and Europe have expressed awe at their Ukraine-based staff. Those developers, along with other Ukrainian civilians in the country, are now being forced to defend their homes and cities while sheltering from Russian bombs. But many are still continuing to remotely work for their employers, supporting the local defense effort by day while sending in their deliverables by night.

"Yes our teams are sending deliverables from a f — ing parking garage in Kharkiv under heavy shelling and gunfire in the area. Amazing humans," Logan Bender, chief financial officer at a San Francisco-based software licensing company, said in a story posted to Instagram on Tuesday by venture capital meme account PrayingforExits. "We of course told them all deliverables are off the table. Nothing of you expected other than to let us know how we can help other than wiring money and getting their visa process going," he said. Bender has been working to get a defense service to extract his employees from the conflict zone under armed guards....

"Our lead front-end developer fled to Lviv to his parents' rural house 40km outside the city and is still submitting pull requests," Eric Hovagim, CEO and founder of Los Angeles-based betting platform Pogbet, told CNBC. "He's returning to Lviv tomorrow morning to continue his work while helping with the fight."

"These Ukrainians are built different," Hovagim said. "No armed guard extraction necessary. These people are their own armed guards...."

Ukrainians in IT-related fields are also deploying their skills for the fight at home. Employees at a local digital marketing agency in Kyiv are helping carry out cyberattacks against Russian entities in collaboration with Ukraine's Ministry of Digital Transformation. A local Telegram channel dedicated to crowd-sourcing programmers to carry out cyberattacks against Russia has nearly a million subscribers...

Alexandru Asimionese, co-founder of Moldova-based software developer Labs42, described one of his freelance designers based in the northwestern Ukrainian city of Lutsk. "In the morning goes to buy high-protein snacks to deliver to the local army. Late night, sends logo ideas. Always paid in crypto (via) Binance," he said. Another start-up manager said that his Ukrainian girlfriend was returning to Ukraine from overseas to fight, and plans to continue working for her tech company while not fighting invaders.

"Much of the most widely used free and open source software is developed by only a handful of contributors," warns the Linux Foundation, in the executive summary for its massive new census of free and open source software application libraries. It was prepared in conjunction with Harvard's Laboratory for Innovation Science — and that's just one of its five high-level findings.

The census also notes "the increasing importance of individual developer account security," but also the persistence of legacy software, the need for a standardized naming schema for software components, and "complexities" around package versions. But there's also just a lot of data about package popularity, writes SD Times: The report, Census II, is a follow-up to Census I, which was conducted in 2015 to identify the packages in Debian Linux that were most critical to the operation and security of the kernel. According to the Linux Foundation, Census II allows for a more "complete picture of free and open source (FOSS) adoption."

"Understanding what FOSS packages are the most critical to society allows us to proactively support projects that warrant operations and security support," said Brian Behlendorf, executive director at Linux Foundation's Open Source Security Foundation (OpenSSF).
The census "aggregates data from over half a million observations of FOSS libraries used in production applications at thousands of companies," according to its executive summary. It argues that preserving FOSS will require this kind of data-sharing (about where and how FOSS packages are being used ) as well as coordination — including standardizing terminology — and of course, investment.

"The motivation behind publishing these findings is to not only inform, but also to inspire action by developers to improve their security practices and by end users to support the FOSS ecosystem and developers who need assistance." (It suggests companies companies could provide not just financial support but also the technical talent and their time.) The results take the form of eight Top 500 lists — four that include version numbers in the analysis and four that are version agnostic. Further, as mentioned above, we present npm and non-npm packages in separate lists... Although these lists provide valuable, important insights into the most widely used FOSS projects, it is important to also consider the level of security related to these projects. Therefore, in each list, we also include the "Tiered %" measure from the OpenSSF Best Practices Badging Program....

The Wordle clones are back on the App Store, just a few weeks after Apple wiped out nearly all the copycat games in January. From a report: A quick glance at the top free apps on the App Store reveals at least two prominently placed Wordle-alikes, while diving into Apple's more specific word games category (or simply searching "Wordle") surfaces plenty of other copycats, many of which appear to have been part of Apple's first wave of takedowns a few months ago. None of the new games are actively passing themselves off as Wordle -- at least, not in name. Instead, the clones have creatively rebranded to "Wordus," "Word Guess," "Wordl," and other thinly veiled references to the original game. But all of them offer some variant on Wordle's gameplay, down to the same gameplay, UI, design, and color scheme.

GitHub's Copilot is an AI-powered autocompletion tool for coders, but the FSF has come up with a new way to describe it:

Service as a Software Substitute (SaaSS).

But they also feel the service "immediately raised serious questions for the free software movement and our ability to safeguard user and developer freedom" — which is why last July they'd put out a call for papers from the free software community. And they're now announcing the results: [W]e concluded there were five papers that would be best suited to inform the community and foster critical conversations to help guide our actions in the search for solutions.... The papers contain opinions with which the Free Software Foundation (FSF) may or may not agree, and any views expressed by the authors do not necessarily represent the FSF. They were selected because we thought they advanced discussion of important questions, and did so clearly....
The five papers are:

• Copilot, copying, commons, community, culture

• Copyright implications of the use of code repositories to train a machine learning model

• If software is my copilot, who programmed my software?

• Interpreting docstrings without common sense

• On the nature of AI code copilots

The FSF adds:

"If this subject is of interest to you, we recommend you read this selection of papers and share your thoughts and feedback. Several of the authors have agreed to participate in follow-up discussions which will be held via IRC, LibrePlanet Wiki, and LibrePlanet Discuss mailing list.... Whether or not you are able to attend any of the live events, we encourage you to contribute to the discussion on the wiki and mailing list. As stakeholders in free software, the preservation of user freedom and copyleft, we would like to engage the community in any possible actions that must be taken."

The creator of Apple's Swift programming language stayed involved in the Swift core team and Evolution community... until this week. Though he'd left Apple more than five years ago, "Swift is important to me, so I've been happy to spend a significant amount of time to help improve and steer it," Lattner wrote in an explanatory comment on the Swift community forum. "This included the ~weekly core team meetings (initially in person, then over WebEx)..."

The tech news site DevClass notes Lattner is also "the mind behind compiler infrastructure project LLVM," but reports that "Apparently, Lattner hasn't been part of the [Swift] core team since autumn 2021, when he tried discussing what he perceived as a toxic meeting environment with project leadership after an especially noteworthy call made him take a break in summer." "[...] after avoiding dealing with it, they made excuses, and made it clear they weren't planning to do anything about it. As such, I decided not to return," Lattner wrote in his explanation post. Back then, he planned to keep participating via the Swift Evolution community "but after several discussions generating more heat than light, when my formal proposal review comments and concerns were ignored by the unilateral accepts, and the general challenges with transparency working with core team, I decided that my effort was triggering the same friction with the same people, and thus I was just wasting my time."

Lattner had been the steering force behind Swift since the language's inception in 2010. However, after leaving Apple in 2017 and handing over his project lead role, design premises like "single things that compose" seem to have fallen by the wayside, making the decision to move on completely easier for language-creator Lattner.
The article points out Lattner's latest endeavour is AI infrastructure company Modular.AI.

And Lattner wrote in his comment that Swift's leadership "reassures me they 'want to make sure things are better for others in the future based on what we talked about' though...." Swift has a ton of well meaning and super talented people involved in and driving it. They are trying to be doing the best they can with a complicated situation and many pressures (including lofty goals, fixed schedules, deep bug queues to clear, internal folks that want to review/design things before the public has access to them, and pressures outside their team) that induce odd interactions with the community. By the time things get out to us, the plans are already very far along and sometimes the individuals are attached to the designs they've put a lot of energy into. This leads to a challenging dynamic for everyone involved.

I think that Swift is a phenomenal language and has a long and successful future ahead, but it certainly isn't a community designed language, and this isn't ambiguous. The new ideas on how to improve things sounds promising — I hope they address the fundamental incentive system challenges that the engineers/leaders face that cause the symptoms we see. I think that a healthy and inclusive community will continue to benefit the design and evolution of Swift.
DevClass also reported on the aftermath: Probably as a consequence of the move, the Swift core team is currently looking to restructure project leadership. According to Swift project lead Ted Kremenek... "The intent is to free the core team to invest more in overall project stewardship and create a larger language workgroup that can incorporate more community members in language decisions."

Kremenek also used the announcement to thank Lattner for his leadership throughout the formative years of the project, writing "it has been one of the greatest privileges of my life to work with Chris on Swift."
In 2017 Chris Lattner answered questions from Slashdot's readers.

Respondents to the annual survey of the Rust community reported an uptick in weekly usage and challenges, writes InfoWorld: Among those surveyed who are using Rust, 81% were using the language on at least a weekly basis, compared to 72% in last year's survey. Of all Rust users, 75% said they are able to write production-ready code but 27% said it was at times a struggle to write useful, production-ready code.... While the survey pointed toward a growing, healthy community of "Rustaceans," it also found challenges. In particular, Rust users would like to see improvements in compile times, disk usage, debugging, and GUI development...

- For those who adopted Rust at work, 83% found it "challenging." But it was unclear how much of this was a Rust-specific issue or general challenges posed by adopting a new language. During adoption, only 13% of respondents believed the language was slowing their team down while 82% believed Rust helped their teams achieve their goals.

- Of the respondents using Rust, 59% use it at least occasionally at work and 23% use it for the majority of their coding. Last year, only 42% used Rust at work.
From the survey's results: After adoption, the costs seem to be justified: only 1% of respondents did not find the challenge worth it while 79% said it definitely was. When asked if their teams were likely to use Rust again in the future, 90% agreed. Finally, of respondents using Rust at work, 89% of respondents said their teams found it fun and enjoyable to program.

As for why respondents are using Rust at work, the top answer was that it allowed users "to build relatively correct and bug free software" with 96% of respondents agreeing with that statement. After correctness, performance (92%) was the next most popular choice. 89% of respondents agreed that they picked Rust at work because of Rust's much-discussed security properties.

Overall, Rust seems to be a language ready for the challenges of production, with only 3% of respondents saying that Rust was a "risky" choice for production use.
Thanks to Slashdot reader joshuark for submitting the story...

theodp writes: Tech-bankrolled nonprofit Code.org is inviting kids to join the Coldplay Dance Party, explaining in a Medium post that "we've teamed up with award-winning band Coldplay to launch a global campaign that celebrates music and computer science." Teachers and students are encouraged to "share your creations for Code.org and Coldplay to see!" on Twitter, Instagram, TikTok, and Facebook, although a footnote warns: "In most countries, use of social media is not permitted for underage students [Dance Party targets kindergarten thru high school students]. Do not post videos or photos of students without the permission of a parent or guardian." From the announcement: "Coldplay and Code.org believe in the power of computer science education for every student, in every classroom around the world. That's why we're teaming up to inspire students everywhere to code and dance [YouTube] -- let's celebrate the magic of computer science and music! Join the party by using Code.org's Dance Party activity to code your own choreography to Coldplay's "Higher Power." Get creative with classic moves, and have fun with new album-inspired visuals and dancer formations! Post or submit your creations for Coldplay and Code.org to see, and we'll share the best ones on social media [GitHub]. Plus, you'll get a chance to win tickets to see Coldplay on tour, or a chance for your classroom to video chat with the band." "This is a new creative way to continue introducing people to play with and dance around the practice of programming," Google AI Chief Jeff Dean tweeted to his 200K+ Twitter followers. "Since it launched in 2018 [in partnership with Amazon]," Code.org exclaimed in its Medium post, "Dance Party has engaged more than 5.7 million students!"

Linux programmers fixed bugs faster than anyone — in an average of just 25 days (improving from 32 days in 2019 to just 15 in 2021). That's the conclusion of Google's "Project Zero" security research team, which studied the speed of bug-fixing from January 2019 to December 2021.

ZDNet reports that Linux's competition "didn't do nearly as well." For instance, Apple, 69 days; Google, 44 days; and Mozilla, 46 days. Coming in at the bottom was Microsoft, 83 days, and Oracle, albeit with only a handful of security problems, with 109 days.

By Project Zero's count, others, which included primarily open-source organizations and companies such as Apache, Canonical, Github, and Kubernetes, came in with a respectable 44 days.

Generally, everyone's getting faster at fixing security bugs. In 2021, vendors took an average of 52 days to fix reported security vulnerabilities. Only three years ago the average was 80 days. In particular, the Project Zero crew noted that Microsoft, Apple, and Linux all significantly reduced their time to fix over the last two years.

As for mobile operating systems, Apple iOS with an average of 70 days is a nose better than Android with its 72 days. On the other hand, iOS had far more bugs, 72, than Android with its 10 problems.

Browsers problems are also being fixed at a faster pace. Chrome fixed its 40 problems with an average of just under 30 days. Mozilla Firefox, with a mere 8 security holes, patched them in an average of 37.8 days. Webkit, Apple's web browser engine, which is primarily used by Safari, has a much poorer track record. Webkit's programmers take an average of over 72 days to fix bugs.

A recent post on the AWS Open Source blog announced that AWS "is investing in the sustainability of Rust, a language we believe should be used to build sustainable and secure solutions."

It was written by the chair of the Rust foundation (and leader of AWS's Rust team) with a Principal Engineer at AWS, and reminds us that Rust "combines the performance and resource efficiency of systems programming languages like C with the memory safety of languages like Java."

But there's another reason they're promoting Rust: Worldwide, data centers consume about 200 terawatt hours per year. That's roughly 1% of all energy consumed on our planet... [C]loud and hyperscale data centers have been implementing huge energy efficiency improvements, and the migration to that cloud infrastructure has been keeping the total energy use of data centers in balance despite massive growth in storage and compute for more than a decade... [I]s the status quo good enough? Is keeping data center energy use to 1% of worldwide energy consumption adequate..? [Will] innovations in energy efficiency continue to keep pace with growth in storage and compute in the future? Given the explosion we know is coming in autonomous drones, delivery robots, and vehicles, and the incredible amount of data consumption, processing, and machine learning training and inference required to support those technologies, it seems unlikely that energy efficiency innovations will be able to keep pace with demand...

[J]ust like security, sustainability is a shared responsibility. AWS customers are responsible for energy efficient choices in storage policies, software design, and compute utilization, while AWS owns efficiencies in hardware, utilization features, and cooling systems.... In the same way that operational excellence, security, and reliability have been principles of traditional software design, sustainability must be a principle in modern software design. That's why AWS announced a sixth pillar for sustainability to the AWS Well-Architected Framework. What that looks like in practice is choices like relaxing service-level agreements for non-critical functions and prioritizing resource use efficiency. We can take advantage of virtualization and allow for longer device upgrade cycles. We can leverage caching and longer times-to-live whenever possible. We can classify our data and implement automated lifecycle policies that delete data as soon as possible. When we choose algorithms for cryptography and compression, we can include efficiency in our decision criteria.

Last, but not least, we can choose to implement our software in energy efficient programming languages.

There was a really interesting study a few years ago that looked at the correlation between energy consumption, performance, and memory use.... What the study did is implement 10 benchmark problems in 27 different programming languages and measure execution time, energy consumption, and peak memory use. C and Rust significantly outperformed other languages in energy efficiency. In fact, they were roughly 50% more efficient than Java and 98% more efficient than Python. It's not a surprise that C and Rust are more efficient than other languages. What is shocking is the magnitude of the difference. Broad adoption of C and Rust could reduce energy consumption of compute by 50% — even with a conservative estimate....

No one developer, service, or corporation can deliver substantial impact on sustainability. Adoption of Rust is like recycling; it only has impact if we all participate. To achieve broad adoption, we are going to have to grow the developer community.
That "interesting study" cited also found that both C and Rust execute faster than other programming languages, the blog post points out, so "when you choose to implement your software in Rust for the sustainability and security benefits, you also get the optimized performance of C."

And the post also notes Linus Torvalds' recent acknowledgement that while he really loves C, it can be like juggling chainsaws, with easily-overlooked and "not always logical" type interactions. (Torvalds then went on to call Rust "the first language I saw which looked like this might actually be a solution.")

The Rust Foundation is a non-profit partnership between Amazon Web Services (AWS), Google, Huawei, Microsoft, and Mozilla.