Tutti amiamo quando la fisica decide di collaborare invece di complicarci la vita con costi di produzione folli e catene di approvvigionamento che sembrano un dungeon di un RPG di livello 99.

Se seguite un minimo le news sul settore automotive, sapete che il grande elefante nella stanza è la dipendenza dalle terre rare. Ne terreste un po’ per costruire un magnete decente, ma il problema non è solo la scarsità, è il caos geopolitico e l’impatto ambientale di estrarle. È quel classico caso di ‘single point of failure’ che fa tremare i polsi a chiunque abbia un minimo di senso strategico. Renault, però, sembra aver trovato un workaround interessante: stanno spingendo su motori elettrici che non ne hanno bisogno.

Non è magia nera e non è un miracolo divino, è ingegneria. L’idea è quella di usare motori a magneti assenti, puntando su configurazioni che sfruttano altri principi elettromagnetici. Ora, non aspettatevi che il motore sia un piccolo prototipo fatto in garage con un Arduino e due bobine di rame, ma il concept è rivoluzionario per la scalabilità industriale. Se riesci a eliminare un componente critico che costa un occhio della testa e che dipende da un unico fornitore globale, hai appena vinto la partita della supply chain.

Da smanettone, la cosa che mi eccita di più è la democrazia tecnica che questa scelta sottintende. Meno dipendenza da materiali rari significa che la barriera all’ingresso per innovare la produzione si abbassa. È un po’ come quando passi da una libreria proprietaria e super complessa a qualcosa di più standard e modulare: meno headache, meno costi e più spazio per la creatività.

Certo, resti con il dubbio: quanto è efficiente questo motore rispetto a un classico PMSR (Permanent Magnet Synchronous Motor)? Sappiamo che i motori senza terre rare hanno spesso sfide legate alla densità di coppia o alla gestione termica. Ma se il trade-off è un motore leggermente meno performante ma infinitamente più sostenibile e facile da produrre in massa, allora il deal è decisamente accettabile.

Per noi che amiamo smontare oggetti e capire come far girare le cose con quello che abbiamo sotto mano, vedere un gigante dell’automotive che smette di inseguire l’hype dei materiali preziosi per concentrarsi su soluzioni più robuste e indipendenti è una boccata d’aria fresca. Meno fuffa marketing, più sostanza ingegneristica. Speriamo solo che non usino questa scusa per complicarci il debugging dei sistemi di controllo termico quando andremo a smontare la prossima vettura elettrica!

Source: Electric motors with no rare earths

C’è un livello di stress che va ben oltre il vedere il tuo codice andare in crash dopo una notte di debugging senza caffè. Immaginate di trovarvi in un ambiente a pressione controllata, a chilometri di altezza, e di sentire un sibilo che non dovrebbe esserci. Ecco, la NASA ha appena vissuto questo momento decisamente poco rilassante.

Recentemente, sulla Stazione Spaziale Internazionale (ISS) è stata rilevata una perdita d’aria. Non parliamo di un piccolo bug nel modulo di gestione del software o di un sensore che va in loop infinito; parliamo di un problema strutturale serio. La NASA ha dovuto dare ordini drastici: cinque astronauti su sette sono stati evacuati dalla zona interessata e sono stati fatti rifugiare all’interno del modulo SpaceX Crew Dragon «Freedom». Mentre loro stavano lì, in attesa che la situazione si stabilizzasse, due cosmonauti russi hanno dovuto mettersi al lavoro per tentare una riparazione d’urgenza.

Da smanettone, la prima cosa che mi viene in mente è: che tipo di patch stavano applicando? Se fosse un circuito stampato, avrei suggerito un po’ di resina epossidica o una buona goccia di saldatore, ma quando sei nello spazio, il ‘quick fix’ è decisamente più complicato. Il problema è che la ISS è, a tutti gli effetti, il progetto di engineering più complesso mai realizzato, un mix di hardware di epoche diverse, protocolli legacy e componenti di fornitori differenti che dovrebbero convivere in un ecosistema perfetto. E invece, ecco il leak.

Questa notizia ci ricorda una cosa fondamentale che noi che amiamo il makerismo sappiamo bene: l’importanza della manutenzione predittiva e della ridondanza. Se un pezzo di hardware fallisce in un ambiente controllato, hai un piano di backup. Se fallisce in orbita, hai un problema di sopravvivenza. Mi fa riflettere su quanto sia critico non sottovalutare mai i componenti ‘low-level’. Possiamo anche passare le ore a ottimizzare un shader in Blender o a scrivere script Python complessi per l’IA, ma se la struttura fisica (il ‘hardware’ di base) cede, tutto il resto è inutile.

