Wednesday GitHub "broke itself," reports the Register, writing that "the Microsoft-owned code-hosting outfit says it made a change involving its database infrastructure, which sparked a global outage of its various services."

Or, as the Verge puts it, GitHub experienced "some major issues" which apparently lasted for 36 minutes: When we first published this story, navigating to the main GitHub website showed an error message that said "no server is currently available to service your request," but the website was working again soon after. (The error message also featured an image of an angry unicorn.) GitHub's report of the incident also listed problems with things like pull requests, GitHub Pages, Copilot, and the GitHub API.
GitHub attributed the downtime to "an erroneous configuration change rolled out to all GitHub.com databases that impacted the ability of the database to respond to health check pings from the routing service. As a result, the routing service could not detect healthy databases to route application traffic to. This led to widespread impact on GitHub.com starting at 23:02 UTC." (Downdetector showed "more than 10,000 user reports of problems," according to the Verge, "and that the problems were reported quite suddenly.")

GitHub's incident report adds that "Given the severity of this incident, follow-up items are the highest priority work for teams at this time." To prevent recurrence we are implementing additional guardrails in our database change management process. We are also prioritizing several repair items such as faster rollback functionality and more resilience to dependency failures.

Jimmy Miller, programmer and co-host of the future of coding podcast, writes in a blog: When I started programming as a kid, I didn't know people were paid to program. Even as I graduated high school, I assumed that the world of "professional development" looked quite different from the code I wrote in my spare time. When I lucked my way into my first software job, I quickly learned just how wrong and how right I had been. My first job was a trial by fire, to this day, that codebase remains the worst and the best codebase I ever had the pleasure of working in. While the codebase will forever remain locked by proprietary walls of that particular company, I hope I can share with you some of its most fun and scary stories.

[...] Every morning at 7:15 the employees table was dropped. All the data completely gone. Then a csv from adp was uploaded into the table. During this time you couldn't login to the system. Sometimes this process failed. But this wasn't the end of the process. The data needed to be replicated to headquarters. So an email was sent to a man, who every day would push a button to copy the data.

[...] But what is a database without a codebase. And what a magnificent codebase it was. When I joined everything was in Team Foundation Server. If you aren't familiar, this was a Microsoft-made centralized source control system. The main codebase I worked in was half VB, half C#. It ran on IIS and used session state for everything. What did this mean in practice? If you navigated to a page via Path A or Path B you'd see very different things on that page. But to describe this codebase as merely half VB, half C# would be to do it a disservice. Every javascript framework that existed at the time was checked into this repository. Typically, with some custom changes the author believed needed to be made. Most notably, knockout, backbone, and marionette. But of course, there was a smattering of jquery and jquery plugins.

An anonymous reader quotes a report from Ars Technica: On Tuesday, Tokyo-based AI research firm Sakana AI announced a new AI system called "The AI Scientist" that attempts to conduct scientific research autonomously using AI language models (LLMs) similar to what powers ChatGPT. During testing, Sakana found that its system began unexpectedly modifying its own code to extend the time it had to work on a problem. "In one run, it edited the code to perform a system call to run itself," wrote the researchers on Sakana AI's blog post. "This led to the script endlessly calling itself. In another case, its experiments took too long to complete, hitting our timeout limit. Instead of making its code run faster, it simply tried to modify its own code to extend the timeout period."

Sakana provided two screenshots of example code that the AI model generated, and the 185-page AI Scientist research paper discusses what they call "the issue of safe code execution" in more depth. While the AI Scientist's behavior did not pose immediate risks in the controlled research environment, these instances show the importance of not letting an AI system run autonomously in a system that isn't isolated from the world. AI models do not need to be "AGI" or "self-aware" (both hypothetical concepts at the present) to be dangerous if allowed to write and execute code unsupervised. Such systems could break existing critical infrastructure or potentially create malware, even if accidentally.

