Microsoft, annuncio a sorpresa: Windows 10 integrerà un kernel Linux completo

[Nui_Mg]

Originariamente inviato da cdimauro

Il punto è proprio il supporto, che è il punto di forza di Linux.

Perché, come già detto, se l'obiettivo è meramente un basso footprint, la soluzione non è certo Linux, pur nelle sue forme ridotte e adattate per l'embedded.

Il punto fondamentale è che Linux, una volta compilato/moddato/librerire ad hoc per le soluzioni simil-embedded, ha dato grande prova di essere a basso (e anche bassissimo) footprint per tantissime specifiche soluzioni. A me basta e avanza questo. Ci sono soluzioni con minor footprint? Certamente, nessuno l'ha negato, ma mancano di un sacco di "buon" supporto e flessibilità rispetto a quanto disponibile con il pinguino.

[cdimauro]

E io che ho detto?

[s-y]

Originariamente inviato da cdimauro

Il punto è proprio il supporto, che è il punto di forza di Linux.

ciao
se si pensa a com'era solo pochi anni fa, direi che un certo cambiamento è assodato anche da quel punto di vista

cmq dato che appunto lo sviluppo costa, e molto, io non trascurerei, almeno in potenza, l'opzione 'winde', che è vero che il kernel è lo stesso, ma averlo su una base di installato molto minore richiederebbe meno sviluppatori (con questo non trascuro l'aspetto prettamente umano, è per spiegarmi meglio)

[cdimauro]

Originariamente inviato da s-y

ciao
se si pensa a com'era solo pochi anni fa, direi che un certo cambiamento è assodato anche da quel punto di vista

Se ti riferisci alla diffusione & supporto, senz'altro.

D'altra parte la maggior parte dei contributi a Linux arrivano da aziende private, che hanno investito parecchi soldi perché gli conveniva così.

Ma vedremo in futuro, con l'arrivo di Fucsia.

cmq dato che appunto lo sviluppo costa, e molto, io non trascurerei, almeno in potenza, l'opzione 'winde', che è vero che il kernel è lo stesso, ma averlo su una base di installato molto minore richiederebbe meno sviluppatori (con questo non trascuro l'aspetto prettamente umano, è per spiegarmi meglio)

Scusami, questa parte non m'è chiara: potresti approfondire?

In particolare, cosa sarebbe winde? Un Windows Desktop Environment? E come sarebbe strutturato?

[s-y]

Originariamente inviato da cdimauro

Se ti riferisci alla diffusione & supporto, senz'altro.

D'altra parte la maggior parte dei contributi a Linux arrivano da aziende private, che hanno investito parecchi soldi perché gli conveniva così.

si certamente, ms è solo l'ultima ad averlo fatto

Ma vedremo in futuro, con l'arrivo di Fucsia.

altra 'variabile' non indifferente

Scusami, questa parte non m'è chiara: potresti approfondire?

In particolare, cosa sarebbe winde? Un Windows Desktop Environment? E come sarebbe strutturato?