Certo, c’è da lodare la capacità di reazione. L’uso del Crew Dragon come ‘safe room’ è una prova del fatto che l’integrazione tra sistemi diversi (SpaceX e la struttura russa/americana della ISS) funziona, almeno nelle emergenze. Ma speriamo che la prossima ‘update’ non richieda di resettare l’intera stazione spaziale come se fosse un router impazzito. Incrociamo le dita per i russi e per gli astronauti, e speriamo che il prossimo leak sia solo quello di una memoria RAM difettosa sul mio vecchio PC retro.

Source: Astronauts told to return to ISS after sheltering over air leak repairs

E se vi dicessi che il problema dell’acqua dolce non è la mancanza di risorse, ma il fatto che siamo storicamente dei pessimi gestori degli scarti?

Per anni, la dissalazione è stata quel processo un po’ ‘dirty’ che, pur regalandoci acqua potabile, ci lascia in mano una brodaglia di salamoia iper-concentrata e carca di additivi chimici, un vero incubo per gli ecosistenti marini. È un po’ come quando provi a fare il debugging di un codice complesso e, per risolvere un memory leak, finisci per saturare la RAM con log inutili: hai risolto il problema primario, ma hai creato un altro casino da gestire.

Però, occhi aperti, perché la notizia che arriva dall’Università di Rochester è decisamente stimolante. Sembra che abbiano trovato un modo per rendere il processo efficiente dal punto di vista energetico, eliminando l’uso di additivi chimici e, la parte che mi ha fatto saltare dalla sedia, trasformando i residui di sale in materiali utili. In pratica, invece di avere un sottoprodotto tossico che devi smaltire con costi e fatica, ottieni una risorsa. È il concetto di ‘zero waste’ applicato alla macro-ingegneria.

Da smanettone, la prima cosa che mi viene in mente è: come funziona il loop di feedback? Se riesci a estrarre valore dal rifiuto, hai creato un sistema a ciclo chiuso che è l’incubo di ogni manager aziendale orientato al profitto a breve termine, ma il sogno di ogni maker che punta alla sostenibilità. Mi immagino già delle piccole unità di dissalazione modulari, magari alimentate da pannelli solari o turbine eoliche, che potrebbero essere implementate in contesti isolati o su infrastrutture decentralizzate.

Certo, restiamo con i piedi per terra. Non è che domani potremo stampare in 3D un impianto da milioni di litri nel nostro garage tra un progetto su Godot e un rendering su Blender. La sfida qui è la scalabilità e la meccanica del processo. Ma l’idea di non dover gestire la ‘brina’ chimica è una vittoria enorme.

Per noi che amiamo smontare le cose e ricostruirle con logica e ingegno, vedere che la scienza sta finalmente affrontando il problema dell’output (e non solo dell’input) è la scintilla che serve. Spero solo che questa tecnologia non finisca sotto qualche brevetto blindato che impedisce la replicabilità o l’implementazione low-cost. Perché se l’idea è buona, la vera magia accade quando la portiamo fuori dai laboratori accademici e la rendiamo accessibile a chi, come noi, non ha paura di sporcarsi le mani con un po’ di elettrotecnica e tanta sana curiosità.

Source: New method turns ocean water into drinking water, without waste

Chi l’ha detto che per avere potenza bruta bisogna per forza vivere attaccato al muro come un vampiro con l’alimentatore?

Per anni ci hanno venduto la solita storia: vuoi giocare ai titoli tripla A o far girare un modello di IA locale senza che la tua workstation esploda? Allora preparati a un peso morto che ti distrugge la schiena e una batteria che ha la resistenza di un pezzo di ghiaccio nel Sahara. Ma sembra che Nvidia abbia deciso di smetterla di prenderci in giro con i soliti compromessi da ‘mobile gaming’. La nuova linea RTX Spark sta facendo parlare di sé perché, e non è una mezza notizia, promette di mantenere prestazioni da desktop con un’autonomia che non fa piangere.