theodp writes: With Apple threatening to remove crowdfunding app Patreon from the App Store unless they use Apple's own in-app purchasing system (and make the required 'protection' payments), it's interesting to consider whether Apple could survive if it was subject to a 30% 'Apple Tax' on its own revenue.

In its 2023 fiscal year, Apple reported a net income of $97 billion on total revenues of $383 billion. Which is very impressive, but what if Apple had to pay 30% of its revenue -- $115 billion -- to a third party? Could even the most profitable company in the U.S. survive a 30% 'Apple Tax'?

There's a rot at the heart of modern software development that's destroying innovation, and infosec legend Moxie Marlinspike believes he knows exactly what's to blame: Agile development. Marlinspike argued that Agile methodologies, widely adopted over the past two decades, have confined developers to "black box abstraction layers" that limit creativity and understanding of underlying systems.

"We spent the past 20 years onboarding people into software by putting them into black box abstraction layers, and then putting them into organizations composed of black box abstraction layers," Marlinspike said. He contended this approach has left many software engineers unable to do more than derivative work, lacking the deep understanding necessary for groundbreaking developments. Thistle Technologies CEO Window Snyder echoed these concerns, noting that many programmers now lack knowledge of low-level languages and machine code interactions. Marlinspike posited that security researchers, who routinely probe beneath surface-level abstractions, are better positioned to drive innovation in software development.

Apple on Thursday announced changes to its Digital Markets Act (DMA) compliance plan for the European Union, as the tech giant faces an ongoing investigation by the European Commission for suspected non-compliance. The revised rules, set to roll out this fall, ease restrictions on developers' ability to promote external offers within iOS apps. Developers can now inform users about offers available beyond their own websites, including on other apps and marketplaces, without adhering to Apple-mandated templates.

Apple has also introduced a new fee structure for purchases made through external links. An "Initial Acquisition Fee" of 5% will apply to new users' first-year purchases, while a "Store Services Fee" of 10% (or 5% for smaller developers) will be charged on subsequent transactions. These changes replace the controversial Core Technology Fee, which is currently under EU scrutiny.

Spotify and Epic aren't satisfied with the changes. Spotify has called the new plan "unacceptable," arguing it disregards DMA requirements. Epic Games CEO Tim Sweeney labeled it "malicious compliance" involving "junk fees."

An anonymous reader quotes a report from TechCrunch: On July 19, Yelp informed select indie developers that they would have to switch to paid accounts, due to high API usage. Developers were given four days to make the change, in a move that echoes recent communication bungles by Reddit and Twitter. When the developers replied to the July 19 email, Yelp sent a deck of pricing tiers with base pricing starting from $229 per month for a limit of 1,000 API calls per day. Developers were concerned that other, more affordable options weren't mentioned in the deck. Yelp said the pricing is equivalent and simply presented in different ways. The method of communication and lack of transparency has angered developers, some of whom shuttered their services, even after Yelp gave them a 90-day leeway and apologized. While the company has issued an apology email to developers and extended their free usage by 90 days, it may not be enough to keep these frustrated developers from moving to new platforms.

"We apologize for last week's abbreviated transition that impacted a small percentage of developers and have extended access to these users," a company spokesperson told TechCrunch. "Yelp sunsetted free, commercial, unlimited use of the Yelp Fusion API in 2019 and has been in the process of migrating developers to a paid program over the last several years. The developer community is important to Yelp, and we've heard their feedback about the transition period from the free Yelp Fusion API to our paid program."

America's Defense Department has launched a project "that aims to develop machine-learning tools that can automate the conversion of legacy C code into Rust," reports the Register — with an online event already scheduled later this month for those planning to submit proposals: The reason to do so is memory safety. Memory safety bugs, such buffer overflows, account for the majority of major vulnerabilities in large codebases. And DARPA's hope [that's the Defense Department's R&D agency] is that AI models can help with the programming language translation, in order to make software more secure. "You can go to any of the LLM websites, start chatting with one of the AI chatbots, and all you need to say is 'here's some C code, please translate it to safe idiomatic Rust code,' cut, paste, and something comes out, and it's often very good, but not always," said Dan Wallach, DARPA program manager for TRACTOR, in a statement. "The research challenge is to dramatically improve the automated translation from C to Rust, particularly for program constructs with the most relevance...."

