Oggi mi son divertito un po’ a creare uno script “Arch Update Checker” da usare su Arch Linux (niente derivate).
Lo script pesa pochissimo, è bilingue, ha un controllo degli errori testato e verificato e se messo in autostart controlla dopo 30 secondi dall’avvio del sistema e poi ogni ora (non usare chron, ci pensa già lui).
Se si ha yay o paur controlla anche la presenza di aggiornamenti nel database AUR (altrimenti solo di sistema tramite pacman).
Io ho messo il file .sh in: /home/mioutente/.config/ Ricordarsi di dare i permessi di esecuzione (chmod +x nomefile.sh).
E il file .desktop in: /home/mioutente/.config/autostart/
In principio c’era LiLo, ma ormai è storia antica.
Da più di un decennio uso esclusivamente Grub come boot manager predefinito e mi è sempre piaciuto per la grande capacità di customizzazione (temi, nuove voci, ordine personalizzato).
Ultimamente però, quasi tutte le distribuzioni spingono ad usare systemd-boot (ormai come scelta consigliata di default).
Avendo reinstallato da pochissimo (ne ho parlato qui: arch-linux-fix-adb-permission-issue), ho dunque deciso di provare systemd-boot e devo ammettere che in un primo momento mi son sentito totalmente smarrito.
Cosa è successo?
È successo che non potevo aggiungere Spegni(mi piace averlo di default, così se il cane, il gatto, la moglie o le bimbe accendono per sbaglio il pc almeno si spegne da solo dopo pochissimo tempo), non potevo riordinare come volevo, non riuscivo ad aggiungere Windows (installato su altro hd con uefi separata, così da avere entrambi i sistemi autonomi e funzionanti anche se stacco o si rompe uno dei due dischi).
Come ho risolto?
Per inserire Windows ho semplicemente copiato l’intera directory dalla efi del disco Windows: /EFI/Microsoft/ in /boot/EFI/
Avendo così /boot/EFI/Microsoft/ mi son ritrovato la voce Windows 11 dopo un semplicissimo riavvio.
Insomma, systemd-boot si è rilevato una piacevole sorpresa e adesso che inizio a saperci smanettare posso dire che son contento di aver sostituito grub.
A titolo di cortesia…
Vi aggiungo qui i file già compilati e col percorso.
Vi basterà estrarli nel percorso corretto e riavviare 😉
Authy, per chi non la conoscesse, è una famosissima app per l’autenticazione a 2 fattori (2fa).
Il successo di Authy probabilmente è stato il suo essere multi-piattaforma (io la usavo su Android, Linux e Windows così da avere un backup nel caso in cui avessi perso il telefono).
Incomprensibilmente, purtroppo, Authy ha deciso di terminare il supporto all’app desktop e concentrarsi solo su quella mobile (che a questo punto non ha niente di più di tante altre app, spesso graficamente più belle e con molte più funzionalità).
Ho dunque deciso di abbandonare Authy ma… Cosa scegliere?
Authenticator Pro permette davvero tantissime personalizzazioni, praticamente nessun permesso (non lavora online) e permette di editare gli elementi già presenti o di esportarli/importarli in pochi click.
Ok, possiamo dunque abbandonare Authy su Android, ma rimane il problema per Linux e Windows.
Cercando e ricercando, alla fine – usando Firefox (ma c’è anche per Chrome) – ho scelto la comoda estensione che permette di avere i codici OTP (One Time Password) direttamente nel browser: GitHub:Authenticator-Extension
Funziona in modo ottimale, non richiede account, comoda modalità di importazione ed esportazione (ho importato in pochi secondi i codici già presenti su Authenticator PRO, esportati poco prima in modalità testuale).
Riguardo ad Authy, c’è una procedura un po’ complicata per esportare i dati attualmente presenti, ma personalmente preferisco rifarli tutti (così facendo st anche controllando e ripulendo un po’ di roba nei singoli account).
E voi che soluzione avete trovato? Conoscete app migliori?
Ultimamente ho passato alcuni giorni facendo distro hopping a manetta (usavo manjaro ormai da qualche tempo, ma era ora di cambiare anche perchè mi ha dato spesso problemi di repo, chiavi scadute e dipendenze incasinate! e poi è una derivata e io non son stato mai granchè amante delle derivate…).
In ordine ho provato:
Debian(la mia distro madre se vogliamo): La stable poco aggiornata, la testing meno sicura di stable e sid, sid potenzialmente troppo instabile! e comunque abbandonai debian tanti anni fa causa freeze periodico (https://guide.debianizzati.org/index.php/Freeze)
LMDE(linux mint debian edition): bello, facile e veloce, vede tutto senza problemi, ma usa cinnamon e io voglio kde (amo kde connect e comunque continuo a credere che le derivate non abbiano molta ragione di esistere).
EndeavourOS(derivata arch): davvero niente male come approccio facile ad arch linux, ma “troppo” smanettata e con troppe aggiunte (si è capito che tollero poco le derivate?)
Tumbleweed(OpenSuse rolling release): sembrava la distro perfetta (una rolling stabile e completa), ma sarà che conosco piuttosto bene solo debian* e arch* (* = e derivate!), ho letteralmente distrutto il bootmanager di opensuse dopo il primo riavvio e non ho nemmeno capito perché (mai successo con nessuna distro, nemmeno con le più ostiche).
Insomma, deluso e sconsolato (o meglio, il solito inaccontentabile) la scelta era: Debian vs Arch (ma odiando il Debian freeze ho deciso di puntare su Arch, installato in pochi minuti grazie ad ArchInstall).
Il brutto (o bello?) di Arch, però, è che non è tutta pappa pronta e tocca smanettarci appena installato altrimenti tante cose non potranno funzionare (per fare un esempio, su tutte le altre distro provate la mia stampante hp era già bella e operativa in tray, su arch ho dovuto installare manualmente hplip+cups e avviare il servizio di stampa), ma io son sempre stato un po’ masochista e quindi è letteralmente la distro perfetta per me.
Dopo questa dovuta premessa, ecco il problema con android-tools(uso PixelFlasher per aggiornare il mio Pixel 7 Pro rootato e per la prima vola non riuscivo a farlo funzionare):
In pratica adb non voleva saperne di funzionare correttamente e andava solo tramite root o impostando manualmente dallo smartphone la preferenza USB su “Trasferimento file”(ma PixelFlasher non è bene usarlo via root e comunque anche impostando su File poi si avevano problemi ai seguenti riavvii).
Così mi sono messo a cercare una soluzione e ho scoperto che mancavano le regole udev per gestire correttamente i dispositivi usb.
E trovato info sul file: /lib/udev/rules.d/51-android.rules
Ho dunque scaricato e poi estratto il .deb, infine copiato il file “51-android.rules” in /etc/udev/rules.d/
Come previsto, dopo un riavvio ho ottenuto il risultato sperato:
adb funziona!Di conseguenza anche PixelFlasher
Ok, sembra complicato?
In effetti il problema è mio che prima provo a risolvere il tutto in modo astruso (ma efficace) e solo dopo scopro che bastava installare un pacchetto (presente sia nei repo che in aur, ma di cui non conoscevo il nome) per risolvere il tutto in pochi secondi:
Usando pacman -S nomepacchettoUsando yay nomepacchetto
Io ho preferito la versione aur (git) che è più aggiornata, ma la fonte è la medesima quindi nessun problema.
Se preferite un approccio più manuale (ma meno della mia soluzione di estrazione del deb), questa è l’origine del pacchetto (sia aur che arch): https://github.com/M0Rf30/android-udev-rules
Ecco, direi che è tutto.
Adesso insultatemi pure per aver scaricato ed estratto un .deb quando bastava semplicemente installare il pacchetto ufficiale di Arch o da Aur 😄
Gestisci Consenso Cookie
Per fornire la migliore esperienza, utilizziamo i cookie per memorizzare e/o accedere alle informazioni del dispositivo. Non acconsentire o ritirare il consenso può influire negativamente su alcune caratteristiche e funzioni.
Funzionale
Sempre attivo
L'archiviazione tecnica o l'accesso sono strettamente necessari al fine legittimo di consentire l'uso di un servizio specifico esplicitamente richiesto dall'abbonato o dall'utente, o al solo scopo di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica.
Preferenze
L'archiviazione tecnica o l'accesso sono necessari per lo scopo legittimo di memorizzare le preferenze che non sono richieste dall'abbonato o dall'utente.
Statistiche
L'archiviazione tecnica o l'accesso che viene utilizzato esclusivamente per scopi statistici.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
L'archiviazione tecnica o l'accesso sono necessari per creare profili di utenti per inviare pubblicità, o per tracciare l'utente su un sito web o su diversi siti web per scopi di marketing simili.