In pratica, Nvidia sta cercando di risolvere l’eterno dilemma del rapporto tra TDP e durata della batteria. Non sono qui per fare il comunicato stampa della multinazionale, ma l’idea di avere una macchina che può gestire rendering pesanti su Blender o compilare script complessi senza che la ventola sembri un decollo della NASA ogni volta che apri un tab di Chrome è una boccata d’aria fresca. Se l’hardware è ottimizzato come dicono, potremmo finalmente avere un dispositivo che non sia solo un ‘desktop che si piega’, ma un vero strumento di lavoro e svago portatile.

Da smanettone, però, la mia guardia resta alta. Sappiamo tutti come funziona il gioco: Nvidia ti dà la potenza, ma la ti lega con le catene del loro ecosistema. Mi chiedo subito quanto di questo ‘miracolo’ dipenda da ottimizzazioni software proprietarie che ti rendono schiavo dei loro driver e del loro stack tecnologico. Spero vivamente che non sia il solito caso di vendor lock-in mascherato da innovazione. Vorrei poter spingere l’hardware al limite senza dover chiedere il permesso a un algoritmo proprietario che decide cosa è ‘efficiente’ e cosa no.

Per noi che passiamo le notti a far girare emulatori, testare nuovi motori grafici su Godot o far macinare i neuroni alle IA locali, un laptop del genere potrebbe essere la svolta. Immaginate di poter portare il vostro setup di sviluppo o la vostra console retro-gaming personalizzata in un workshop, in un fablab o semplicemente sul divano, senza l’ansia costante di vedere l’icona della batteria che lampeggia in rosso. Se la promessa è vera, è un upgrade che meritiamo tutti. Se è solo marketing aggressivo per gonfiare i prezzi… beh, sapete come finisce la storia.

Restiamo sintonizzati, ma con un occhio critico e le pinzette pronte per smontare ogni singola promessa.

Source: Nvidia’s RTX Spark Laptops Are the Kick in the Ass Gaming PCs Needed

Se un computer crasha mentre stai compilando un progetto importante, ti arrabbi e ricominci da capo. Se un razzo da centinaia di metri si schianta nel Golfo del Messico durante il primo volo della sua nuova versione, SpaceX lo chiama ‘un successo straordinario’. Benvenuti nel mondo della V3.

Sì, avete letto bene. Il 22 maggio 2026, SpaceX ha finalmente dato il via al Flight 12 della nuova Starship V3. Non è stato un volo perfettamente nominale (scusate la terminologia da manuale), ma è stato un mix incredibile di ingegneria d’avanguardia e caos controllato. Il nuovo design della V3 promette rivoluzioni, ma il debutto è stato decisamente movimentato: un motore che ha deciso di andare in vacanza, un booster che non ha completato la sua missione originale e una serie di manovre che avrebbero fatto sudare anche un pilota di simulatore di volo professionista.

Andiamo al sodo: cosa è successo davvero? Mentre il primo stadio cercava di fare il suo dovere, uno dei motori ha smesso di collaborare, rendendo impossibile la manovra di rientro prevista. Il risultato? Un’esplosione (o meglio, un ‘ritorno al pianeta non pianificato’) che ha trasformato il booster in un gran relitto oceanico. Però, guardando oltre il fumo, c’è del concreto. La parte superiore della navetta ha completato il suo percorso, testando i nuovi sistemi e i payload sperimentali, tra cui quei famosi piccoli satelliti che devono ancora dimostrare il loro valore.

Per noi che amiamo smanettare con hardware e codice, il messaggio è chiaro: l’iterazione è tutto. Non importa se il primo prototipo va in crash, l’importante è che i log della telemetria ti dicano esattamente *perché* è esploso. SpaceX sta facendo esattamente questo: testare i limiti fisici della materia, fallire in modo spettacolare e usare i dati di quel fallimento per la versione 1.1, 1.2 e così via, fino alla stabilità definitiva.

La vera sfida per il futuro non è solo evitare che i motori si spengano, ma gestire la complessità della nuova architettura. La V3 deve gestire carichi enormi e sistemi di rifornimento in orbita che sono, a tutti gli effetti, il debugging definitivo in ambiente di produzione (l’orbita terrestre). Se riusciranno a rendere il sistema di rifornimento affidabile quanto un buon script Python ben commentato, allora la strada per Marte sarà aperta.

In breve: il volo non è stato perfetto, ma il ‘commit’ è stato accettato. Restiamo in attesa del prossimo aggiornamento, sperando che il prossimo test non richieda troppi pezzi di ricambio nuovi.

Source: SpaceX launches Starship v3 rocket