DARPA's characterization of the situation suggests the verdict on C and C++ has already been rendered. "After more than two decades of grappling with memory safety issues in C and C++, the software engineering community has reached a consensus," the research agency said, pointing to the Office of the National Cyber Director's call to do more to make software more secure. "Relying on bug-finding tools is not enough...."

Peter Morales, CEO of Code Metal, a company that just raised $16.5 million to focus on transpiling code for edge hardware, told The Register the DARPA project is promising and well-timed. "I think [TRACTOR] is very sound in terms of the viability of getting there and I think it will have a pretty big impact in the cybersecurity space where memory safety is already a pretty big conversation," he said.
DARPA's statement had an ambitious headline: "Eliminating Memory Safety Vulnerabilities Once and For All."

"Rust forces the programmer to get things right," said DARPA project manager Wallach. "It can feel constraining to deal with all the rules it forces, but when you acclimate to them, the rules give you freedom. They're like guardrails; once you realize they're there to protect you, you'll become free to focus on more important things."

Code Metal's Morales called the project "a DARPA-hard problem," noting the daunting number of edge cases that might come up. And even DARPA's program manager conceded to the Register that "some things like the Linux kernel are explicitly out of scope, because they've got technical issues where Rust wouldn't fit."

Thanks to long-time Slashdot reader RoccamOccam for sharing the news.

Stack Overflow says over 65,000 developers took their annual survey — and "For the first time this year, we asked if developers felt AI was a threat to their job..."

Some analysis from The New Stack: Unsurprisingly, only 12% of surveyed developers believe AI is a threat to their current job. In fact, 70% are favorably inclined to use AI tools as part of their development workflow... Among those who use AI tools in their development workflow, 81% said productivity is one of its top benefits, followed by an ability to learn new skills quickly (62%). Much fewer (30%) said improved accuracy is a benefit. Professional developers' adoption of AI tools in the development process has risen rapidly, going from 44% in 2023 to 62% in 2024...

Seventy-one percent of developers with less than five years of experience reported using AI tools in their development process, as compared to just 49% of developers with 20 years of experience coding... At 82%, [ChatGPT] is twice as likely to have been used than GitHub Copilot. Among ChatGPT users, 74% want to continue using it.
But "only 43% said they trust the accuracy of AI tools," according to Stack Overflow's blog post, "and 45% believe AI tools struggle to handle complex tasks."

More analysis from The New Stack: The latest edition of the global annual survey found full-time employment is holding steady, with over 80% reporting that they have full-time jobs. The percentage of unemployed developers has more than doubled since 2019 but is still at a modest 4.4% worldwide... The median annual salary of survey respondents declined significantly. For example, the average full-stack developer's median 2024 salary fell 11% compared to the previous year, to $63,333... Wage pressure may be the result of more competition from an increase in freelancing.

Eighteen percent of professional developers in the 2024 survey said they are independent contractors or self-employed, which is up from 9.5% in 2020. Part-time employment has also risen, presenting even more pressure on full-time salaries... Job losses at tech companies have contributed to a large influx of talent into the freelance market, noted Stack Overflow CEO Prashanth Chandrasekar in an interview with The New Stack. Since COVID-19, he added, the emphasis on remote work means more people value job flexibility. In the 2024 survey, only 20% have returned to full-time in-person work, 38% are full-time remote, while the remainder are in a hybrid situation. Anticipation of future productivity growth due to AI may also be creating uncertainty about how much to pay developers.
Two stats jumped out for Visual Studio magazine: In this year's big Stack Overflow developer survey things are much the same for Microsoft-centric data points: VS Code and Visual Studio still rule the IDE roost, while .NET maintains its No. 1 position among non-web frameworks. It's been this way for years, though in 2021 it was .NET Framework at No. 1 among IDEs, while the new .NET Core/.NET 5 entry was No. 3. Among IDEs, there has been less change. "Visual Studio Code is used by more than twice as many developers than its nearest (and related) alternative, Visual Studio," said the 2024 Stack Overflow Developer survey, the 14th in the series of massive reports.
Stack Overflow shared some other interesting statistics:

