If you want read-only memory today, you might be tempted to use flash memory or, if you want old-school, maybe an EPROM. But there was a time when that wasn’t feasible. [Igor Brichkov] shows us how to make a core rope memory using a set of ferrite cores and wire. This was famously used in early UNIVAC computers and the Apollo guidance computer. You can see how it works in the video below.

While rope memory superficially resembles core memory, the principle of operation is different. In core memory, the core’s magnetization is what determines any given bit. For rope memory, the cores are more like a sensing element. A set wire tries to flip the polarity of all cores. An inhibit signal stops that from happening except on the cores you want to read. Finally, a sense wire weaves through the cores and detects a blip when a core changes polarity. The second video, below, is an old MIT video that explains how it works (about 20 minutes in).

Why not just use core memory? Density. These memories could store much more data than a core memory system in the same volume. Of course, you could write to core memory, too, but that’s not always a requirement.

We’ve seen a resurgence of core rope projects lately. Regular old core is fun, too.

youtube.com/embed/cdeHAdR83b8?…

youtube.com/embed/ndvmFlg1WmE?…

hackaday.com/2025/05/14/your-o…

Treat dispensers are old hat around here, but what if kitty doesn’t need the extra calories — and actually needs to drop some pounds? [MethodicalMaker] decided to link the treat dispenser to a cat wheel, and reward kitty for healthy behaviors. The dispenser can be programmed to make the cat run long enough to burn the calories of its treat. Over time, kitty can be trained to run longer between treats to really melt off the pounds.

The wheel itself is an off the shelf model called “One Fast Cat”; apparently these are quite cheap second hand as most cats don’t really see the point in exercise. [MethodicalMaker] glued evenly-spaced magnets along the rim in order to track the rotation with a hall effect sensor. A microcontroller is watching said sensor, and is programmed to release the treats after counting off a set number of revolutions. Control over the running distance and manual treat extrusion is via web portal, but the networking code had difficulty on the Arduino R4 [MethodicalMaker] started with, so he switched to an ESP32 to get it working.

The real interesting part of this project is the physical design of the treat dispenser: it uses a double-auger setup to precisely control treat release. The first auger lives inside a hopper that holds a great many treats, but it tended to over-dispense so [MethodicalMaker] methodically made a second auger that sits beneath the hopper. The handful of treats extruded by the first auger are dispensed individually by the second auger, aided by a photosensor inside the exit chute to count treats. This also lets the machine signal when it needs refilled. For precise control, continuous servos are used to drive the augers. Aside from the electronics, everything is 3D printed; the STLs are on Printables, and the code is on GitHub.

If you don’t have a cat wheel, DIY is an option. If you don’t have a cat, we’ve also highlighted dog treat dispensers. If you don’t have either, check with your local animal shelter; we bet good money there are oodles ready to adopt in your town, and then you’ll have an excuse to enter one of your projects into our ongoing Pet Hacks Contest.

youtube.com/embed/nUOUaUAySG0?…

hackaday.com/2025/05/14/2025-p…

Negli Stati Uniti è emerso un nuovo potenziale rischio per la sicurezza delle infrastrutture energetiche.

Alcuni esperti del settore hanno scoperto dispositivi di comunicazione non documentati all’interno di inverter solari di produzione cinese, componenti fondamentali utilizzati per connettere pannelli solari e turbine eoliche alla rete elettrica. Questi dispositivi non erano elencati nella documentazione ufficiale e potrebbero rappresentare una minaccia se utilizzati per accedere da remoto ai sistemi energetici.

Gli inverter di potenza, prodotti principalmente in Cina, sono utilizzati in tutto il mondo per collegare pannelli solari e turbine eoliche alla rete elettrica. Sono presenti anche in batterie, pompe di calore e caricabatterie per veicoli elettrici.

Gli inverter, infatti, sono progettati per permettere aggiornamenti e manutenzione a distanza, ma negli Stati Uniti le aziende di servizi pubblici installano firewall per bloccare le comunicazioni dirette con server cinesi. Tuttavia, la presenza di apparecchiature di comunicazione non autorizzate – tra cui radio cellulari – aggira potenzialmente questi controlli. Negli ultimi nove mesi, componenti simili sono stati rinvenuti anche in batterie e altri dispositivi provenienti da diversi fornitori cinesi.

Il timore degli esperti è che questi sistemi possano essere utilizzati per interferire con la rete elettrica nazionale, causando malfunzionamenti o blackout mirati. Un precedente caso nel novembre 2024, in cui alcuni inverter sono stati disattivati da remoto dalla Cina, ha rafforzato i sospetti e spinto le autorità statunitensi a intensificare le ispezioni su tutte le tecnologie connesse alla rete.

A livello internazionale, alcuni paesi stanno già adottando misure concrete. La Lituania, ad esempio, ha introdotto una nuova legislazione che vieta l’accesso remoto ai produttori cinesi di inverter nei siti con capacità superiore a 100 kilowatt. La norma si applica alle nuove installazioni dal 1° maggio 2025, e richiede agli impianti esistenti di adeguarsi entro maggio 2026, rafforzando così la protezione della propria infrastruttura energetica.