Smettetela di cercare la funzione matematica magica che risolva tutto, perché la realtà ha una brutta abitudine a non essere derivabile in ogni suo punto.

Avete presente quel momento in cui state cercando di calibrare un encoder su una CNC fatta in casa e, nonostante tutti i calcoli sulla carta sembrino perfetti, il pezzo esce completamente storto perché il motore ha un micro-slittamento imprevedibile? Ecco, l’attuale hype dell’Intelligenza Artificiale sta vivendo lo stesso identico momento di crisi, ma su scala planetaria. Recentemente, un pezzo su Astral Codex Ten ha sollevato un dubbio che molti dei ‘big tech evangelist’ preferirebbero ignorare: l’idea che funzioni matematiche eleganti e ‘morbide’, come la sigmoide, possano catturare la complessità caotica del mondo reale.

Il punto è questo: stiamo costruendo modelli basati su funzioni di attivazione che tendono a ‘appiattire’ i valori estremi, cercando di creare una regolarità dove invece regna il disordine. Le sigmoidi sono bellissime, sono lisce, sono matematicamente rassicuranti. Ma il mondo non è una curva di regressione perfetta. Il mondo è fatto di discontinuità, di picchi improvvisi, di eventi che non seguono una distribuzione gaussiana così carina. Se provi a modellare un sistema fisico reale — tipo una macchina che ricicla plastica che deve gestire variazioni di temperatura e densità del polimero — usando solo logiche che tendono all’appiattimento, prima o poi il sistema va in allucinazione o, peggio, fallisce miseramente.

Da smanettone che passa le serate a debuggare script in Python o a modellare parti in Blender, trovo che questa discussione sia fondamentale. Spesso ci incaponiamo a cercare la soluzione ‘elegante’ nel codice, dimenticando che l’hardware e la fisica hanno una loro voce, spesso molto rumorosa e tutt’altro che smooth. Il rischio dell’attuale corsa all’IA è quello di creare dei ‘modelli prigionieri’ della propria matematica: sistemi che sembrano intelligenti finché la situazione resta entro i binari prestabiliti, ma che diventano completamente inutili non appena accade qualcosa di veramente nuovo o imprevisto.

Per noi che amiamo il low-level, il retrocomputing e la costruzione di macchine reali, questo è un promemoria vitale. Non fidatevi ciecamente di ciò che appare ‘fluido’ o ‘ottimizzato’ da un black box proprietario. La vera ingegneria sta nel capire dove la curva si rompe e nel saper gestire il rumore. Se i modelli di domani non impareranno a gestire l’imprevedibilità delle funzioni discontinue, resteranno solo dei bellissimi giocattoli matematici, incapaci di interagire con il ferro, i circuiti e la materia che noi, ogni giorno, cerchiamo di domare nel nostro garage.

Source: The sigmoids won't save you

Dimenticate i lanci di prodotto patinati con luci LED e presentazioni in 8K che non servono a nulla se non a gonfiare il valore delle azioni. Il vero cuore pulsante della tecnologia non si trova nei keynote della Silicon Valley, ma nei commenti di un thread di Hacker News dove la gente vera — quella che non ha paura di bruciare un microcontrollore — si scambia idee su cosa sta costruendo nel proprio garage.

È uscito il classico ‘What are you working on?’ di maggio 2026 e, come ogni mese, la community ha risposto con quella dose di genialità pura e caos creativo che ci tiene in vita. Mentre i big tech si scervellano su come venderti un altro abbonamento mensile per farti usare la tua stessa stampante, qui si parla di roba seria: nuovi firmware per retrocomputing, ottimizzazione di algoritmi di machine learning per far girare l’AI su hardware che ha l’età del mio primo Commodore, e progetti di riciclo plastico che sembrano usciti da un film di fantascienza low-budget.

Leggere questi thread è come fare benzina. C’è chi sta rifacendo il design di una CNC per renderla più precisa usando componenti recuperati da vecchie stampanti 3D e chi sta scrivendo un motore grafico da zero su Godot, solo per il gusto di dire ‘l’ho fatto io’. È quella tipica sana ossessione che ci spinge a passare le notti su Blender a modellare componenti che poi, con un po’ di fortuna e tanto nastro isolante, cercheremo di materializzare nella realtà.

Per noi che amiamo mettere le mani in pasta, questi thread sono una miniera d’oro. Non è solo ‘cosa’ viene costruito, ma il ‘come’. È il debugging ossessivo, è l’approccio open-source che combatte il vendor lock-in, è l’idea che un pezzo di plastica di scarto possa diventare un ingranaggio funzionale grazie a una macchina autocostruita.