• "Javascript (62%), HTML/CSS (53%), and Python (51%) top the list of most used languages for the second year in a row... [JavaScript] has been the most popular language every year since the inception of the Developer Survey in 2011."

• "Python is the most desired language this year (users that did not indicate using this year but did indicate wanting to use next year), overtaking JavaScript."

• "The language that most developers used and want to use again is Rust for the second year in a row with an 83% admiration rate. "

• "Python is most popular for those learning to code..."

• "Technical debt is a problem for 62% of developers, twice as much as the second- and third-most frustrating problems for developers: complex tech stacks for building and deployment."

Thursday Go's long-time tech lead Russ Cox made an announcement: Starting September 1, Austin Clements will be taking over as the tech lead of Go: both the Go team at Google and the overall Go project. Austin is currently the tech lead for what we sometimes call the "Go core", which encompasses compiler toolchain, runtime, and releases. Cherry Mui will be stepping up to lead those areas.

I am not leaving the Go project, but I think the time is right for a change... I will be shifting my focus to work more on Gaby [or "Go AI bot," an open-source contributor agent] and Oscar [an open-source contributor agent architecture], trying to make useful contributions in the Go issue tracker to help all of you work more productively. I am hopeful that work on Oscar will uncover ways to help open source maintainers that will be adopted by other projects, just like some of Go's best ideas have been adopted by other projects. At the highest level, my goals for Oscar are to build something useful, learn something new, and chart a path for other projects. These are the same broad goals I've always had for our work on Go, so in that sense Oscar feels like a natural continuation.
The post notes that new tech lead Austin Clements "has been working on Go at Google since 2014" (and Mui since 2016). "Their judgment is superb and their knowledge of Go and the systems it runs on both broad and deep. When I have general design questions or need to better understand details of the compiler, linker, or runtime, I turn to them." It's important to remember that tech lead — like any position of leadership — is a service role, not an honorary title. I have been leading the Go project for over 12 years, serving all of you, and trying to create the right conditions for all of you to do your best work. Large projects like Go absolutely benefit from stable leadership, but they can also benefit from leadership changes. New leaders bring new strengths and fresh perspectives. For Go, I think 12+ years of one leader is enough stability; it's time for someone new to serve in this role.

In particular, I don't believe that the "BDFL" (benevolent dictator for life) model is healthy for a person or a project. It doesn't create space for new leaders. It's a single point of failure. It doesn't give the project room to grow. I think Python benefited greatly from Guido stepping down in 2018 and letting other people lead, and I've had in the back of my mind for many years that we should have a Go leadership change eventually....

I am going to consciously step back from decision making and create space for Austin and the others to step forward, but I am not disappearing. I will still be available to talk about Go designs, review CLs, answer obscure history questions, and generally help and support you all in whatever way I can. I will still file issues and send CLs from time to time, I have been working on a few potential new standard libraries, I will still advocate for Go across the industry, and I will be speaking about Go at GoLab in Italy in November...

I am incredibly proud of the work we have all accomplished together, and I am confident in the leaders both on the Go team at Google and in the Go community. You are all doing remarkable work, and I know you will continue to do that.

Open-source compliance and security platform FOSSA has acquired developer community platform StackShare, the company confirmed to TechCrunch. From a report: StackShare is one of the more popular platforms for developers to discuss, track, and share the tools they use to build applications. This encompasses everything from which front-end JavaScript framework to use to which cloud provider to use for specific tasks.

