Korora 26 “Bloat” è ufficialmente disponibile per il download.

Korora 26 è l’ultima versione della nota derivata di Fedora (nello specifico Fedora 26) che ha come caratteristica principale quella di facilitare l’utilizzo di Fedora grazie alla presenza di repository di terze parti e ottimizzazioni varie (tweaks, codecs e packages che non si trovano su Fedora).

Disponibile Korora 26 “Bloat”

porcospino bloat korora 26

La novità più importante di questa versione è l’abbandono del supporto a 32 bit: a partire da Korora 26 verranno supportati solo i sistemi a 64 bit (x86_64). Gli utenti che dispongono hardware in grado di far girare sistemi a 64 bit ma che in passato hanno installato la versione a 32 bit sono invitati dagli sviluppatori a migrare alla versione a 64 bit. Altri requisiti importanti: sono richiesti 2GB di memoria RAM e 20GB di spazio libero sul disco di sistema.
Cinque sono le edizioni disponibili, ognuna con uno specifico desktop environment:

  • Cinnamon 3.4;
  • Gnome 3.24;
  • Plasma 5.10;
  • Mate 1.18;
  • Xfce 4.12.

Ricordate che il desktop environment predefinito su Fedora è GNOME pertanto se non sapete quale edizione scegliere la GNOME-edition è sicuramente quella meglio ottimizzata.

Indipendentemente dal DE scelto avrete a disposizione una funzione di backup tutta nuova: “[…] Ad ogni release cerchiamo di migliorare il nostro sistema operativo. Questa volta abbiamo implementato una nuova app per il backup dei vostri dati che sarà presente in ogni edizione di Korora 26 […]“.

Una curiosità: il nome “Bloat” non è certo stato scelto perchè il sistema è pieno di bloatware. “Bloat” è il nome di un porcospino che compare nel popolare cartone “Alla ricerca di Nemo” prodotto da Disney/Pixar. Tutte le versioni di Korora prendono il nome di un personaggio di tale cartone.

Per il download di Korora 26 potete recarvi qui.

sharing-caring-1

Vi ricordiamo che seguirci è molto semplice: tramite la pagina Facebook ufficiale, tramite il nostro canale notizie Telegram e la nostra pagina Google Plus. Da oggi, poi, è possibile seguire il nostro canale ufficiale Telegram dedicato ad Offerte e Promo!