Certo, c’è sempre quel 5% di fuffa o di progetti che sembrano troppo ambiziosi per non finire in un cassetto dopo due settimane, ma è il prezzo da pagare per far parte di questa tribù. La vera magia accade quando un’idea detta in un commento diventa il progetto che ti tiene sveglio fino alle quattro del mattino, con la saldatrice in mano e una tazza di caffè freddo accanto.

E voi? State scrivendo codice che funziona o state solo cercando di capire perché quel sensore non risponde al comando? Fatemelo sapere nei commenti, che qui abbiamo tutti bisogno di un po’ di ispirazione (e di qualche idea per il prossimo progetto inutile ma bellissimo).

Source: Ask HN: What are you working on? (May 2026)

Avete presente quando state smanettando con un nuovo script o configurando un driver e, dopo un errore chilometrico, l’AI vi risponde con un «Mi dispiace molto per l’inconveniente, capisco la tua frustrazione»? Ecco, in quel preciso istante, state cadendo nel tranello.

Recentemente è uscito un paper di Susam Pal che mette dei paletti molto sani (e necessari) al caos che stiamo vivendo con l’AI generativa. L’autore propone le «Tre Leggi Inverse della Robotica». E no, non sono le leggi di Asimov per impedire ai robot di massacrare l’umanità, ma una guida per impedire agli umani di diventare degli idioti digitali.

Il punto centrale è che stiamo diventando troppo pigri. Con l’integrazione dei chatbot direttamente nei motori di ricerca, la tentazione di leggere il primo paragrafo generato e dire «ok, fatto» è altissima. Il problema è che questi sistemi sono progettati dai vendor per sembrare empatici, umani, quasi… amichevoli. È puro marketing, ragazzi. È una patina di cortesia applicata sopra un gigantesco calcolo probabilistico che non ha la minima idea di cosa sia la verità, ma sa benissimo quali parole suonano bene insieme.

Le tre leggi di Pal sono terra terra, ma fondamentali per chi, come noi, vive di debug e hardware:

1. Niente antropomorfizzazione: Non attribuite emozioni o intenzioni all’AI. È un modello statistico, non un compagno di workshop. Se inizia a sembrare troppo ‘umana’, smanettate sul prompt per renderla più meccanica. Aiuta a mantenere la prospettiva.

2. Niente fede cieca: Non prendete per oro colato quello che sputa fuori. Se sta generando codice per il vostro progetto in Godot o una configurazione per una CNC, verificate. Usate i unit test, usate i proof checker, usate il buon senso. L’AI può allucinare con una convinzione tale che sembrerebbe un ingegnere senior con troppa caffeina.

3. La responsabilità è vostra: Se l’AI vi suggerisce una modifica al firmware che fa esplodere il vostro prototipo, non potete dire «me l’ha detto ChatGPT». La responsabilità del deploy e delle conseguenze resta sempre in mano a chi preme l’invio.

Per noi che amiamo smontare le cose, questo è un richiamo alla nostra natura: noi siamo quelli che controllano il basso livello. Non possiamo permetterci di delegare il pensiero critico a un software che non ha nemmeno un’interfaccia fisica. Usiamo l’AI come un assistente super veloce, un pennello avanzato per Blender o un suggeritore di codice, ma restiamo noi i progettisti.

In un mondo che corre verso l’automazione totale, l’unica vera difesa è continuare a essere quelli che sanno come funziona il codice sotto il cofano. Non lasciate che il comfort della risposta pronta sostituisca la soddisfazione del capire davvero.

Source: Three Inverse Laws of AI

Chi l’avrebbe mai detto che per testare un sistema a pressione idrica avremmo avuto bisogno di un’esplosione degna di un episodio di Transformers?

Sì, avete letto bene. Mentre tutti aspettano con il fiato sospeso il prossimo lancio di Starship, SpaceX ha appena trasformato un test di routine del sistema di ‘water deluge’ in un piccolo spettacolo pirotecnico non programmato. In pratica, stavano cercando di perfezionare il sistema di raffreddamento a pioggia per evitare che la forza bruta del lancio spacchi tutto il pad di lancio, e invece hanno ottenuto un’esplosione che ha fatto tremare la base.

