An anonymous reader quotes a report from Phys.org: The mission team of NASA's Jupiter-orbiting Juno spacecraft executed a deep-space move in December 2023 to repair its JunoCam imager to capture photos of the Jovian moon Io. Results from the long-distance save were presented during a technical session on July 16 at the Institute of Electrical and Electronics Engineers Nuclear & Space Radiation Effects Conference in Nashville. JunoCam is a color, visible-light camera. The optical unit for the camera is located outside a titanium-walled radiation vault, which protects sensitive electronic components for many of Juno's engineering and science instruments. This is a challenging location because Juno's travels carry it through the most intense planetary radiation fields in the solar system. While mission designers were confident JunoCam could operate through the first eight orbits of Jupiter, no one knew how long the instrument would last after that. Throughout Juno's first 34 orbits (its prime mission), JunoCam operated normally, returning images the team routinely incorporated into the mission's science papers. Then, during its 47th orbit, the imager began showing hints of radiation damage. By orbit 56, nearly all the images were corrupted.

While the team knew the issue might be tied to radiation, pinpointing what was specifically damaged within JunoCam was difficult from hundreds of millions of miles away. Clues pointed to a damaged voltage regulator that was vital to JunoCam's power supply. With few options for recovery, the team turned to a process called annealing, where a material is heated for a specified period before slowly cooling. Although the process is not well understood, the idea is that heating can reduce defects in the material. Soon after the annealing process finished, JunoCam began cranking out crisp images for the next several orbits. But Juno was flying deeper and deeper into the heart of Jupiter's radiation fields with each pass. By orbit 55, the imagery had again begun showing problems.

"After orbit 55, our images were full of streaks and noise," said JunoCam instrument lead Michael Ravine of Malin Space Science Systems. "We tried different schemes for processing the images to improve the quality, but nothing worked. With the close encounter of Io bearing down on us in a few weeks, it was Hail Mary time: The only thing left we hadn't tried was to crank JunoCam's heater all the way up and see if more extreme annealing would save us." Test images sent back to Earth during the annealing showed little improvement in the first week. Then, with the close approach of Io only days away, the images began to improve dramatically. By the time Juno came within 930 miles (1,500 kilometers) of the volcanic moon's surface on Dec. 30, 2023, the images were almost as good as the day the camera launched, capturing detailed views of Io's north polar region that revealed mountain blocks covered in sulfur dioxide frosts rising sharply from the plains and previously uncharted volcanoes with extensive flow fields of lava. To date, the solar-powered spacecraft has orbited Jupiter 74 times. Recently, the image noise returned during Juno's 74th orbit.

Communications of the ACM checks in on the quest for room-temperature superconductivity. "Time and time again, physicists have announced breakthroughs that were later found to be irreproducible, in error, or even fraudulent."

But "The issue is once again simmering..." In January 2024, a group of researchers from Europe and South America announced they had achieved a milestone in room-temperature ambient-pressure superconductivity. Using Scotch-taped cleaved pyrolytic graphite with surface wrinkles, which formed line defects, they observed a room-temperature superconducting state. Their paper, published in the journal Advanced Quantum Technologies, has gained considerable attention in the scientific world... Although many in the scientific community remain incredulous, if valid, this development could help solve a key piece of the puzzle: how defects and wrinkles in a material such as scotch-taped cleaved pyrolytic graphite (HOPG) affect electrical properties and behavior within superconductive systems...

"We haven't reached a point where there is a clear path to room temperature superconductivity because researchers are either overly enthusiastic or deceptive," said Elie Track, chief technology officer at HYPRES, Inc., an Elmsford, NY, company that develops and commercializes superconductor integrated circuits (ICs) and systems. "People fail to check measurements and others can't reproduce their results. There is a lot of carelessness and sloppy science surrounding the space because people are so eager to achieve success." The team conducting research into scotch-taped cleaved pyrolytic graphite believe their discovery could tilt the search for practically useful room-temperature superconductivity in a favorable direction. They reported they were able to achieve one-dimensional superconductivity in pyrolytic graphite at temperatures as great as 300 degrees Kelvin (26.85 degrees Celsius), and at ambient pressure. Vinokur and physicist Maria Cristina Diamantini described the development as the first "unambiguous experimental evidence" for a global room temperature zero-resistance state. If true, the team's research could illuminate a path to new superconducting materials....

