Author Archives: pappp

Source: Hack a Day

One of the most crucial aspects of FDM 3D printing is ensuring sufficient material is extruded. Determining the right flow rate can be done manually, but some printers these days automatically perform this adjustment, which is very convenient. [Stefan] of CNC Kitchen investigates how to add similar functionality using existing bed-leveling sensors.

A major complication with extrusion in FDM printers is that the flow rate has to fit the printing speed. However, you can’t just immediately speed up or reduce the flow rate, as the melting filament is flexible and thus acts like a spring, especially as the extruder is exerting significant force on the filament, which adds compression.

The moment you reduce or increase the speed of the nozzle, you can get over- or under-extrusion, but the delayed response by the extruded filament means that you have to adjust for this change in advance. Ergo, the name ‘pressure advance’, also known as the K-value. Obviously, this is a parameter that differs with each material, printer, and other factors, so a direct measurement is always the best.

In the Bambu Lab X1 FDM printer, a Lidar scanner was used to scan various test patterns to automatically determine the optimal setting. This was later moved to the purge section of the extruder in newer Bambu Lab printers. On other FDM printers, the only available sensor in that area is typically the pressure sensor for bed leveling. Could this sensor make a similar measurement?

This wasn’t just an idle thought, but was inspired by the Snapmaker U1, which runs open-source Klipper, with tantalizing glimpses of how it does pressure-advance sensing in its extruder. This extruder also only contains a load cell, as do some Prusa printers. These much more open printers thus provided a test bed for some experimentation.

With load cell data available, [Stefan] measured how various extrusion rates affect the load cell, which can then theoretically be correlated with the appropriate K-values for specific transitions. He created a calibration tool for a range of Prusa printers that works with stock firmware, though this is definitely still a work in progress. There are also a couple of similar open-source projects, such as this Auto PA Calibration project by [Mark].

Overall, K-value presets tend to work pretty well, but adding a pressure-advance calibration feature to existing FDM printers is definitely an interesting idea. There’s also the prospect of lateral sensing using this same bed-leveling sensor, which could allow the printer to sense much more than just the bed.

Source: Hacker News

Source: Published articles

Bug 522075 has been causing JUST enough load and thus heat on my i7-1365U to be annoying (warm back, spinning fans). That machine runs Neon so it got 6.7.3 this morning, it looks like the two relevant patches sufficently solved/mitigated it. Many thanks to Xaver and Vlad.

Source: The Verge - All Posts

Epic Games and Google have just jointly withdrawn their attempt to retroactively settle the lawsuit that's changing how Android app stores work in the United States - and that means Google will be forced to carry rival app stores inside of its own. In fact, Google tells the court, it's ready to begin carrying third-party app stores on Wednesday, July 22nd. Does that mean it's time for Microsoft to launch an Xbox game store on Android?

In October 2024, Judge James Donato originally agreed that forcing Google to carry rival Android app stores within its own Google Play store for several years, and forcing it to share its own entire catalog of …

Read the full story at The Verge.

Source: Ars Technica

An industry-wide standard Microsoft invented to protect Windows, and later Linux, devices from firmware infections has been trivial to bypass for 13 of its 14 years of existence. The discovery was made by researchers at security firm ESET after identifying 11 firmware images, at least one from 2013, that were known to be defective but remained signed by the software company anyway.

The images are known as shims, which were invented to extend Secure Boot to Linux devices and utility software. Using a technique simple enough to be performed by novice hackers, these old, forgotten shims can be used to completely circumvent the protection, which is embedded into the UEFI (Unified Extensible Firmware Interface) of the device's motherboard. The gaffe is the result of the failure by Microsoft, which oversees the signing of shims, to revoke the publicly available images once vulnerabilities were found in them.

Threat extends to Windows and Linux users

The threat extends to Windows and Linux users alike, since the shim can be installed on devices running both operating systems. From there, an attacker can subvert the mandated chain of digitally signed firmware to install malicious firmware that loads early in the boot process and persists after either the OS is reinstalled or a hard drive is replaced.

Read full article

Comments

Source: Hacker News

Source: Hacker News

Source: Hacker News

Source: The Register