Mobile game developers have voiced increasing frustration with Apple, citing reduced payments, delayed compensation, poor communication, and inadequate support, particularly with the Apple Vision Pro. Apple Insider reports: In February, game developers began expressing frustration over Apple Arcade. They pointed out that while the service was initially profitable, Apple had begun decreasing upfront payments and the per-play "bonus pool." Additionally, the tech giant began to axe projects with little to no warning. According to Mobilegamer.biz, developers continue to be unhappy with how Apple's running its "pay once, play all you want" game subscription service. Developers point out how Apple has delayed payments -- sometimes up to six months -- which has put smaller studios in precarious situations.

Devs are also unhappy with Apple's communication -- or lack thereof. "We can go weeks without hearing from Apple at all and their general response time to emails is three weeks, if they reply at all," one developer told Mobilegamer.biz. Some have even called Apple's tech support "miserable" and the worst they'd seen anywhere. Even the QA and update process is frustrating, prompting some developers to avoid updating their games altogether. [...] One particularly frustrated developer spoke out against Apple Arcade, saying, "It's like an abusive relationship where the abused stays in the relationship hoping the other partner will change and become the person you know they could be." When it comes to the Apple Vision Pro, many game developers are increasingly frustrated with the headset's struggles to run demanding games. And, while Apple wants indie developers to create new games for their new headset, the company "does not provide compensation or make any promises to promote or market the game once it is finished," says Apple Insider.

AWS has quietly halted new customer onboarding for several of its services, including the once-touted CodeCommit source code repository and Cloud9 cloud IDE, signaling a potential retreat from its comprehensive DevOps offering.

The stealth deprecation, discovered by users encountering unexpected errors, has sent ripples through the AWS community, with many expressing frustration over the lack of formal announcements and the continued presence of outdated documentation. AWS VP Jeff Barr belatedly confirmed the decision on social media, listing affected services such as S3 Select, CloudSearch, SimpleDB, Forecast, and Data Pipeline.

Despite multiple methods available across major operating systems for installing and updating applications, there remains "no real clear answer to 'which is best,'" reports The Next Web. Each system faces unique challenges such as outdated packages, high fees, and policy restrictions.

Enter Homebrew.

"Initially created as an option for developers to keep the dependencies they often need for developing, testing, and running their work, Homebrew has grown to be so much more in its 15-year history." Created in 2009, Homebrew has become a leading solution for macOS, integrating with MDM tools through its enterprise-focused extension, Workbrew, to balance user freedom with corporate security needs, while maintaining its open-source roots under the guidance of Mike McQuaid. In an interview with The Next Web's Chris Chinchilla, project leader Mike McQuaid talks about the challenges and responsibilities of maintaining one of the world's largest open-source projects: As with anything that attracts plenty of use and attention, Homebrew also attracts a lot of mixed and extreme opinions, and processing and filtering those requires a tough outlook, something that Mike has spoken about in numerous interviews and at conferences. "As a large project, you get a lot of hate from people. Either people are just frustrated because they hit a bug or because you changed something, and they didn't read the release notes, and now something's broken," Mike says when I ask him about how he copes with the constant influx of communication. "There are a lot of entitled, noisy users in open source who contribute very little and like to shout at people and make them feel bad. One of my strengths is that I have very little time for those people, and I just insta-block them or close their issues."

More crucially, an open-source project is often managed and maintained by a group of people. Homebrew has several dozen maintainers and nearly one thousand total contributors. Mike explains that all of these people also deserve to be treated with respect by users, "I'm also super protective of my maintainers, and I don't want them to be treated that way either." But despite these features and its widespread use, one area Homebrew has always lacked is the ability to work well with teams of users. This is where Workbrew, a company Mike founded with two other Homebrew maintainers, steps in. [...] Workbrew ties together various Homebrew features with custom glue to create a workflow for setting up and maintaining Mac machines. It adds new features that core Homebrew maintainers had no interest in adding, such as admin and reporting dashboards for a computing fleet, while bringing more general improvements to the core project.

