Apple rolled out a software update Wednesday to address an overheating issue that plagued some early buyers of the iPhone 15 Pro line. From a report: The update, called iOS 17.0.3, is available as an over-the-air fix in the software update section of the iPhone settings app. The release notes say the update "provides important bug fixes, security updates, and addresses an issue that may cause iPhone to run warmer than expected." The update was also released for older iPhones as well as iPads. Some early iPhone 15 Pro owners reported that their iPhone could get hotter than normal. Apple on Saturday blamed bad code in apps including Uber, Instagram and the Asphalt 9 racing game, in addition to a bug in the device's software. The company said the new device set-up could overwork the processor and lead to overheating.

An anonymous reader shared this report from CNBC: Apple said on Saturday that it will issue a software update that would address customer complaints about the latest iPhone 15 models, released just over a week ago, running hot.

Apple said that the new iPhone models were running hot because of a combination of bugs in iOS 17, bugs in apps, and a temporary set-up period... After Apple released the new iPhone 15 models earlier this month, user complaints on Apple's forums, Reddit, and social media suggest that all four models can get hotter than expected during use. CNBC's review of the new iPhone Pros also noted the iPhone 15 Pro Max got hot. "I just got the iPhone 15 Pro today and it's so hot i can't even hold it for very long!" wrote one commenter on Apple's forums.

Apple's new high-end models, the $999 iPhone 15 Pro and $1,199 iPhone 15 Pro Max have a redesigned titanium enclosure with an aluminum frame to make them easier to repair. The problem with the new models overheating was not related to the titanium chassis design, Apple said. Instead, Apple points to bugs with specific apps and a bug in iOS that can be fixed with software updates.

Kyle Orland writes via Ars Technica: The "first official Unity user group in the world" has announced that it is dissolving after 13 years because "the trust we used to have in the company has been completely eroded." The move comes as many developers are saying they will continue to stay away from the company's products even after last week's partial rollback of some of the most controversial parts of its fee structure plans.

Since its founding in 2010, the Boston Unity Group (BUG) has attracted thousands of members to regular gatherings, talks, and networking events, including many technical lectures archived on YouTube. But the group says it will be hosting its last meeting Wednesday evening via Zoom because the Unity of today is very different from the Dave Helgason-led company that BUG says "enthusiastically sanctioned and supported" the group at its founding.

"Over the past few years, Unity has unfortunately shifted its focus away from the games industry and away from supporting developer communities," the group leadership wrote in a departure note. "Following the IPO, the company has seemingly put profit over all else, with several acquisitions and layoffs of core personnel. Many key systems that developers need are still left in a confusing and often incomplete state, with the messaging that advertising and revenue matter more to Unity than the functionality game developers care about."

BUG says the install-fee terms Unity first announced earlier this month were "unthinkably hostile" to users and that even the "new concessions" in an updated pricing model offered late last week "disproportionately affect the success of indie studios in our community." But it's the fact that such "resounding, unequivocal condemnation from the games industry" was necessary to get those changes in the first place that has really shaken the community to its core. "We've seen how easily and flippantly an executive-led business decision can risk bankrupting the studios we've worked so hard to build, threaten our livelihoods as professionals, and challenge the longevity of our industry," BUG wrote. "The Unity of today isn't the same company that it was when the group was founded, and the trust we used to have in the company has been completely eroded."

An exploit for a bug in Windows appears to increase the performance of File Explorer in Microsoft's flagship operating system. From a report: Spotted over the weekend by Xitter user @VivyVCCS, the hack is triggered by a swift jab of the F11 key to switch File Explorer in and out of full-screen mode. According to the post, load performance is improved markedly.

Slash_Account_Dot writes: Hackers are able to grab a target's IP address, potentially revealing their general physical location, by simply sending a link over the Skype mobile app. The target does not need to click the link or otherwise interact with the hacker beyond opening the message, according to a security researcher who demonstrated the issue and successfully discovered my IP address by using it. Yossi, the independent security researcher who uncovered the vulnerability, reported the issue to Microsoft earlier this month, according to Yossi and a cache of emails and bug reports he shared with 404 Media. In those emails Microsoft said the issue does not require immediate servicing, and gave no indication that it plans to fix the security hole. Only after 404 Media contacted Microsoft for comment did the company say it would patch the issue in an upcoming update.