Qui potrete trovare le varie notizie da noi riportate sul blog. È possibile, inoltre, commentare, condividere e creare spunti di discussione inerenti l’argomento.

  • franck

    Dopo aver installato korora 26 kde, alla pagina da inserire la password per accedere, non la riconosce. Con altre distro tutto regolare. Installata due volte ma sempre con lo stesso problema. In dual boot con windows 10.

  • Kim Allamandola

    Il nome non è cmq mal scelto, IMO: tutto ciò che gravita intorno al software del cappello rosso, dal camaleonte alle varianti commerciali a quelle “ricompilate” dal tree ufficiale è un “bloat” nel senso di massa piena di problemi. Un tempo SuSe (ancora tedesca) aveva fatto una campagna pubblicitaria il cui slogan era “volete un sistema con mille programmi o uno con mille problemi?”. Bé mi duole ammetterlo ma se un tempo si intendeva GNU/Linux vs Windows direi che oggi la “migrazione” di utenti da Windows a portato GNU/Linux ad essere una massa di problemi sulla falsariga di Windows, mitigati solo dal fatto di essere in gran parte FOSS e di avere una base ancora di una certa solidità. Ciò che gravita intorno al cappello rosso è per me la causa prima di questo fenomeno, per lo più a mio avviso causa cecità, ignoranza e manie di grandezza.

    Spero solo che riesca a tornar diffusa a livello “di massa” qualche distro community-based che almeno cerchi di mitigare questo fenomeno altrimenti dovremmo, di nuovo, ripiegare su FreeBSD sperando nel supporto hw… Mala tempora currunt e i “polli” si beano del successo numerico attuale scavandosi la fossa sotto i piedi.

    Scusate il rant…

    • Maudit

      Non riesco a capire a cosa ti stai riferendo nello specifico, ma windows, a mio modesto parere, non è così influente, gli utenti che migrano ancora meno.

      • Kim Allamandola

        Prendi ad esempio pulsaudio, systemd (compresi i log binari) sino a snap/flatpack&c, sono tutte implementazioni di concetti tipici del mondo Microsoft, estranei al mondo UNIX. UNIX s’è sempre dedicato al mondo professionale nel quale il desktop non è granché sviluppato ma questo non vuol dire per evolvere seguire la strada già battuta da Windows con tutti i problemi noti del caso.

        Purtroppo sempre più sviluppatori vengono da Windows e trovano certe soluzioni “naturali” e le poche aziende che oramai “comandano” di fatto la community pensano che questo sia una buona cosa “perché Windows ha avuto successo. Diciamo che oggi IMO non esiste praticamente più una community GNU/Linux e quella che c’è gravita intorno a 4 aziende in croce. Di peggio i nuovi utenti nulla sanno di *nix e ripropongono soluzioni che conoscono, senza vederne i limiti e problemi. Di peggio ancora non c’è più sostanziale concorrenza “di alto livello” i classici unix commerciali oramai sono quasi spariti, conosciuti solo a pochi e sempre più chiusi in una nicchia…

        • DeeoK

          Snap e Flatpak vanno incontro agli utenti: dover sperare che il repository sia aggiornato o che ci sia qualche ppa o che ci sia un pacchetto pre-compilato per l’applicazione che vuoi installare è una rottura di maroni indescribile. Mettiamoci poi quando devi scaricarti l’archivio, compilartelo e sperare che vada tutto bene e che non manchi qualcosa perché a quel punto devi sperare che quel qualcosa sia ottenibile in tempi decenti.
          A conti fatti, al momento, nel mondo GNU/Linux installare un’applicazione è sempre un terno al lotto se non è nel repository e se anche va tutto bene spesso e volentieri c’è comunque da smanettare da qualche parte.
          Snap e Flatpak sono i benvenuti.

          Non mi esprimo sul resto perché non ho seguito le faccende.

          • Kim Allamandola

            > “Snap e Flatpak vanno incontro agli utenti”
            come ho già scritto molte volte per me van incontro *solo* alle software houses proprietarie che non volendo distribuire le source devono, nel modello tradizionale, supportare direttamente ogni distro e star dietro a tutti gli aggiornamenti.

            > dover sperare che il repository sia aggiornato
            Questo è il primo punto: ogni distro ha qualche repo “community” dove chiunque con quasi nessuna barriera di ingresso può impacchettare. Se un pacchetto non è aggiornato o non ci sono abbastanza packagers per la propria distro o vi sono altri buoni motivi. L’utente del FOSS è parte della community, non consumatore, quindi se gli manca qualcosa si informa e lavora. Se questo non va bene all’utente da supermercato non è un nostro problema: l’azienda al suo interno avrà il suo IT e il privato avrà qualche amico che gli dà una mano, altrimenti si paga qualcuno che sa farlo. FOSS non vuol dire birra gratis con un altro conto da pagare nascosto sottobanco.

            Comunque il tuo commento centra il mio punto: nel FOSS si è oramai insinuata la cultura Windows e una gran quantità di persone non conosce più la cultura FOSS e neppure ne comprende i principi e non vede i limiti e i problemi del modello Windows.

          • DeeoK

            No, anche dev con software open spesso rilasciano archivi da compilarsi. E’ una rottura di maroni ingiustificata.
            Il discorso sull’utente che deve contruibuire non ha senso. Se sto usando un pc domestico non devo trasformarmi in un sistemista per poterlo usare. Passo già tutto il tempo a lavoro a configurare sistemi, a casa voglio un SO che funzioni senza tanti sbattimenti.
            FOSS non c’entra una mazza con il distribuire pacchetti invece che sorgente, sono due concetti totalmente slegati. FOSS riguarda solo codice open e licenze.

            E’ come lamentarsi perché la gente vuole un’automobile che funzioni da sé invece che imparare a montarsela. Senza dubbio tutti saremmo molto più bravi nel ripararla, ma è uno sforzo totalmente ingiustificato per il fine.
            Un software è un mezzo, non un fine, per la quasi totalità dell’utenza ed è giusto che sia così.

            ps: il fatto di doversi appoggiare ad una community per avere pacchetti aggiornati è sbagliato per definizione se la distro non è gestita dalla community.

          • Kim Allamandola

            > No, anche dev con software open spesso rilasciano archivi da compilarsi.
            > E’ una rottura di maroni ingiustificata.
            E questo è il punto di vista Windows-iano. Il punto di vista FOSS è che se il tarball interessa qualcuno lo impacchetta&uppa in un repo. Si comincia dai repo “community” scalando via via la “classifica”. In altri termini il tarball è il codice che i suoi sviluppatori ritengono maturo per il rilascio. Qualche interessato inizia a compilarselo, trova problemi, suggerisce miglioramenti, fornisce patch ecc. La cerchia di interessati si allarga e qualcuno fa un pacchetto per la sua distro favorita, altri packagers arrivano ecc. Nel tempo e nelle iterazioni il codice matura, si correggono bachi, arrivano nuove funzioni ecc. L’utente ha un codice tanto più stabile tanto più è inesperto o perché lo sceglie consapevolmente. Questo è il processo di sviluppo FOSS.

            L’utente Windows-iano che non sa o non vuole compilarsi un pacchetto, se ne infischia della stabilità, non vuole contribuire al progetto ecc ma solo essere un mero consumatore non fa parte della community e non c’è motivo di appoggiarlo. Un’applicazione che non arriva ad essere impacchettata o per la difficoltà di impacchettarla è sempre poco aggiornata nei repo è segno che la sua qualità o il generale interesse non sono adatte a far parte di una distro.

            Grazie a questo sistema di sviluppo *partecipativo*, *comunitario*, *distribuito* si ha da sempre avuto una qualità complessiva inarrivabile da parte della quasi totalità dei software commerciali, si ha da sempre avuto una flessibilità, un’affidabilità ecc inarrivabile da qualsiasi software commerciale. Col sistema Windows-iano è normale trovarsi malware infilati ovunque, bachi a non finire ecc ecc ecc.

            > Il discorso sull’utente che deve contruibuire non ha senso.
            > Se sto usando un pc domestico non devo trasformarmi in un
            > sistemista per poterlo usare.
            Nessuno te lo chiede, ma il tuo PC FOSS, sul piano software è parte della community, non ci sono “consumatori” e “produttori” ma, appunto, una community che collabora, condivide, sviluppa, dialoga, evolve. Se non vuoi questo allora la soluzione è una distro commerciale ove sarai “il cliente” o semplicemente un OS commerciale. Ogni soluzione ha i suoi pregi e difetti.

            > Passo già tutto il tempo a lavoro a configurare sistemi, a casa voglio
            > un SO che funzioni senza tanti sbattimenti.
            È lo stesso per me, e lo ottengo con la stessa automazione che uso al lavoro poiché questo è l’IT. Il FOSS è fatto per chi fa parte dell’IT, chi non ne fa parte è sempre accolto, ma ha bisogno di qualcuno che gestisca gli aspetti tecnici per suo conto.

            Il FOSS non è solo una licenza ma un modello di sviluppo. Gli snap come i vecchi pbi, i flatpack ecc sono al contrario un tentativo di replicare il modello di sviluppo commerciale ove ogni software è una cosa a se, ove chi sviluppa&vende fa tutto e dall’altra parte c’è l’utente/cliente vs la community ove non c’è un confine chiaro tra utente, sistemista, sviluppatore ecc.

            > E’ come lamentarsi perché la gente vuole un’automobile che funzioni
            > da sé invece che imparare a montarsela.
            E per questo c’è il software commerciale, con i suoi pregi e i suoi difetti. Se a te sta bene accettare le potenziali vulnerabilità, le scatole chiuse ed i costi del modello commerciale hai una piccola scelta, se non ti sta bene hai altre scelte. La botte piena e la moglie ubriaca non è possibile.

            > il fatto di doversi appoggiare ad una community per avere pacchetti
            > aggiornati è sbagliato per definizione se la distro non è gestita dalla community.
            Se la distro non è nata, sviluppata e gestita in forma comunitaria non è FOSS, al massimo opensource e pertanto presenta tutti o parte dei rischi e dei vantaggi del modello closed.

            Per sdrammatizzare sai perché so che vieni da Windows? Scrivi “E'” anziché “È”, probabilmente perché su Windows fare accentate è complicato e nessuno ricorda i Alt-???. Su GNU/Linux come su ogni *nix è molto più semplice, di norma col compose 😀

          • DeeoK

            >Questo è il processo di sviluppo FOSS.
            No. Questa è la mentalità di uno sviluppatore che non vuole mai smettere di sviluppare. FOSS non c’entra una mazza.
            Lo stesso kernel Linux non funziona in questo modo, allo sviluppo partecipano aziende ed è comunque la Linux Foundation a dirigere gli sviluppi.
            Il metodo da te indicato va bene per fare gli n lettori audio in circolazione. Se devi fare software complessi è un casino, non puoi permetterti di avere decine di persone che mettono mano al codice in maniera occasionale, ti servono pochi sviluppatori che ci lavorano costantemente, quindi servono aziende che paghino un lavoro full time.
            Tra l’altro, FOSS significa Free and Open Source Software. Non puoi avere libertà se imponi un modus operandi agli altri e ti chiudi a riccio se qualcuno si comporta diversamente.
            Se vuoi che la tua nicchia rimanga nicchia nessuno te lo vieta, ma non impedire agli altri di avere un’alternativa a Windows.

            L’ultima frase poi lascia il tempo che trova. Scrivo E’ perché sono con il pc aziendale che ha Windows. Non ho nessuna voglia di perdere tempo con ALT, anche perché quelle combinazioni credo che Windows le abbia disabilitate (è da un po’ che non funzionano, almeno a me). Su Linux basta il caps lock (penso ci siano anche altri modi ma non ho mai investigato avendo già una soluzione comoda).

          • luX0r.reload

            Sarà una mia limitazione ma non riesco proprio a capire il senso del suo discorso ¯_(ツ)_/¯

          • DeeoK

            Fa parte di una nicchia che si reputa elité e vuole che le cose restino così.

          • alex

            il problema è che confonde il “modello di sviluppo” con il prodotto in sè. Un sistema basato su linux non è per forza in una categoria o nell’altra, puoi tranquillamente portarti avanti la tua bella distribuzione basta sulla “mitica comunity” con cui smanettare come fornire “un OS commerciale” già pronto per tutti.

          • DeeoK

            Che è quello che penso anche io.
            Pure a me piace smanettare di tanto in tanto, non c’è nulla di male. Ma non posso ogni volta perdere ore per ottenere un qualunque risultato sul pc domestico perché devo compilarmi questo o quest’altro. Il pc smette di essere uno strumento utile così.

          • ale

            l’unica cosa bella di “smanettare” col pc è che può permettere di capire molte cose, se non ci si limita a dare una serie di comandi letti da qualche parte. Però non può essere la norma altimenti come giustamente dici non è più uno strumento utile se non solo a livello didattico

          • Kim Allamandola

            > Questa è la mentalità di uno sviluppatore
            > che non vuole mai smettere di sviluppare.
            Beh, direi che è oramai voce comune che il software non è un prodotto finito ma un “servizio” in continuo divenire. Lato commerciale si è addirittura arrivati alle C.I…

            > Lo stesso kernel Linux non funziona in questo modo,
            > allo sviluppo partecipano aziende ed è comunque la Linux
            > Foundation a dirigere gli sviluppi.
            Ovvero c’è una community (le aziende, diverse, con idee e scopi diversi che sviluppano insieme un progetto sempre parte della community sono) e una governance comunitaria formata sia da aziende sia singoli sviluppatori. Per capirci un modello diverso è Alfresco, Nuxeo, Odoo, OpenBravo, … ovvero prodotti *commerciali* nati e sviluppati da una singola azienda che vende personalizzazioni, supporto, training ecc e a codice aperto semplicemente perché obbligate dalle licenze open dei componenti core che usano. Linux è una community come lo è ancora GNU.

            > Il metodo da te indicato va bene per fare gli n lettori audio in circolazione.
            Il kernel Linux, Gcc, Emacs, XOrg mi paiono piuttosto complessi come prodotti e si sviluppano e sono nati con questo modello…

            > Se devi fare software complessi è un casino, non puoi permetterti di
            > avere decine di persone che mettono mano al codice in maniera
            > occasionale, ti servono pochi sviluppatori che ci lavorano
            > costantemente, quindi servono aziende che paghino un lavoro full time.
            Guarda che è così nel mondo open per molti progetti, da Linux a Python per far qualche esempio sono progetti nati in forma “amatoriale” ed evoluti in comunità i cui sviluppatori sono talmente tanti che i commit sono continui, di migliaia di persone diverse sparse per il mondo, *inclusi* dipendenti di aziende che usano questi software e che li estendono/migliorano per il loro uso personale. FOSS non vuol dire roba del cantirano in garage vuol dire software sviluppato da qualcuno (azienda o privato, studente, docente, professionista che sia) per il suo proprio interesse e condiviso col resto dell’universo a condizioni tali per cui ogni altro interessato possa cooperare per il suo proprio interesse senza problemi. Altri progetti sono single-man-show o giù di li (GiMP è un esempio, ma anche mplayer) e li il rischio è maggiore.

            > Non puoi avere libertà se imponi un modus operandi
            Il FOSS ha come modus operandi la massima libertà possibile e la impone con opportune licenze. Il software commerciale ha la minima libertà possibile e la impone con opportune licenze. Libertà != da Anarchia.

            > Se vuoi che la tua nicchia rimanga nicchia nessuno te lo vieta,
            > ma non impedire agli altri di avere un’alternativa a Windows.
            Invece stà accadendo l’opposto: l’emorragia di ex-Windowsiani stà portando il modello Windows su GNU/Linux, per citare un esempio la recente scoperta di malware su PyPi sino ai log binari di systemd. Questo provoca due cose: la community Windows si “diluisce” trasferendosi “da noi” e “noi” sommersi da mega-aziende e tonnellate di pecore che gli vanno dietro ci troviamo in minoranza, messi al muro. Quindi l’alternativa a Windows l’abbiamo sempre offerta, quel che stà accadendo è che non stiamo diventando un altro Windows, senza praticamente più altre alternative percorribili.

            Sulla tastiera di nuovo è storia: tu conosci la tastiera Microsoft e credi che questa sia “La Tastiera”, in effetti non è così, esistono molti altri tipi di tastiera e nel caso quelle unix sono normalmente dotate di un tasto chiamato compose col quale componi appunto due tasti per formare un certo carattere, es compose+e` == è, compose+a+’ == á, compose+O+/ == Ø, compose s+s == ß (in tedesco classico ss si usava scriverlo con una beta) ecc In molte tastiere era presente un tasto per chiudere l’applicazione con focus, era presente il tasto copia, taglia, incolla ecc. C’è un mondo al di la di Microsoft i cui abitanti han sempre riconosciuto, tollerato e cooperato con “i diversi”, Microsoft al contrario pensa di esser sola nell’universo e tutti gli altri o obsoleti o stupidi. Questo è il problema. Noi (unix users, unix haters, …) stia perdendo la *nostra* libertà e l’umanità tutta stà perdendo un mare di tecnologia, senza manco rendersene conto.

          • DeeoK

            Linux è sviluppato dalla community ma alla fine decide Torvalds come dirigere gli sviluppi. Quando ci fu l’anniversario dei 20 anni (se ben ricordo) Torvalds decise che quella sarebbe stata la versione 3 ed anche se molti si lamentarono alla fine fu così.
            La gestione dei progetti in sé è sempre fatta da team relativamente piccoli, il resto della community va a dare una mano ma a conti fatti non decide granché, altrimenti non ci sarebbero sempre tutte queste polemiche.

            Anche il discorso delle community windowsiane che vi rubano il lavoro non ha senso. Visto che la GPL costringe a lasciare il codice open nulla vieta di forkare il progetto ed ignorare le grandi aziende. Che poi Red Hat forza la direzione degli sviluppi da 20 anni, quindi non è certo una novità, la cosa.
            Quello che la tua visione della community offre non è mai stata un’alternativa a Windows. Windows, come in realtà qualunque altro SO in circolazione, è un mezzo per l’esecuzione di software che a loro volta sono mezzi per l’ottenimento di qualcos’altro. Pretendere che solo gli sviluppatori possano essere anche utenti è ridicolo e non c’entra una mazza né con il concetto di home computer, né con FOSS e mi tocca citare Wikipedia:
            “Free and open-source software (FOSS) is software that can be classified as both free software and open-source software.[a] That is, anyone is freely licensed to use, copy, study, and change the software in any way, and the source code is openly shared so that people are encouraged to voluntarily improve the design of the software.[3] ”
            Dice “encouraged”, non “force”. Ti rendi conto di quanto sia ridicolo dire “massima libertà possibile e la impone con opportune licenze”? Questa è la mentalità americana, dove la libertà può essere imposta. Tutto ciò che è imposto non è libero e questa è una definizone.
            Citare poi i bug sostenendo che sia la mentalità Windows a portarli è ridicolo. Il kernel Linux ha già avuto i suoi bug in passato e continueranno ad esserci Windows o non Windows. Cercarci implicazioni significa cercare conferme delle proprie convinzioni.

            Infine tutto il discorso sulla tastiera non perdo nemmeno tempo a commentarlo essendo totalmente basato sul nulla. “tu conosci la tastiera Microsoft e credi che questa sia “La Tastiera”” è una cosa di cui ti sei convinto da solo, io non c’entro nulla.

          • Kim Allamandola

            Mh, temo di non esser stato chiaro: nessuno “ruba il codice” semplicemente il “nostro” codice, protetto da licenze open, evolve alla maniera di Windows. Non parlo di righe di codice copiate ma di quel che queste implementano. Oggi si stà realizzando un ecosistema GNU/Linux che sempre più assomiglia a quello di Windows.

            > Pretendere che solo gli sviluppatori possano essere anche utenti è ridicolo
            Infatti non ho detto questo. Purtroppo tu vieni da Windows e per questo non vedi “chiaro” come funziona(va) il mondo FOSS, pensi a “programmatore”, “sistemista”, “utente” ecc ovvero a soggetti distinti ognuno che fa una cosa specifica diversa dagli altri. La classica divisione dei ruoli aziendale. Il mondo FOSS non è un’azienda e non c’è una netta divisione dei ruoli. L’utente contribuisce ad un dato progetto fornendo bugreport (più dettagliati del tipico “non funziona!!!!” Windowsiano, che in quell’ambiente è nato perché l’utente non può dire granché di più), scrivendo documentazione, diffondendo la conoscenza del progetto nella sua cerchia di conoscenze. Il sistemista fa bugreport più accurati, fornisce spesso patch, suggerisce idee evolutive, lo sviluppatore spesso è anche utente e quindi ha entrambi i punti di vista ecc. Oggi chi viene da un certo ambiente non riesce a vedere qualcosa che non sia aziendalistico, ma se guardi per un attimo la storia, non solo dell’IT, ti rendi conto che questa visione (il capitalismo anglosassone) è *fallimentare* e insostenibile nel tempo. Il commercio funziona solo se c’è qualcosa da commerciare e questa non nasce con le leggi dell’economia bensì quelle della tecnica che in ultima analisi è fatta di singoli umani, non da rigide gerarchie.

            > Ti rendi conto di quanto sia ridicolo dire “massima libertà possibile
            > e la impone con opportune licenze”?
            Pardon, correggo: la GARANTISCE con opportune licenze in assenza delle quali il “malaffare” impera. Vedi per “incoraggiare” l’utente a migliorare *devi* avere e dargli gli strumenti per farlo. Quale utente, capra a parte, contribuisce a Google Maps che non è “anche sua” vs OpenStreetMaps che è “anche mia, tua e di chiunque”?

            > Questa è la mentalità americana, dove la libertà può essere imposta.
            No, questa è la mentalità Europea dove c’è uno Stato rappresentativo “forte” vs quella USA dove c’è uno stato debole che di fatto è una corporatocrazia…

            > Tutto ciò che è imposto non è libero e questa è una definizone.
            La libertà assoluta, teorizzata nel modello anarchico, non è funzionante. La libertà di cui parli è proprio il modello USA dove ti dicono che devono esserci poche regole (quando poi la loro burocrazia è più pesante e contorta di quella italica) e che lo stato non deve intromettersi in nulla (quando sono una dittatura fascista). La libertà di cui parlo io è quella Europea fatta da regole condivise, create come accordo tra uomini liberi e rispettate e *fatte rispettare* con ogni mezzo. Secondo te chi è libero e chi schiavo?

            > Citare poi i bug sostenendo che sia la mentalità Windows
            > a portarli è ridicolo. Il kernel Linux ha già avuto i suoi bug
            > in passato e continueranno ad esserci Windows o non Windows.
            Come diceva un mio prof di economia per discutere di qualcosa bisogna scendere nei dettagli: in quanto tempo vengono corretti i bug scoperti nel mondo FOSS vs nel mondo commerciale? Quali azioni si intraprendono alla scoperta di *potenziali* falle di sicurezza nel mondo FOSS vs nel mondo commerciale? E di più che può fare l’utente Windows se incontra un bug? Che può fare invece l’utente FOSS? Di nuovo, chi è libero? Chi schiavo?

            > Infine tutto il discorso sulla tastiera non perdo nemmeno tempo a commentarlo
            È certo una supposizione, ma direi basata su indizi che per esperienza son sufficienti 🙂
            mica è un’accusa eh! Solo una constatazione: ci sono persone che per mera storia sono abituate ad un certo strumento, un certo modo di fare, al punto da non comprendere o trovare strano che ve ne siano altri, la tastiera è un banale esempio per mostrare una parte dei concetti sopra esposti.

          • DeeoK

            www . theregister . co . uk/2017/02/23/linux_kernel_gets_patch_against_12yearold_bug/
            lol

            Comunque, condivido parte del discorso ma non la sua interezza, perché mentre alcuni elementi hanno un senso, altri no.
            Il discorso su una community guidata ha senso ed è sicuramente preferibile ad una visione dittatoriale. Cioè, in linea di massima chi se ne frega se si parla di software “accessori” (che so, Photoshop), ma se si parla di componenti fondamentali la visione dittatoria è da evitare.
            Il punto su cui sono in disaccordo è come da questo concetto di base di modello di sviluppo si finisca con il dire che aspetti come Snap siano il male perché rendono trasparente l’installazione di applicativi.
            Dire che la divisione fra utente e sviluppatore sia figlia di una visione aziendale è sbagliato perché è semplicemente lo stato delle cose, sia in informatica sia in qualunque altro campo.
            Io utente compro un pc perché devo farci delle cose e voglio un software che sia semplice da installare e configurare (facendo i doverosi distinguo in base al software). Non devo essere forzato a scaricarmi i sorgenti, compilarmeli e installarmeli sperando che tutto vada bene.
            Questo per due banali motivi:
            1) Richiede conoscenze che non sono tenuto ad avere (quando utilizzi un farmaco non sei tenuto ad aver studiato farmacia, deleghi al farmacista questa conoscenza)
            2) Il pc perde il suo scopo di strumento. Devo accendere il pc per fare una ricerca online; se passa mezz’ora prima che io sia riuscita a farla ho fatto in tempo a controllare su un’enciclopedia.
            Questo è solo un esempio, ma se ne possono fare a decine. Non devo essere un ingegnere elettrico per assemblarmi un pc, se voglio usare una stampante non devo configurarmi i protocolli che collegano la stampante al pc se non per singoli aspetti di sicurezza come la password.
            Il modello che proponi non solo non ha senso, ma non è neanche applicabile. Tu parli di informatica perché è il tuo campo, ma esistono migliaia di altri campi dove potrei spostare senza problemi il discorso e ogni individuo finirebbe con l’impiegare i primi 40 anni di vita per imapare i rudimenti per poter usare gli strumenti moderni. E’ privo di senso.
            Un pc deve funzionare out of the box perché è uno strumento e tale rimane. Se qualcuno vuole usarlo come fine non c’è nulla di male, ma non si può e non si deve costringere tutti a farlo perché rompe il concetto di strumento.
            Io quando sono a casa sono quasi sempre utente ed il fatto che a lavoro sia sviluppatore è slegato. Se a casa voglio perdere tempo a smanettare sono libero di farlo, ma non devo essere costretto. Quando accendo il pc non ho nessuna voglia, ogni volta, di star dietro a compilazioni e quant’altro, perché devo ottenere un risultato e raramente ho un pomeriggio per farlo.

            Anche quello della tastiera è un buon esempio: se una persona ha sempre usato un tipo di tastiera è normale che si trovi bene con quella, ma senza metterci di mezzo il software basta anche solo usare un pc di un altro paese per ritrovarsi con una mappatura diversa. Una persona si adatta se ne ha voglia e non è giusto costringerla ad adattarsi. Soprattutto perché per molti è impossibile adattarsi: non puoi chiedere ad un 50enne che non ha mai avuto a che fare con un pc di imparare a gestire un repository per potersi fare un solitario. Non ci riuscirà mai, finirà con il non usare mai un computer.

            Infine, non ho mai parlato di rubare il codice. Se non ti piace un approccio non sei costretto a seguirlo. Non ti piace come opera il tema di Gnome? Usa KDE. Non ti piace nemmeno quello? Forkati un DE e fattene uno tuo. Questa è libertà lasciando agli altri la possibilità di decidere in autonomia in base alle proprie esigenze, alle proprie conoscenze ed al tempo a disposizione. In fin dei conti a te, che ci siano gli Snap in circolazione non cambia nulla. Finché la licenza usata è la GPL hai comunque a disposizione il sorgente e per tutti gli altri l’installazione è semplice.

          • Kim Allamandola

            Attenzione: ho detto quanto tempo passa da quando una vulnerabilità o bug viene *scoperta*, non quanto tempo può servire per farla venire alla luce (che non è normalmente né misurabile a priori né paragonabile).

            > Dire che la divisione fra utente e sviluppatore sia figlia di una
            > visione aziendale è sbagliato perché è semplicemente lo stato
            > delle cose, sia in informatica sia in qualunque altro campo.
            Guarda al recente passato: cosa faceva, sapeva e poteva fare il meccanico o il carrozziere di un tempo? Cosa faceva, sapeva e poteva fare l’umano semplice medio di 30-40 anni fa rispetto a quello odierno? Per capirci un ragazzo degli anni ’50 si cambiava normalmente i freni del proprio mezzo (se l’aveva, è chiaro), l’olio, i filtri ecc. Oggi se dico che le gomme tra estate&inverno me le cambio in garage, che le pastiglie dei freni, i filtri ecc pure mi guardano come se fossi pazzo o addirittura pericoloso. In Italia quando dico che mi son fatto tramezze e impianti (elettrico e idraulico, la ventilazione l’ho fatta fare) io mi prendono per matto, in Francia molto meno perché c’è ancora un po’ di abitudine a far da soli. In Svezia e Russia ancora meno perché è molto più comune far da soli. La “divisione” o meglio l’iperspecializzazione odierna è figlia del modello Ford poiché per poter dirigere meglio la società è bene avere tanti bipedi incapaci di vivere in autonomia riducendo le loro competenze all’unghia del mignolo del piede sinistro e facendo credere che ciò sia un bene.

            Il PC *non*è* uno strumento, è oggi il sistema nervoso della società, l’archivio personale ed il centro della maggior parte delle attività, anche private pertanto non lo si può considerare come un frullatore anche se questo è il trend che viene spinto a viva forza. Col PC ci paghi le tasse, fai bonifici, controlli di averne ricevuto, gestisci buona parte dei tuoi servizi oltre a giocare a passar il tempo su internet. Se ci si facesse solo cose serie non lo si tenderebbe a considerare uno strumento, purtroppo essendo anche il centro di gioco e svago per quasi tutte le età lo si considera un giocattolo salvo poi urlare quando il monodisco senza backup si rompe, quando gira qualche ramson ecc. E questo non solo a livello domestico. Mi spiace ma il PC dev’essere come e più dell’auto o del conto bancario, altrimenti è un disastro in attesa di accadere.

            > per molti è impossibile adattarsi
            Ogni cambiamento costa fatica, provoca sofferenza, è la vita. Pensa al parto, all’adolescenza, alla menopausa, alla vecchiaia. La società dovrebbe provvedere (e in parte provvede) a facilitare le cose. Il cinquantenne ignorante informatico avrà *comunque* bisogno di qualcosa (vedi la fila in certi negozi di bipedi disperati per trasferire la rubrica da un android (con mail a loro sconosciuta, password ovviamente anche) ad un altro. Se lo sa da subito sceglie un parente/amico/terzo pagato che da subito lo guida e gli evita problemi, altrimenti fa disastri o si stà preparando a farli.

            > Se non ti piace un approccio non sei costretto a seguirlo.
            Torniamo al principio della rana: “se non vuoi un’auto connessa non comprarla! Mica è vietato!”, certo oggi posso ancora comprare con fatica qualche UAZ che ha una centralina solo per il common-rail… Domani? Quante auto (inclusa la mia Duster) una un “dispositivo” a bordo che può fare e fa taaante cose, alcune magari non gradite come il metter in moto d’inverno la macchina 10′ ogni 2 ore quanto la temperatura va un tot sottozero basandosi semplicemente sul livello del gps per decidere se è all’aperto o in garage? Quante vulnerabilità fuori dal controllo dell’utente son già venute fuori tra auto aperte, messe in moto, schiantate via sms&c abbiamo già scoperto? Domani? Nessuno imporrà la guida autonoma per un po’, anzi sarà desiderata, più in la tutti i veicoli avran la guida autonoma e più in la ancora sarà una dotazione minima di legge. L’incapacità di vedere un trend per tempo e correggerlo è purtroppo un classico della nostra società che ci ha già portato tragedie enormi, innumerevoli volte.

            > In fin dei conti a te, che ci siano gli Snap in circolazione non cambia nulla.
            Certo, oggi. Quando un domani divenissero comuni mi troverei a dover gestire tonnellate di problemi di sicurezza per snap non aggiornati (con dipendenze non aggiornate) perché qualche sviluppatore se non ignorante per lo meno poco lungimirante ha deciso che vuol risolvere un problema che manco ha compreso senza manco degnarsi di guardare a cosa altri han fatto a tema nel tempo. Se solo vai a qualche conferenza a tema IT sentiresti delle cose da farsi venire i brividi. Ti dico solo di una nota banca che scarica immagini docker (complete/binarie) da internet e le spara direttamente in produzione via jenkins e han pure la faccia di dire che questa è innovazione. Ovviamente non sanno cosa siano le jails né le zones. Il discorso è sempre quello siamo individui ma viviamo in società e l’evoluzione di questa tocca tutti. L’evoluzione odierna è un disastro e per quanto mi prepari travolge anche me.

          • DeeoK

            Il problema è che estremizzi: avere un minimo di competenza di base è un conto, essere un esperto è un altro.
            Che ci sia una eccessiva ignoranza in ambito informatico è indubbio, ma un conto è avere un certo quantitativo di conoscenza di base, un conto è essere in grado di gestire problematiche non basiche.
            Tu sai invertire le gomme (e hai un garage per farlo, sob), ma se hai un problema effettivo vai da un meccanico. Quello di cui parli in ambito automobilistico in ambito informatico si traduce con il conoscere un minimo di sicurezza informatica (gestire le password, ad esempio) e conoscere un minimo di manutenzione del sistema (come formattare, come fare pulizia tra i file, come fare backup e via dicendo). Ma sono tutte conoscenze di manutenzione di uno strumento, esattamente come lo è cambiare le pasticche dei freni.

            I pacchetti precompilati sono esattamente la stessa cosa dell’olio motore venduto già in flaconi. Tu vuoi che tutti si compilino da soli i pacchetti, ma è praticamente come chiedere che tutti debbano sapersi miscelare un olio per il proprio motore.
            Tra l’altro l’esempio che fai sugli Snap indica che non hai ben capito come funzionino perché per come sono pensati in ambito sicurezza funzionano molto meglio della compilazione manuale. Essendo tutto incapsulato in una sandbox le dipendenze sono all’interno. Se ci sono falle nelle dipendenze o nel codice va rigenerato lo snap ma essendo una entità a sé stante questo processo resta piuttosto semplice. Tra l’altro avendo a disposizione il sorgente qualunque utente può rigenerare uno snap. Snap serve a modularizzare il codice, aspetto fondamentale soprattutto se si vuole vivere agevolmente in un ambiente gestito da tante community diverse.
            Nel caso di compilazioni manuali a me è capitato di non riuscire a compilare software perché venivano richieste librerie più vecchie di quelle attuali e l’applicazione non era compatibile con le versioni più recenti. Di oscenità in ambito sicurezza ce ne sono una marea ma questo non c’entra una mazza con l’avere community che gestiscono i progetti o l’avere solo codice OS. La sicurezza in ambito aziendale è puramente una questione di quanto tale azienda decide di investire a riguardo.
            Quindi continuo a ripetere quel che dico dall’inizio: stai radicalizzando un concetto facendolo sforare in una marea di altri ambiti.

          • Kim Allamandola

            Ni, non voglio affatto che “tutti si compilino” il software che vogliono, voglio che si creino sistemi per rendere più comodo l’impacchettamento (la SUN con IPS aveva iniziato bene, ad esempio) e la distribuzione. Go col suo go get, java col suo modello di distribuzione mostrano ottime soluzioni, che vanno estese, migliorate. Gli snap van nella direzione opposta. La loro sandbox è poco più del vecchio chroot, di provata *inaffidabilità* (nulla al confronto di jails o zones) e ignorano completamente i motivi per cui su *nix si scelse il linking dinamico vs la compilazione statica di Windows. In altri termini snap è il parto di sviluppatori d’estrazione Windowsiana che non comprendendo storia e ragioni di unix han detto “tagliamo la complessità” replicando il modello Windows. Costoro non han letto l’unix zen, in particolare quel famoso passaggio sulle pipe: su quanto sian complesse da implementare e quanto sian semplici da usare.

            > Se ci sono falle nelle dipendenze o nel codice va rigenerato
            > lo snap ma essendo una entità a sé stante questo processo
            > resta piuttosto semplice.
            Oh, certo, per la precisione richiede che chi ha generato lo snap provveda ad aggiornarlo e pubblicarlo nel repo del caso che tradotto vuol dire:
            – sistema classico: il packager impacchetta il codice e lo pubblica sul repo del caso
            – in caso di update c’è un testing automatico e manuale, se qualcosa non va il packager interviene
            – sistema snap: il packager (che in genere è l’upstream) deve star dietro a *tutti* gli aggiornamenti di *tutte* le dipendenze e rifarle lo snap per *ogni* update di queste ultime.
            Mi manca la parte della semplicità: su snap è semplice il principio e in pratica si traduce in un macello di lavoro, nelle soluzioni classiche è complesso il principio e poco il lavoro. È un po’ come dire ma perché far gerarchie rappresentative all’italiana, facciamo elezione diretta e votazione a suffragio universale di ogni legge. Al di la del rischio dittatoriale dai più non visto hai idea di cosa vuol dire andar a votare, contar le schede ecc per *ogni* legge? Certo chi viene da Windows ed è uno sviluppatore queste cose non le comprende. Tipicamente comprende solo il suo desktop e non riesce a pensare alla complessità. Un altro bell’aneddoto del caso è nelle cronache di Simon dove c’è il programmatore che per monitorare lo stato di una stampa in coda fa un poll al secondo sulla stampante DOS-ando l’intera rete aziendale…

            > Nel caso di compilazioni manuali a me è capitato di non riuscire
            > a compilare software perché venivano richieste librerie più vecchie
            > di quelle attuali e l’applicazione non era compatibile con le versioni
            > più recenti.
            Hai lo stesso problema a compilarle statiche per fare uno snap eh! Soltanto nel metodo classico l’interessato andava a caccia dei problemi (funzioni/metodi rinominati, deprecati ecc) e magari forniva una patch, questo soggetto è tipicamente il maintainer. Negli snap essendo concettualmente dall’upstream all’utente questa figura non c’è e tutto è sulle spalle dell’upstream che spesso non ha alcun interesse a supportare l’ultima versione di ogni libreria visto che facendo un’immagine può permettersi di non farlo.

            Per tradurre snap == software instabile e meno aggiornato. Sistema classico == software stabile, più o meno testato e ben integrato ovvero l’esatto opposto di quel che gli sviluppatori di snap&c sostengono.

            Il tema security richiederebbe un romanzo ma il punto è che con uno sviluppo comunitario hai di solito nella community anche ricercatori, docenti, bug-hunters ecc che seguono il codice mentre si evolve (ovvero lo conoscono intimamente, non si trovano un milione di righe da leggere di colpo) ed altri che “arrivano” ad un certo punto, magari notando problemi passati inosservati a chi ha seguito l’evoluzione. Il risultato è che in genere il software FOSS è molto più sicuro, per default di quello proprietario. Se ci fai caso le recenti vulnerabilità in ambito open (più che FOSS) sono in buona parte codice sviluppato da aziende.

          • DeeoK

            Ma il tuo discorso funziona solo ed esclusivamente con software gestito totalmente dalla community e non è detto che questo sia possibile o che sia voluto.

            I test automatizzati con le nuove librerie funzionano sia con gli Snap che con la compilazione manuale, non cambia assolutamente nulla a riguardo. Con gli Snap è l’upstreamer che se ne occupa come è giusto che sia avendo lui rilasciato il software ma nulla vieta di poter delegare ad altri la cosa. La possibilità di patch resta invariata rispetto al modello tradizionale.

            Il problema di compatibilità delle librerie con gli Snap non si presenta perché ogni Snap incapsula le librerie e se una nuova versione crea problemi può tenere la vecchia in attesa di risolvere tali problemi. Snap è solo un pacchetto precompilato che include tutte le librerie necessarie, niente di più. Ha tutti i vantaggi della compilazione manuale senza averne gli svantaggi (es. conflitti).
            Se io voglio installare un software ed ho un conflitto non è detto che possa mettermi a scaricare i sorgenti e capire dove sia il problema e non è nemmeno detto che qualcun altro lo farà a breve. Snap consente alle applicazioni di gestire autonomamente le proprie librerie senza preoccuparsi troppo di quel che è installato sul sistema. In un mondo frammentario è comodissimo e nulla vieta di compilarsi a mano i pacchetti (se il codice è libero nessuno lo vieta) ed è il motivo per cui è, imho, un’alternativa migliore a Flatpak che se ho ben capito è una specie di ibrido tra Snap e modello tradizionale finendo per non essere né carne né pesce.
            Che ci siano al momento problemi di sicurezza è indubbio, ma ci sono anche problemi strutturali per lo spazio. Attualmente resta un sistema in sviluppo (infatti che io sappia ancora non è presente di default su Ubuntu) e mi pare che voglia in futuro consentire il linking dinamico delle librerie. In generale comunque il riassunto di Snap è che si parla di un pacchetto che incapsula tutte le librerie che gli servono per funzionare operando in una sandbox. A quanto ho letto la parte di sicurezza è ancora in sviluppo e comunque stiamo andando avanti da anni con XOrg che è tutto fuorché sicuro.

            Il problema dell’avere tanta gente che mette mano al codice è che chiaramente molti possono contribuire, ma possono pure inserire altri bug, eh, non è che solo perché lavorano in una community sono programmatori fantastici. Per dire, una delle più recenti vulnerabilità in circolazione è stata quella si Samba, progetto FOSS.

          • Kim Allamandola

            > Con gli Snap è l’upstreamer che se ne occupa come è giusto che sia
            È giusto nel modello Windows, è sbagliato nel modello FOSS per una semplice ragione. L’upstream deve occuparsi del suo software nel suo ambiente favorito cercando di essere il più multipiattaforma possibile. Ogni distro od OS con le sue peculiarità richiederà del lavoro extra per far girare quel software. A questo servono i maintainers. Ma non solo: grazie alla necessità di porting (che non pesa, del tutto, sull’upstream) si scovano bachi, arrivano patch, vengono proposte modifiche, arriva documentazione ecc.

            Un software non è la mera implementazione di un algoritmo, è *anche* quella che rappresenta tra l’altro secondo la letteratura che normalmente si insegna una *minima* percentuale del codice. Un software è anche risorse diverse (documentazione, localizzazione, icone, temi ecc) e tutti questi è bene ricevano *forti* contributi della community perché lo sviluppatore che scrive un software di fotoritocco è sicuramente interessato all’elaborazione delle immagini, ma molto probabilmente non gli interessa tradurlo in n lingue, produrre i più svariati set di icone e scrivere documentazione.

            Col modello classico un progetto ha un upstream “core” e una marea di contributors più o meno occasionali che realizzano l’enorme mole di lavoro a bassa competenza richiesto per rendere un software comodo&completo e nel processo contribuiscono a fornire idee e migliorie. Questo nel mondo commerciale non c’è e il risultato lo conosciamo: documentazione noiosa, spesso inutile, localizzazioni che fan pena, bug ridicoli, flessibilità scarsa ecc.

            > Il problema di compatibilità delle librerie con gli Snap
            > non si presenta perché ogni Snap incapsula le librerie
            > e se una nuova versione crea problemi può tenere la vecchia
            Esatto, ovvero l’upstream che non è granché interessato alla libreria $pincopallo che usa solo marginalmente visto che c’è un problema pospone la cosa sine die. Nel modello classico invece la libreria è separata e quindi viene aggiornata. Il packager nota che il programma non va d’accordo con la nuova versione e come minimo avvisa l’upstream ma di solito contribuisce con una patch col risultato che il modello classico è più aggiornato *globalmente* e il software è passato da vari occhi. Nel modello snap tutto è in mano all’upstream che ha interessi e velocità diverse.

            > Se io voglio installare un software ed ho un conflitto non è detto
            > che possa mettermi a scaricare i sorgenti e capire dove sia il
            > problema e non è nemmeno detto che qualcun altro lo farà a breve.
            Se il software ha un qualche interesse non sarai tu utente ma tu maintainer del pacchetto a scaricare le source e comprendere/risolvere il problema. Se così non è sarai tu utente a contribuire alla community segnalando o risolvendo il problema in base al tuo tempo e competenze. Del resto ricorda una massima dell’operation: never trust an unpatched release of anything. Sei sicuro di aver così tanto bisogno dell’ultima versione e non aver ne tempo ne competenze per contribuire? Sei sicuro che la soddisfazione di questo tuo impellente bisogno valga la perdita del flusso di review, patch e idee del modello classico? Se si va su un prodotto commerciale perché questa è la via: pagare qualcuno che prepara la pappa pronta per te. Ovviamente questo ha anche degli svantaggi, ben noti. La botte piena e la moglie ubriaca insieme non sono possibili al momento e forse mai.

            Per quanto riguarda snap al momento è installato di default su Ubuntu ma essendo assai poco usabile praticamente non è usato. Il tentar di bucare la sandbox, prima per poter accedere al filesystem perché uno dei primi bachi segnalati agli sviluppatori compagnoni&sorridenti per il loro nuovo giocattolo è stato: “si, ok, bello… E mo mi spieghi come **** faccio ad accedere ai files della mia /home se *tutto* è chrootato!?” e questo è stato aggirato introducendo una maggior superficie d’attacco e potenziali vulnerabilità future (app con vulnerabilità non completamente sandboxate per aver una accesso a quel che serve), se aggiungi il linking dinamico crei un castello di carte che dire fragile è dir poco. Io (e non solo io peraltro, ma tanta gente assai più competente di me) da decenni dico che il modello del filesystem posix va superato, non risponde più ai bisogni attuali. In casa SUN l’han capito e han partorito lo zfs, in casa DragonFlyBSD idem e han partorito Hammer, altre software houses proprietarie han fatto i loro mostri commerciali a tema (IBM su AiX e HP su HP_UX), altri ancora han mostrato di non aver capito un tubo dicendo che lo zfs è una “rampant layer violation” (tal Andrew Morton, così per dire) e altri ancora si credevano di far gli “sboroni” partorendo il btrfs (col risultato che in casa SUN son scoppiati a ridere sino a farsela addosso che già stavano ridendo per la richiesta mi pare di NetApp di “cancellare” la versione open di zfs perché “avrebbe rovinato il mercato dello storage”). Siccome oggi non si fa più ricerca non si cambia nulla, si gioca solo ai lego ricombinando cose che già ci sono e limando dettagli nessuno gradisce imbarcarsi in avventure che solo le vecchie unix company e i progetti FOSS potevano (e possono) affrontare. Mi spiace, snap non è altro che *una porcata*. Vuoi un sistema flessibile? Prendi OpenSolaris: puoi installare una macchina e clonarla su n altre con un banale zfs send, puoi clonare il tuo OS (occupando su disco solo i bit che cambi), fare un esperimento e alla fine rebootare nel “clone” originale, bello pulito, distruggendo il resto. Vuoi dei “container”? Ecco le zones. Ecc. Questa è tecnologia scritta da Programmatori, che han ascoltato le richieste dell’operation non codice scritto da sviluppatori macinacodice guidati dal manager di turno.

            Sul tema security e gli esempi di Samba (difficile comunque render sicuro un software che implementa un protocollo insicuro by design) e XOrg sono ottimi esempi dell’utilità della community: le vulnerabilità son scoperte e corrette, tante o poche che siano. In ambito commerciale sino alla pubblicazione dell’exploit nel 90% dei casi non muove foglia. Altro punto, relativo a XOrg è che un progetto dopo un tot di anni è bene sia riscritto perché troppi strati di codice, generazioni di gente c’han messo mano, e questo vale tanto per il commerciale quanto per il FOSS. XOrg (come anche Emacs, dove si sente meno grazie al lisp) è un progetto nato negli anni ’80 (Emacs addirittura nel 1976) oramai troppe cose sono cambiate per continuare a farlo evolvere. E qui si torna ad un altro punto dolente: sono anni che dico (e non son certo solo) che il successo di UNIX si chiama C, ai tempi, e che oggi non c’è più nessuna implementazione di UNIX in circolazione. Serve un nuovo “C” adatto ai tempi moderni. Non so quanto il Go o il Rust possano essere valide alternative, Python per la sua grammatica sarebbe anche lui ottimo ma per la sua implementazione non può esserlo ma serve un nuovo linguaggio e la riscrittura per lo meno dell’userland e delle librerie base. Lavoro enorme, che solo una vasta community oggi può affrontare ma che va affrontato. Altrimenti la torre di babele continua a crescere rimandando ad un botto sempre più grande quando crollerà.

          • DeeoK

            La cosa sta sfuggendo di mano. Comunque:

            >Questo nel mondo commerciale non c’è e il risultato lo conosciamo:
            documentazione noiosa, spesso inutile, localizzazioni che fan pena, bug
            ridicoli, flessibilità scarsa ecc.

            No: conosci molto poco il mondo oltre il tuo. Tanto per dirne una, lingue extra sono prodotte dalla community pure per progetti estremamente closed come sono i videogiochi. Io stesso ho partecipato una volta ad una mod fatta dalla community.

            >Nel modello snap tutto è in mano all’upstream che ha interessi e velocità diverse.

            Non necessariamente, dipende dalla volontà dell’upstream ed è giusto che sia così. Chiunque può rigenerare uno Snap e chiunque potrebbe voler produrre una patch. Dipende dalla volontà di chi lavora al progetto. Usare Snap non ha le implicazioni di cui parli.

            >Se il software ha un qualche interesse non sarai tu utente ma tu maintainer del pacchetto a scaricare le source e comprendere/risolvere il problema. Se così non è sarai tu utente a contribuire alla community segnalando o risolvendo il problema in base al tuo tempo e competenze.

            Nulla vieta di replicare il comportamento con gli Snap. Dipenderà molto dalla piattaforma usata per la loro gestione.

            >non codice scritto da sviluppatori macinacodice
            Molto di quel codice è scritto dalla comunità FOSS che tanto elogi.
            In generale poi XOrg era notoriamente inadatto allo scopo ma la comunità FOSS l’ha comunque lasciato lì. Wayland è un progetto di neanche 10 anni ed ancora non è pronto, la community non si è svegliata proprio presto. ZFS ha una versione open ma è un progetto gestito da un’azienda, non da una community ed usa comunque le POSIX.
            Oltretutto con ZFS il problema delle librerie non cambia minimamente e continua a c’entrare ben poco con Snap (che comunque possono accedere alla Home tramite interfacce).
            La gestione degli errori è simile in entrambi i mondi: nel mondo open chi scopre l’exploit lo segnala prima ai manteiners, nel mondo closed lo segnala prima all’azienda. Se non viene chiusa la falla in un mese è prassi eticamente corretta quella di rendere pubblico l’exploit. Se anche l’azienda non si fosse occupata di chiudere il bug ci sarebbe lo sm***mento pubblico (come è già capitato) costringendola a risolvere.
            Per inciso, l’unico caso che trovo in rete di problemi di sicurezza con Snap è relativo a X11.

          • Kim Allamandola

            > No: conosci molto poco il mondo oltre il tuo. Tanto per
            > dirne una, lingue extra sono prodotte dalla community
            > pure per progetti estremamente closed
            Sai che vuol dire questo? Vuol dire community di idio** poiché lavorano a gratis per qualcuno che vuole dei soldi da loro… Ad ogni buon conto io parlo di software commerciale non ludico dove le localizzazioni spesso sono vere e proprie “nuove installazioni” bacate e problematiche, pagate a parte e spesso talmente malfatte da lavorare con la versione inglese… Idem la documentazione, reference per ogni cosa e impossibilità pratica di apprendimento se non coi corsi appositi del vendor… Il mondo open stà seguendo questa scia: prova a domandare quanti usano info, apropos, persino quanti usano man. Poi chiedi quanti usano soluzioni terze (da stackexchange a google) rispetto a soluzioni “distribuite” (ng, ml ecc).

            > Chiunque può rigenerare uno Snap e chiunque
            > potrebbe voler produrre una patch.
            Ti rendi conto del caos che implica quanto affermi? Oggi ogni pacchetto ha un maintainer + un catchall per i pacchetti orfani. In pratica gli sviluppatori scrivono il programma e basta, i maintainer prendono le source e le impacchettano. Il linking dinamico e i test (+bugreport della community “di sviluppo” della distro) fan il loro lavoro. Nel tuo modello per aggiornare chessò SSL che è dipendenza richiesta da millemila pacchetti ogni singolo snap dev’essere aggiornato. Ma se poi l’upstream non è veloce vabbé qualcun’altro fa e pubblica uno o più snap nei repo “snap” ufficiali. Renditi conto che vuol dire sul piano sistemistico *non sapere* quante n versioni di versi di una libreria con le relative vulnerabilità hai installate sul tuo sistema. È molto simile al caos di Windows, manca solo l’update individuale degli snap con il popup nel systray per esser uguali!
            È PURA FOLLIA.

            > Nulla vieta di replicare il comportamento con gli Snap
            Certo, ma nulla incoraggia. Se tu upstream pubblichi un tarball, n maintainer di n distro/OS diversi pigliano le source, provano a compilarle, scovano problemi ecc c’è una “partecipazione tecnicamente obbligata”, un flusso di contributi occasionali e soggetti vicini per competenze che si parlano costantemente. Col modello snap l’upstream si può chiudere a riccio e la comunicazione è solo utente-sviluppatore che in molti casi vuol dire zero patch, bugreport inusabili, zero idee utili perché l’utente è sempre più spesso informaticamente ignorante a livelli parossistici. Snap non vieta come systemd non obbliga ad esser usato, l’insieme di chi tira le fila forte della sua posizione obbligano di fatto distruggendo il “tessuto sociale” della community.

            > Molto di quel codice è scritto dalla comunità FOSS che tanto elogi.
            Non più da tempo, oramai la “community” sono show aziendali monocolore, quasi tutti col cappello rosso…

            > In generale poi XOrg era notoriamente inadatto allo scopo
            > ma la comunità FOSS l’ha comunque lasciato lì.
            Si, per una semplice ragione: non c’è più da *decenni* una comunità FOSS che sviluppa. Oggi si vede a livelli plateali, 10-15 anni fa si vedeva meno. Per capirci una comunità FOSS è quella GNU, oggi in larga stagnazione, quella BSD oggi sempre più piccola numericamente, quella Linux, oggi sempre più formata da 4 gatti supercontributori e contributori marginali. Pensa solo a 10 anni fa o giù di li coi rami CK (e giusto per dire Con Kolivas è un anestesista che manteneva il più apprezzato ramo “desktop” di Linux), MM ecc oggi non c’è manco più qualcuno che compila un kernel personale.

            > Wayland è un progetto di neanche 10 anni ed ancora non è pronto,
            Wayland è un progetto by RedHat e quel po’ di community ancora rimasta non gradisce granché questa azienda…

            > ZFS ha una versione open ma è un progetto gestito da un’azienda,
            > non da una community ed usa comunque le POSIX.
            Non ti offendere ma tu lo zfs non l’hai probabilmente mai usato né studiato. Si lo zpl (zfs posix layer) implementa un fs posix, deve farlo poiché il 99% delle applicazioni quello conosce, con quello parla. Ma lo ZPL è un layer sopra lo zfs e di layer se ne possono fare tanti altri, seguendo un po’ il modello di Plan9, per esempio puoi avere un layer “applicazioni”, un layer “foto”, un layer “video”, un layer “db” ecc. Caratteristiche di cui abbiamo un gran bisogno. Quanto allo zfs oggi è parte di IllumOS, una community e la SUN pur essendo un’azienda è storicamente sempre stata community friendly e molto ben vista.

            > Oltretutto con ZFS il problema delle librerie non cambia minimamente
            zfs live deduplication: puoi avere n binari statici ovvero che dal loro punto di vista (via il layer posix fs) che contengono le librerie di cui han bisogno, ma su disco c’è una sola copia della libreria. In pratica un linking dinamico ad un altro livello. E la dedup, le varie compressioni, raiz* ecc mostrano come sia utile sorpassare il vecchio modello posix e come si possa fare, con un software production-ready.

            > nel mondo open chi scopre l’exploit
            Non si scopre “un exploit” si scopre una potenziale falla. Nel mondo FOSS si segnala la potenziale falla all’upstream e in molti casi sono proprio i maintainers ad accorgersi che qualcosa non va essendo n occhi che guardano lo stesso codice, ben prima di scrivere un exploit che la sfrutti. Nel mondo commerciale in genere sino a che non si è diffuso un pochino l’exploit fatto e finito non si corregge nulla.

            > Se anche l’azienda non si fosse occupata di chiudere il bug
            > ci sarebbe lo sm***mento pubblico (come è già capitato)
            > costringendola a risolvere.
            Si, tipo tutto l’abandoware mobile che continua a girare con bachi e backdoor di fabbrica…

            > Per inciso, l’unico caso che trovo in rete di problemi di
            > sicurezza con Snap è relativo a X11.
            Anche questo è mentalità Windows: non mi interessa le vulnerabilità già scoperte ma quelle potenziali. Snap dice che si occupa di sicurezza tramite sandboxing ovvero incoraggia il concetto che con snap sei comunque al sicuro. Poi buca la sandbox per permetterti di accedere alla home perché ad es. se scrivi un documento con Libreoffice-snap vuoi magari poterlo inviare con Thunderbird-snap e se la containerizzazione è completa non puoi a meno di non comunicare via rete, cosa a dir poco assurda. Poi arrivi a dire bé si, effettivamente per 300Kb di SSL aggiornare 300MB di software (senza contare lo spazio disco e la ram occupate) è un pelo una cavolata, bucheremo la sandbox anche per questo. La traduzione è “abbiamo proposto un concetto che credevamo fosse carino, abbiamo scoperto che presenta un mucchio di problemi e anziché vedere come altri prima di noi han risolto andiamo avanti col colabrodo”. Questo significa “insecure by design”. Questo è il tipico modello USA commerciale: “butta e poi fix on the go”.

          • DeeoK

            >Sai che vuol dire questo? Vuol dire community di idio** poiché lavorano a gratis per qualcuno che vuole dei soldi da loro…
            La community lavora sempre gratis, altrimenti è un’azienda…
            Spesso il team di localizzatori viene “ripagato” con qualche copia omaggio, ma generalmente lo si fa per passione, non per ricavarci nulla.

            > Discorso sugli Snap
            Il funzionamento è lo stesso che c’è attualmente dove se vuoi scaricare un pacchetto hai a disposizione il tar, il deb, rpm e compagnia bella. Dopo basteranno solo tar e Snap.
            Forse impigrirà la community ma è tutto fuorché maggior casino. Il casino c’è ora dove devi sempre sperare che la compilazione vada a buon fine.

            > Wayland è un progetto by RedHat e quel po’ di community ancora rimasta non gradisce granché questa azienda…
            Senza dubbio, ma resta il fatto che XOrg è stato lasciato lì per decenni senza che nemmeno fosse nato come server grafico.

            > ZFS ha una versione open ma è un progetto gestito da un’azienda,
            > non da una community ed usa comunque le POSIX.
            Quanto allo zfs oggi è parte di IllumOS, una community e la SUN pur essendo un’azienda è storicamente sempre stata community friendly e molto ben vista.
            Ma resta una azienda, quindi come puoi vedere sei passato dal dire che le aziende sono il male al dire che solo alcune aziende lo sono.

            >zfs live deduplication: puoi avere n binari statici ovvero che dal loro punto di vista (via il layer posix fs) che contengono le librerie di cui han bisogno, ma su disco c’è una sola copia della libreria. In pratica un linking dinamico ad un altro livello. E la dedup, le varie compressioni, raiz* ecc mostrano come sia utile sorpassare il vecchio modello posix e come si possa fare, con un software production-ready.
            Ma resta il problema delle dipendenze e della distribuzione.

            >Non si scopre “un exploit” si scopre una potenziale falla. Nel mondo FOSS si segnala la potenziale falla all’upstream e in molti casi sono proprio i maintainers ad accorgersi che qualcosa non va essendo n occhi che guardano lo stesso codice, ben prima di scrivere un exploit che la sfrutti. Nel mondo commerciale in genere sino a che non si è diffuso un pochino l’exploit fatto e finito non si corregge nulla.
            Non necessariamente ed il caso Samba mostra come è venuto fuori prima l’exploit e solo da lì si è scoperta la falla.

            Anche questo è mentalità Windows: non mi interessa le vulnerabilità già scoperte ma quelle potenziali. Snap dice che si occupa di sicurezza tramite sandboxing ovvero incoraggia il concetto che con snap sei comunque al sicuro. Poi buca la sandbox per permetterti di accedere alla home perché ad es. se scrivi un documento con Libreoffice-snap vuoi magari poterlo inviare con Thunderbird-snap e se la containerizzazione è completa non puoi a meno di non comunicare via rete, cosa a dir poco assurda. Poi arrivi a dire bé si, effettivamente per 300Kb di SSL aggiornare 300MB di software (senza contare lo spazio disco e la ram occupate) è un pelo una cavolata, bucheremo la sandbox anche per questo. La traduzione è “abbiamo proposto un concetto che credevamo fosse carino, abbiamo scoperto che presenta un mucchio di problemi e anziché vedere come altri prima di noi han risolto andiamo avanti col colabrodo”. Questo significa “insecure by design”. Questo è il tipico modello USA commerciale: “butta e poi fix on the go”.

            >Discorso sicurezza
            No, non buca la sandbox, se ho ben capito dalla documentazione si basa su permessi ed interfacce quindi l’accesso a cartelle “non proprie” avviene tramite la comunicazione tra Snap.
            Neanche nel discorso delle dimensioni si buca la sandbox perché dovrebbe avvenire tutto durante la generazione dello Snap da parte di un package manager, quindi a tempo di compilazione, non di esecuzione.

          • Kim Allamandola

            > La community lavora sempre gratis, altrimenti è un’azienda…
            La community, nel FOSS lavora per se medesima quindi non è gratis ne a pagamento, è mero interesse personale. Ben alto è lavorare gratis per un’aziende che con te non condivide nulla ma ti fa pagare un servizio/prodotto.

            >> Discorso sugli Snap
            > Il funzionamento è lo stesso
            Scusa la rudezza ma temo tu non abbia capito come funziona il FOSS, l’opensource in genere. Il fatto che l’utente si trovi “comandi equivalenti” per apt/yum/pacman/* e snap non significa affatto che il funzionamento è lo stesso. Oltre ai problemi di sicurezza che se snap avrà successo chiunque abbia un po’ di esperienza sa che arriveranno a pioggia, oltre al macello della gestione degli update, oltre alla “perdita di ruolo” delle distro l’utente tipo si troverà deploy sui 30Gb anziché 10Gb, si troverà aggiornamenti da centinaia di Mb costanti (e sopratutto se li troveranno i server delle distro) e si finirà come con docker a scaricare roba da sorgenti (siti) sconosciute cadendo ancora di più nel modello Windows. Non è lo stesso per un accidente di niente.

            > Senza dubbio, ma resta il fatto che XOrg è stato lasciato lì
            > per decenni senza che nemmeno fosse nato come server grafico.
            Si, anche perché scrivere un server grafico è una lavoraccio e nessuno alla fine si è trovato abbastanza scontento da XOrg per scrivere qualcos’altro. Adesso (non da adesso) è esplosa la moda dei compositing, dei DE come canvas ecc ma all’utente tipo questo NON interessa. Per capirci abbiamo tutti usato con divertimento compiz, beryll e tutti gli altri col cubo rotante, le finestre tremolanti ecc, molti abbiamo anche usato LookingGlass (un desktop 3D sperimentale della SUN) ma abbiamo tutti detto: bello. Non ci investo 1′ di tempo però. Non mi da nulla di utile, solo un po’ di zucchero. Se qualcuno lo vuol sviluppare si accomodi ma la community in massa non è molto interessata. Tieni presente che la maggior parte degli “sviluppatori esperti” che potrebbero fare un simile progetto gradivano fluxbox, windowmaker, sawfish, twm, enlightenment (sino alle prime e17), … oggi i3, awesome, ratpoison, xmonad, … A ben guardare la stragrande maggioranza di quel che si fa al computer è mero *testo* ed è più comodo gestirlo in forma testuale/integrata (per esempio mail, contatti, calendario, news, feeds, podcast, … tutti a portata di dito in Emacs, tutti integrati tra loro via org-mode). Via “stile GUI” punta&clicca non si è ancora riuscito in decenni, tanto nel mondo commerciale quanto in quello open ad arrivare a qualcosa di altrettanto usabile ed efficiente.

            > Ma resta una azienda, quindi come puoi vedere sei
            > passato dal dire che le aziende sono il male al dire
            > che solo alcune aziende lo sono.
            L’aziendalismo di stampo inglese è il male, il managerismo. Le aziende di una volta, di quando accidentalmente non c’era crisi, c’era evoluzione, la produttività era assai maggiore di oggi, la gente era mediamente contenta ecc non erano quelle di oggi. Nel mondo IT il futuro lo decidevano i tecnici delle aziende sentiti i loro clienti, il management faceva il suo lavoro ovvero gestiva il presente. Se avessi parlato qualche volta col supporto SUN e qualche volta con qualche azienda moderna da IBM ad Accenture capiresti la differenza. Poiché ad oggi l’aziendalismo è la regola la community resta l’unico “rifugio” per non bruciarsi ulteriormente perché abbiamo imparato che anche le aziende buone d’un tempo possono fallire, scomparire, snaturarsi e quindi nonostante fossero buone non sono affidabili nel lungo periodo. Oggi, dopo esserci bruciati varie volte l’abbiamo (almeno alcuni tra noi) imparato.

            >> zfs live deduplication
            > Ma resta il problema delle dipendenze e della distribuzione.
            Se fai un sistema basato sulla dedup non hai problemi di dipendenze collegati, al massimo di risorse per la dedup stessa. Puoi compilare staticamente tutti i binari se vuoi, mantenendo il metodo tradizionale così non hai più i problemi delle versioni multiple di una libreria o software vario e non occupi spazio disco extra perché solo i “blocchi” unici vengono salvati effettivamente.
            La distribuzione la puoi fare incapsulando zfs send che supporta l’invio deduplicato e incrementale da anni. Per capirci puoi fare pacchetti come mini-volumetti zfs aggiungendo tra l’altro varie feature carine (update incrementale à-la-freebsd-update, zfs diff per controllare cosa è cambiato in un pacchetto, possibilità di legare una conf ad un pacchetto nella propria automazione e tanto altro). IPS di OpenSolaris aveva timidamente mostrato una via e senza arrivare a quanto sopra già permetteva cose *impossibili* o *ipercomplesse* su tutti gli altri sistemi esistenti:
            – clonazione del deploy in uso ovvero avere n versioni dell’install su disco per poter giocare con n configurazioni diverse, occupando solo le differenze tra un’install e l’altra
            – invio dell’OS da una macchina ad altre, incrementale incluso
            – controllo di ogni singolo cambiamento in un deploy
            Chi non l’ha usato penso abbia difficoltà solo a comprendere cosa vuol dire.
            Ti cito solo un esempio banale: stai supportando un certo numero di configurazioni su un certo numero di macchine. Ok. Le deploy in locale (su ferro adatto, ovvio) quindi ti installi in locale i mailserver, dns, loadbalancer, db, … ognuno in un volume dedicato, testi, automatizzi ecc poi invii il volume alle macchine fisiche di produzione. Il classico in altri ambiti è con soluzioni virtuali ovvero con un’overhead enorme, il problema di mantenere le immagini aggiornate (non lo sono mai) e di gestire un’infrastruttura elefantiaca. Con OpenSolaris avevi l’equivalente di MAAS, OpenStack &c senza overhead sostanziale, come installando a mano bare-metal e senza mostri da gestire, deployare, conoscere, aggiornare ecc.

            > Non necessariamente ed il caso Samba mostra come è
            > venuto fuori prima l’exploit e solo da lì si è scoperta la falla.
            Posso chiederti per te cos’è un exploit? Perché se mi dici “il protocollo è fallato e quindi la sua implementazione formalmente corretta è vulnerabile-by-design” non stai dicendo nulla. Prima si scopre il problema, poi si automatizza il modo di sfruttarlo.

            > No, non buca la sandbox, se ho ben capito dalla documentazione
            > si basa su permessi ed interfacce quindi l’accesso a cartelle “non
            > proprie” avviene tramite la comunicazione tra Snap.
            Il fatto che dalla sandbox ci passi attraverso “un mediatore” non aggiunge una virgola sul piano security: stai bucando la sandbox. Se il tuo apparentemente legittimo programma, per esempio, vuol cancellare tutti i files nella tua home li cancella. il “mediatore” qualche che esso sia che offra direttamente le api posix, che le offra tramite fuse o qualcos’altro non ha modo di decidere se quel che fai è legittimo o meno. Voler girare intorno ad un problema per ricascarci (cosa che fa snap&c) è solo ignorante/infantile, non è che cambiando nomi o aggiungendo elementi inutili che cambi la sostanza.

            > Neanche nel discorso delle dimensioni si buca la sandbox perché
            > dovrebbe avvenire tutto durante la generazione dello Snap da
            > parte di un package manager, quindi a tempo di compilazione,
            > non di esecuzione.
            Prova a elaborare… Gli snap sono in ultima analisi container di applicazioni statiche. Ovvero se snap_pippo, snap_pluto, snap_paperino, snap_minnie, … usano tutti libreria paperopoli tutti avranno una copia di paperopoli al suo interno, questa occuperà quindi n volte il suo spazio su disco con n == numero_di_snap_che_la_usano e occuperà n volte la ram a runtime. In fase di compilazione che fai? Replichi i pkg-man tradizione introducendo le dipendenze tra gli snap? Così dopo un po’ arrivi ai deb n.x n volte più complessi e che non offrono un’ɛ in più? Oppure fai compilare in locale ogni snap con fetch di source, bdeps (che occupano più spazio delle rdeps, giocoforza) e tutto? Allora hai creato una brutta copia peggiorata dei ports dei BSD, del portage di Gentoo, di AUR ecc.

            Mi spiace. Snap è una PORCATA scritta da qualcuno che non s’è guardato intorno, s’è buttato sul codice credendo di fare “una figata pazzesca”, l’ha pubblicizzato così, ha ottenuto una gran hype di altri che non si son guardati intorno e pian piano i nodi vengon scoperti sul pettine. Ci abbiamo messo un buon decennio per arrivare ai pkg-man tradizionali e chi c’ha lavorato aveva in media assai più competenze degli sviluppatori odierni. È piuttosto difficile che lo stesso problema venga risolto meglio giocando coi lego.

          • DeeoK

            >La community, nel FOSS lavora per se medesima quindi non è gratis ne a pagamento, è mero interesse personale. Ben alto è lavorare gratis per un’aziende che con te non condivide nulla ma ti fa pagare un servizio/prodotto.
            Quale lavoro gratis per l’azienda, lì si fanno mod e traduzioni per gli altri utenti, quindi si lavora comunque per la community (e pure per sé stessi, perchè tali aziende potrebbero comunque appoggiarsi allo stesso team per avere lo stesso risultato in futuro).

            >Non è lo stesso per un accidente di niente.
            Come già detto si parla di un sistema in sviluppo ed ho già discusso sulla questione dimensione, poi fai come ti pare.

            >Xorg
            In pratica il riassunto è “Alla community andava bene così, quindi amen”. Gran bel modus operandi, oltretutto non tutti amano avere esclusivamente una shell testuale ma va beh.

            >ZFS
            Devi condividere sottovolumi, quindi il problema delle dimensioni dei pacchetti rimane.

            >Posso chiederti per te cos’è un exploit? Perché se mi dici “il protocollo è fallato e quindi la sua implementazione formalmente corretta è vulnerabile-by-design” non stai dicendo nulla. Prima si scopre il problema, poi si automatizza il modo di sfruttarlo.
            Questo lo hai detto tu. Il problema fu scoperto (dalla massa) perché c’era un attacco noto. Se scopro una falla e voglio sfruttarla mica lo vado a dire a tutti.

            >Il fatto che dalla sandbox ci passi attraverso “un mediatore” non aggiunge una virgola sul piano security.
            Certo che lo aggiunge. E’ lo stesso funzionamento che hai con qualsiasi entità software che usi un qualche tipo di API. Si chiamano interfacce ed una qualunque sandbox le usa (mica esiste in un universo a sé stante). La gestione sicurezza a quel punto la fai gestendo le comunicazioni ed i permessi.

            >Prova a elaborare…
            Nel caso si voglia scaricare (e processi simili) Sanp a sé stanti sì, replichi paperopoli. Nel caso si voglia usare un gestore software puoi condividere librerie. In caso di aggiornamento puoi decidere se integrare nei singoli Snap la libreria condivisa oppure aggiornare paperopoli lasciandola condivisa. Queste informazioni possono essere gestite tramite l’operato dei mantainer: se testo lo snap con paperopoli 1.1 e funziona posso lasciare paperopoli si aggiorni, alternativamente posso passare alla duplicazione.

          • Kim Allamandola

            > lì si fanno mod e traduzioni per gli altri utenti,
            > quindi si lavora comunque per la community
            Si, per la community che *paga* quello a cui contribuisce. Nel FOSS quel che contribuisci è tuo, tuo copyright, tuo il diritto di usare e diffondere il tuo contributo ed il codice. Se la vogliamo portare nel mondo fisico è come se porti in ufficio usa sedia/lampada/altro “perché così si stà più comodi”. L’ufficio non è il tuo anche se ci lavori, il software libero si.

            > Come già detto si parla di un sistema in sviluppo
            Quindi secondo te siccome è in sviluppo (peraltro già nella iso ufficiale, quindi non proprio embrionale eh!) qualsiasi cavolata fatta a livello di design non conta?

            > ed ho già discusso sulla questione dimensione, poi fai come ti pare.
            Con affermazioni inconsistenti: non puoi ridurre la dimensione degli snap salvo appunto avere la root su un filesystem deduplicato. Ogni altro tentativo (che per inciso non hai descritto, anche perché non può tecnicamente esistere) è semplicemente impossibile. A meno di non ritornare al paradigma classico, niente più containers ne linking statico. Se, siccome il trend è dire che snap è bello, vuoi difenderlo ad ogni costo fai pure ma sappi che stai difendendo una posizione indifendibile, che per di più o, spero chiaramente, smontata nei post precedenti.

            > In pratica il riassunto è “Alla community andava bene così,
            > quindi amen”. Gran bel modus operandi,
            Ahem, la community siamo noi tutti, ok? Non siamo “consumatori” o “clienti” siamo parte della community, “cittadini” se vuoi. Quindi se a noi va bene così, ci va bene. A chi altro dovrebbe andare? A qualche azienda USA che non gradisce la community?

            > oltretutto non tutti amano avere esclusivamente
            > una shell testuale ma va beh.
            Non mi pare ci troviamo con una shell testuale, in effetti avevamo grafica decenni prima di Windows e del DOS… Semplicemente la grafica che abbiamo ci va bene com’è. Emacs come centro del mondo desktop o gVim+app varie non sono “TUI”, sono GUI il cui metodo principale di interazione è il testo, poiché questo è ad oggi il più comodo ed efficiente sistema che abbiamo di interagire. Per capirci dentro Emacs ci vedo anche Youtube.

            > Devi condividere sottovolumi, quindi il problema delle
            > dimensioni dei pacchetti rimane.
            Non conosci lo zfs. I volumi descritti sono sotto un solo uberblock, parte del root volume, ovvero deduplicato. Questo è una cosa oggi *inesistente* ma *possibile*, IPS più semplicemente usa un solo volume dandoti comunque grazie allo zfs la possibilità di clonare, inviare, ecc la tua install e ad oggi NON c’è altra soluzione al mondo in grado di far ciò senza essere un mostro tipo un’infrastruttura VMWare full-stack.

            > Il problema fu scoperto (dalla massa) perché c’era un attacco noto.
            Ma ti riferisci per caso “alla massa” di pirla che esponeva share windows dai nas su internet? Quelli han solo scoperto di essere pirla. Ripeto dire prima arriva l’exploit poi si scopre la vulnerabilità è come dire che prima nasce il feto, poi ovulo e spermatozoo si uniscono. L’exploit è lo sfruttamento di una falla. Non puoi sfruttare una falla se non la conosci. Nel mondo FOSS poi è uso comune non “tenere per se” le vulnerabilità ma informare con discrezione l’upstream perché tutti siamo parte della community, sia gli scopritori di una vulnerabilità che le vittime. Nel “mondo commerciale” invece siccome il software si monetizza come un prodotto questo può anche non avvenire. Ma il mondo commerciale non è “Il Mondo”, è solo uno degli aspetti della nostra società.

            > Certo che lo aggiunge. E’ lo stesso funzionamento che hai
            > con qualsiasi entità software che usi un qualche tipo di API.
            > Si chiamano interfacce ed una qualunque sandbox le usa
            > (mica esiste in un universo a sé stante). La gestione sicurezza
            > a quel punto la fai gestendo le comunicazioni ed i permessi.
            Temo, senza offesa, che tu non sappia come funziona un filesystem. Per capirci un fs è un’API che il tuo software usa, open(), write() ecc sono funzioni/metodi di questa API, sono il tuo mediatore. Se in mezzo ci metti qualcosa di “trasparente” (perché è la sola cosa che puoi metterci, altrimenti devi scrivere il software apposta per la tua api personale) che parli posix da un lato e dall’altro non ti permette di aggiungere nulla. Posix prevede permessi (user, groups, other) e livelli di accesso (lettura, scrittura, esecuzione) e questi sono normalmente più che sufficienti. Altri OS, Windows ad esempio, prevedono sistemi assai più contorti e non mi risulta che siano più sicuri, anzi.

            > Nel caso si voglia scaricare (e processi simili) Sanp a sé stanti sì,
            > replichi paperopoli. Nel caso si voglia usare un gestore software
            > puoi condividere librerie.
            Cosa vuol dire in italiano? Ti immagini che snap (gestore degli snap, “comando” di default sulla tua Ubuntu) quando scarichi pippo, pluto e minnie sappia che questi usano paperopoli e dialogando col server snap prenda solo una copia di paperopoli e poi la “distribuisca” in loco sugli snap scaricati? Se è così temo che tu non abbia mai scritto altro che un hello world perché è semplicemente *pure follia* richiederebbe una sorta di “filesystem” del “repo snap” che abbia una sua deduplicazione interna e dialoghi col client fornendo in stile “streaming” solo i blocchi dati necessari e poi il client si componga gli archivi. Ammesso che si riesca a realizzare cotale mostro e che questo funzioni stabilmente hai una centralizzazione totale, rigida e pazzesca per farlo funzionare, hai bisogno di risorse qualche ordine di grandezza superiori ai repo tradizionali sia lato server che lato client e una complessità assurda.

            > In caso di aggiornamento puoi decidere se integrare nei singoli Snap la libreria condivisa
            UAU, ancora più folle, linking statico senza ricompilazione…

            > oppure aggiornare paperopoli lasciandola condivisa
            Cioè implementando il linking dinamico che già c’è da decenni, ovviamente senza più container perché altrimenti non puoi realizzarlo.

            > Queste informazioni possono essere gestite tramite l’operato
            > dei mantainer: se testo lo snap con paperopoli 1.1 e funziona
            > posso lasciare paperopoli si aggiorni, alternativamente posso
            > passare alla duplicazione.
            Ti rendi conto che alla fine del mostro stai arrivando ad uno qualsiasi degli n pkg-man già esistendi da decenni? update-alternatives per far un esempio sai da quanto c’è sulle Debian?

            Guarda non mi pare che andiamo molto avanti. Penso che sia abbastanza chiaro che gli snap sono una *cavolata pazzesca* priva di alcun senso se non l’aiutare il software commerciale, da quel che hai scritto si capisce che cerchi giustificazioni (cosa positiva eh, se si è convinti di qualcosa cercare di dimostrarlo vuol dire verificarlo, comprenderlo e questo fa parte del normale processo evolutivo di ogni utente FOSS, nessuno “nasce esperto” ma “cresce” lungo la strada) senza trovarne e posso garantirti che il motivo è semplice: non ce ne sono. Se vuoi un esempio ben più testato degli snap guarda i PBI di PCBSD e guarda dov’è PCBSD oggi. Hai molta più documentazione degli snap essendo un progetto assai più anziano.

            Sul discorso dedup tieni presente che su OpenSolaris dove lo zfs è nato era semplice parte di un sistema di automazione “inviarsi” installazioni in rete, clonarle, modificale, ecc ed era (è, se vuoi perché puoi sempre installarlo tutt’ora con OpenIndiana) FANTASTICO, su GNU/Linux la storia è ben diversa. C’è un port zoppicante dello zfs realizzato dal LLNL (Lawrence Livermore National Laboratory, che è un buon esempio di azione comunitaria: un’istituzione di ricerca prende un progetto open source e lo evolve) ma non c’è IPS, non c’è BEADM, non c’è il grub patchato dalla SUN, non c’è l’SMF ecc. Puoi installare su root zfs, su Ubuntu come su Arch (cerca “Ubuntu o Arch zfs root) il supporto è discretamente usabile. Puoi clonare ed inviare un’install (ovvero un volume) di Ubuntu o Arch in LAN ma hai parecchio lavoro manuale sia per l’installa che per l’invio. Puoi automatizzarlo ma non è così “stabile”. Se pensi su questo di farci un pkg-man sopra allo stato attuale stai pensando ad una torre di Babele tenuta insieme con lo scotch, non certo qualcosa che possa andare oltre il POC sulla macchina dell’autore.

            Esplora, prova lo zfs, anche solo per la /home se vuoi semplificarti la vita, poi prova a backupare la home ed usare gli snapshot. Prova a “semi-clonare” la home se hai più desktop (es. un laptop ed un fisso) usando unison. C’è un mondo “storico”, tutt’ora vivo che ti permette di fare cose assai comode e *impensabili* per l’utente Windows-iano. Guardati una demo di org-mode su youtube, poi prova a farti la tua configurazione. Sarà una via lunga ma questa è la via del FOSS: cominci facilmente e impari via via, man mano che senti il bisogno o la curiosità per qualcosa. La curva di apprendimento è lunghissima, morbidissima e infinita. “socialmente” è la differenza tra una società competitiva ed una collaborativa. Tra una società di alienati stressati ed una di persone tranquille e rilassate. Questo è ciò che mi gira che questa comodità, tranquillità è sempre più messa in pericolo da evoluzioni che sono di fatto *involuzioni*, corse a passo di gambero.

            Quando avrai toccato con mano e passato lo shock culturale vedrai che i progetti à-la-Windows ti faran montare i nervi e riconoscerai anche solo a pelle la loro natura e possibile evoluzione.

          • DeeoK

            >Ahem, la community siamo noi tutti, ok? Non siamo “consumatori” o “clienti” siamo parte della community, “cittadini” se vuoi. Quindi se a noi va bene così, ci va bene. A chi altro dovrebbe andare? A qualche azienda USA che non gradisce la community?
            Il discorso è inconsistente. XOrg era inadatta ma non è stato fatto nulla perché alla community (quindi al popolo) andava bene così. Potrei riapplicarti il discorso a tutti gli aspetti contestati fino ad ora. Al popolo è andato bene fino ad ora stare senza ZFS, quindi va tutto alla grande.
            >poiché questo è ad oggi il più comodo ed efficiente sistema che abbiamo di interagire
            Passi l’efficienza ma sulla comodità c’è sicuramente da ridire.
            >Non puoi sfruttare una falla se non la conosci.
            Capisci che questo ragionamento funziona solo con un insieme di una persona? Io scopro una falla che nessuno altro ha ancora scoperto, la uso, una volta usata diventa nota. E’ un funzionamento pressoché standard. Tiene per sé l’utente malizioso, non il mantainer. L’approccio in questo caso è sempre lo stesso a prescindere dall’ambiente: chi scopre segnala a chi di dovere e solo se quest’ultimo è inadempiente allora viene resa nota la falla.

            Sorvolo sul discorso ZFS perché non avendolo provato è inutile discuterne.
            Sorvolo anche sul discorso Snap perché al di là di tutto non ho voglia di starmi a leggere tutta la documentazione a riguardo e onestamente neanche mi interessa. Al di là dell’infinito discorso che, tra l’altro, Disqus ha pure tagliato quindi non so per quanto prosegua, online l’unico problema di sicurezza riscontrato fino ad ora alla fine è un problema di XOrg quindi tutti questi mostruosi problemi o non ci sono o non interessano alla community, quindi al popolo, quindi siamo tutti felici.

          • Kim Allamandola

            Interessante e azzeccato il paragone tra zfs e XOrg, non è proprio la stessa cosa per un solo motivo: il desktop è abbastanza secondario: lo usiamo tutti, ma a livello di commodity, “quello che conta” sono le applicazioni e il sistema di base (kernel+userland), per quando io sia un paladino del desktop FOSS il grosso dell’utenza è da sempre professionale, non domestica quindi il grosso dello sviluppo è in queste aree. L’utente desktop forte di hw discretamente affidabile per la criticità dell’uso che svolge (guasti di hd abbastanza rari) e del semplice backup (in genere una singola macchina o due a persona) se ne infischia. Avrebbe certo dei vantaggi dallo zfs sia nell’immediato (meno lavoro necessario e sgradito in caso di problemi, giochi ed esperimenti personali “sicuri”) sia nel medio&lungo periodo (un OS “moderno”, che oggi *non* abbiamo tanto nel FOSS quanto nel commerciale). A chi altro potrebbe interessare? A noi che lavoriamo con GNU/Linux. E qualcuno il port l’ha fatto (più di uno a dire il vero anche se l’LLNL è l’unico veramente mantenuto e valido) e tanti l’han supportato da Ubuntu ad Arch. Ocio che *non* siamo più, da tempo, la fetta maggioritaria di *utenti*, i deploy “da lavoro” sono la maggioranza ma chi li gestisce è una minoranza, sempre più ristretta e chiusa nel datacenter. La maggioranza degli utenti sono “nuove leve”.
            > Passi l’efficienza ma sulla comodità c’è sicuramente da ridire.
            Un esempio personale: all’avvio del computer metto una password (tastiera), mi parte in automatico Tilix con 4 terminali ed Emacs (1 frame, il demone e 3 windows) ho subito disponibile le note (Deft) ove posso cercare semplicemente scrivendo e battendo invio sul match del caso oppure navigando nel buffer. Sotto ho l’agenda che a differenza di quella di Google&c è visivamente una sola interfaccia ma le “source” degli eventi sono una vasta gamma di files sparsi, per esempio ho
            – fiscoFR. org (scadenze fiscali&c francesi)
            – fiscoIT. org (idem come sopra per l’Italia)
            – fiscoSE. org (idem per la Svezia)
            – contacts. org (compleanni e anniversari, la mia rubrica)
            – $nomeProgetto. org uno per progetto nella relativa directory
            – manutenzione. org (eventi cadenziati, divisi nel file per categoria
            – TODOs. org
            ….
            Se voglio ho al volo la panoramica di tutti gli eventi in una data finestra di tempo, ho concentrati e gestibili semplicemente tutti gli eventi di un certo tipo, posso anche zapparli in blocco se serve, posso aggiungere qualsiasi nota mi pare ho tutta la flessibilità di org-mode ed Emacs sottomano.
            Ho le mail aperte (notmuch) con ricerca alla velocità della luce (sono il locale succhiate via dovecot/offlineimap secondo la macchina su cui sono) e nelle stesse ricevo i feed (sino a poco tempo fa usavo elfeed) le vedo al volo, le scrivo al volo, le linko al volo nei files org sparsi, agenda inclusa, ho al volo disponibili i contatti. Posso nello scratch scrivere qualsiasi documento dalla lettera al foglio di calcolo al “notebook” stile mathematica/maxima/jupyter&c con la potenza di due CAS simbolici di tutto rispetto (calc di Emacs e imaxima) e se voglio anche numerici (octave, anche se è un lascito dei tempi dell’uni), nello stesso file di testo costruisco al volo le tabelle che agiscono come foglio di calcolo (cerca org-mode tables demo sul tubo), scrivo report pescando direttamente da ELK, scrivo l’automazione che mi serve e la eseguo sul posto (org-babel) per una pletora di linguaggi, disegno diagrammi se serve (ditaa, graphviz o TiKz secondo quel che devo fare) esporto il tutto in pdf se mi serve, o lo stampo o lo invio via mail o lo invio via rsync/http(s) post/curl a qualche sito, ricevo i ticket che mi riguardano, chatto, ho un terminale (un po’ bacato ma comodo al volo) ecc ah, si, gestisco anche la contabilità personale con ledger succhiando un QFX che ricevo dalla banca. Passo da una finestra all’altra nel desktop con alt+frecce, chiudo le finestre con un tasto dedicato sulla tastiera. Incollo con clipIt con un altro tasto dedicato sulla tastiera che apre il popup. Non lo trovi comodo? Dove hai uno strumento che sia:
            – PIM
            – agenda
            – posta
            – cas
            – terminale
            – MUA
            – client di chat
            – frontend ad un paio di sistemi di ticketing
            – suite da ufficio con la potenza di LaTeX e pandoc sempre disponibili e integrato con una pletora di linguaggi di programmazione (es. grafici generati con snippet semplici python o elisp o shell)
            – client feed e news
            – ricerca full tex integrata (via Recoll e counsel)
            – browser minimale
            – rubrica superaccessoriata comprensiva di sincronia con radicale per restare unito al telefono
            – logbook (org-clocking/habit ecc)

            Il più vasto ERP/DMS/CRM/Ticketing che ci sia non ha le stesse funzioni è n-mila volte più complesso, n-mila volte più problematico da mantene e non ha la stessa flessibilità, anzi manco ci va vicino.
            > Io scopro una falla che nessuno altro ha ancora scoperto,
            > la uso, una volta usata diventa nota. E’ un funzionamento
            > pressoché standard.
            Si, su Windows. In ambito FOSS se la scopri sei parte della community e la prassi standard è esser un onesto cittadino perché vivi in un ambiente onesto, rilassato, di un certo livello. Su Windows sei in un mondo di squali, di stressati e di gente che ha sempre qualcosa che non va.
            > chi scopre segnala a chi di dovere e solo se quest’ultimo
            > è inadempiente allora viene resa nota la falla.
            Di nuovo no. Se sei nel mondo FOSS non c’è un “chi di dovere” specifico, tu stesso se la community di un certo progetto non si segue che puoi pubblicare una patch (perché hai il codice ed il diritto di usarlo, modificarlo e redistribuirlo) e i membri di quella community possono venirti dietro, possono forkare il progetto ecc. Solo nel mondo closed non hai scelta.
            L’ho detto che per chi viene da Windows è difficile comprendere ambienti diversi.

            Ps a tema Disqus pensa alla liberta dei vecchi e tutt’ora attivi newsgroup o ml, ove non solo non avevi limiti “della piattaforma” ma avevi anche i contenuti in locale gestibili e indicizzabili a piacere.

          • DeeoK

            Hai elencato aspetti di efficienza, non comodità, che è personale. Poi magari a lavoro ti dicono di usare exchange e tutto crolla.

            Comunque Snap non è pensato per un uso in ambito professionale dove i sistemi sono configurati ad hoc ma nasce per loT, dove la gestione deve essere più semplice possibile, e per il mondo home desktop, dove il passaggio da una distro all’altra non è praticamente mai indolore (io, almeno, ho sempre avuto problemi di pacchetti).
            In ambito professionale la gestione di software e aggiornamenti è ben diversa ed è sottomessa all’operatività.

          • Kim Allamandola

            Per esperienza posso dirti che se fai distinguo causi problemi. Ogni cosa diversa che devi gestire vuol dire studio, test, esperienza, attenzione ovvero lavoro in più, possibilità di fare errori in più, potenziali maggiori vulnerabilità (vecchia regola, più cose hai più è probabile ci siano problemi di sicurezza o se vuoi “quel che non c’è non si può rompere”) quindi mentre tutto il mondo spinge sull’integrazione, sul monocolore (in parte a ragione), dove cerchiamo la convergenza verso IP (ed è realtà oramai quasi ovunque, dalle nuove ADSL domestiche con fonia solo VoIP al cablaggio aziendale dove camere, citofoni, telefoni, … sono oramai tutti IP sullo stesso cablaggio), dove cerchiamo la convergenza tra desktop e mobile voler far una cosa diversa del genere è comunque folle.

            Sull’embedded/IoT hai risorse minime, l’idea di Ubuntu Core non credo possa aver successo, semplicemente “consuma troppo” in termini di risorse. Quel che si fa per quel che ad oggi non dà troppi problemi è considerare ogni dispositivo un unicum: come fosse non un’OS/distro che componi ma un solo “pacchetto” di os e applicativi richiesti. La partenza è da una “distro” source-based dove giochi a potare tutto il potabile per arrivare ad una microimmagine che includa tutto il necessario. L’update è in genere: tieni due “flash”, aggiorna su una, riavvia su di lei e controlla che tutto vada, se si aggiorna l’altra dopo qualche tempo (settimana/mese, ‘somma da esser realmente sicuri che tutto vada), costa ma veramente poco ed è la miglior garanzia… Sul desktop sarebbe un discorso paurosamente lungo: abbiamo n cose che non vanno nel modello classico, e il package management è una delle chiavi del problema, però non è la soluzione.

            Per estrema sintesi (sorry, è noto non esser il mio forte) oggi anziamo verso la “semplicità modulare”: non più datacenter di n servers ma “datacenter-as-a-computer” (famoso paper di Google per chi vuole i dettagli) dove hai rack che fan solo “storage” (infiniband, fiberchannell, persino iscsi (scsi other ethernet) per chi non può permettersi altro e macchine blade con ram+cpu. Lato “software” l’oggi è: fa roba resiliente, devi poter reinstallare tutto da zero come se ti piovesse un meteorite su tutto il tuo ferro, in pochi passaggi, meglio se uno solo, nonappena il ferro nuovo è disponibile. Fai qualcosa che regga riavvii random continui (chaos monkey by netflix va molto di moda) dove ogni componente è il più possibile autonomo, semplice, gestibile in forma isolata dagli altri. Non abbiamo software adatto per questo. Ci siamo inventati n soluzioni, di solito iper-complesse che stan anche su ma con una fragilità, indebuggabilità, incomprensibilità, impossibilità a conoscerle veramente a fondo spaventosa per qualche keyword si va dal classico virtualizzazione full-stack stile VMWare sino a OpenStack sino alla “virtualizzazione in hw” by IBM Power. Funziona per carità, ma è un mostro. Canonical ha cercato di dir la sua con MAAS, altri vendor propongono le loro soluzioni perché il castello è talmente complesso che la maggior parte delle aziende non ha competenze né risorse per farselo in casa. Risposta ulteriore: il cloud. Teoria: è troppo complicato far tutto questo in casa. Facciamolo fare a 4 supergiganti con legioni di sviluppatori, sysadmin, superdatacenter e non pensiamoci più. Ulteriore evoluzione: tutto sul cloud! Desktop, documenti personali ecc. Ovvio che non è una soluzione ma è solo scaricar la patata bollente su qualcuno che ha le spalle large, a prezzi che sempre più vediamo esser moooolto alti e indeterminabili a priori (furti e crash di portata planetaria, dipendenza sempre maggiore da 4 gatti che praticamente diventano la “piattaforma” del mondo intero e o passi da loro o non passi proprio ecc).

            Una soluzione “valida”, se si avesse una *vasta* community, di ricercatori, programmatori con tripla P maiuscola, operation veramente esperte ecc che lavorano insieme non per sei mesi ma per 4-6-8 anni almeno sarebbe secondo me:
            – superare il concetto di filesystem, lo zfs ha mostrato la via
            – realizzare sul nuovo layer di storage package manager adeguati
            – grazie a questi realizzare installer adeguati
            lato OS recuperare il cocktail di idee di Plan9 (modello di “computer distribuito”, “tutto è un file all’ennesima potenza”), modello LispM (source che girano sull’hw, tutto si può vedere e modificare a runtime) e modello unix (una solida, flessibile, portabile libreria standard con la base di cui abbiam bisogno, programmi semplici che interagiscono tra loro con IPC fantasticamente semplici). Per far quanto sopra serve un nuovo linguaggio che abbia le caratteristiche che aveva il C ai tempi (semplicità, libreria standard, facilità di utilizzo per quasi ogni cosa). Java un tempo iniziò con alcune di queste idee ma fuori dal mondo SUN e nella stessa parte amministrativa di SUN nessuno lo comprese, go (go get, package come url e compilazione lampo) ha ripreso questo modello.

            In conclusione, per me serve ripartire dal foglio bianco forti dell’esperienza maturata. Aggiunger pezzi e ricombinare tecnologie esistenti perché ripartire dal foglio bianco richiede un gazzilione di tempo e risorse che nel mondo moderno non solo non abbiamo ma manco sappiamo più formare vuol dire continuare con la torre di Babele accelerando sempre più il suo crollo e aumentando il botto quando crollerà. Diciamo che tirar fuori dal cappello qualcosa di semplice&veloce dicendo “hey abbiam risolto tutti i problemi del mondo” è quel che chiede il manager di scuola inglese tipo, è quel che crede di poter fare il “giovane” sviluppatore nato sulle CI, sul DevOps e del tutto privo di esperienza. Il risultato lo vediamo. L’ultimo proprio tra ieri e oggi è il collasso di Amadeus che ha mandato in tilt il settore “turistico” di praticamente tutto il mondo…

          • DeeoK

            Nell’IoT considerare ogni componente come unico è esattamente il problema: ti ritrovi a dover mantenere una miriade di configurazioni diverse con costi esponenziali. Al momento Snap ha come unica richiesta esagerata di risorse quella dello spazio che non è comunque particolarmente un problema (in un dispositivo per l’IoT non installi decine di applicativi) ed incapsulando tutto rende semplice distribuzione, test e aggiornamenti. Snap nasce dal mondo IoT, quello dekstop è venuto dopo.
            Per ogni ambito devi trovare soluzioni diverse perché le esigenze sono diverse.
            Comunque definire il C come semplice è da lol. Le basi sono semplici come quelle di qualunque altro linguaggio, ma anche i soli puntatori sono dei mostri di problemi e buona parte dei linguaggi successivi ha avuto la bella idea di rimuoverli o scoraggarne l’uso. Tra l’altro C e Java sono su due livelli di programmazione diversi e paragonarli negli usi è assurdo. Anche perché Java basa tutto sull’astrazione che non è certo la politica del C.

          • Kim Allamandola

            Nell’IoT il problema è che non esiste uno standard di riferimento ma considerare ogni router, ogni ipcam ecc un pezzo unico non è *mai* stato un problema per la semplice ragione che *sono* pezzi unici costruiti “contro progetto” per un uso specifico, non sono per capirci ferro “general-purpose” costruito da qualcuno e successivamente “specializzato” da altri. Per capirci se fai router domestici non prendi una distro generica, prendi qualcosa di basato su source, es LFS, ti fai la tua distro supersemplice e la consideri un firmware, un “pezzo unico” dove non fai aggiornamenti stile desktop ma semmai stile “immutable servers” per garantire che tutto vada realmente bene. Snap non ti aiuta in alcun modo perché questi dispositivi non han risorse per usi generici. Oggi va di moda OpenWRT&c per un solo motivo: in molti vogliono qualcosa di più di un “minirouter”, vogliono un “miniserver” su cui piazzare vari servizi senza consumare troppa corrente, doversi preoccupare di piazzare qualcosa di ingombrante, avere raffreddamenti attivi ecc. La soluzione per questi non è Ubuntu Core (che infatti pur girando sul raspy non lo usa praticamente nessuno) ma una distro tradizionale potata ma non troppo. E di nuovo snap peggiora le cose con le sue risorse in più in termini di storage ma anche di ram. Il punto è che mancano miniPC di larga diffusione che non siano hack su nas e router domestici. Mancano miniserver SOHO molto più economici dei supermicro. Non certo le distro 🙂

            Sul C: hai tempi era semplice, ai tempi gli OS erano scritti in assembly. Ai tempi era un linguaggio di alto livello, come python/perl/ruby nel “sentire” odierno. Oggi è un linguaggio “di basso livello” e per questo sarebbe bene staccarcene e dedicarlo ad una nicchia, cosa difficile però visto che ogni università si ostina a presentarlo come primo linguaggio…

            Il Java l’ho citato per l’idea (incompresa dai più) che aveva: realizzare un “OS” che fosse l’ambiente java garantendo quindi una certa portabilità, una certa libreria standard moderna, un package-management legato alle source, il concetto di “OS/Internet-as-software” con l’uso dei nomi di dominio invertiti per ridurre, idealmente garantire, l’assenza di name clash ecc. Questa era l’idea di Java, mai compresa e mai seguita realmente. Go l’ha ripresa in parte migliorandone alcuni aspetti.

          • DeeoK

            In Java semplicemente le applicazioni girano su VM.
            Ha tantissimi vantaggi, ma ha pure il vantaggio di peggiorare le prestazioni rispetto al girare nativamente. Il problema principale di Java e che nessun altro se l’è filato e tutt’ora sulla JVM girano solo Java e Python.
            Windows ha voluto replicare la cosa con .Net, con risultati pure peggiori.
            Se la cosa avesse preso più piede ora si potrebbe scrivere applicazioni con qualunque linguaggio avendo la portabilità garantita e invece per ottenere risultati simili si è dovuti arrivare a quell’obbrobrio di Electron. Ahimè Java considerò sempre troppo poco la parte di front end finendo con il rimanente bloccato sulla parte business.
            Comunque continuare ad insegnare il C a mio parere ha senso. Ha poco senso investirci troppo tempo.

          • Kim Allamandola

            > Il problema principale di Java e che nessun altro se l’è filato
            > e tutt’ora sulla JVM girano solo Java e Python.”
            ??? Sulla JVM girano n linguaggi (jruby, scala, clojure, prolog, per citare i più famosi più una pletora di linguaggi “minori” e una pletora di DSL). Il cuore di java non è la jvm in se ma il concetto di “framework + ambiente operativo moderno” uniti e la vicinanza tra source e runtime.

            Senza contare che di linguaggi basati su VM ce ne sono altri a bizzeffe dall’erlang (nato per l’HPC nelle TLC quindi non certo “low performance/high overhead” al “vecchio” perl al ruby a vari dialetti del lisp (usati anche loro in ambito HPC, tra i tanti usi che spaziano dalla grafica dei CAD all’AI al calcolo simbolico/numerico/finanziario ecc anche se sono poco noti ai più) ecc

            > Se la cosa avesse preso più piede ora si potrebbe scrivere
            > applicazioni con qualunque linguaggio avendo la
            > portabilità garantita e invece per ottenere risultati simili
            > si è dovuti arrivare a quell’obbrobrio di Electron.
            Ah bé, Electron è tutto fuorché portabile, oltre a girare solo dove gira webkit ed esser usato sostanzialmente solo per le GUI (non aggiungere Node che pur essendo nato da ex-SUN per cui mi tolgo cappello e calzini per me non dovrebbe manco esistere). Se intendi dire che manca una GUI multipiattaforma moderna son d’accordo, le più portabili sono le Tk che in ambito *nix, anche con le TTk non han un grande aspetto (su Windows han scelto di usare gli widget nativi/le WinAPI quindi sono indistinguibili dalle applicazioni native, visivamente) e comunque pur essendo abbastanza flessibili non son certo comode per GUI moderne. Ma questo è una parte del problema che citavo sopra: non c’è più una “libreria standard con (quasi) tutto quel che serve nella vita di tutti i giorni” e avercela va ben oltre la grafica, rientra nella necessità di ammodernarsi, ripartendo dal foglio bianco. Qui tutte le “innovazioni” recenti son solo mostri, a partire dalla non proprio recente idea di considerare i browser dei framework e le pagine web delle applicazioni…

            Se la famosa (e mai avvenuta salvo alcuni “coraggiosi e un po’ folli” che stan tentando un port in Rust e dicon di esser pure a buon punto) riscrittura moderna di Emacs fosse avvenuta forse in un po’ più gente ci si sarebbe avvicinata e avrebbe scoperto un paradigma assai più efficacie di quelli attuali e per di più assai meno complesso e stratificato.

            > Ahimè Java considerò sempre troppo poco la parte di front end
            JavaFX doveva essere una risposta a tema ma il punto è che Java ha curato la parte EE (si fa per dire) perché quella era la richiesta. Non c’è mai stato un gran interesse lato desktop.

            > Comunque continuare ad insegnare il C a mio parere
            > ha senso. Ha poco senso investirci troppo tempo.
            È un po’ ossimorico: un banale esempio quanto tempo impiega una matricola a digerire abbastanza il linguaggio per poter implementare strutture dati basilari? Quanto impiega a far la stessa cosa in python? E di più essendo oggi il C “di basso livello” quanto senso ha insegnare al muratore la chimica del mattone prima ancora di insegnarli come metter un mattone sopra l’altro? Capirei insegnare il C alla specialistica quando si comincia a parlare di grammatiche, di parser, lexer ecc, quando si mette mano al dragon book ma prima che senso ha? Il risultato che ho visto sinora è gente che si abitua a buttar giù righe di codice picchiandosi col compilatore e manco comprendendo realmente come funziona un castello di carte troppo complesso per le loro conoscenze, cambiato ambito cercano come falene e lampade di notte tutto ciò che “assomiglia” al C (a loro dire, al netto delle conoscenze mal-apprese) e finiscono tipicamente sul PHP, tipicamente se van sul C++ scrivono obbrobri di standard vecchi di anni (c’è ancora gente che usa per dire iostrem.h o addirittura stdlib.h, che non usa manco i namespace, che non conosce l’STL se non a livello di nome pur *lavorando* con il C++) e si va avanti così.

            Per me si dovrebbe cominciare col dire che oggi l’informatica è parte della società al pari della lingua, quindi l’uso base del computer deve andar di pari passo a quello della penna dalle elementari, alle medie si può cominciare ad automatizzare piccoli compiti con la shell (dal rename massivo a imagemagick) e introdurre al concetto di “iterazione”, di algoritmo in genere usando il logo e linguaggi simili. Alla prima superiore ci si dovrebbe poter aspettare una conoscenza base dei principali os e delle più comuni applicazioni, shell *nix incluse e cominciare non col pascal ma con script di shell per poi passare al python da mantenere per tutte le superiori. All’università (informatica & classe ing. industriale, matematica, fisica, ecc) si può iniziare a parlare di strutture dati un pelo più complesse delle solite liste, map &c cominciare a parlare di multiprocesso&IPC, sempre in python, passando poi in base alla facoltà ad altri linguaggi. Nel caso dell’ing. informatica direi presentando scheme (chicken, racket, quel che si vuole) o magari qualche lisp e il go o il rust magari per un buon triennio. Alla specialistica parliamo di C e asm, C++, java, prolog, … lasciamoli da parte. Il prolog al massimo accoppiamolo per curiosità a latere del lisp/scheme, magari si presenti brevemente altri linguaggi (erlang, haskell ad es.) tanto per far “astrarre l’algoritmo dalla sua rappresentazione in codice”. Durante questo processo abituiamo a gestire e documentare il codice (cosa in genere *sempre* omessa), magari presentando anche qualche forma di literate programming, magari presentando org-mode che al di la di babel è molto utile per una pletora di cose. Son convinto che avremmo ingegneri (lato software, chiaro) assai migliori di noi stessi.

          • DeeoK

            Non c’è nessun linguaggio diffuso, a parte Java (in parte Python) che sfrutti la JVM. Kotlin pare che potrebbe diventare il successore di Java, ma difficilmente andrà oltre l’ambito mobile.
            Il problema della scarsa cura del front-end di Java ha fatto sì che venisse via via sempre più snobbato nel mondo consumer finendo con l’arrivare a mostri come Electron che sono portabili proprio in virtù del fatto che ormai qualunque pc ha installato webkit.
            Quindi Java è rimasto limitato al mondo enterprise e non ci sarebbe nulla di male se non fosse che ormai vive di inerzia. JavaFX è arrivato troppo tardi, ormai temo che Java in ambito consumer finirà con il morire. C’è chi passerà a .Net (che a quel che so integra di default parecchie tecnologie), c’è chi opterà per Electron e Node senza rendersi conto che scrivere la stessa applicazione in Java sarebbe molto più efficiente.

            Il vantaggio dell’insegnare C è che consente di avere una visione più pratica di una parte di sistema operativo con cui interagire, cosa che con Java si perde. L’università deve darti le basi, il resto è lo studente che deve ottenerlo e per insegnare le basi di C ed un po’ di programmazione di sistema basta il primo anno, passando alla programmazione ad oggetti il secondo. L’università non deve essere un corso sui linguaggi, quelli l’informatico può impararseli da sé, ma deve essere un corso per capire come funzionino. Presupporre che insegnamenti informatici inizino sin dalle superiori implica l’impossibilità per molti di accedere a corsi universitari in informatica in caso di scelta errata durante le superiori (ed ho conosciuto gente che fatto informatica dopo un classico).
            Uso base del computer e programmazione sono cose diverse. Sono d’accordo che si debba insegnare il funzionamento di un computer a tutti, probabilmente già alle medie, ma deve riguardare la conoscenza dello strumento più che una conoscenza tecnica di basso livello. Far fare script a bambini delle medie (o anche del liceo) può lasciare il tempo che trova per tutta quella marea di persone che non sono interessate a questo livello di approfondimento (al pari, per riprendere un esempio già fatto, dell’avere una conoscenza approfondita delle automobili).

          • Kim Allamandola

            Mah, Scala e Clojure direi che son diffusi eccome, secondo GitHub scala è al 16 posto, persino sopra il Go, secondo TIOBE è l’inverso. Quanto a Python non so quanti usino Jython, ma non penso siano molti. L’implentazione stra-dominante è Cython. Kotling non lo conosco se non per gli annunci ma da quel che ho visto sospetto sia un fuoco di paglia tirato dall’enorme numero di code monkeys che scrivono codice su Android…

            > mostri come Electron che sono portabili proprio
            > in virtù del fatto che ormai qualunque pc ha installato webkit.

            Mah, guarda sicuramente o via Chrom{e,ium} molti desktop han installato una qualche implementazione di WebKit ma definire questo largamente diffuso e portabile è semplicemente *folle*. Senza contare che su tantissimi desktop aziendali webkit fuori da Chrome è *vietato* per i suoi noti problemi di sicurezza… Oggi se vuoi una soluzione per scrivere GUI portabili/generiche/di bell’aspetto le Qt sono la scelta meno-schifosa disponibile. Le (T)Tk son buone seconde, un pelino “anziane” ma con un mondo di supporto e su Windows han un aspetto nativo by default, su GNU/Linux devi soffrire un po’ se vuoi un aspetto moderno ma se sviluppi a titolo professionale sono un’ottima scelta (l’estetica conta poco, le solide basi molto di più)

            > per insegnare le basi di C ed un po’ di
            > programmazione di sistema basta il primo anno

            Quant’è che non fai quattro chicchere con una matricola? Perché per quel che era già ai miei tempi si arrivava a passare l’esame, magari anche bene, ma non si sapeva *un tubazzo di nulla*, c’era chi sapeva qualcosa già di suo e se la cavava, c’era chi apprendeva senza comprendere in stile tavoletta di cera e c’eran tanti che buttavan giù codice picchiandosi col compilatore per riuscire ad arrivare a qualcosa che gira. In sintesi: *nessun* studente (a meno che già non sapesse di suo) era in grado di mettere insieme teoria&pratica. Oggi penso sia assai peggio.

            > L’università non deve essere un corso sui linguaggi
            L’università deve per lo meno indicare una via, e quella che indica oggi andava forse bene 30/40 anni fa. Grossomodo quando eran studenti gli attuali docenti… Oggi con il 3+2 gli studenti della triennale devono formarsi per essere poco più che “tecnici informatici”, perché per la preparazione con cui entrano e quella con cui possono uscire altro non sono in grado di fare; con la specialistica si può sperare di formare passabili sviluppatori; col dottorato si può sperare di dar loro una nicchia in cui possan lavorare senza far troppi danni. Il resto oramai lo puoi imparare solo fuori dall’università. La sintesi è che per “far prima” si può ottenere la stessa preparazione di un tempo (o quasi) nel quadruplo del tempo, non meno.

            L’università dovrebbe per me dare una preparazione di base e nel caso dell’informatica dividersi in alcuni rami (tlc, software, hardware almeno) e ad oggi al massimo dà, se sei capace di “estrarlo”, il modo di imparare, tutto il resto lo puoi tranquillamente redirigere su /dev/null.

            > Presupporre che insegnamenti informatici inizino sin dalle superiori
            Temo di non esser stato chiaro: l’uso del computer, al pari dell’uso di un foglio di carta con la penna, di un libro, un vocabolario, un elenco telefonico, una grammatica ecc dev’essere insegnato *di pari passo* quindi dalle elementari, livello dopo livello. Perché se arrivi a ing. informatica che non hai mai installato un sistema operativo, non hai idea di cosa sia e manco conosci i principali OS di oggi ma solo 4 applicazioni in croce l’università deve prima farti imparare questo (compito quasi impossibile in tempo utile). Il computer oggi è socialmente rilevante come lo è il foglio bianco con la penna da cui tirar fuori una lettera manoscritta, completa di impaginazione “valida”, piegatura in busta, indirizzi ben formati, oggetto eventuale, introduzione svolgimento e conclusione. Oggi il giovane tipo, anche neodottorato, spesso *non sa* manco far questo, per capire la situazione dell’istruzione.

            > Far fare script a bambini delle medie (o anche
            > del liceo) può lasciare il tempo che trova per tutta
            > quella marea di persone che non sono interessate a
            > questo livello di approfondimento

            Questo *non è* un approfondimento è il *solo modo* ad oggi di poter usare proficuamente un computer. Ci mancano i db desktop/visuali di NextSTEP, ci mancano gli strumenti adeguati per lavorare comodamente perché un gran numero di ****** ha detto che si deve imparare ad usare un computer in pochi giorni clicchettando in giro e il risultato lo conosciamo. Solo per citare Linux, si sviluppa tutt’ora con flussi di patch via mail, semplicemente perché questa è la via più comoda, rapida efficacie che nessuno dei mostri moderni è in grado di eguagliare, figuriamoci di superare.

            Per cambiare in meno-peggio, questa disastrosa situazione l’unico modo è far conoscere gli strumenti validi in modo che la popolazione nel tempo non sia più gregge ma massa di cittadini che chiede e pretende quel che le serve.

            Un banale es. ho risposto in questo thread a @Samael, la risposta (senza link) è “in moderazione”. Hai presenti i vecchi ng? Bé li non può accadere. Ci sono certo gruppi moderati, ma si comunica anche via mail, diretta. Questo per dire che l’informatica odierna crea mostri ipercomplessi e dittature senza aggiungere un’ε a quel che si poteva fare 30+ anni fa.

          • DeeoK

            Mi sa che sei fuori dal giro della didattica da un po’ e te lo dico perché io ho la laurea da pochi anni quindi parlo con cognizione di causa (oppure non sei fuori dal giro ma hai semplicemente fatto o avuto a che fare con una pessima università).

            Comunque andiamo con ordine.

            Non so che dati hai guardato, ma qui si dice diversamente: https :// madnight . github . io/githut/
            Scala è messo poco meglio di Swift e Rust come diffusione. Non che sia un male, ma la situazione in quanto a diffusione non mi pare rosea.
            Kotlin non l’ho ancora provato, anche se rimedierò a breve. Di per sé si presuppone come successore di Java (le cui recenti vicissitudini sono piaciute a pochi) e si basa su Scala e lo stesso Java. L’adozione su Android è in realtà relativamente tardiva ed è figlia dei noti problemi legali tra Google ed Oracle.

            Per quel che riguarda le GUI, io parlo esclusivamente del mondo consumer, non business. Il mondo business segue logiche differenti e, tutto sommato, se ne frega di quanto siano fighe le GUI tanto quasi tutto sarà una web app e quindi si va di HTML, infatti dubito che qualcuno che lavori con JEE abbia mai usato Swing per scopi lavorativi che non siano secondari (ad esempio un’applicazione per i soli dev, come capitò nel mio caso). Nel caso la GUI non sia una web app lato business è probabile che se freghino comunque e rimangano con GUI orribili, almeno nella stragrande maggioranza dei casi.

            Per quanto riguarda l’università, nessuno ti insegna ad usare il pc. Quando ci arrivi o lo sai usare da te o ti arrangi da solo. Ti insegnano l’informatica, che con l’uso del pc (es. installazione di un SO) c’entra poco. Insegnare millemila linguaggi non serve ad una mazza, basta insegnare i paradigmi base, poi i linguaggi si imparano dai manuali (e dall’utilizzo).
            Ti insegnano il funzionamento di un SO e come interagire con esso tramite shell, ti insegnano le basi dei linguaggi, come funziona un compilatore, programmazione imperativa, funzionale, ad oggetti e via discorrendo. Fare queste cose sin dalle elementari lascia il tempo che trova.
            A scuola non si dovrebbe insegnare l’informatica, ma l’uso degli strumenti e la capacità di replicare pattern mentali per usi di strumenti diversi. Quindi il funzionamento, con un alto livello di astrazione, di un sistema operativo, quali sono le componenti di un pc e come interagiscono fra loro senza buttarci in mezzo l’elettronica, il funzionamento di un browser, nozioni di sicurezza (così magari evitiamo password come 123456) e via dicendo.
            All’università si impara la teoria che c’è dietro a tutto questo.
            Io non mi piacchiavo per far compilare a fortuna i programmi, perché i primi programmi li scrivevo su carta, quindi ero io il compilatore e se non sapevo come funzionasse il tutto ne veniva fuori qualcosa che portato su pc non avrebbe portato a nulla.
            Poi va beh, anche negli esami di laboratorio bastava usare suite di test decenti e vedrai che un programma fatto male non passava. E pure lì niente IDE, solo Gedit e compilazione bash. Gli IDE vengono dopo, quando si sa quel che si fa.

          • Kim Allamandola

            È un po’ di anni che son fuori dall’uni ma vedo i “nuovi” ingegneri (3+2 eh, non solo triennale) e quel che sanno fare. Diciamo che in media li vedrei a zappare un campo, a mano, perché con un mezzo meccanico non mi sentirei troppo tranquillo sui danni che possono fare. Per dire: il 99% non è in grado di comprendere la burocrazia di base del suo paese, a partire dal fare un CV o una banale lettera, sino al saper leggere una busta paga. Il 99% riesce a fatica a installare il proprio desktop, non ha mai visto un rack in vita sua, non ha mai visto un patch panel in vita sua, non è in grado di pensare “su scala” (es. comprendere una certa cosa che peso computazionale può avere, se può o meno scalare ecc) e non ha la più pallida idea delle tecnologie “correnti”. In media dichiara di “saper programmare in [linguaggi]” ove linguaggi è in genere C/C++/Java/php/js “con [IDE]” ove IDE sono in genere VisualStudio/XCode/Eclipse/Netbeans con residuale IntellJ. Non sanno realmente scrivere codice che sia più complesso di un hello world, non sanno scriptare quasi nulla, non sanno cosa sia un LOM qualsiasi, manco a livello concettuale, …

            Menomale che l’università si sarebbe avvicinata al mercato del lavoro….

            Sui linguaggi dico solo che conoscere la “base teorica” (intesa come principi di programmazione) e qualche algoritmo nella pratica serve a poco specie se non conosci la libreria standard, non sai gestire il tuo codice, non sai collaborare, non sai compilare/impacchettare/distribuire ecc. Se l’università deve dare solo le basi lo fa male, ma anche lo facesse bene allora prima di entrare nel mondo del lavoro visto che l’affiancamento non esiste più allora si deve rendere obbligatorio un corso di 4-6 anni post-diploma per avere quel minimo di pratica che serve.

          • DeeoK

            In realtà l’affiancamento a lavoro in teoria esiste ancora.
            Il problema che descrivi non riguarda l’università ma il mondo aziendale.
            Una università non può e non deve formarti su singoli aspetti lavorativi, sarebbe già sbagliato che perdano tempo ad insegnarti ad usare XCode o VisualStudio che sono IDE proprietari.
            Quelle sono tutte informazioni che dovrebbero dare le aziende che formano il neolaureato affinché sia in grado di essere produttivo nel contesto in cui andrà inserito.
            Il problema è che questo non avviene, si pretende che lo studente venga formato negli nmila aspetti lavorativi diversi dentro le università, cosa ovviamente impossibile, e che poi possa essere più o meno assunto senza investirci nulla pretendendo l’immediata produttività.

            E’ questa mentalità che è totalmente sbagliata e che porta a situazioni imbarazzanti come la ricerca di stagisti con esperienza.

            Che poi un ingegnere faccia fatica ad installare un SO è imbarazzante. Ma manco quelli con GUI o con guida annessa? Perché in tal caso si parla di minorati mentali e lì l’università può solo impedirgli di conseguire una laurea.

          • Kim Allamandola

            Installare nel senso di arrivare a qualcosa che si avvia (con installer grafico) bene o male ci riescono tutti ma quando gli chiedi un setup diverso dal default (es. cortesemente mi metti la root su due dischi in mirror, 4 dischi in raid10 per /var ecc) la maggior parte non sa da che parte girarsi. Quasi tutti sanno cosa sia il raid, pochi sanno descriverti a parole i tipi di raid più comuni, manco a livello di rappresentazione (cioè se non sai cosa vuol dire “jbod” pazienza, se non sai cosa vuol dire raid 0 o raid 10 pazienza, ma almeno sappimi disegnare come cavolo son fatti), molto pochi sanno cosa sia lvm o LUKS ed è meglio non andar oltre. Quasi nessuno ha la più pallida idea di come si possa gestire una serie di macchine diversamente dall’una per una a mano dei loro desktop. Anche lato “competenze base” (per dire spiegami che è un firewall e poi descrivimi a parole come configuri un fw per un DNS locale, per un webserver pubblico ecc) qualcuno sa dirti a memoria le più comuni porte, spesso solo dei servizi “legacy” (per dire molti sanno dire per l’webserver deve passare la 80, ma ben pochi la 443, anzi molti dicono che http+https sono normalmente sulla stessa porta, qualcuno dice che https passa “a parte” via SSL che è una specie di SSH e trovate fantasiose del genere), ovviamente quasi nessuno sa che esiste /etc/services…

            Ora è chiaro che un neolaureato difficilmente conoscerà bene un webserver in particolare, o qualche application server, figuriamoci applicazioni “specifiche” ma almeno una conoscenza sufficiente per muoversi devi averla sennò la teoria è talmente astratta che non riesci manco a replicarla in pratica.

            Sul discorso mentalità sbagliata: per me è sbagliato voler chiudere sempre più presto il percorso di studi, per me un perito che arriva ad esser tale a 20 anni, un ingegnere anche a 26 andrebbe bene (tanto più che il trend è di alzare sempre più le soglie pensionistiche), purché possa essere operativo dopo un 5-6 mesi di affiancamento. Oggi e non da oggi il modello è far presto ad ogni costo e il risultato è che magari hai l’ingegnere anche di 22 anni, peccato che poi devi insegnargli una quantità di cose che per 4/5 anni resta “stagista”, l’affiancamento non c’è più come concetto nel senso che praticamente nessuna azienda lo prevede col risultato che se arriva qualcuno “senza esperienza” i colleghi devono oltre al loro lavoro fare anche il suo, sorvegliare che non combini disastri e magari cercare di insegnargli qualcosa… ‘Somma se vuoi tutto&subito ok, proviamoci, però o si trova il modo di farlo funzionare o si ammette il fallimento e corregge il tiro.

          • DeeoK

            Non so per ingegneria, ma in generale mi pare che alcuni tuoi requisiti non siano banalissimi. Insegnare a gestire un RAID non mi sembra esattamente materiale su cui farci didattica.
            Diciamo che la differenza con una buona didattica la vedi con la velocità nell’apprendimento di nuove nozioni. Il fatto che le aziende non presuppongano l’affiancamento è un difetto delle aziende, non delle università. E’ normale che in affiancamento il dipendente con esperienza debba stargli dietro, altrimenti non è affiancamento.

            Non per nulla ora come ora si è nella situazione in cui c’è carenza di personale qualificato in molti settori perché le scuole, giustamente, non formano a riguardo e le aziende hanno solo pretese ma nessuna voglia di investire sui lavoratori.
            Quello che servirebbe non è un cambio alla didattica da questo punto di vista, perché non puoi organizzare una didattica che dipenda da singole esigenze aziendali. Perdi di generalità e finisci che ad un laureato non insegni una materia, ma un mesterie. Per quello ci sono i periti: persone con scarse conoscenze teorie ma più ferrati nella pratica.
            Quello che serve è l’avere, alla fine del ciclo didattico, un periodo di tirocinio importante che insegni aspetti lavorativi agli studenti. Questa cosa non c’è: fai un tirocinio, l’azienda ti sfrutta come dipendente sottopagato (o non pagato) e poi tanti saluti e grazie dell’avermi portato il caffé.

            All’improvviso sembra che tutti in passato abbiano imparato tutto nel giro di una notte…

          • Kim Allamandola

            Non chiedo di arrivare fresco di triennale e cominciare a montare e configurare una SAN, ma almeno aver fatto qualche laboratorio dove ti han mostrato (e poi hai provato un po’ a casa) come fare un mirror di *due* dischi, un 10 di *4* dischi, oh van bene anche delle economicissime penne USB eh! Prendi un hub USB, ci metti 4 penne mi fai la demo, stacchi una penna, la rasi con dd a parte, la rimetti e ricostruisci il volume. Tutto qui. Se per un neolaureato in ing. informatica questo è troppo allora che lo si mette a fare? Supporto di primo livello stile call-center? Se non ricordo male di RAID ai miei tempi si parlava in sistemi operativi al II anno…

            Sulla didattica: ricordo ancora al primo anno, primo giorno si presentò il prof di Analisi 1 e mostrò come benvenuto il grafico dei risultati storici dei suoi allievi: sino all’ultimo anno del VO media abbastanza alta, gran parte degli allievi promossi al primo appello, dal nuovo ordinamento il crollo: esame passato al primo appello mi pare da meno del 10% degli allievi, media disastrosa in costante peggioramento anno dopo anno. Come metrica mi è rimasta impressa.

            > Perdi di generalità e finisci che ad un laureato
            > non insegni una materia, ma un mesterie.
            Ma questo è lo scopo dichiarato di tutte le recenti riforme universitarie… Del resto “la materia” nel senso teorico, astratto serve al ricercatore ma anche in paesi dove un po’ di ricerca ancora esiste (e son sempre meno IMO) i ricercatori sono numericamente mooooolto meno dei laureati in *. È un po’ ossimorico voler un’università d’élite e tutti laureati… In Francia per questo han fatto dai tempi di Napoleone le Grandes écoles che pur essendo formalmente università sono pensate per formare la futura classe dirigente mentre le università “classiche” sono pensate per formare “i tecnici”, “gli specialisti” di domani…

            I tirocini son un altro problema: si le aziende sfruttano in genere i tirocinanti (e in genere se lo fan per compiti di una certa importanza lo pagano anche, abbastanza caro) ma d’altro canto il tirocinante d’una volta era ragionevolmente “maturo” sul piano ontologico in alcuni mesi quindi potevi con una certa attenzione fagli fare un “vero” tirocinio, adesso la maggior parte dei tirocini sarebbe un “insegnare tutto quel che non han imparato negli anni di studio pregressi” e dovrebbe durare alcuni anni almeno. Per carità teoricamente si potrà pur fare ma non è questo il compito né l’interesse tipico di un’azienda…

            Non credo che in passato si imparasse nel giro di una notte ma constato che più prendi un “anziano” più questo ha ordini di grandezza di competenza in più che non possono essere solo frutto della mera esperienza. Penso che una volta semplicemente:
            – ci fosse selezione (se non sei abbastanza bravo vai all’avviamento e impara un mestiere “di basso livello”)
            – la scuola fosse fatta per formare teste, non operai modello Ford (io per primo ho sempre recuperato vecchi testi constatando che in una frazione delle pagine spiegavano di più e più chiaramente di quelli attuali/ufficiali del mio corso)
            – l’organizzazione del lavoro fosse tale per cui si poteva maturare in azienda, con i tempi del caso

          • DeeoK

            Non so dirti per ingegneria informatica, io ho fatto informatica ed i RAID si facevano a SO nel secondo anno ma solo in maniera teorica (quali sono e come funzionano). Mai creato un sistema RAID fino ad ora.

            E’ vero che la teoria prepara più alla ricerca che al lavoro (ed è il motivo per cui mi sono fermato alla triennale, essendo il mondo della ricerca, in Italia, la sagra del precariato) ma è anche vero che ti da le basi ed un modus operandi per imparare quel che ti manca. Senza considerare che è impossibile preparare lo studente al lavoro perché esistono troppi possibili incarichi da coprire.

            Io non avevo idea di cosa fosse un application server uscito dall’università, di cosa fossero gli EJB, JPA e compagnia bella. In un mese di stage ho colmato le lacune, almeno dal punto di vista teorico, poi il resto l’ha fatto l’esperienza.

            In generale la mia opinione è che la triennale deve dare tutte le basi necessarie per qualunque tipo di lavoro in quel settore. Le specialistiche invece devono differenziarsi di più, offrendo percorsi più teorici ma anche qualcosa di più indirizzato al formare specifiche figure professionali. Effettivamente questa seconda opzione manca.
            Inoltre aumenterei i tirocini, magari facendoli pagare almeno un 5 o 600€. Io ad esempio avevo 300 ore di tirocinio se ben ricordo. Si parla di più o meno due mesi, non moltissimo.

          • Kim Allamandola

            IMO se in una disciplina tecnica separi teoria e pratica vai incontro ad un disastro. La teoria e la forma mentis servono, ma se sono talmente astratte da non poterle rapportare al mondo reale sono inutili a qualsiasi tecnico. Se non hai mai messo in pratica nulla nel tuo corso di studi non bastano due mesi per imparare abbastanza da non esser pericoloso ed esser ragionevolmente autonomo sul lavoro ti servono almeno due anni, posto di impegnarti non poco. E nessuno stage può darti questo. Se sai già un po’ muoverti, hai già un certo “istinto” e ti senti abbastanza a casa in vari ambienti si in un annetto puoi essere autonomo, in pochi mesi puoi far un po’ di cose sapendo/capendo quando fermarti e chiedere, altrimenti quel che accade lo possiamo vedere nello sconsolato panorama odierno.

          • DeeoK

            Ma non devi separarle, è giusto fare laboratori durante il corso di studi.
            Ma anche i laboratori devono avere argomenti relativamente generici, non puoi, ad esempio, insegnare ad usare JBoss, perché è troppo specifico. Al massimo puoi usarlo come esempio per spiegare come funzioni un application server.

          • Kim Allamandola

            Io semmai mostrerei sia Tomcat che JBoss che chessò Geronimo, con un paio di app “scomode” di demo. Così non hai imparato uno specifico prodotto ma conosci un pelino una discreta fetta di quel che offre il mercato. Non puoi prescindere da questo sennò la teoria resta un mondo a se.

            Lo stesso vale per il DNS, presenta BIND, presenta Unbound, DNSMasq poi che lo studente scelga quel che vuole, ma che almeno conosca i principali DNS server e come operano in pratica. Lo stesso per le shell, presenta la zsh, la tcsh per avere due esempi diversi, fa scriptare in sh e poi picchiarsi perché lo script giri su FreeBSD, OpenIndiana e GNU/Linux. Presenta pf, ipf e la serie ip(6)tables magari con ferm; fa lavorare su almeno due o tre OS diversi. Fa setuppare un mailserver completo (smtp+IMAP) locale con es. postfix e dovecot ecc ecc ecc

            Il laboratorio in un corso tecnico non può essere quell’appendice di relax a latere del “corso vero”, dovrebbe essere la “verifica pratica” di ogni singola lezione.

          • DeeoK

            Come esempi ci stanno, io mi riferivo all’entrare nei dettagli delle varie impostazioni.

            Personalmente sono stato estremamente deluso dal corso di reti perché era diviso in due modulo, teoria e laboratorio, solo che i contenuti erano fatti male. Il modulo laboratorio aveva un suo senso, perché faceva sviluppare applicazioni Java che sfruttassero comunicazione di rete. Io, ad esempio, dovetti implementare il gioco dell’impiccato distribuito, scegliendo come strutturare il server, se usare TCP o UDP, come gestire il multicast (perché i giocatori potevano essere raggruppati) e così via.
            La parte teorica invece non serviva quasi ad una mazza: era esclusivamente teoria con l’esame che consisteva nel “fregare” lo studente creando scenari TCP incasinati e chiedendogli di capire quali pacchetti mancassero, quale fosse il prossimo byte da spedire e quesiti simili. Tendenzialmente l’utilità didattica di una roba del genere era nulla. Avrei preferito avere un corso di teoria sui fondamenti della rete (che serve) e poi avere due moduli di laboratorio, uno di alto livello ed uno di basso livello. Visto che il corso era da 12 crediti lo avrei diviso in 3 moduli da 4 ed avrei rimosso l’esame di teoria dalla dubbia utilità lasciando le verifiche ai moduli di laboratorio.

            Nel laboratorio di sistemi operativi usai solo la bash. Altre shell erano state descritte ma non usate in pratica. E’ anche vero che le difficoltà a cui ti riferisci non riguardano tanto le shell quando più le diverse strutture dei vari sistemi. La stessa shell bash ci vuole poco ad imparare ad usarla, il resto è solo pratica. Io, per dire, dimentico continuamente la sintassi dei comandi e devo usare sempre man per ricordarmela.

          • Kim Allamandola

            Seguendo il tuo esempio per reti domando: quanto tempo hai perso per implementare l’algoritmo e quanto per farlo effettivamente funzionare, ovvero quanta parte era teoria e quanta java? Personalmente mi legai al dito il commento di un professore che chiese uno script/”programma” che realizzasse un report del traffico salvato in un file cap. Lo feci in zsh+graphviz+LaTeX, un del pdf in output. Mi rispose che lui conosceva solo il C o il C++ (!!!) e che per la parte grafica vabbé potevo usare matlab (!!!) se proprio Excel non mi andava bene (!!!!!!).

            A livello di shell non mi riferisco al saper confezionare uno script banale ma a saper usare un po’ la shell, dal set -e alle regex. Ovvero quelle cose che di solito non trovi negli howto in giro per l’web, che apprendi o se te le insegna qualcuno o negli anni. Da sapere e pensare, prima ancora di scrivere, alle peculiarità che può avere un OS rispetto ad un altro (opzioni diverse di ls, tar ecc per es), imparare cosa è bene “tener da parte” per future modifiche di portabilità e cosa non dovrebbe cambiare, imparare a scrive e organizzare script, imparare a livello una serie di software a corredo (da awk a imagemagick passando per curl) ecc. Richiede certo un docente che abbia lui per primo una solida esperienza, e qui casca moooolto facilmente l’asino, ma non richiede un tempo spaventoso e dà un’accelerazione notevole alla capacità dell’allievo di esplorare ed evolvere.

            Diciamo che per me un neolaureato in ing. informatica, come in informatica dev’essere in grado di gestire efficacemente e “allo stato dell’arte” (ovvero senza strati di porcate) lo scenario IT di un piccolo ufficio, saper realizzare con strumenti comuni soluzioni custom ferro+software (da arduino al raspy, scegliete quel che volete), saper disegnare in teoria infrastrutture IT un po’ più complesse identificandone scalabilità, problemi potenziali, fragilità, riducendo al massimo gli spof ecc. A livello di conoscenze dovrebbe riuscire a passare l’LPIC 3 dopo un due/tre mesi di tirocinio se sceglie il ramo “software”. Altrimenti non è pronto per lavorare dopo un periodo di affiancamento, è solo pronto (forse) per un lungo periodo di studio che non dovrebbe essere a carico dell’azienda.

          • DeeoK

            Dal punto di vista del codice in sé non ricordo particolari difficoltà, nel senso che la UI era accessoria (e non richiesta) infatti feci una robetta in Swing giusto per comodità. Il grosso del lavoro era capire come strutturare il server che gestiva strutture dati condivise con i thread che si occupavano delle richieste di connessioni, doveva gestire le notifiche in caso di eventi (che potevano essere unicast, multicast, poteva esserci polling e via discorrendo), gestire i gruppi di giocatori e le partite. Una volta deciso come organizzare il tutto poi il lavoro Java non era enorme.
            Il problema principale era che si parlava di una gestione della rete di alto livello. Sarebbe stato interessante anche farsi un server DNS con i client che inviavano le richieste sfruttando l’indirizzo simbolico del server ed il DNS si occupava di tradurre le chiamate, tanto per fare un esempio. Per questo avrei ridotto la parte di teoria andando ad aumentare la parte di laboratorio che poteva essere suddivisa in due parti (o in una parte più grande).

            Comunque, quando dovevo scegliere un percorso universitario, scartai ingegneria informatica proprio perché non mi sembrava né carne, né pesce, nel senso che si faceva meno software di alto livello e pure la parte di basso livello veniva svolta alla bene e meglio, magari perdendo un sacco di tempo dietro assembly, argomento che il mio professore di architettura riassunse così: “Potrei farvi anche un corso approfondito su assembly, ma la verità è che la cosa avrebbe una qualche utilità forse sullo 0,1% di quelli che si laureano e si ritrovano a lavorare con assembly, quindi useremo una versione adattata alla didattica per illustrar più velocemente i concetti e se volete approfondire ne parliamo in separata sede”.

          • Kim Allamandola

            Mh, mi piace prendere il discorso del tuo prof domandando: ok, ma per il tuo compito *di reti* quanto tempo hai investito in cose *di programmazione* (ovvero non tema del corso) e quanto in reti? Perché questo è un punto centrale che critico: per far certe cose serve conoscere una certa gamma di “strumenti”. Bene. Quel che osservo è che si tende a negare questo requisito di base magari creando “percorsi” monotecnologici per giustificare l’assenza di questo prerequisito col risultato di far lavorare molto di più in maniera inutile (re-invenzione della ruota, se va bene con strumenti inadatti) e si passa molta meno informazione “sostanziale” a causa della mancanza degli strumenti di cui sopra.

            Per dire quanto tempo impieghi (e quindi quanto puoi far comprendere in un corso semestrale) a insegnare strutture dati partendo da variabili e array usando il pyhton come base vs il C? IMO se parti dal Python al primo anno presenti già strutture di una certa complessità e i relativi algoritmi per traversing&c. Il C cosa ti dà in più? A latere perché per la programmazione un approccio bottom-up anziché uno top-down (parti dalla shell, arrivi a qualche linguaggio di alto livello, prosegui con linguaggi moderni più di “medio” livello (go, rust ad es.) e solo quando anche questi ti stan stretti o devi allargarti un po’ scendi al C e all’assembly). Dopotutto se si vuol “partire dalle basi” allora che si dia il dragon book alle matricole perché se non sai fare un compilatore che ti serve il linguaggio?

          • DeeoK

            In realtà di Java in sé non c’era molto, nel senso che sì, si usava Java, ma una volta che sai come gestire una connessione multicast con un linguaggio il resto è una questione di conoscere le api, niente di più. Indubbiamente alcuni concetti fatti in quel corso sono generici della programmazione concorrente e quindi sarebbe stato meglio farli altrove, non a caso l’altro corso che non ho apprezzato è programmazione 2 che sostanzialmente è un corso di linguaggi con alla fine un po’ di programmazione OO e concorrente. L’utilità di fare linguaggi nella triennale mi è sempre sfuggita.

            Comunque io tutte le strutture dati tradizionali li ho viste al primo anno. Il C lo usammo per la comprensione di ambiente e memoria (e qui i puntatori erano utili) più la creazione “di basso livello” di alcune strutture dati come le liste puntate tramite struct.
            Certo, mettersi a fare strutture dati come tabelle hash in C lascia il tempo che trova, in generale dove necessario si usava uno pseudolinguaggio.
            Io personalmente avrei tenuto il C al primo semestre per la parte di ambiente e memoria. Dal secondo sarei partito con la programmazione OO che comunque ormai è sostanzialmente uno standard.

        • Maudit

          sotto siete andati avanti con la discussione e non ho ancora letto gli sviluppi, comunque…
          Io credo che ciò che indichi come un problema (lo è), sia dovuto all’impiego commerciale di linux, a prescindere da windows.

          P.S.:
          1) Snap/flat/app, a mio parere, sono cose da macachi, non da winari.
          2) Linux non è comunque un sistema UNIX, e non ha la prerogativa di esserlo.

          • Kim Allamandola

            GNU/Linux (purtroppo) è il solo “pseudounix” adeguato per un uso desktop: morto OpenSolaris il solo con una massa critica adeguata è FreeBSD, ma con l’evoluzione dell’hw attuale non è proprio praticabile… E abbiamo imparato che essere sul desktop vuol dire essere sui desktop degli studenti, futuri managers, programmatori, sistemisti, meri utenti di computer che si abitueranno ad un certo ambiente e un certo modo di pensare…

            Ad allargarsi un po’ il problema è la mera presenza di paradigmi concorrenti: un tempo unix era una famiglia in continua e viva lotta, oggi chi ha ancora HU-UX lo tiene o cerca di passare a GNU/Linux, idem chi ha AiX, il resto è divenuto residuale. Prima ancora c’era assai più concorrenza sia sul piano software sia su quello hardware… Oggi abbiamo x86 con un morente fetta sparc e una timida e non molto in evoluzione power, il resto è come per gli OS, residuale.

            Di questo passa qualsiasi cosa un domani sarà un “computer”, monoarchitettura, su cui gira uno ed un solo OS per *tutto* dal frigorifero al server passando per il desktop e l’automobile, ovviamente la gestione è facile immaginare sarà quasi solo monovendor… Quale futuro c’è senza varietà? Quale futuro c’è se la conoscenza diventa proprietà intellettuale privata? Quale è persino il commercio se al posto del libero mercato c’è la “piattaforma”? Il commercio c’era e c’è sempre stato, senza esser necessariamente un problema, l’evoluzione attuale lo è.

            GNU/Linux per me era una “speranza”, finito OpenSolaris, ora anche questa va sparendo. Personalmente “ho perso” Irix, poi (Open)Solaris, i *BSD (FreeBSD sostanzialmente) che non han mai sfondato… Dopo GNU/Linux cosa resta?

  • mag1

    Solo versione 64 bit. Ok, il progresso va avanti e non si può fermare ma…Giorni fa un mio collega mi ha dato il suo notebook del 2008, con Vista, fermo da 2 anni nel vero senso della parola perché non può comprarne uno nuovo quindi reinstallo ma non con 7 craccato bensì con Ubuntu Mate 16.04. Gira bene, sarà aggiornato fino al 2021 e lui non rimpiangerà Win. Spero che Canonical e alcune derivate come Mint e LXLE rilascino una versione a 32 bit di 18.04. L’ultima

No more articles