Per chi non mastica il gergo dei lanci spaziali, il sistema di ‘deluge’ è fondamentalmente una gigantesca doccia ad alta pressione progettata per assorbire l’energia termica e acustica. Ma, come spesso accade quando si lavora con pressioni elevate e hardware custom, qualcosa ha deciso di non collaborare. La notizia ufficiale parla di ‘kinks da risolvere’, che è il modo elegante e corporate per dire: «Ragazzi, abbiamo un problema serio con la gestione delle pressioni e probabilmente abbiamo distrutto un pezzo di infrastruttura».

Da smanettone che non ne può più dei prodotti ‘black box’ che si rompono appena li tocchi, trovo questa cosa incredibilmente familiare. È lo stesso feeling che si prova quando provi a sovraalimentare un vecchio motore o quando carichi un firmware non ottimizzato su una scheda ESP32 e tutto il modulo inizia a fumare. La differenza è che se fallisco io, brucio un sensore da dieci euro; se falliscono loro, mandano in orbita (o giù, nel caso specifico) tonnellate di metallo costoso.

Per noi maker e ingegneri del garage, c’è però un lato positivo da celebrare. Vedere SpaceX che fallisce pubblicamente durante i test è una lezione di verità: il ‘fail fast, fail often’ non è solo uno slogan da startup della Silicon Valley, è l’unico modo per arrivare al successo. Sbagliare il setup di una pompa idraulica è doloroso, lo so, ma è proprio analizzando i log del crash che si scrive il codice (o si progetta il sistema) che funziona davvero.

Quindi, niente panico. Se riescono a gestire un’esplosione durante un test idrico, un lancio interplanetario non sarà poi così complicato, no? Restiamo in attesa di vedere se il prossimo aggiornamento del sistema sarà un fix software o se dovranno letteralmente ricostruire la doccia da capo.

Source: Explosion Rocks SpaceX’s Test of Water Deluge System Ahead of Starship Launch

Dimenticate il fragore assordante che vi farebbe saltare i componenti dal banco da saldatura ogni volta che un jet passa sopra la testa.

La NASA ha appena rilasciato dei video dell’X-59 che sfreccia sopra il deserto del Mojave, e non sono solo spettacolari manovre acrobatiche per farci sognare, ma rappresentano un tentativo serio di risolvere uno dei problemi più irritanti della tecnologia aeronautica: il boom sonico. Avete presente quando state scrivendo una riga di codice complessa o state cercando di calibrare una stampante 3D e un rumore improvviso vi fa perdere il filo? Ecco, il boom supersonico è esattamente quel tipo di ‘interruzione non richiesta’ che non vogliamo più sentire.

L’obiettivo del progetto è quello di creare un volo supersonico ‘silenzioso’. In pratica, l’idea è di modificare la forma dell’aereo per dissipare le onde d’urto, trasformando quel ‘BOOM’ devastante in un semplice ‘thump’ che sembri quasi un battito lontano. Se ci riuscite, l’idea è di poter riaprire i voli supersonici su rotte commerciali senza far incazzare i residenti sotto le piste.

Da smanettone, la cosa che mi affascina non è solo l’aerodinamica (che è comunque una figata pazzesca, un vero capolavoro di modellazione fluida), ma l’approccio ingegneristico al problema del rumore. È un po’ come quando cerchiamo di ottimizzare un algoritmo pesantissimo: l’obiettivo non è solo farlo girare, ma farlo girare senza saturare ogni singola risorsa del sistema. Qui stiamo parlando di gestire l’energia delle onde d’urto come se fossero pacchetti di dati che dobbiamo instradare senza causare collisioni nella rete.

Certo, restiamo con i piedi per terra. Vediamo quanto tempo ci vorrà prima che i grandi player dell’aviazione decidano di implementare questa tecnologia invece di continuare a venderti il solito modello con il ‘vendor lock-in’ dei costi di manutenzione folli. Ma l’idea di avere voli superveloci che non sembrano un attacco aereo è qualcosa che merita un applauso.

Per noi che amiamo smontare e rimontare il mondo, vedere la tecnologia che affronta un problema fisico così brutale con una soluzione così elegante è la benzina giusta per continuare a sperimentare. Se la NASA riesce a domare le onde d’urto, forse un giorno potremo anche noi progettare qualcosa che non faccia tremare tutto il garage quando si attiva il motore.

Source: Watch NASA’s Supersonic Jet Pull Off Some Sweet Maneuvers in Recent Test