Others remain skeptical, however. For example Alan Kadin [a technical consultant in the field and a former professor of electrical engineering at the University of Rochester] pointed out that one of the key researchers for the project, Yakov Kopelevich, has been working in the field for two decades and, so far, "The results are not reproducible in other labs...Until someone else independently reproduces these results, I think we can safely ignore them," he argued...

Yet as scientists continue to bang away at the superconducting challenge — including the possibility of using generative AI to explore materials and techniques — optimism is growing that a major breakthrough could occur.

When it comes to introducing liability for software products, "the EU and U.S. are taking very different approaches," according to Lawfare's cybersecurity newsletter. "While the U.S. kicks the can down the road, the EU is rolling a hand grenade down it to see what happens." Under the status quo, the software industry is extensively protected from liability for defects or issues, and this results in systemic underinvestment in product security. Authorities believe that by making software companies liable for damages when they peddle crapware, those companies will be motivated to improve product security... [T]he EU has chosen to set very stringent standards for product liability, apply them to people rather than companies, and let lawyers sort it all out.

Earlier this month, the EU Council issued a directive updating the EU's product liability law to treat software in the same way as any other product. Under this law, consumers can claim compensation for damages caused by defective products without having to prove the vendor was negligent or irresponsible. In addition to personal injury or property damages, for software products, damages may be awarded for the loss or destruction of data. Rather than define a minimum software development standard, the directive sets what we regard as the highest possible bar. Software makers can avoid liability if they prove a defect was not discoverable given the "objective state of scientific and technical knowledge" at the time the product was put on the market.

Although the directive is severe on software makers, its scope is narrow. It applies only to people (not companies), and damages for professional use are explicitly excluded. There is still scope for collective claims such as class actions, however. The directive isn't law itself but sets the legislative direction for EU member states, and they have two years to implement its provisions. The directive commits the European Commission to publicly collating court judgements based on the directive, so it will be easy to see how cases are proceeding.

Major software vendors used by the world's most important enterprises and governments are publishing comically vulnerable code without fear of any blowback whatsoever. So yes, the status quo needs change. Whether it needs a hand grenade lobbed at it is an open question. We'll have our answer soon.

An anonymous reader shares a report: In March 2020, as the Covid-19 pandemic began to transform the world, the company then known as Facebook struck a deal to buy all the augmented reality displays made by British firm Plessey. At the time, the deal appeared to be a savvy way of squeezing out Apple in the competition to develop AR glasses, as Plessey was one of the few makers of AR displays. Three years on, however, the deal has turned into a bust for Meta. Development of Plessey's technology has stalled, say people with direct knowledge of the effort. Facebook, now called Meta Platforms, has struggled to make Plessey's displays bright enough for use in its AR glasses under development and to reduce defects that crop up in the manufacturing process. Earlier this year, Meta decided to abandon Plessey's microLED tech in favor of an older display technology, liquid crystal on silicon or LCoS. The decision is one of several Meta has made, for either technological or cost-saving reasons, that will reduce the edge that the AR glasses have over existing AR headsets like Microsoft's HoloLens.

The episode highlights the twists and turns Meta is navigating as it tries to stay ahead of Apple and other rivals in the still-developing market for AR and virtual reality. Meta was early to the VR market with its Quest headsets and has been working on developing AR glasses to get ahead of rivals like Snap which are trying to develop similar products. Now it faces competition from Apple, which last month unveiled its mixed-reality headset, the Vision Pro, which will be available early next year. At the same time, Meta is under pressure from investors to curb the more than $10 billion it is spending annually at the Reality Labs division developing its AR and VR products. Technical setbacks have forced Meta to delay the timeline for releasing AR glasses multiple times, and it isn't anticipating releasing a pair of AR glasses to the public until at least 2027.

Electric cars make up less than 5% of new U.S. vehicle sales today — but automakers are betting on increasing demand. Chevy even plans to stop producing gas-powered cars altogether over the next 15 years, according to the Washington Post.

But they also ponder the implications of this year's recall of the Chevy Bolt: The crisis involving the Chevrolet Bolt was a painful reminder for the auto industry that despite treating the electric vehicle era as essentially inevitable — a technical fait accompli — significant obstacles to manufacturing the cars, and especially their batteries, continue to threaten that future. "It's a terrible thing that has happened," Tim Grewe, GM's general director for electrification strategy and cell engineering, said in an interview in September...