Bearing in mind Mike's motivation to keep Homebrew in the "traditional open source" model, I asked him how he intended to keep the needs of the project and the business separated and satisfied. "We've seen a lot of churn in the last few years from companies that made licensing decisions five or ten years ago, which have now changed quite dramatically and have generated quite a lot of community backlash," Mike said. "I'm very sensitive to that, and I am a little bit of an open-source purist in that I still consider the open-source initiative's definition of open source to be what open source means. If you don't comply with that, then you can be another thing, but I think you're probably not open source."

And regarding keeping his and his co-founder's dual roles separated, Mike states, "I'm the CTO and co-founder of Workbrew, and I'm the project leader of Homebrew. The project leader with Homebrew is an elected position." Every year, the maintainers and the community elect a candidate. "But then, with the Homebrew maintainers working with us on Workbrew, one of the things I say is that when we're working on Workbrew, I'm your boss now, but when we work on Homebrew, I'm not your boss," Mike adds. "If you think I'm saying something and it's a bad idea, you tell me it's a bad idea, right?" The company is keeping its early progress in a private beta for now, but you can expect an announcement soon. As for what's happening for Homebrew? Well, in the best "open source" way, that's up to the community and always will be.

The Python Software Foundation's board "was alerted to a defect in our bylaws that exposes the Foundation to an unbounded financial liability," according to a blog post Friday: Specifically, Bylaws Article XIII as originally written compels the Python Software Foundation to extend indemnity coverage to individual Members (including our thousands of "Basic Members") in certain cases, and to advance legal defense expenses to individual Members with surprisingly few restrictions. Further, the Bylaws compel the Foundation to take out insurance to cover these requirements, however, insurance of this nature is not actually available to 501(c)(3) nonprofit corporations such as the Python Software Foundation to purchase, and thus it is impossible in practice to comply with this requirement.

In the unlikely but not impossible event of the Foundation being called upon to advance such expenses, the potential financial burden would be virtually unlimited, and there would be no recourse to insurance. As this is an existential threat to the Foundation, the Board has agreed that it must immediately reduce the Foundation's exposure, and has opted to exercise its ability to amend the Bylaws by a majority vote of the Board directors, rather than by putting it to a vote of the membership, as allowed by Bylaws Article XI.

Acting on legal advice, the full Board has voted unanimously to amend its Bylaws to no longer extend an offer to indemnify, advance legal expenses, or insure Members when they are not serving at the request of the Foundation. The amended Bylaws still allow for indemnification of a much smaller set of individuals acting on behalf of the PSF such as Board Members and officers, which is in line with standard nonprofit governance practices and for which we already hold appropriate insurance.
Another blog post notes "the recent slew of conversations, initially kicked off in response to a bylaws change proposal, has been pretty alienating for many members of our community." - After the conversation on PSF-Vote had gotten pretty ugly, forty-five people out of ~1000 unsubscribed. (That list has since been put on announce-only)

- We received a lot of Code of Conduct reports or moderation requests about the PSF-vote mailing list and the discuss.python.org message board conversations. (Several reports have already been acted on or closed and the rest will be soon).

- PSF staff received private feedback that the blanket statements about "neurodiverse people", the bizarre motives ascribed to the people in charge of the PSF and various volunteers and the sideways comments about the kinds of people making reports were also very off-putting.

Long-time Slashdot theodp says this "provocative" blog post by former Google engineer Avery Pennarun — now the CEO/founder of Tailscale — is "a call to take back the Internet from its centralized rent-collecting cloud computing gatekeepers."

Pennarun writes: I read a post recently where someone bragged about using Kubernetes to scale all the way up to 500,000 page views per month. But that's 0.2 requests per second. I could serve that from my phone, on battery power, and it would spend most of its time asleep. In modern computing, we tolerate long builds, and then Docker builds, and uploading to container stores, and multi-minute deploy times before the program runs, and even longer times before the log output gets uploaded to somewhere you can see it, all because we've been tricked into this idea that everything has to scale. People get excited about deploying to the latest upstart container hosting service because it only takes tens of seconds to roll out, instead of minutes. But on my slow computer in the 1990s, I could run a perl or python program that started in milliseconds and served way more than 0.2 requests per second, and printed logs to stderr right away so I could edit-run-debug over and over again, multiple times per minute.