Questa vicenda sottolinea quanto sia cruciale garantire la sicurezza dei dispositivi collegati alla rete, soprattutto in un contesto di transizione energetica globale sempre più dipendente dalla tecnologia digitale.

La trasparenza nella produzione e nella documentazione tecnica dei componenti elettronici sarà fondamentale per prevenire rischi futuri e tutelare la sovranità tecnologica delle nazioni.

L'articolo Infrastrutture Energetiche Nel Mirino! Gli Inverter Cinesi Sono Controllati Da Remoto proviene da il blog della sicurezza informatica.

Earlier this month we covered the brewing controversy over libogc, the community-developed C library that functions as the backbone for GameCube and Wii homebrew software. Questions about how much of the library was based on leaked information from Nintendo had been circulating for decades, but the more recent accusations that libogc included code from other open source projects without proper attribution brought the debate to a head — ultimately leading Wii Homebrew Channel developer Hector Martin to archive the popular project and use its README as a central point to collect evidence against libogc and its developers.

At the time, most of the claims had to do with code being taken from the Real-Time Executive for Multiprocessor Systems (RTEMS) project. Martin and others in the community had performed their own investigations, and found some striking similarities between the two codebases. A developer familiar with both projects went so far as to say that as much as half the code in libogc was actually lifted from RTEMS and obfuscated so as to appear as original work.

While some of these claims included compelling evidence, they were still nothing more than accusations. For their part, the libogc team denied any wrongdoing. Contributors to the project explained that any resemblance between libogc code and that of either leaked Nintendo libraries or other open source projects was merely superficial, and the unavoidable result of developing for a constrained system such as a game console.

But that all changed on May 6th, when the RTEMS team released an official statement on the subject. It turns out that they had been following the situation for some time, and had conducted their own audit of the libogc code. Their determination was that not only had RTEMS code been used without attribution, but that it appeared at least some code had also been copied verbatim from the Linux kernel — making the license dispute (and its solution) far more complex.

Permissive vs Restrictive

At first glance, this all might seem like something of a non-issue. After all, libogc, RTEMS, and the Linux kernel are all open source projects. Surely, the point of releasing these projects as open source in the first place was to facilitate and even encourage the sharing of source code. In a sense, this could be looked at as the system working as intended.

Indeed, it’s not the reuse of code that’s really the issue here. The problem stems from the licenses by which the respective projects have made their source code available, and more specifically, how well those licenses integrate with each other.

When the complaint was that libogc was using large swaths of code from RTEMS, the path towards compliance was simple as latter project was released under what’s known as a permissive license, namely, the 2-Clause BSD License. As the name implies, permissive licenses such as this give the user broad rights on how they can reuse the code

For example, one could take BSD-licensed code, merge it as-is into a closed source project, and sell the resulting software for profit without violating the license. All the original project asks in return is that you give proper attribution. In this case, that means acknowledging you used code from said project in the documentation, and including a copy of the license.

Returning to libogc, the issue at hand could be resolved with a single commit to the project’s GitHub repository. A simple notice that the project used code from RTEMS and a copy of the BSD license is all it would take to satisfy the requirements. That the libogc developers will not make even such a simple concession in the face of overwhelming evidence that they did indeed reuse code is frankly indefensible; a sentiment expressed in the statement from the RTEMS developers:

RTEMS is open source and this means RTEMS can be copied and used as long as the license conditions are met and copyright is maintained. We are at a loss why there has been removal of license details and copyright and a general disregard to apply appropriate attributions. As a result the RTEMS license and copyright holders reserve their rights in relation to the copying of RTEMS code.

That being said, the revelation that libogc would appear to include code from the Linux kernel complicates matters considerably. Unlike RTEMS, Linux is licensed under the GPL v2 — a license that is not only far more restrictive, but viral in nature.

The Case for Kernel Code

It’s that viral aspect of the license that promises to give libogc the most trouble. If they did indeed use code from the Linux kernel, that would mean there are only two solutions. Either the offending code must be removed, or the entire project will need to be re-licensed under the GPL v2.

For a codebase as old as libogc, changing the license would be a massive undertaking, as every person who’s added code to the project would have to agree to have their individual contribution re-licensed. The libogc repository lists dozens of contributors, and that’s only since project was added to GitHub. As there appears to be no CREDITS file that lists the contributions before the advent of Git, there may be no way to know at this point how many contributors there actually are and what they added.

So the question of whether or not libogc uses Linux code is going to be critical to determining how the project moves forward. The RTEMS statement doesn’t go into great detail about this claim, simply stating that the “spinlock implementation is copied directly from Linux circa 2.4 or 2.6 release series.” Sure enough, when comparing the file spinlock.h file from the latest version of libogc to linux-2.6.0/include/asm-ppc/spinlock.h there are indeed functions which are nearly identical:

