journalctl -u micro
104 subscribers
2.39K photos
234 videos
293 files
1.62K links
Esperienze e consigli di uno sviluppatore tech−unenthusiast

creation — 2021-04-29
owner — @Microeinstein

networks
@sigma_hub Σ
@ageiroumena
Download Telegram
Ah bene
Una piccola lista non esaustiva di vendor alternativi per computer e altri device Linux. Se ne conoscete altri li aggiungo.

Nota: non ho verificato affidabilità né qualità

Prevalentemente laptop / desktop / x64
Slimbook — ES
TUXEDO Computers — DE
Laptop with Linux — NL
Star Labs — UK
framework — USA
system76 — USA
Purism — USA
Kubuntu Focus (MindShare) — USA

Prevalentemente SBC / altro

Zima (IceWhale) — CH
LattePanda — CH
Pine64 — HK
Raspberry Pi — UK
🔥5
Ora posso controllare la TV del salotto stando comodamente seduto in camera, oppure da telefono, oppure da internet appena metto wireguard
Odio la vita
Sto cercando di migrare da Syncthing a Syncthing-Fork, peccato che gli sviluppatori abbiano rimosso la possibilità di importare dal vecchio formato di configurazione
https://forum.syncthing.net/t/syncthing-fork-new-config-format-prevents-migration-from-legacy-syncthing-app/24496

Quindi mi tocca
• fare un backup sull'app originale (non più mantenuta)
• installare il fork 1.28.1 (che si trova SOLO qui)
• importare
• aggiornare a 1.30.0 (uguale, grazie izzysoft)
• esportare di nuovo
• disinstallare l'app (hanno cambiato package id...)
• installare l'ultima versione
• reimportare

Edit: ok, la vecchia versione è presente nei repo FDroid come "Syncthing-Fork v1"
Sto provando NVMe over Fabrics tra la zimaboard e il mio pc, figata spaziale. Si può esporre via TCP qualsiasi dispositivo a blocchi (sia dischi interi che partizioni, sia SSD che HDD, anche volumi LVM) con latenza zero e banda sfruttata al massimo.

Unico contro: anche se il protocollo supporta più client sullo stesso device, i dati verranno inevitabilmente corrotti, a meno di utilizzare un filesystem adatto per cluster
🔥1
Si vola, posso tornare a chiudere la porta anche qui
🔥1😁1
journalctl -u micro
https://gist.github.com/rikka0w0/50895b82cbec8a3a1e8c7707479824c1
IPXE fighissimo per fare il boot fa rete MA è impossibile avviare un kernel con initramfs (come un bootloader qualsiasi) per motivi che ancora non comprendo del tutto.

Anche se con uefi è necessario passare --initrd immagine.img da riga di comando, il kernel ne ignora l'avvio, usa quindi la modalità legacy montando direttamente l'argomento root= fallendo miseramente e andando in kernel panic.

ALLORA per non impazzire ho creato un UKI (Unified Kernel Image) ovvero un binario unico efi con vmlinuz + initramfs + riga di comando + ecc, ed ha funzionato. Non serve firmarla se non si ha secure boot.
Inoltre ho visto che quelli di Arch hanno messo un QR con background blu in caso di kernel panic, come i BSOD di Windows
Un'altra figata di IPXE è che può avviare menu e immagini da HTTPS, quindi ci si può sbizzarrire con contenuti dinamici anche PHP
Quando le figate diventano necessari per fare workaround ... non sono più così divertenti
(qui sono in un ambiente archiso custom)
🔥1
Media is too big
VIEW IN TELEGRAM
La tela è tessuta. Full-disk sharing via NVMe over TCP / Initramfs / hook custom

Consigliati ma non necessari:
UKI / IPXE / PHP / HTTPS
👍1