For the first time, the source code of KSOS, backed by the US Department of Defense in the late 1970s and 1980s, is available to the public in the archives of The Unix Heritage Society (TUHS). TUHS volunteers preserve the historical source code and documentation of the original UNIX – or as much of it as is left. A few days ago, in an email to its mailing list, TUHS founder Warren Toomey announced the addition of KSOS to the collection. "KSOS was the US Department of Defense (DoD) Kernelized Secure Operating System (KSOS, formerly called Secure UNIX). KSOS is intended to provide a provably secure operating system for larger minicomputers," he wrote. Despite its age, KSOS sounds surprisingly modern. It was a Unix-compatible OS, implemented in a type-safe programming language, Modula, rather than C. Modula was the late great Niklaus Wirth's successor to Pascal and, in turn, the forerunner to Modula-2 – which we described when it was added to the GNU Compiler Collection in 2022. KSOS was designed to be formally verifiable, so that it could be trusted for use in highly secure systems. It ran on commodity hardware, and its development was sponsored by the US DOD. Very few OS kernels have been formally verified, and one of the best-known modern examples is the seL4 microkernel, as used in the Ironclad OS we covered last year, and also in the new QSOE RISC-V RTOS. KSOS isn't some cutting-edge experimental new Rust effort, like the Asterinas project we described last year or the even newer Maestro project. What became KSOS started in 1978 at Ford Aerospace (yes, that Ford). On the team were Peter Neumann, who later ran the RISKS Digest – The Register was quoting him in 2004 – and Tom Perrine, who described it and its modern relevance in a 2002 article for the USENIX journal ;login:. It's titled "The Kernelized Secure Operating system (KSOS)" [PDF], and at only three and a bit pages long, it's well worth a read. Even then, 24 years ago, projects were struggling to reinvent things KSOS did successfully a couple of decades earlier. That's even more true today. To learn more about how KSOS worked, there's a 1978 Executive Summary [PDF] – which, despite its title, runs to 15 pages. Clearly, executives back then had longer attention spans. Perrine gave a talk about KSOS at DEF CON 20 in 2012, which you can watch on YouTube. KSOS isn't forgotten. For instance, it came up in a talk at last year's FOSDEM: Confidential Computing's Recent Past, Emerging Present, and Long-Lasting Future. Page 8 of the slide deck [PDF] says KSOS was "among the first security-focused kernels, emphasizing formal verification" and "source code was publicly available, rejecting 'security through obscurity.'" KSOS was not confined to academic research. It was used in production. Last October, Perrine explained more in another TUHS email: "KSOS – for PDP-11, originally developed by Ford Aerospace, and then extended at Logicon. It did have a supervisor-mode UNIX-system-call-compatible system. Later, there was also a userland library that implemented something that mostly matched the UNIX system calls. It had no kernel code in common with UNIX. It was written in Modula. "KSOS was used in the Trusted Downgrade System of the multi-level-secure 'all-source' intel fusion system that Logicon built for a few agencies. ACCAT-GUARD and USAFE-GUARD, for example. "KSOS-32 – a VAX 'port' of KSOS (which was then retconned as 'KSOS-11'). The Modula code from -11 was run though Emacs macros to produce Modula-2, and then parts were rewritten as needed. "I worked on both systems at Logicon." It's Perrine we have to thank for KSOS reappearing in public view after 38 years – he found an old tarball of the source code, and with the help of John O Goyo and Thalia Archibald, it made its way to the TUHS code archive. Now there’s a new quest: find the original compiler used to build it. One thing that may help slightly is that KSOS was not self-hosting: it was compiled under UNIX. We have mentioned TUHS's important work before: for instance, when a tape of UNIX V4 was found in University of Utah boffin Robert Ricci's department — and successfully recovered. Bootnote Mr Goyo also found time to email The Reg FOSS desk about the recovery, for which we thank him. ®

Source: The Register

The ancient dispute over ownership of UNIX, and perhaps Linux too, has returned to court. Again. As The Register has explained many, many, times since this matter first went to court in 2003, the roots of the case are the 1998 alliance between IBM and a company called the Santa Cruz Operation which sold a version of UNIX for x86 CPUs. Those two companies, plus Intel and Sequent, created “Project Monterey” – an effort to create a unified version of UNIX that could run on multiple processors. By 2001, Project Monterey was close to delivering a unified UNIX, an achievement made possible by blending code from IBM and SCO. By then, a little project called “Linux” already ran on multiple processors. Big Blue decided Linux was the future and bailed from Project Monterey – then allegedly contributed some Monterey code to the open-source project and to its own AIX and Z operating systems. SCO felt it owned some of that code, so sued IBM. SCO and its successors struggled to survive, but interested parties kept the lawsuit alive because the chance to emerge as owner of parts of the Linux codebase, and IBM’s code, had the potential to turn into a colossal payday. The case and its successors ended in 2021, with a settlement that saw litigants agree to end the matter without IBM admitting fault. But by then, SCO had sold its software to a biz called Xinuos that decided to fight on. The Xinuos case has burbled along quietly since, and on June 22nd reached the milestone of a hearing. The matter has become a little more modern, if only because this hearing was held online and the presiding judge appeared to unwittingly be on mute at one point. But the arguments otherwise seemed to revisit Project Monterey, debated the relevance of past litigation, contested who owned what, when they owned it, and how they could prove it. Xinuos argued IBM never had a license for SCO code. Big Blue argued that it did nothing wrong. The core issue seems to be whether Xinuos even has the right to litigate the matter, or if some ancient legalese in the original agreements means the window for legal argument has long since expired. The matter continues and appears likely to do so until either the heat death of the universe or the year of Linux on the desktop – whichever comes sooner. ®