This month the official Rust blog announced: For the 6th year in a row, the Rust Project conducted a survey on the Rust programming language, with participation from project maintainers, contributors, and those generally interested in the future of Rust. This edition of the annual State of Rust Survey opened for submissions on December 5 and ran until December 22, 2022... [W]e had 9,433 total survey completions and an increased survey completion rate of 82% vs. 76% in 2021...

- More people are using Rust than ever before! Over 90% of survey respondents identified as Rust users, and of those using Rust, 47% do so on a daily basis — an increase of 4% from the previous year.

- 30% of Rust user respondents can write simple programs in Rust, 27% can write production-ready code, and 42% consider themselves productive using Rust. Of the former Rust users who completed the survey, 30% cited difficulty as the primary reason for giving up while nearly 47% cited factors outside of their control.

- The growing maturation of Rust can be seen through the increased number of different organizations utilizing the language in 2022. In fact, 29.7% of respondents stated that they use Rust for the majority of their coding work at their workplace, which is a 51.8% increase compared to the previous year.

- There are numerous reasons why we are seeing increased use of Rust in professional environments. Top reasons cited for the use of Rust include the perceived ability to write "bug-free software" (86%), Rust's performance characteristics (84%), and Rust's security and safety guarantees (69%). We were also pleased to find that 76% of respondents continue to use Rust simply because they found it fun and enjoyable. (Respondents could select more than one option here, so the numbers don't add up to 100%.)

- Of those respondents that used Rust at work, 72% reported that it helped their team achieve its goals (a 4% increase from the previous year) and 75% have plans to continue using it on their teams in the future.

- But like any language being applied in the workplace, Rust's learning curve is an important consideration; 39% of respondents using Rust in a professional capacity reported the process as "challenging" and 9% of respondents said that adopting Rust at work has "slowed down their team". However, 60% of productive users felt Rust was worth the cost of adoption overall...

- Of those respondents who shared their main worries for the future of Rust, 26% have concerns that the developers and maintainers behind Rust are not properly supported — a decrease of more than 30% from the previous year's findings. One area of focus in the future may be to see how the Project in conjunction with the Rust Foundation can continue to push that number towards 0%.

- While 38% have concerns about Rust "becoming too complex", only a small number of respondents were concerned about documentation, corporate oversight, or speed of evolution. 34% of respondents are not worried about the future of Rust at all.

This year's survey reflects a 21% decrease in fears about Rust's usage in the industry since the last survey.

Yes, Red Hat Enterprise Linux changed its licensing last month — but how will that affect AlmaLinux? The chair of the nonprofit AlmaLinux OS Foundation, benny Vasquez, tells SiliconANGLE that "For typical users, there's very, very little difference. Overall, we're still exactly the same way we were, except for kernel updates." Updates may no longer be available the day a new version of RHEL comes out, but developers still have access to Red Hat's planned enhancements and bug fixes via CentOS Stream, a version of RHEL that Red Hat uses as essentially a test bed for new features that might later be incorporated into its flagship product. From a practical perspective, that's nearly as good as having access to the production source code, Vasquez said. "While there is a generally accepted understanding that not everything in CentOS Stream will end up in RHEL, that's not how it works in practice," she said. "I can't think of anything they have shipped in RHEL that wasn't in Stream first."

That's still no guarantee, but the workarounds AlmaLinux has put in place over the past month should address all but the most outlier cases, Vasquez said. The strategy has shifted from bug-for-bug compatibility to being application binary interface-compatible... ABI compatibility doesn't guarantee that problems will never occur, but glitches should be rare and can usually be resolved by recompiling the source code. "It is sufficient for us to be ABI-compatible with RHEL," Vasquez said. "The most important thing is that this allows our community to feel stability."

In fact, Red Hat's change of direction has been a blessing in disguise for AlmaLinux, she said... "We view this as a release from our bonds of being one-to-one." Patches can be applied without waiting for a cue from Red Hat and "we get to engage with our community in a completely new and exciting way." AlmaLinux has also seen a modest financial windfall from Red Hat's decision. "The outpouring of support has been pretty impressive," Vasquez said. "People have shown up for event staffing and website maintenance and infrastructure management and we've gotten more financial backing from corporations."
Vasquez also told the site that "the number of everyday people throwing in $5 has more than quadrupled."

"Teams across Google are working hard to prepare the web for the migration to quantum-resistant cryptography," writes Chrome's technical program manager for security, Devon O'Brien.

"Continuing with our strategy for handling this major transition, we are updating technical standards, testing and deploying new quantum-resistant algorithms, and working with the broader ecosystem to help ensure this effort is a success." As a step down this path, Chrome will begin supporting X25519Kyber768 for establishing symmetric secrets in TLS, starting in Chrome 116, and available behind a flag in Chrome 115. This hybrid mechanism combines the output of two cryptographic algorithms to create the session key used to encrypt the bulk of the TLS connection:

X25519 — an elliptic curve algorithm widely used for key agreement in TLS today
Kyber-768 — a quantum-resistant Key Encapsulation Method, and NIST's PQC winner for general encryption

In order to identify ecosystem incompatibilities with this change, we are rolling this out to Chrome and to Google servers, over both TCP and QUIC and monitoring for possible compatibility issues. Chrome may also use this updated key agreement when connecting to third-party server operators, such as Cloudflare, as they add support. If you are a developer or administrator experiencing an issue that you believe is caused by this change, please file a bug.
The Register delves into Chrome's reasons for implementing this now: "It's believed that quantum computers that can break modern classical cryptography won't arrive for 5, 10, possibly even 50 years from now, so why is it important to start protecting traffic today?" said O'Brien. "The answer is that certain uses of cryptography are vulnerable to a type of attack called Harvest Now, Decrypt Later, in which data is collected and stored today and later decrypted once cryptanalysis improves." O'Brien says that while symmetric encryption algorithms used to defend data traveling on networks are considered safe from quantum cryptanalysis, the way the keys get negotiated is not. By adding support for a hybrid KEM, Chrome should provide a stronger defense against future quantum attacks...

Rebecca Krauthamer, co-founder and chief product officer at QuSecure, told The Register in an email that while this technology sounds futuristic, it's useful and necessary today... [T]he arrival of capable quantum computers should not be thought of as a specific, looming date, but as something that will arrive without warning. "There was no press release when the team at Bletchley Park cracked the Enigma code, either," she said.

Google announced today that Chrome is now adopting weekly Stable channel updates in an effort to block major exploits quicker. 9to5Google reports: Google's browser gets major "milestone" updates every four (previously six) weeks, like going from version 100 to 101. In the past, Chrome would get a "Stable Refresh" update to "address security and other high impact bugs" in-between milestones every two weeks. This is now changing to occur weekly between milestones, starting with Google Chrome 116 on desktop and mobile, so that security updates get to end users much faster. Since Chromium is an open source project, "anyone can view the source code, submit changes for review, and see the changes made by anyone else, even security bug fixes." [...]

The current patch gap is around 15 days. It was previously 35 days before switching to patch updates every two weeks in 2020. Google expects weekly patch updates to result in security fixes shipping "3.5 days sooner on average, greatly reducing the already small window for n-day attackers to develop and use an exploit against potential victims and making their lives much more difficult." This new schedule will also result in fewer unplanned updates that occur when there are known in-the-wild exploits: "By now shipping stable updates weekly, we expect the number of unplanned updates to decrease since we'll be shipping updates more frequently."

In February of 1994 Jon "maddog" Hall interviewed a young Linus Torvalds (then just 24). Nearly three decades later — as Hall approaches his 73rd birthday — he's shared a long essay looking back, but also assessing today's controversy about Red Hat's licensing of RHEL. A (slightly- condensed] excerpt: [O]ver time some customers developed a pattern of purchasing a small number of RHEL systems, then using the "bug-for-bug" compatible version of Red Hat from some other distribution. This, of course, saved the customer money, however it also reduced the amount of revenue that Red Hat received for the same amount of work. This forced Red Hat to charge more for each license they sold, or lay off Red Hat employees, or not do projects they might have otherwise funded. So recently Red Hat/IBM made a business decision to limit their customers to those who would buy a license from them for every single system that would run RHEL and only distribute their source-code and the information necessary on how to build that distribution to those customers. Therefore the people who receive those binaries would receive the sources so they could fix bugs and extend the operating system as they wished.....this was, and is, the essence of the GPL.

Most, if not all, of the articles I have read have said something along the lines of "IBM/Red Hat seem to be following the GPL..but...but...but... the community! "

Which community? There are plenty of distributions for people who do not need the same level of engineering and support that IBM and Red Hat offer. Red Hat, and IBM, continue to send their changes for GPLed code "upstream" to flow down to all the other distributions. They continue to share ideas with the larger community. [...]

I now see a lot of people coming out of the woodwork and beating their breasts and saying how they are going to protect the investment of people who want to use RHEL for free [...] So far I have seen four different distributions saying that they will continue the production of "not RHEL", generating even more distributions for the average user to say "which one should I use"? If they really want to do this, why not just work together to produce one good one? Why not make their own distributions a RHEL competitor? How long will they keep beating their breasts when they find out that they can not make any money at doing it? SuSE said that they would invest ten million dollars in developing a competitor to RHEL. Fantastic! COMPETE. Create an enterprise competitor to Red Hat with the same business channels, world-wide support team, etc. etc. You will find it is not inexpensive to do that. Ten million may get you started.

My answer to all this? RHEL customers will have to decide what they want to do. I am sure that IBM and Red Hat hope that their customers will see the value of RHEL and the support that Red Hat/IBM and their channel partners provide for it. The rest of the customers who just want to buy one copy of RHEL and then run a "free" distribution on all their other systems no matter how it is created, well it seems that IBM does not want to do business with them anymore, so they will have to go to other suppliers who have enterprise capable distributions of Linux and who can tolerate that type of customer. [...]

I want to make sure people know that I do not have any hate for people and companies who set business conditions as long as they do not violate the licenses they are under. Business is business.

However I will point out that as "evil" as Red Hat and IBM have been portrayed in this business change there is no mention at all of all the companies that support Open Source "Permissive Licenses", which do not guarantee the sources to their end users, or offer only "Closed Source" Licenses....who do not allow and have never allowed clones to be made....these people and companies do not have any right to throw stones (and you know who you are).

Red Hat and IBM are making their sources available to all those who receive their binaries under contract. That is the GPL.

For all the researchers, students, hobbyists and people with little or no money, there are literally hundreds of distributions that they can choose, and many that run across other interesting architectures that RHEL does not even address.
Hall answered questions from Slashdot users in 2000 and again in 2013.

Further reading: Red Hat CEO Jim Whitehurst answering questions from Slashdot readers in 2017.

An anonymous reader quotes a report from Wired: Travel rewards programslike those offered by airlines and hotels tout the specific perks of joining their club over others. Under the hood, though, the digital infrastructure for many of these programs -- including Delta SkyMiles, United MileagePlus, Hilton Honors, and Marriott Bonvoy -- is built on the same platform. The backend comes from the loyalty commerce company Points and its suite of services, including an expansive application programming interface (API).But new findings, published today by a group of security researchers, show that vulnerabilities in the Points.com API could have been exploited to expose customer data, steal customers' "loyalty currency" (like miles), or even compromise Points global administration accounts to gain control of entire loyalty programs. The researchers -- Ian Carroll, Shubham Shah, and Sam Curry -- reported a series of vulnerabilities to Points between March and May, and all the bugs have since been fixed.

"The surprise for me was related to the fact that there is a central entity for loyalty and points systems, which almost every big brand in the world uses," Shah says. "From this point, it was clear to me that finding flaws in this system would have a cascading effect to every company utilizing their loyalty backend. I believe that once other hackers realized that targeting Points meant that they could potentially have unlimited points on loyalty systems, they would have also been successful in targeting Points.com eventually." One bug involved a manipulation that allowed the researchers to traverse from one part of the Points API infrastructure to another internal portion and then query it for reward program customer orders. The system included 22 million order records, which contain data like customer rewards account numbers, addresses, phone numbers, email addresses, and partial credit card numbers. Points.com had limits in place on how many responses the system could return at a time, meaning an attacker couldn't simply dump the whole data trove at once. But the researchers note that it would have been possible to look up specific individuals of interest or slowly siphon data from the system over time.

Another bug the researchers found was an API configuration issue that could have allowed an attacker to generate an account authorization token for any user with just their last name and rewards number. These two pieces of data could potentially be found through past breaches or could be taken by exploiting the first vulnerability. With this token, attackers could take over customer accounts and transfer miles or other rewards points to themselves, draining the victim's accounts. The researchers found two vulnerabilities similar to the other pair of bugs, one of which only impacted Virgin Red while the other affected just United MileagePlus. Points.com fixed both of these vulnerabilities as well. Most significantly, the researchers found a vulnerability in the Points.com global administration website in which an encrypted cookie assigned to each user had been encrypted with an easily guessable secret -- the word "secret" itself. By guessing this, the researchers could decrypt their cookie, reassign themselves global administrator privileges for the site, reencrypt the cookie, and essentially assume god-mode-like capabilities to access any Points reward system and even grant accounts unlimited miles or other benefits.

Long-time Slashdot reader SonicSpike shares a report from CNBC: On Tuesday, the Biden administration put the final nail in the coffin for incandescent light bulbs, the result of a decade-plus-long legislative path. The journey began in 2007 when the Energy Independence and Security Act passed. That law required the Department of Energy to evaluate whether efficiency standards for light bulbs needed to be set or amended and required a minimum standard of energy efficiency for light bulbs of 45 lumens per watt to be considered. The 2007 law required that if the DOE determined a new energy efficiency standard was necessary, it should go into effect by January 1, 2017. But politics intervened as the Trump administration appealed those rules.

The Biden administration picked the issue back up. And in April 2022, the Biden administration issued a rule requiring the minimum standard efficiency of 45 lumens per watt, which became effective in July. At that time, the Department of Energy said it would have a gradual transition to the new rule so that stores with inventory would not be stuck with light bulbs they could no longer sell. In Department of Energy lingo, this is called "progressive enforcement." Full enforcement of the ban for retailers took effect on Tuesday. The DOE does not disclose its techniques for enforcing these step-wise implementation of the rule. However, the agency's new regulations will be enforced in "a fair and equitable manner," and smaller retailers are advised to reach out to the DOE to speak about existing inventory they may still have on hand, a spokesperson told CNBC.

Enforcing the sale of the more energy-efficient light bulbs will save consumers nearly $3 billion per year on their utility bills, according to DOE estimates, and cut carbon emissions by 222 million metric tons over the next 30 years. That's about the quantity of emissions that 28 million homes generate in a year, the Department of Energy said. [...] Not all light bulbs are included in the ban. Exceptions include a whole slew of specific light bulb implications, including appliance lamps, black light lamps, bug lamps, colored lamps, general service fluorescent lamps, marine lamps, marine signal service lamps, mine service lamps, sliver bowl lamps, showcase lamps, and traffic signal lamp, to name a few.

An anonymous reader shares a report: When Microsoft releases new test builds of Windows, there are usually a handful of features that are announced but only actually enabled for a small subset of testers. Sometimes it's because the company is A/B testing a couple of different versions of the same thing or because Microsoft wants to roll out major changes to a few users before rolling them out to everyone. Users normally have little control over whether new features actually appear in their Windows beta installs, but Microsoft has internal software called StagingTool that its own developers can use to switch things on and off themselves.

And now StagingTool has leaked to the public, thanks to a "bug bash" the company is running this week to find and fix problems before the next big batch of new Windows features releases this fall. As reported by The Verge, some bug bash participants were sent on "quests" that explicitly mentioned using the StagingTool to turn on specific features. Those quests and the tool itself have since been removed from Microsoft's servers, but StagingTool is already being freely distributed among Windows enthusiasts who want more control over the features they see.

Apple's Screen Time controls are failing parents. From a report: The company's cloud-based Family Sharing system is designed in part for parents to remotely schedule off-limits time and restrict apps and adult content on their children's iPhones, iPads and iPod Touch models. Trouble is, parents are finding that when they use their iPhones to set restrictions on their kids' devices, the changes don't stick. "We are aware that some users may be experiencing an issue where Screen Time settings are unexpectedly reset," an Apple spokeswoman said. "We take these reports very seriously and we have been, and will continue, making updates to improve the situation."

Downtime, found in Settings under Screen Time, is the tool parents use to define the hours each day that a kid's device is limited or completely unusable. But when they check the setting lately, they often see the times they scheduled have reverted to a previous setting, or they see no restrictions at all. This can go unnoticed for days or weeks -- and kids don't always report back when they get extra time for games and social media. Apple previously acknowledged the bug, calling it "an issue where Screen Time settings may reset or not sync across all devices." However, the company had reported the issue fixed with iOS 16.5, which came out in May. In our testing the bug persists, even with the new public beta of iOS 17.

Monday a researcher with Google Information Security posted about a new vulnerability he independently found in AMD's Zen 2 processors. Tom's Hardware reports: The 'Zenbleed' vulnerability spans the entire Zen 2 product stack, including AMD's EPYC data center processors and the Ryzen 3000/4000/5000 CPUs, allowing the theft of protected information from the CPU, such as encryption keys and user logins. The attack does not require physical access to the computer or server and can even be executed via JavaScript on a webpage...

AMD added the AMD-SB-7008 Bulletin several hours later. AMD has patches ready for its EPYC 7002 'Rome' processors now, but it will not patch its consumer Zen 2 Ryzen 3000, 4000, and some 5000-series chips until November and December of this year... AMD hasn't given specific details of any performance impacts but did issue the following statement to Tom's Hardware: "Any performance impact will vary depending on workload and system configuration. AMD is not aware of any known exploit of the described vulnerability outside the research environment..."

AMD describes the exploit much more simply, saying, "Under specific microarchitectural circumstances, a register in "Zen 2" CPUs may not be written to 0 correctly. This may cause data from another process and/or thread to be stored in the YMM register, which may allow an attacker to potentially access sensitive information."
The article includes a list of the impacted processors with a schedule for the release of the updated firmware to OEMs.

The Google Information Security researcher who discovered the bug is sharing research on different CPU behaviors, and says the bug can be patched through software on multiple operating systems (e.g., "you can set the chicken bit DE_CFG[9]") — but this might result in a performance penalty.

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

After Red Hat's decision to only share RHEL source code with subscribers, AlmaLinux asked their bug report submitters to "attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place."

Red Hat told Ars Technica they are "eager to collaborate" on their CentOS Stream distro, "even if we ultimately compete in a business sense. Differentiated competition is a sign of a healthy ecosystem."

But Red Hat still managed to ruffled some feathers, reports ZDNet: AlmaLinux Infrastructure Team Leader Jonathan Wright recently posted a CentOS Stream fix for CVE-2023-38403, a memory overflow problem in iperf3. Iperf3 is a popular open-source network performance test. This security hole is an important one, but not a huge problem.

Still, it's better by far to fix it than let it linger and see it eventually used to crash a server. That's what I and others felt anyway. But, then, a senior Red Hat software engineer replied, "Thanks for the contribution. At this time, we don't plan to address this in RHEL, but we will keep it open for evaluation based on customer feedback."

That went over like a lead balloon.

The GitLab conversation proceeded:

AlmaLinux: "Is customer demand really necessary to fix CVEs?"

Red Hat: "We commit to addressing Red Hat defined Critical and Important security issues. Security vulnerabilities with Low or Moderate severity will be addressed on demand when [a] customer or other business requirements exist to do so."

AlmaLinux: "I can even understand that, but why reject the fix when the work is already done and just has to be merged?"

At this point, Mike McGrath, Red Hat's VP of Core Platforms, AKA RHEL, stepped in. He explained, "We should probably create a 'what to expect when you're submitting' doc. Getting the code written is only the first step in what Red Hat does with it. We'd have to make sure there aren't regressions, QA, etc. ... So thank you for the contribution, it looks like the Fedora side of it is going well, so it'll end up in RHEL at some point."

Things went downhill rapidly from there...

On Reddit, McGrath said, "I will admit that we did have a great opportunity for a good-faith gesture towards Alma here and fumbled."

Finally, though the Red Hat Product Security team rated the CVE as "'Important,' the patch was merged.
Coincidentally, last month AlmaLinux announced that its move away from 1:1 compatibility with RHEL meant "we can now accept bug fixes outside of Red Hat's release cycle."

This Thursday AlmaLinux also reiterated that they're "fully committed to delivering the best possible experience for the community, no matter where or what you run." And in an apparent move to beef up compatibility testing, they announced they'd be bringing openQA to the RHEL ecosystem. (They describe openQA as a tool using virtual machines that "simplifies automated testing of the whole installation process of an operating system in a wide combination of software and hardware configurations.")

Last weekend in Portland, Oregon, the Software Freedom Conservancy hosted a new conference called the Free and Open Source Software Yearly.

And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:

• benny Vasquez, the Chair of the AlmaLinux OS Foundation
• Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
• James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances

"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."

One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"

In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."

When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."

AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."

And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."

Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."

Read Slashdot's transcript of highlights from the discussion.

The hack of Microsoft's cloud that resulted in the compromise of government emails was an example of a traditional espionage threat, a senior National Security Agency official said. From a report: Speaking at the Aspen Security Forum, Rob Joyce, the director of cybersecurity at the N.S.A., said the United States needed to protect its networks from such espionage, but that adversaries would continue to try to secretly extract information from each other. "It is China doing espionage," Mr. Joyce said. "It is what nation-states do. We have to defend against it, we need to push back against it. But that is something that happens."

The hackers took emails from senior State Department officials including Nicholas Burns, the U.S. ambassador to China. The theft of Mr. Burns's emails was earlier reported by The Wall Street Journal and confirmed by a person familiar with the matter. Daniel J. Kritenbrink, the assistant secretary of state for East Asia, also had his email hacked, a U.S. official said. The emails of Commerce Secretary Gina Raimondo were also obtained in the hack, which was discovered in June by State Department cybersecurity experts scouring user logs for unusual activity. Microsoft later determined that Chinese hackers had obtained access to email accounts a month earlier.

Microsoft is expanding its suite of free security tools for customers, the software company said on Wednesday, following criticism that it was charging clients to protect themselves against Microsoft's mistakes. From a report: The move follows a high-level hack that allowed allegedly Chinese spies to steal emails from senior U.S. officials - and complaints from security specialists and lawmakers against paying for tools In a blog post published on Wednesday, Microsoft said the advanced features in Microsoft's auditing suite - which it calls Microsoft Purview - would be available to all customers "over the coming months." Although not enough to prevent hacks on their own, digital auditing tools are critical for helping organizations figure out whether intruders are in their network, how they got in and how to get them out.

Most outsourced programmers in India will see their jobs wiped out in the next year or two, Stability AI CEO Emad Mostaque said. CNBC reports: Mostaque, on a call with UBS analysts, said that most of the country's outsourced coders will lose their jobs as the effects of AI mean that it is now possible for software to be developed with far fewer people. "I think that it affects different types of jobs in different ways," Mostaque said on a call with analysts at the Swiss investment bank last week. "If you're doing a job in front of a computer, and no one ever sees you, then it's massively impactful, because these models are like really talented grads."

According to Mostaque, not everyone will be affected in the same way, however. That is due in no small part to differing rules and regulations around the world. Countries with stronger labor laws, like France, will be less likely to see such an impact, for example. In India, Mostaque said, "outsourced coders up to level three programmers will be gone in the next year or two, whereas in France, you'll never fire a developer." "So it affects different models in different countries in different ways in different sectors."

Mostaque reiterated a previous statement he made saying that there will be "no more programmers" in five years' time -- however, he caveated this to say that he meant coders in the traditional sense. "Why would you have to write code where the computer can write code better? When you deconstruct the programming thing from bug testing to unit testing to ideation, an AI can do that, just better," Mostaque said. "But it won't be doing it automatically, it will be AI 'co-pilots,'" Mostaque said. "That means less people are needed for classical programming, but then are they needed for other things? This is the question and this is the balance that we have to understand, because different areas are also affected differently."