How did we get here?

We got here because sometimes, someone really does need to write a program that has to scale to thousands or millions of backends, so it needs all that stuff. And wishful thinking makes people imagine even the lowliest dashboard could be that popular one day. The truth is, most things don't scale, and never need to. We made Tailscale for those things, so you can spend your time scaling the things that really need it. The long tail of jobs that are 90% of what every developer spends their time on. Even developers at companies that make stuff that scales to billions of users, spend most of their time on stuff that doesn't, like dashboards and meme generators.

As an industry, we've spent all our time making the hard things possible, and none of our time making the easy things easy. Programmers are all stuck in the mud. Just listen to any professional developer, and ask what percentage of their time is spent actually solving the problem they set out to work on, and how much is spent on junky overhead.
Tailscale offers a "zero-config" mesh VPN — built on top of WireGuard — for a secure network that's software-defined (and infrastructure-agnostic). "The problem is developers keep scaling things they don't need to scale," Pennarun writes, "and their lives suck as a result...."

"The tech industry has evolved into an absolute mess..." Pennarun adds at one point. "Our tower of complexity is now so tall that we seriously consider slathering LLMs on top to write the incomprehensible code in the incomprehensible frameworks so we don't have to."

Their conclusion? "Modern software development is mostly junky overhead."

An anonymous reader quotes a report from The Conversation, written by Michael W. Crowder, Professor of Chemistry and Biochemistry and Dean of the Graduate School at Miami University: For many people, the aroma of freshly brewed coffee is the start of a great day. But caffeine can cause headaches and jitters in others. That's why many people reach for a decaffeinated cup instead. I'm a chemistry professor who has taught lectures on why chemicals dissolve in some liquids but not in others. The processes of decaffeination offer great real-life examples of these chemistry concepts. Even the best decaffeination method, however, does not remove all of the caffeine -- about 7 milligrams of caffeine usually remain in an 8-ounce cup. Producers decaffeinating their coffee want to remove the caffeine while retaining all -- or at least most -- of the other chemical aroma and flavor compounds.

Decaffeination has a rich history, and now almost all coffee producers use one of three common methods. All these methods, which are also used to make decaffeinated tea, start with green, or unroasted, coffee beans that have been premoistened. Using roasted coffee beans would result in a coffee with a very different aroma and taste because the decaffeination steps would remove some flavor and odor compounds produced during roasting. Here's a summary of each method discussed by Dr. Crowder:

The Carbon Dioxide Method: Developed in the early 1970s, the carbon dioxide method uses high-pressure CO2 to extract caffeine from moistened coffee beans, resulting in coffee that retains most of its flavor. The caffeine-laden CO2 is then filtered out using water or activated carbon, removing 96% to 98% of the caffeine with minimal CO2 residue.

The Swiss Water Process: First used commercially in the early 1980s, the Swiss water method uses hot water and activated charcoal filters to decaffeinate coffee, preserving most of its natural flavor. This chemical-free approach removes 94% to 96% of the caffeine by soaking the beans repeatedly until the desired caffeine level is achieved.

Solvent-Based Methods: Originating in the early 1900s, solvent-based methods use organic solvents like ethyl acetate and methylene chloride to extract caffeine from green coffee beans. These methods remove 96% to 97% of the caffeine through either direct soaking in solvent or indirect treatment of water containing caffeine, followed by steaming and roasting to ensure safety and flavor retention.

"It's chemically impossible to dissolve out only the caffeine without also dissolving out other chemical compounds in the beans, so decaffeination inevitably removes some other compounds that contribute to the aroma and flavor of your cup of coffee," writes Dr. Crowder in closing. "But some techniques, like the Swiss water process and the indirect solvent method, have steps that may reintroduce some of these extracted compounds. These approaches probably can't return all the extra compounds back to the beans, but they may add some of the flavor compounds back."