The recall of the Bolt covered all of the roughly 141,000 units GM had ever built. The company identified the issue as dual defects that led battery materials to make contact with one another and the components to combust spontaneously. It's a danger that comes directly from the core challenge of creating electric-vehicle batteries: the competition to pack more and more energy into them... Even as automakers seek to phase out gasoline engines en masse, high-voltage car batteries remain in their early stages of mass production. Many manufacturers are experimenting with new technologies and battery chemistries. While they do so, they are discovering defects — some of which can prove catastrophic.... Electric-car-battery explosions can release massive amounts of energy — and the fires can burn for hours, stretching longer and registering hotter than fires in cars with internal-combustion engines...

LG, which has made batteries for the Bolt's entire run, is reimbursing GM for nearly $2 billion of costs associated with the recall.... GM has been hit hardest by fire concerns — but Audi and Hyundai also have recalled EVs over fire risks.

An anonymous reader quotes a report from Ars Technica, written by Tim De Chant: GM announced last Friday that it was recalling every Chevrolet Bolt it had ever made, including the new electric utility vehicle model that debuted this year. After a string of fires affected Bolt models, the company traced the problem to two simultaneously occurring defects in the cars' LG Chem-made batteries. The automaker initially discovered the problem in batteries from one of LG's Korean plants, and it recalled cars with those cells last November. But then more Bolts caught fire, and other LG plants were ensnared in the investigation, spurring two expansions of the recall. The problem, GM said, has been traced to a torn anode tab and a folded separator.

That's all GM has said so far. It hasn't said how widespread the defects are, nor has it said how, exactly, the fires started. But in what little information has been released, and in the timing of GM's recalls, there are clues. To decipher them, Ars spoke with Greg Less, technical director of the University of Michigan's Battery Lab. "What we're looking at is a perfect storm," Less said. The Bolt's battery packs are made up of pouch-type cells, which are essentially layers of cathodes, anodes, and separators that are flooded with liquid electrolyte and encased in a flexible polymer pouch. The torn anode tab, he said, would create a projection in what should be an otherwise flat battery. The projection brings the anode closer to the cathode. "And that would probably be OK if the separator was where it was supposed to be," he said.

But in problematic Bolt batteries, the separator wasn't where it was supposed to be. Separators are placed between the anode and cathode to prevent the two electrodes from touching. A torn tab wouldn't necessarily be an issue on its own because the separator would prevent any projection from bridging the anode-cathode gap. In cells with a folded separator, though, the gap would be missing from at least part of the battery. If the anode bridges the gap, Less said, "you have a short, and it's all downhill from there." "It wouldn't surprise me if both defects are caused by the same thing," he added. "I would imagine that the separator must be folded at the edge near where the anode tab is at. What I'm guessing is that at some point during the handling of the cell, before it's fully packaged, some part of the robot machine is catching. The tab is catching, the separator is catching -- something is catching very infrequently so that it hasn't been noticed, and it's causing this damage."

"Software research is a train wreck," says Hillel Wayne, a Chicago-based software consultant who specialises in formal methods, instancing the received wisdom that bugs are way more expensive to fix once software is deployed. Wayne did some research, noting that "if you Google 'cost of a software bug' you will get tons of articles that say 'bugs found in requirements are 100x cheaper than bugs found in implementations.' They all use this chart from the 'IBM Systems Sciences Institute'... There's one tiny problem with the IBM Systems Sciences Institute study: it doesn't exist." The Register: Laurent Bossavit, an Agile methodology expert and technical advisor at software consultancy CodeWorks in Paris, has dedicated some time to this matter, and has a post on GitHub called "Degrees of intellectual dishonesty". Bossavit referenced a successful 1987 book by Roger S Pressman called Software Engineering: a Practitioner's Approach, which states: "To illustrate the cost impact of early error detection, we consider a series of relative costs that are based on actual cost data collected for large software projects [IBM81]." The reference to [IBM81] notes that the information comes from "course notes" at the IBM Systems Sciences Institute. Bossavit discovered, though, that many other publications have referenced Pressman's book as the authoritative source for this research, disguising its tentative nature.

Bossavit took the time to investigate the existence of the IBM Systems Science Institute, concluding that it was "an internal training program for employees." No data was available to support the figures in the chart, which shows a neat 100x the cost of fixing a bug once software is in maintenance. "The original project data, if any exist, are not more recent than 1981, and probably older; and could be as old as 1967," said Bossavit, who also described "wanting to crawl into a hole when I encounter bullshit masquerading as empirical support for a claim, such as 'defects cost more to fix the later you fix them'."