That said, this may not be as damning as it seems. To play Devil’s advocate, one could argue that the terse nature of assembly code means that a certain level of similarity is unavoidable between the two implementations. Of course, convention can only get you so far. It’s one thing to independently arrive at the same assembly code, but this explanation becomes harder to believe when you consider the identical variable names and comments.

What’s Next?

As of this writing, the libogc project has not made an official statement on the situation. We reached out to maintainer Dave [WinterMute] Murphy before going to press with this article, but he declined to comment, saying that he first needed to confer with the original developer of the library, Michael [shagkur] Wiedenbauer.

At the same time, our contacts within the RTEMS project have indicated they believe they have sufficient evidence to have libogc removed from GitHub if necessary. However, they’re understandingly hesitant to disrupt the Wii homebrew community over an issue that could ultimately be resolved with a simple discussion. While the potential use of Linux code does add a considerable wrinkle to the overall situation, if the libogc project would at least acknowledge the use of RTEMS code and properly attribute it after all these years, it would at least be a step in the right direction.

We’ll continue to keep an eye on the situation, and bring you updates as we have them. In the meantime, we think the final line of the RTEMS statement nicely summarizes the biggest takeaway from this whole mess:

Our goal now is to provide education on how the behavior engaged in by the devkitPro/libOGC project is a very good example of what not to do.

hackaday.com/2025/05/14/rtems-…

Qualcuno esperto in #legge , magari un #avvocato, mi aiuti a capire, per favore.

Tutto felice e contento ho firmato il referendum di cui si parla, condiviso da alcuni amici, ma sembrerebbe che sia addirittura controproducente una raccolta firme. Che fare, in questo caso? Sarà corretto quello che dice la rete Lenford? (fonte in chiusura del post).

Sono davvero amareggiato e confuso.

"NON ESISTE UN REFERENDUM SUL MATRIMONIO TRA PERSONE DELLO STESSO SESSO
In questi giorni sta circolando online la richiesta di firme per un referendum, che viene descritto dal partito promotore con queste parole: ‘si firma per il referendum sul matrimonio delle coppie same sex’.
Non è così.
Anche se si raccogliessero almeno 500.000 firme entro il 3 agosto 2025 e anche se il referendum venisse giudicato ammissibile (e, quindi, effettivamente proponibile) dalla Corte costituzionale, un esito favorevole nelle urne NON introdurrebbe in Italia il matrimonio per coppie formate da persone dello stesso sesso.
Quel referendum, infatti, vuole mantenere le unioni civili introdotte nel 2016, eliminando le parti che le differenziano dal matrimonio anche rispetto alla filiazione.
La conseguenza di una vittoria dei ‘SÌ’ sarebbe, perciò, questa: le coppie same sex potrebbero continuare soltanto a unirsi civilmente, parificando gli effetti della loro unione a quelli matrimoniali, ma non potrebbero sposarsi.
Questo è un punto che deve essere molto chiaro e che Rete Lenford, nata nel 2007 proprio con la campagna ‘Affermazione civile’ volta a introdurre in Italia il matrimonio per persone dello stesso sesso, ha il dovere di chiarire pubblicamente, a seguito di decine di richieste che ci stanno giungendo nelle ultime ore.
Nei prossimi giorni, e con ampio margine di anticipo rispetto alla scelta che potrà essere fatta sulla firma della proposta referendaria, Rete Lenford lavorerà a una nota illustrativa con uno sguardo ‘bifocale’:
1) tecnico, per un approfondimento sui singoli quesiti e sulla loro dubbia ammissibilità, anche (e soprattutto) per le contraddittorie conseguenze in punto di filiazione, specialmente con riguardo alle coppie conviventi e alla legge sulla procreazione medicalmente assistita (la quale, anche dopo il referendum, continuerebbe a mantenere il requisito esplicito della ‘diversità di sesso’ della coppia richiedente);
2) politico, per le significative implicazioni che questo referendum potrebbe generare sia sul percorso di introduzione del ‘matrimonio same sex’, sia su quello di riconoscimento delle famiglie omogenitoriali.
Naturalmente, e anche al fine di elaborare una posizione condivisa in vista del termine del 3 agosto prossimo, non mancheremo di attivare un confronto con le altre realtà associative, tenute sorprendentemente escluse da questa iniziativa partitica.
Nel frattempo, ci è risultato doveroso prenderci del tempo, ma allo stesso tempo chiarire sin da subito quale sarebbe l’esito del referendum, così da favorire soltanto firme consapevoli da parte di chi, già in questi giorni, decidesse di non aspettare una elaborazione delle realtà LGBT+ e volesse esprimere online la propria posizione."

facebook.com/Rete.Lenford/post…

@Alberto

#lgbt
#LGBTQIA #samesexmarriage #MatrimonioEgualitario

Rete Lenford - Avvocatura per i diritti LGBTI+

NON ESISTE UN REFERENDUM SUL MATRIMONIO TRA PERSONE DELLO STESSO SESSO In questi giorni sta circolando online la richiesta di firme per un referendum, che viene descritto dal partito promotore con...

^{www.facebook.com}