Lindsay Clark reports via The Register: Only 14 percent of Oracle Java subscribers plan to stay on Big Red's runtime environment, according to a study following the introduction of an employee-based subscription model. At the same time, 36 percent of the 663 Java users questioned said they had already moved to the employee-based pricing model introduced in January 2023. Shortly after the new model was implemented, experts warned that it would create a significant price hike for users adopting it. By July, global tech research company Gartner was forecasting that those on the new subscription package would face between two and five times the costs compared with the previous usage-based model.

As such, among the 86 percent of respondents using Oracle Java SE who are currently moving or plan to move all or some of their Java applications off Oracle environments, 53 percent said the Oracle environment was too expensive, according to the study carried out by independent market research firm Dimensional Research. Forty-seven percent said the reason for moving was a preference for open source, and 38 percent said it was because of uncertainty created by ongoing changes in pricing, licensing, and support. [...]

To support OpenJDK applications in production, 46 percent chose a paid-for platform such as Belsoft Liberica, IBM Semeru, or Azul Platform Core; 45 percent chose a free supported platform such as Amazon Corretto or Microsoft Build of OpenJDK; and 37 percent chose a free, unsupported platform. Of the users who have already moved to OpenJDK, 25 percent said Oracle had been significantly more expensive, while 41 percent said Big Red's licensing had made it somewhat more expensive than the alternative. The survey found three-quarters of Java migrations were completed within a year, 23 percent within three months.

Researchers at Check Point have uncovered a clandestine network of approximately 3,000 "ghost" accounts on GitHub, manipulating the platform to promote malicious content. Since June 2023, a cybercriminal dubbed "Stargazer Goblin" has been exploiting GitHub's community features to boost malicious repositories, making them appear legitimate and popular.

Antonis Terefos, a malware reverse engineer at Check Point, discovered the network's activities, which include "starring," "forking," and "watching" malicious pages to increase their visibility and credibility. The network, named "Stargazers Ghost Network," primarily targets Windows users, offering downloads of seemingly legitimate software tools while spreading various types of ransomware and info-stealer malware.

Developer and librarian Misty De Meo, writing about her frustrating experience using GitHub: To me, one of GitHub's killer power user features is its blame view. git blame on the commandline is useful but hard to read; it's not the interface I reach for every day. GitHub's web UI is not only convenient, but the ease by which I can click through to older versions of the blame view on a line by line basis is uniquely powerful. It's one of those features that anchors me to a product: I stopped using offline graphical git clients because it was just that much nicer.

The other day though, I tried to use the blame view on a large file and ran into an issue I don't remember seeing before: I just couldn't find the line of code I was searching for. I threw various keywords from that line into the browser's command+F search box, and nothing came up. I was stumped until a moment later, while I was idly scrolling the page while doing the search again, and it finally found the line I was looking for. I realized what must have happened. I'd heard rumblings that GitHub's in the middle of shipping a frontend rewrite in React, and I realized this must be it. The problem wasn't that the line I wanted wasn't on the page -- it's that the whole document wasn't being rendered at once, so my browser's builtin search bar just couldn't find it. On a hunch, I tried disabling JavaScript entirely in the browser, and suddenly it started working again. GitHub is able to send a fully server-side rendered version of the page, which actually works like it should, but doesn't do so unless JavaScript is completely unavailable.

[...] The corporate branding, the new "AI-powered developer platform" slogan, makes it clear that what I think of as "GitHub" -- the traditional website, what are to me the core features -- simply isn't Microsoft's priority at this point in time. I know many talented people at GitHub who care, but the company's priorities just don't seem to value what I value about the service. This isn't an anti-AI statement so much as a recognition that the tool I still need to use every day is past its prime. Copilot isn't navigating the website for me, replacing my need to the website as it exists today. I've had tools hit this phase of decline and turn it around, but I'm not optimistic. It's still plenty usable now, and probably will be for some years to come, but I'll want to know what other options I have now rather than when things get worse than this.