Linus Torvalds oversees every line of code added to the Linux kernel, but in recent years the male-dominated community has become increasingly divided, reports BBC. Rows about sexism and rudeness led to the creation of a Code of Conflict (CoC) in 2015 which was short -- simply recommending people "be excellent to each other." That has now been replaced by a more detailed Code of Conduct -- which retains the acronym, but attempts to be more inclusive and eliminate insulting and derogatory comments and behaviour. Reader sinij writes: Recently Linux Community adopted a new controversial Code of Conduct authored by Contributor Covenant also known for authoring the Post-Meritocracy Manifesto. In an exclusive email interview with the BBC, Mr Torvalds shared his thoughts on his decision to temporarily step aside, the controversy behind the CoC, and the defects of the community he set up. His thoughts on CoC: The advantage of concentrating on technology is that you can have some mostly objective measures, and some basis for agreement, and you can have a very nice and healthy community around it all. I really am motivated by the technology, but the community around Linux has been a big positive too. But there are very tangible and immediate common goals in any technical project like Linux, and while there is occasionally disagreement about how to solve some particular issue, there is a very real cohesive force in that common goal of improving the project. And even when there are disagreements, people in the end often have fairly clear and objective measures of what is better. Code that is faster, simpler, or handles more cases naturally is just objectively 'better', without people really having to argue too much about it.

In contrast, the arguments about behaviour never seem to end up having a common goal. Except, in some sense, the argument itself. Have you read the Twitter feeds and other things by the people who seem to care more about the non-technical side? I think your 'hyped stories' is about as polite as you can put it. It's a morass of nastiness. Instead of a 'common goal', you end up with horrible fighting between different 'in-groups'. It's very polarising, and both sides love egging the other side on. It's not even a 'discussion', it's just people shouting at each other. That's actually the reason I for the longest time did not want to be involved with the whole CoC discussion in the first place. That whole subject seems to very easily just devolve and become unproductive. And I found a lot of the people who pushed for a CoC and criticised me for cursing to be hypocritical and pointless. I could easily point you to various tweet storms by people who criticise my 'white cis male' behaviour, while at the same time cursing more than I ever do.

So that's my excuse for dismissing a lot of the politically correct concerns for years. I felt it wasn't worth it. Anybody who uses the words 'white cis male privilege' was simply not worth my time even talking to, I felt. "And I'm still not apologising for my gender or the colour of my skin, or the fact that I happen to have the common sexual orientation. What changed? Maybe it was me, but I was also made very aware of some of the behaviour of the 'other' side in the discussion. Because I may have my reservations about excessive political correctness, but honestly, I absolutely do not want to be seen as being in the same camp as the low-life scum on the internet that think it's OK to be a white nationalist Nazi, and have some truly nasty misogynistic, homophobic or transphobic behaviour. And those people were complaining about too much political correctness too, and in the process just making my public stance look bad. And don't get me wrong, please -- I'm not making excuses for some of my own rather strong language. But I do claim that it never ever was any of that kind of nastiness. I got upset with bad code, and people who made excuses for it, and used some pretty strong language in the process. Not good behaviour, but not the racist/etc claptrap some people spout. So in the end, my 'I really don't want to be too PC' stance simply became untenable. Partly because you definitely can find some emails from me that were simply completely unacceptable, and I need to fix that going forward. But to a large degree also because I don't want to be associated with a lot of the people who complain about excessive political correctness.

"Last week, a California judge decided to allow a class action lawsuit filed in December 2017 against Fiat Chrysler to proceed," reports IEEE Spectrum. "The lawsuit, which could have major ramifications for car makers, was filed in response to stalling issues with 2017 Chrysler Pacifica minivans that the plaintiffs allege were caused by known software defects." From the report: The plaintiffs allege that Fiat Chrysler, despite numerous owner complaints about the Pacifica stalling out, concealed knowledge of defects in Pacifica's powertrain control module (PCM) to keep customers from having concerns about buying the vehicle. Fiat Chrysler attempted to get the lawsuit dismissed, arguing that consumer complaints don't prove that a vehicle defect exists, or demonstrate that the company knew about the alleged defect a priori and concealed it.

The judge agreed with Fiat Chrysler on those points, ruling that the plaintiffs could not use consumer complaints alone as evidence of a defect. However, he pointed out that Fiat Chrysler had issued two technical service bulletins relating to Pacifica's PCM software before the plaintiffs had purchased their vehicle, and two more following their purchase. The judge ruled that there was sufficient evidence to believe it was "at least plausible" that Fiat Chrysler knew that there was a stalling problem with the vehicles before the plaintiffs bought them.