si, una 'sorta' di d.e. (un'interfaccia con tutti i tool per accedere ai servizi cloud)
è un'ipotesi 'futuribile' e non esattamente 'realistica', nè tecnica...
per quanto mi riguarda non è nemmeno una speranza, ma diciamo che se implementassero una soluzione di questo tipo non sarei esattamente sorpreso, dati i numerosi passi sorprendenti già fatti negli ultimi tempi

in ogni caso a me basta che il concetto di sorgenti aperti (a prescindere sia da licenza che da os) stia sempre più prendendo piede, e non per moda, ma per convenienza.
alla fine non credo che sia svantaggioso, in senso generale

[cdimauro]

Originariamente inviato da s-y

si, una 'sorta' di d.e. (un'interfaccia con tutti i tool per accedere ai servizi cloud)
è un'ipotesi 'futuribile' e non esattamente 'realistica', nè tecnica...
per quanto mi riguarda non è nemmeno una speranza, ma diciamo che se implementassero una soluzione di questo tipo non sarei esattamente sorpreso, dati i numerosi passi sorprendenti già fatti negli ultimi tempi

OK. Giusto un'ulteriore domanda che scaturisce: è una visione "cloud-based" la tua, dove il kernel / s.o. "di base" non ha rilevanza, perché il software utente è cloud-based?

in ogni caso a me basta che il concetto di sorgenti aperti (a prescindere sia da licenza che da os) stia sempre più prendendo piede, e non per moda, ma per convenienza.
alla fine non credo che sia svantaggioso, in senso generale

Pubblicare i sorgenti non è uno svantaggio di per sé, a meno che lo sviluppatore o la software non abbiano deciso di monetizzare il loro lavoro, e in questo caso decidano di tenere i sorgenti per sé. Ma questo dipende, appunto, dal lavoro fatto e da come si voglia trarne beneficio.

Pubblicare i sorgenti, però, non vuol dire necessariamente ricevere supporto, e che il progetto sia mantenuto, si evolva, ecc.. Ci sono parecchi progetti open source che languono causa mancanza di sviluppatori.

Per quanto riguarda la licenza, invece, sono totalmente contrario a quelle "virali". Ma questo penso tu lo sappia già.

[s-y]

Originariamente inviato da cdimauro

OK. Giusto un'ulteriore domanda che scaturisce: è una visione "cloud-based" la tua, dove il kernel / s.o. "di base" non ha rilevanza, perché il software utente è cloud-based?

se fosse la mia non sarei qui a ciancicare sui forum (non che mi dispiaccia eh!)
cmq si, intendo quello. credo che anzi in prospettiva abbia più possibilità di 'resistere' come os locale un os come linux, proprio per la sua natura 'frankestein'
d'altra parte sarebbe appunto perfettamente 'in bolla' con lo slogan primigenio di 10, as a service

Pubblicare i sorgenti non è uno svantaggio di per sé, a meno che lo sviluppatore o la software non abbiano deciso di monetizzare il loro lavoro, e in questo caso decidano di tenere i sorgenti per sé. Ma questo dipende, appunto, dal lavoro fatto e da come si voglia trarne beneficio.

Pubblicare i sorgenti, però, non vuol dire necessariamente ricevere supporto, e che il progetto sia mantenuto, si evolva, ecc.. Ci sono parecchi progetti open source che languono causa mancanza di sviluppatori.

si assolutamente, dipende sempre dal come. ritengo cmq che (magari è solo una moda passeggera, ma non credo, date anche le mosse che appunto sono state fatte) più attori importanti partecipano, e più probabilita c'è (non certezza) che ci siano 'vantaggi distribuiti'

Per quanto riguarda la licenza, invece, sono totalmente contrario a quelle "virali". Ma questo penso tu lo sappia già.

si, ne abbiamo già discusso parecchio, e tutto sommato credo che la viralità sia (letta a posteriori, e parzialmente a prescindere dalle intenzioni originarie) anche una sorta di stratagemma per garantire la sopravvivenza in un mondo dove domina il codice proprietario. nell'ipotetico nuovo contesto non sono certo resti così funzionale

[cdimauro]

La viralità di una licenza, però, non è condizione necessaria alla sopravvivenza di un progetto open source: quest'ultima può benissimo avvenire senza l'uso di licenze virali.

Giusto per essere chiari, una licenza come Mozilla è sufficiente allo scopo, pur non essendo virale (è richiesta la pubblicazione delle sole modifiche ai sorgenti coperti da MPL).

GPL et similia, invece, si spingono ben oltre, "attaccando" tutti sorgenti con cui vengono a contatto.

[s-y]

non so, per il fenomeno (cmq globale, e del tutto peculiare) gnu/linux non sono convinto che sarebbe sopravvissuto in così buona forma (cosa che imho resta sorprendente) senza la 'cultura' indotta dalla gpl (che volenti o nolenti, anche una certa 'filosofia' di fondo ha tenuto insieme l'ecosistema, a prescindere da alcune posizioni estremistiche e profetiche, 'citazione' non casuale...)
se fosse possibile, servirebbe una controprova...

poi appunto specialmente negli ultimi anni la gpl ha invece ostacolato una ulteriore diffusione. intendo a prescindere dai gusti, che per me non è un problema che resti zerovirgola

d'altra parte elementi come il controverso (per definizione, in questo discorso) systemd trainano al contrario verso altre direzioni, specialmente dal punto di vista della citata cultura...

quindi vedremo

[cdimauro]

Progetti con licenza MPL ce ne sono e sono sopravvissuti. Come prova dovrebbe essere sufficiente.

Quanto a systemd, che piaccia o meno, è il futuro di Linux. Ed è soltanto questione tempo per l'adozione da parte di tutte le distro, perché non è pensabile che Devuan e Slackware abbiano le risorse per poter mantenere un fork che diventa ogni giorno sempre più pesante.

[s-y]

è che 'linux', inteso come ecosistema, non è un progetto singolo, ma un'accozzaglia di molti (anche troppi), con una percentuale non indifferente di 'fuoco amico incrociato' tra l'altro. senza una licenza a tenere per le palle tutti non so come sarebbe andata

in realtà cmq non vorrei passare per 'purista' della gpl (non credo che tu lo pensi, ma lo scrivo lo stesso ) che poi sono anche più realista del re

su systemd ormai (da un bel pò) il dado è tratto, poco da fare. si adegueranno tutti, salvo equilibrismi semi-autistici per evitarlo. btw a me non piace proprio perchè appiattisce il panorama, ma poi sticazzi (e cmq non si può negare che dal punto di vista 'integrazione' aiuta)

[cdimauro]

Originariamente inviato da s-y

è che 'linux', inteso come ecosistema, non è un progetto singolo, ma un'accozzaglia di molti (anche troppi), con una percentuale non indifferente di 'fuoco amico incrociato' tra l'altro. senza una licenza a tenere per le palle tutti non so come sarebbe andata

in realtà cmq non vorrei passare per 'purista' della gpl (non credo che tu lo pensi, ma lo scrivo lo stesso ) che poi sono anche più realista del re

No, non lo penso, infatti.

Credo che, comunque, una licenza basata sull'estorsione del codice altrui non sia tanto etico, e non capisco come abbia potuto prendere piede.

Ci sono altri modi e licenze per tenere assieme tanti progetti, ma di questo ne abbiamo già parlato.

su systemd ormai (da un bel pò) il dado è tratto, poco da fare. si adegueranno tutti, salvo equilibrismi semi-autistici per evitarlo. btw a me non piace proprio perchè appiattisce il panorama, ma poi sticazzi (e cmq non si può negare che dal punto di vista 'integrazione' aiuta)

Senz'altro, ed è questo uno dei punti di forza di systemd.

Quindi molto più facile gestire il sistema, e un sistema omogeneo, per gli utenti e gli sviluppatori. E molto facile sviluppare servizi/demoni per gli sviluppatori.

L'altro lato della medaglia è che risulta ancora non solido e stabile come ciò che ha sostituito, con una più elevata frequenza di kernel panic dovuti anche soltanto a un servizio che sia andato giù.
Questa è una lamentela comune a TUTTI i sysadmin con cui ho avuto modo di chiacchiera sull'argomento.

[s-y]

Originariamente inviato da cdimauro

L'altro lato della medaglia è che risulta ancora non solido e stabile come ciò che ha sostituito, con una più elevata frequenza di kernel panic dovuti anche soltanto a un servizio che sia andato giù.
Questa è una lamentela comune a TUTTI i sysadmin con cui ho avuto modo di chiacchiera sull'argomento.

non essendo sysadmin non posso aggiungere molto, se non notare come paradossalmente la gestione automatica (e l'autoresume in caso di crash) dei servizi sarebbe proprio una delle funzioni principali...

viene cmq in mente un altro progetto dello stesso autore, e con fini non tanto dissimili, anche se ovviamente su aspetti molto meno critici: pulseaudio, che per un bel periodo è stato davvero quasi inutilizzabile

aggiungo anche che la mia esperienza su systemd è al momento solo su macchine desktop singole, e con applicazioni tipicamente desktop, niente roba server, e non posso dire di aver riscontrato problemi in tal senso. per quel poco che vale ovviamente...

[cdimauro]

Anch'io non ho riscontrato problemi con systemd, lato desktop. Coi server non ho esperienza (ma ho amici che lo fanno per professione. Giusto ieri sera ho avuto una chiacchierata con uno molto bravo).

Su pulseaudio finora leggo valanghe di critiche. Non l'ho mai usato, ma pare che abbia ancora problemi.

[ripsk]

Originariamente inviato da cdimauro

Credo che, comunque, una licenza basata sull'estorsione del codice altrui non sia tanto etico, e non capisco come abbia potuto prendere piede.

Ha preso piede in quanto è un sistema di autodifesa.
Serve ad evitare che qualche avvoltoio prenda il 99,9% di codice aperto scritto da altri, e ci aggiunga il suo 0,1% di sorgenti chiusi che lo rende incompatibile.

[cdimauro]

O prendere soltanto alcuni pezzi che servono per i propri progetti, cosa che è di gran lunga più comune rispetto allo scenario che hai ipotizzato.

Ciò precisato, non serve estorcere il codice altrui per tutelare quello che altri hanno deciso di rilasciare come open source. Licenze che limitino gli usi se ne possono benissimo creare allo scopo.

[s-y]

non userei la parola 'estorcere' cmq, mi pare esagerata
nel senso che la licenza si conosce già prima di contribuire, non solo dopo
si può scegliere di non partecipare, e bona così

in questo senso fu molto più controverso quello che fece canonical con mir, che è vero che rilasciò in gpl, ma corredando con il requisito di accettare la loro cla, che fondamentalmente autorizzava canonical a relicenziare il codice a piacere. quello si era una specie di 'furto' (virgolette), tanto che alcune interpretazioni lessero la mossa come addirittura un tentativo di mettere in cattiva luce forzosamente la gpl.

si torna sempre ai modi di cui sopra

[cdimauro]

Originariamente inviato da s-y

non userei la parola 'estorcere' cmq, mi pare esagerata
nel senso che la licenza si conosce già prima di contribuire, non solo dopo
si può scegliere di non partecipare, e bona così

Non è così semplice: ci sono casi di codice GPL che sia finito accidentalmente in un progetto, costringendone poi al rilascio.

in questo senso fu molto più controverso quello che fece canonical con mir, che è vero che rilasciò in gpl, ma corredando con il requisito di accettare la loro cla, che fondamentalmente autorizzava canonical a relicenziare il codice a piacere. quello si era una specie di 'furto' (virgolette), tanto che alcune interpretazioni lessero la mossa come addirittura un tentativo di mettere in cattiva luce forzosamente la gpl.

si torna sempre ai modi di cui sopra

Non so in che modo sia stato realizzato MIR da Canonical, ma il dual-licensing è abbastanza diffuso e non c'è assolutamente nulla di male nel rilasciare un prodotto con più licenze a seconda del tipo di utilizzo che l'utente finale ne deve fare.

[s-y]

che non sia semplice è vero, ma non credo che siano casi voluti quelli dei 'rilasci automatici'. di qui la mia nota sulla definizione di estorsione, che è esagerata

casomai poca attenzione, o anche cazzonaggine, ma è diverso (e magari pure peggio...)

che sia poi un aspetto controverso e correggibile della gpl, sono d'accordo

sulla licenza di mir le ombre c'erano, non si trattava di doppia licenza, ma di clausola obbligatoria, accessoria e aggiuntiva alla gplv3 (di fatto)

ps: questa la critica più argomentata sulla questione, anzi se non ricordo male fu proprio il post che 'iniziò le danze'

[cdimauro]

OK, ma è stata un'aggiunta postuma al rilascio di MIR, o era già inclusa ed evidente durante la prima pubblicazione?

Che poi, comunque, non è che sia così importante questo dettaglio, perché se i sorgenti di un progetto sono rilasciati col copyright dello sviluppatore, anche se con licenza GPL, il copyright rimane pur sempre al proprietario che può decidere di rilasciare gli stessi sorgenti successivamente anche con licenze diverse.

Per essere chiari, il sorgente rilasciato come GPL può andare per la sua strada, mentre l'azienda/sviluppatore può successivamente continuare a sviluppare lo stesso sorgente in maniera indipendente e con licenza diversa.

Questo giusto per chiarire.