Last week you had the chance to ask ESR about books, guns, and open source software. Below you'll find his answers to those questions.

First time accepted submitter BenLinders writes "The Economics of Software Quality provides solutions to quantify software quality, helping you to manage software development and maintenance. It contains software quality data that you can use to build a business case to improve the quality of your software, and decide upon processes and techniques that can help to implement the needed improvements in your organization." Read below for the rest of Ben's review.

Michael J. Ross writes "Slow Web page loading can discourage visitors to a site more than any other problem, regardless of how attractive or feature-rich the given site might be. Consequently, many Web developers hope to achieve faster response times using AJAX (Asynchronous JavaScript and XML), since only portion(s) of an AJAX page need to be reloaded. But for many rich Internet applications (RIAs), such potential performance gains can be lost as a result of non-optimized JavaScript, graphics, and CSS files. Steve Souders — a Web performance expert previously at Yahoo and now with Google — addresses these topics in his second book, Even Faster Web Sites: Performance Best Practices for Web Developers." Read on for the rest of Michael's review.

Last week you asked Jazz technical lead Erich Gamma questions about Jazz or anything else in his realm of expertise. Here are his answers, along with many external links and places to continue the conversation if you are interested.

You asked. Mårten answered. He even added (and answered) a question he wished had been asked, but wasn't. If you have a comment or follow-up question, please post it. Mårten will spend as much time responding to your comments as his schedule permits.

We recently had a chance to take a look at one of the new offerings from O'Reilly: "Applied Project Management." The book offered some interesting insights and a few updated ways of looking at old ideas -- Read on for a short excerpt.

steeviant wonders: "I live in New Zealand, and have been dealing with AppleCare Australia over issues with my PowerBook G4, which has needed three replacement power supplies, one battery, two motherboards, a top case, and a screen replaced under warranty, and it now has another hardware problem. I'm not satisfied that AppleCare Australia think it is acceptable for my PowerBook to have nine problems in two years, and want the machine replaced, but they are refusing. I have scoured the apple.com.au, and apple.com websites trying to find some way to contact anyone to try to get AppleCare to reconsider their stance on this issue. If New Zealand had an Apple branch office, I would simply take them to court, but even that is not possible as their computers are sold through a local distributor. Surely Apple don't consider this appalling number of failures to be acceptable for a computer which cost over NZD $9000. Can anyone suggest an avenue through which I can contact Apple in the U.S. for help?" Sometimes handing technical issues defect-by-defect works, however it seems to me that there are many cases where it would seem to be a waste of time...both the manufacturer's and the customer's. Should manufacturers be required to replace an entire machine after a certain number of defects in a specific time period, or might there be a better way to handle these kinds of technical issues? Update: 03/31 3AM EDT by C : steeviant wants to let everyone know that Apple has offered to replace his machine with a 'like for like' model before this article was even posted. So, "All's well that ends well." for some, how about you?

Continuing with his campaign to rid the world of lousy software, chromatic is back with this review of Extreme Programming Installed. It sounds like what the authors are advocating is a truly programmer-centric environment; does anyone have experience in a workplace even close to this?

Craig Miskell asks: "Bought a magazine today (PC Authority - Australian magazine). It contained Borland C++ Builder 3, and the licence contained the following, which I read to mean that you can't release the source code to your programs that you create using C++Builder: 'GENERAL TERMS THAT APPLY TO COMPILED PROGRAMS AND REDISTRIBUTABLES You may write and compile (including byte-code compile) your own application programs using the Software, including any libraries and source code included for such purpose with the Software. You may reproduce and distribute, in executable form only, programs which you create using the Software without additional license or fees, subject to all of the conditions in this statement.' What dya think about that? Seems odd to me." Me, too. Borland better bandage that foot before it stains the carpet... Updated Sorry. There seems to nothing to worry about. Read on for a statement direct from Inprise.

Jason Bennett has returned with a review of Mark Minasi's The Software Conspiracy. The book is basically a well-informed perspective of the state of the software industry - how it functions, what it does, and what's really going on. Click below to learn more.

The ACLU, EPIC and EFF have issued a joint news release about the new crypto regulations, describing the many flaws that still exist: licensing to speak, arbitrary restrictions, etc. I've seen at least one coherent argument that the new rules will prevent GPL'd (but not BSD licensed) code from being redistributed as well. Read below for more information about how the civil liberties groups view the new rules.