A quanto pare le critiche su systemd, il sistema di init che ormai sembra aver conquistato il panorama delle distribuzioni Linux, non sono ancora finite, tant’è che proprio in questi giorni lo sviluppatore principale, Lennart Poettering, ha deciso di sfatare i più grandi falsi miti riguardo quello che systemd permette e non permette di fare.
Nel suo post riguardo le false credenze su systemd essenzialmente lo sviluppatore ha messo a fuoco alcuni punti fondamentali che riguardano la non monoliticità del sistema, la velocità del sistema di init (vista come palese conseguenza di un buon design più che come obiettivo in sé) e la compatibilità con personalizzazioni effettuabili dall’utente.
Allo stesso modo ha anche (più o meno) messo in chiaro quello che è il rapporto che intercorre tra systemd, Red Hat e freedesktop.org, e cioè qualcosa improntato sulla visione comune del computing e non una volontà centrale che vuole imporre la propria opinione ad un team sottostante di sviluppatori.
Nonostante le critiche, systemd continua ad essere adottato in massa dalle distribuzioni Linux, certificando in un certo qual modo il lavoro fatto dagli sviluppatori. E voi, che ne pensate? Credete che si stia andando nella miglior direzione possibile, o pensate che systemd sia da buttare?
penso che sia da adottare anche in ununtu!
di Mik - 28 gennaio 2013 - 15:14
Che stia conquistando il panorama delle distro, non mi pare.
Ad oggi, soltanto Fedora, OpenSUSE (che tanto per cambiare fa il copia-incolla da Fedora), Arch e Gentoo (anche se non di default) lo hanno adottato.
.
Debian manco a parlarne. Ubuntu idem (d’altronde entrambe usano upstart…quindi non ha senso passare a systemd).
Slackware nemmeno lontanamente.
Mint e tutte le derivate di Ubuntu non sanno manco da dove iniziare a sviluppare qualcosa da soli…
Insomma, prima di parlare di conquista aspetterei…
.
.
Comunque sia, a me sembra che Poettering stia prendendo la comunità per i fondelli.
Non vuole imporre niente a nessuno? Santo dio, ma se è stato lui stesso ad andare dagli sviluppatori di GNOME a chiedere loro di inserire systemd come dipendenza del desktop e a dire di tagliare fuori gli OS non-Linux.
Ma quale visione comune? A me sembra più una visione da Grande Fratello orwelliano con Red Hat che cerca di indirizzare sempre più la comunità Linux verso le sue squallide politiche.
Come l’ha indirizzate in precedenza su quell’immensa porcheria di PulseAudio, ora la sta indirizzando su systemd.
E lo sta facendo alla grande, integrandolo con Udev e con altre tecnologie chiave che prima potevano essere implementate in maniera indipendente e flessibile.
.
.
E poi mi viene a dire che non è un monolite? Ma LOL
di atomix600 - 28 gennaio 2013 - 16:03
@atomix600
>Debian manco a parlarne. Ubuntu idem (d’altronde entrambe usano upstart…quindi non ha senso passare a systemd).
Solo ubuntu usa upstart
Debian per mantenere compatibilità con kFreeBSD (e HURD ?) ha i sui initscripts , che comunque sono basati sulle dipendenze e supportano l’esecuzione in parallelo
Essendo il SO Universale comunque non hanno intenzione di cambiarlo nel prossimo futuro
di asdf - 28 gennaio 2013 - 16:18
“pettinare le bambole”
a.k.a
“Ma’que’kezz’ce’ne’mport’de’ste’boiate”
di telperion - 28 gennaio 2013 - 16:25
Normalmente è bene sapere quel che si dice.
Non è stato imposto nulla da Pottering.
Se una cosa non funziona, non viene utilizzata o viene abbandonata dopo poco, senza tante questioni.
Ti assicuro che SystemD fa mangiare una tonnellata di polvere ad Upstart…non c’è proprio paragone.
Non invidio gli utenti di Ubuntu, quelli sì che devono spesso sottostare ad imposizioni astruse e poco sensate della dirigenza di Canonical.
di malikay - 28 gennaio 2013 - 16:26
“Non è stato imposto nulla da Pottering.”
Quindi le sue “campagne pubblicitarie” agli sviluppatori di GNOME per farlo inserire come dipendenza, per poi fare tirare in ballo le sue strambe idee sul bloccare lo sviluppo sui presunti OS-giocattolo (riferiti a Debian GNU/kFreeBSD e agli altri OS non-Linux), non erano un pressing velato?
Ti ricordo che il mettere systemd come dipendenza di GNOME equivale a rendere deprecato ConsoleKit. Di conseguenza, nel momento in cui quest’ultimo viene deprecato, automaticamente viene imposto logind (parte di systemd). E venendo imposto logind, viene imposto systemd. E venendo imposto systemd, vengono eliminati tutti gli altri sistemi di INIT.
La stessa cosa sta avvenendo con Udev. Non è un caso se Red Hat e Poettering sono stati criticati di far pressing su FreeDesktop.org, che dovrebbe mantenere uno stato di ente super-partes tra gli OS UNIX.
Tant’è che sulla mailing list di GNOME, venne chiesto a Poettering di rendere systemd portabile anche su OS non-Linux, affinchè il passaggio da ck a logind potesse essere fattibile.
Lui ha risposto che non ne aveva voglia e che essendo open source il codice, chiunque avrebbe potuto prenderlo e modificarlo.
Peccato però che systemd si basa su cgroup che NON È standard ed è Linux-only.
Difatti, proprio per il fatto che usa cgroup, è stato accusato di aver reso systemd VOLUTAMENTE non-portabile.
.
“Se una cosa non funziona, non viene utilizzata o viene abbandonata dopo poco, senza tante questioni.”
Difatti PulseAudio è una porcheria. Tuttavia viene utilizzato.
Un’eccezione che conferma la regola.
.
“Ti assicuro che SystemD fa mangiare una tonnellata di polvere ad Upstart…non c’è proprio paragone.”
La velocità non è l’unico metro di paragone.
Anzi, è l’ultimo metro di giudizio in un gestore dei servizi.
Ciò che conta è quanto è affidabile e come gestisce i demoni.
E systemd non è meglio di Upstart o OpenRC sotto questo punto di vista.
Proprio per questo molte distro non hanno la minima intenzione di accettarlo.
Bisognerà vedere, però, quante saranno costrette a farlo vista l’integrazione forzata tra systemd e Udev. Non tutte hanno la forza per mantenere un fork. E bisognerà mettere in conto anche che Linux potrebbe, adottando Udev di default, adottare di riflesso systemd, tagliando fuori tutti i non aderenti alla massa.
di atomix600 - 28 gennaio 2013 - 16:45
“Ti assicuro che SystemD fa mangiare una tonnellata di polvere”
.
fammi capire, ho debian che parte in 20″, con systemd mi parte in 10″ …
e che *quazzo* mi cambia?!
.
Facessero Gimp che lavora con TUTTI I CORE, quello si che mi cambierebbe a ME.
.
“pettinare le bambole”.
di telperion - 28 gennaio 2013 - 16:46
Giusto!! Poettering piantala con ‘sto systemd e lavora su gimp che non ha il multicore!!!?!!
In ufficio ho libreoffice con calc che impiega 24 secondi ad aprire i fogli pesanti, mentre excel solo 15 perché usa più processori!!
C@zzo Torvalds, piantala con ‘sto kernel del cavolo, ormai è maturo e funziona, io voglio libreoffice che sfrutti il mio quad-core!!! Sveglia Linus, ma passi il tempo a pettinare le bambole quando mi serve calc più veloce??!?
Che schifo, peggio di berlusconi e il duce.
asd
di Luca - 28 gennaio 2013 - 17:46
luca
quelle sono le cose che contano, le cose accademiche se questo o quel sitema di avvio, sono e restano “accademiche”, con impatto prossimo allo zero nella quotidianità del lavoro.
Tratta 1000 immagini in meta tempo, fai 1000 rendering di frame in metà tempo, copia 2TB di dati in metà tempo, aggiorna 50 pacchetti in metà tempo, questo conta non i “capelli delle bambole” …
Quanto ai kernel, visto la EOL premature di 3.5 e 3.6, pensa che livello di qualità eccelsa ultimamente.
Pettiniamo le bambole e lucidiamo i sassi invece di migliorare le aree veramente importanti, e facciamo caKate galattiche come gnome3/shell e unity, dai cosi, facciamoci del male.
di telperion - 28 gennaio 2013 - 18:34
@Luca
Linus è uno sviluppatore kernel, mica uno sviluppatore del progetto LibreOffice il kernel supporta bene il multiprocessore, le applicazioni vanno sviluppate per sfruttarlo.
Inoltre dubito sia tutta colpa del processore quando carichi un file entrano in gioco tanti fattori in primis il file system
@teleperion
Premetto che io con gimp faccio roba piuttosto minimale, taglia, incolla, strumento clone, etc.. però credo che gimp supporti il multicore dalla versione 2.6, io sotto strumenti, opzioni, ambiente ho la voce numero di processori: (e ce ne ho messi 2, visto che il mio amd dual core viene visto come due processori sotto proc)
Ora come lo sfrutti e se lo sfrutti sempre e comunque anche nelle operazioni batch non lo so.
(le batch di solito le faccio con imagemagik ma sempre roba semplice)
per il resto per grandi linee concordo pure.
di michelangelog - 28 gennaio 2013 - 19:48
SystemD è quella cosa che se fosse stata fatta da Ubuntu a quest’ora tutti starebbero stracciandosi le vesti e urlando ad oscuri complotti. Una mezza schifezza, non retro-compatibile, epidemica (nel senso che si forza dipendenza di molti altri sotto-sistemi, anche vagamente correlati) e programmata da qualcuno con troppo ego da smaltire.
Upstart magari sarà più lento nel boot ma è progettato con più senno e attenzione all’ecosistema del SO.
Ma tanto sono parole inutili e ci troveremo presto con un altra schifezza alla PulseAudio con cui fare a cazzotti e a cui non potremo rinunciare.
di Davide Aversa - 28 gennaio 2013 - 19:52
Le critiche ci saranno sempre, e finché sono propositive si possono anche ascoltare.
ma qui le critiche sono solo rivolte a distruggere systemd, non al suo miglioramento.
intanto sempre più distro lo stanno adottando, io l’ho provato e posso dire che hanno perfettamente ragione: la situazione è nettamente migliorata.
di Andreabont - 28 gennaio 2013 - 20:49
a mio avviso è ottimo, ed inoltre attraverso systemctl si ha un controllo molto più “granulare” dei metodi e dei comportamenti degli script per avviare i demoni, per non parlare del logging molto più mirato e preciso in caso di problemi
di trzachan - 28 gennaio 2013 - 21:07
Va bene che il web è la patria di complotti, cospirazioni e avvistamenti di ufo, ma prendere un sistema di avvio per fare la solita distro war mi pare eccessivo. Tra l’altro senza neanche l’ombra di una critica tecnica.
Poettering ha imposto qualcosa a gnome? Io direi piuttosto che è uno sviluppatore ufficiale di gnome, quindi la sua parola conterà pure qualcosa, e non è che ci sia entrato per “raccomandazioni”. Gli altri potevano fare altrettanto, ammesso che avessero altrettanto know-how, cosa di cui dubito.
Systemd piace, e le distro – inclusa debian testing – lo adottano. Punto. A chi non piace non lo usi.
Pulseaudio una schifezza? Dico, finalmente linux ha il suo sistema unificato per fare il multiplexing del suono a/da una periferica o da/a un altro sistema sulla rete in maniera completamente trasparente, e voi lo chiamate una schifezza? Bene, vi auguro di fare di meglio, buon lavoro.
Poi se lo ritenete troppo “overkill” per il vostro pc, nessuno vi impone di usarlo. Disistallatelo, ma io sulla mia fedora mi ci sono sempre trovato bene, si badi, su una macchina anche alquanto datata.
Chissà perché su ubuntu dà problemi. Complotto o manifesta incapacità?
di SeaStorm - 28 gennaio 2013 - 21:24
@telperion
Implementala tu la roba che ti serve in GIMP. O solo gli altri devono mandare a pu…ane il proprio lavoro per sviluppare quello che secondo te conta? E già che ci sei prendi con te pure la portinaia del tuo condominio, tanto non importa il mestiere, basta che tutti lavorino a quello che dici tu.
di Shiba - 28 gennaio 2013 - 21:35
@atomix600,
Debian manco a parlarne. Ubuntu idem (d’altronde entrambe usano upstart…quindi non ha senso passare a systemd).
.
Debian??
.
Comunque, Upstart e systemd non sono così diversi a livello concettuale; io li vedo entrambi buoni progetti, ma per conto mio systemd (che è più “evoluto”) pretende di mettere un po’ troppo le mani dove non gli compete, cioè nell’intimo dei processi di creazione dei servizi e del binding con i relativi socket.
di Marco Buratto - 28 gennaio 2013 - 22:01
Ma quale complotto: la realtà è che tutti gli OS-non Linux sono in terribile crisi…oramai la piattaforma di riferimento per lo sviluppo, che piaccia o no, è Linux (parlando ovviamente di sistemi *nix) … Poco tempo fa gli sviluppatori di OpenBSD si erano lamentati apertamente di questo andamento, cioè del fatto che le nuove tecnologie approdano prima su Linux e vengano studiate per sfruttare le capacità del suo kernel, rendendo difficili o impossibili il porting verso gli altri sistemi: systemd è solo uno dei tanti esempi.
.
Quindi Poettering non è che ha volutamente tagliato fuori gli os-non linux…è che proprio se ne è fregato completamente di scrivere un init portatile, il suo unico obiettivo era creare un nuovo init ottimizzato per Linux e così ha fatto.
.
Poi come lo stesso Poettering ha detto, sarebbe stato inutile spendere un sacco di lavoro per adattarlo ai sistemi non-linux, quando sicuramente nessun sistema bsd (ad esempio) l’avrebbe mai adottato a priori, preferendo restare felicemente con i loro preistorici init vecchi di 40 anni … e su questo punto ha stra-ragione, quindi in pratica di cosa ci si lamenta?
di Ito - 28 gennaio 2013 - 23:27
@Ito: 28/01/2013, Martin Graesslin – his is a classic example for why I think it doesn’t make sense to state that we support non-Linux Unix systems. We break the code without noticing, because nobody is even trying to compile the code on non-Linux systems (also no CI system). The non-Linux system always have to catch up and fix our stuff and then they have a hard time to get the changes back upstream.
Da far imparare a memoria ai propri figli, se ne avete.
di Alessio Biancalana - 28 gennaio 2013 - 23:29
Seriamente?!
I problemi delle distro gnu/linux sono strapparsi i capelli come delle fighette per systemd/upstrart/stokasso???
Ah si, anche questo sarà un altro “anno di linux”.
Che 2 balls!!!!!!
di telperion - 28 gennaio 2013 - 23:41
@Alessio
Lo sviluppo di KDE è un ottimo esempio, rientra perfettamente nel discorso
di Ito - 28 gennaio 2013 - 23:54
Ma dov’è bsd? Freebsd si limita ormai da anni a importare software dall’esterno e basta, netbsd è soppiantato sui router da linux, l’unico a trainare ancora il carro (con molta fatica) è openbsd. E il software possono certamente scriverselo da soli, dato che hanno saputo sviluppare ssh.
Io al lavoro sui server vedo tanto linux e (purtroppo) tanto windows. Bsd non pervenuto. Può essere che il mio sia un caso particolare eh, ma bisogna vedere quante sono le esperienze come la mia.
Poi gli sviluppatori da linux dovrebbero sbattersi per fare port per bsd, per poi generare mostri come le notifiche col polling? Mah…
di SeaStorm - 29 gennaio 2013 - 00:05
@SeaStorm sinceramente a lavoro anch’io ho visto molto Linux, ovviamente Windows (sennò come la fai girare la roba ASPnet che tanto piace ai clienti), BSD pochissimo (giusto a casa ho qualcosa in produzione su FreeBSD io). Mi interessa, perché nel frattempo le statistiche lo danno come survivor quindi non capisco più a chi dare retta
di Alessio Biancalana - 29 gennaio 2013 - 00:08
@Alessio
Più che a dare retta a qualcuno in particolare, direi che ci sono delle realtà da non sottovalutare.
Può darsi che bsd sia ancora vivo e vegeto con la sua piccola nicchia, io non lo so ma lo spero. Certo che le parole espresse dallo stesso Poettering in un’altra occasione fanno riflettere. Che senso ha rallentare lo sviluppo di qualcosa a causa di un 1% di server?
E d’altronde siamo sicuri che tutto il software sviluppato per linux sia di interesse anche per bsd?
Vabbè, dopo queste domande alla Lubrano, buonanotte
di SeaStorm - 29 gennaio 2013 - 00:38
@teleperion sei il solito {aggettivo_a_piacere} di sempre.
Non puoi direi ai programmatori che ti regalano il loro lavoro cosa implementare e cosa no, contribuisci oppure acquista il software proprietario che ti serve se lo reputi migliore.
Il software open si base o su aziende che investono in certi settori (tipicamente, web, database, linguaggi di programmazione, strumenti server) e lavoro per divertimento personale (quasi tutti i de, e i programmi client) uno nel proprio tempo libero fa quello che vuole non quello che vuoi tu, lamentarti sempre e comunque è un ingratitudine verso il lavoro altrui.
di erik_ilrosso - 29 gennaio 2013 - 01:16
@erik_ilrosso Telperion ha perfettamente ragione invece.
Systemd spezza completamente la compatibilità con gli script per rc, hanno spinto per integrarlo il più possibile in gnome (a tal punto che i dev di arch hanno lavorato per più di un mese prima di mettere gnome 3.6 in testing, e l’hanno fatto solo dopo aver completato il passaggio a systemd), hanno dovuto modificare parti di KDE perchè deve usare logind invece di consolekit.
Poi, è fatto per la velocità? Cronometro alla mano ho trovato meno di un secondo di differenza tra Ubuntu con upstart e Arch con systemd. Entrambi con GDM che apre in automatico openbox. E ci scommetto che gran parte di quel secondo di differenza è dovuto alla maggiore quantità di servizi inclusi in Ubuntu.
Diminuendo i servizi in uso la situazione è migliorata parecchio, sono quasi arrivati pari.
E il bello è che il team Ubuntu sta integrando in upstart alcune caratteristiche introdotte da systemd. Tenendo comunque compatibilità con gli script rc.
Bada bene, in alcune distro che sono abbastanza note per essere facilmente smontabili, oltre che molto snelle (come Arch, ho usato systemd, initscripts, Upstart senza nessunissimo problema, anzi) con il passaggio forzato a systemd non permettono di usare altri sistemi di init. Se logind è integrato in systemd, come fai a sfruttarlo per loggare in KDE/GNOME/XFCE/LXDE?
Poi, non costringono nessuno? Qual è la distro che oggi non usa udev? Forse solo slackware, le altre lo usano tutte. Guardacaso Gentoo ha deciso di mantenere l’attuale versione di udev e di integrare le varie modifiche che vengono fatte alla parte udev di systemd.
Ma in Gentoo possono permettersi questo e altro. Le distro minori che non hanno forza lavoro per adattare gnome a consolekit o gli altri DE a logind che dovranno fare?
di winebar - 29 gennaio 2013 - 14:27
#11
Esattamente! Hai centrato il punto.
.
#12
Non puoi migliorare ciò che è sbagliato dal design.
Quando una cosa è sbagliata, la si butta e la si ripensa.
Altrimenti si fa la fine del Btrfs (altro prodotto broken-by-design), che dopo anni di sviluppo è ancora unstable e non si sa quando sarà usabile in produzione (se mai lo sarà).
.
#14
“Va bene che il web è la patria di complotti, cospirazioni e avvistamenti di ufo,”
In questo caso non c’è nessuna cospirazione. Tutto è alla luce del sole.
Poi se si ha il prosciutto sugli occhi, non si vede nemmeno il ladro che ruba un portafogli…ma questo è un altro discorso.
Queste manovre sono una chiara risposta di Red Hat nei confronti di Canonical e Oracle (che sono i suoi due avversari più temibili). Non è un complotto.
.
“ma prendere un sistema di avvio per fare la solita distro war”
Nessuna distro war..
Per lo meno da parte mia. Non mi interessano quelle cose futili.
.
“Tra l’altro senza neanche l’ombra di una critica tecnica.”
Di critiche tecniche ne ho espresse a bizzeffe…e non solo su systemd, ma anche su altre pseudo-panacee.
Mi dispiace, ma non ho voglia di riscrivere le cose ogni volta, anche perchè si uscirebbe off-topic.
.
“Systemd piace, e le distro – inclusa debian testing – lo adottano. Punto.”
Debian testing non lo ha adottato per niente.
Lo ha inserito nei repository, come ha fatto Gentoo…che è ben diverso.
.
“A chi non piace non lo usi.”
Evidentemente non hai letto il mio post, non capendo a pieno la situazione. Rileggilo va…così magari capisci perchè systemd verrà adottato (imposto) in massa.
.
“Pulseaudio una schifezza? Dico, finalmente linux ha il suo sistema unificato per fare il multiplexing del suono a/da una periferica o da/a un altro sistema sulla rete in maniera completamente trasparente, e voi lo chiamate una schifezza?”
Si è una porcheria che crea un ennesimo layer con ennesime API complesse che vanno ulteriormente a complicare una situazione già oscena dello stack audio del kernel Linux.
Hai presente ALSA? Sisi, proprio lo stack audio che al posto di migliorare OSS, ha creato un mostro dalle API complesse e poco pulite, tanto da rendere complesso anche un redirect alla sua alternativa a /dev/dsp.
Sisi, proprio lo stesso stack audio che su alcune periferiche riempe lo schermo di messaggi relativi a errori di snd_pcm_recover e che non è stato corretto perchè la complessità del sottosistema rende difficile un fix.
Sisi, proprio lo stesso ALSA che oltre ad avere delle sue API attiva persino un layer per OSS: uno stack audio sopra un’altro stack audio.
Sisi, proprio lo stesso ALSA che ha bisogno di altre API come JACK per avere una piattaforma di produzione multimediale usabile, fatta però di torri di babele di API super-stratificate.
Ecco, ora che hai presente ALSA aggiungici altre API (PulseAudio) messe tecnicamente più o meno uguale. Sai cosa ottieni? Te lo lascio immaginare.
E poi ci si lamenta sul come mai la gente sceglie OSX per fare produzione multimediale…
PulseAudio non è la soluzione ai problemi. È solo un modo come un altro per nascondere la polvere sotto il tappeto.
.
.
#16
Marco. A quanto ne so anche Debian usa Upstart, dalla Squeeze.
È stato scritto anche un articolo su questo blog: http://www.oneopensource.it/08/09/2009/debian-abbandona-init-e-passa-ad-upstart/
.
“pretende di mettere un po’ troppo le mani dove non gli compete, cioè nell’intimo dei processi di creazione dei servizi e del binding con i relativi socket.”
È da una vita che dico che è un monolite invasivo che vuole controllare tutto.
Se molta gente si informasse prima di scrivere post, forse (e ripeto: FORSE) le cose cambierebbero un po’. Ma si sa che le chiacchiere da bar sono diventate un must.
.
.
#17
“Ma quale complotto: la realtà è che tutti gli OS-non Linux sono in terribile crisi…”
Come si vede che tu nel mondo non-Linux non ci stai.
Illumos in terribile crisi? Vatti a vedere le ultime news…
FreeBSD in terribile crisi? Da quale punto di vista?
NetBSD in terribile crisi? Anche qui, dove l’hai vista?
OpenBSD? Ma LOL…
Ma i changelog li leggete o cercate le notizie su punto informatico?
.
“oramai la piattaforma di riferimento per lo sviluppo, che piaccia o no, è Linux (parlando ovviamente di sistemi *nix) … ”
Sisi hai proprio ragione. È così di riferimento che nVidia non porta Optimus. È così di riferimento che i driver di AMD non funzionano sulle versioni più recenti del kernel.
Linux è così di riferimento che non ha OpenCL, mentre OSX (che è il vero UNIX di riferimento…putroppo o per fortuna, a seconda dei punti di vista) ce l’ha dal 2009.
Sisi…è proprio di riferimento.
·
“Quindi Poettering non è che ha volutamente tagliato fuori gli os-non linux…”
Poettering ha detto CHIARAMENTE che chiunque avrebbe potuto prendere il codice e modificarlo.
MA poi gli hanno fatto notare che non era possibile portarlo su OS non-Linux perchè usava tecnologie non-standard e troppo legate a Linux per poterlo portare. E quando gli hanno detto che non avrebbero accettato la sua proposta perchè ci sono UNIX che usano GNOME, lui ha replicato dicendo che non valeva la pena spendere tempo per altri OS giocattolo, tagliando la corda (ovviamente, per evitare figure di m*rda) quando gli venne risposto che c’era gente nel mondo UNIX che considera Linux un OS-giocattolo.
Ito, conosci l’architettura di systemd? Allora se la conosci saprai che systemd non è portabile by-design per i problemi che io e tanti altri andiamo dicendo da un po’.
.
“Poi come lo stesso Poettering ha detto, sarebbe stato inutile spendere un sacco di lavoro per adattarlo ai sistemi non-linux, quando sicuramente nessun sistema bsd (ad esempio) l’avrebbe mai adottato a priori, preferendo restare felicemente con i loro preistorici init vecchi di 40 anni …”
Avranno 40 anni ma sono molto più affidabili di qualsiasi altra pseudo-soluzione esistente.
Quando un altro gestore dei servizi avrà almeno gli stessi anni di carriera alle spalle, ne parleremo.
Per ora, dopo 40 anni, INIT funziona ancora. E funziona bene.
.
“e su questo punto ha stra-ragione, quindi in pratica di cosa ci si lamenta”
Evidentemente non hai capito il concetto.
Rileggiti il mio post in cui ho spiegato cosa comporterebbe avere systemd come dipendenza di GNOME e cosa comporta la sua integrazione con udev.
Non è un caso se gli sviluppatori di GNOME hanno poi bocciato la sua proposta.
.
.
#21
“Ma dov’è bsd?”
Nello stesso posto dove in cui si trova Linux; negli Hard Disk.
.
“Freebsd si limita ormai da anni a importare software dall’esterno e basta,”
BSD, a differenza di Linux, può importare progetti dall’esterno, se questi sono ottimi. Non ha bisogno di reinventare la ruota. Nè tantomeno spaccia le sue reinventate di ruota come innovazioni.
Inoltre, BSD ancora oggi possiede tecnologie che Linux sogna la notte.
Vedasi il framework di NetBSD che permette di scrivere driver portabili su tutte le architetture SENZA modificare il codice del driver stesso.
Vedasi l’implementazione del chroot di OpenBSD che su Linux è raggiungibile soltanto con le patch esterne del progetto GRsecurity.
Vedasi le Jail di FreeBSD, raggiungibili da Linux soltanto con le patch di OpenVZ (non utilizzabili con tutte le versioni del kernel, per giunta).
PS: vimage non l’ha importato da nessuno. L’hypervisor che hanno in cantiere non lo stanno prendendo da nessuno.
.
“l’unico a trainare ancora il carro (con molta fatica) è openbsd.”
OpenBSD è in salute come tutti gli altri BSD.
Sono una nicchia? Probabile.
Stanno morendo? Ma anche no. E i changelog parlano chiaro.
Anzi, proprio su BSD si stanno verificando migrazioni da Linux/Arch.
Vedasi ArchBSD (basata su FreeBSD) e Starch (basata su OpenBSD).
Ripeto, nelle comunità bisogna starci prima di dare giudizi sommari su presunti precari stati di salute.
Non vedo, invece, situazioni contrarie.
.
“E il software possono certamente scriverselo da soli, dato che hanno saputo sviluppare ssh.”
E beh certo.
Perchè se su BSD si sviluppa un software o uno stack, Linux se ne può approfittare, mentre se lo si sviluppa su Linux si va di lock-in, vero? Ti piace vincere facile?
Ma stiamo parlando di Linux o di Windows?
No sai…perchè di questi tempi le situazioni non mi sembrano poi così differenti…
Ma gli utenti Linux si ricordano che fino a qualche anno fa erano LORO che rompevano i co*lioni a mezzo mondo lamentandosi che Microsoft aveva tagliato loro ogni possibilità di evolversi sul desktop?
.
“Poi gli sviluppatori da linux dovrebbero sbattersi per fare port per bsd, per poi generare mostri come le notifiche col polling? Mah…”
Non si è parlato di fare porting. Si è parlato di rendere il codice portabile, in modo da renderlo condivisibile. È una cosa differente.
.
.
#23
“Certo che le parole espresse dallo stesso Poettering in un’altra occasione fanno riflettere. Che senso ha rallentare lo sviluppo di qualcosa a causa di un 1% di server?”
E allora allo stesso modo ti dico:
Che senso ha sviluppare su Linux che ha si e no l’1% sul desktop? Meglio concentrarsi su Windows e Mac OS X, no?
.
“E d’altronde siamo sicuri che tutto il software sviluppato per linux sia di interesse anche per bsd?”
E qui ti do ragione.
Non tutto il software è di loro interesse.
Ma se Red Hat cerca e fa in modo di piazzare systemd dovunque, non ci sarà più possibilità di porting per alcun software di rilievo. Capisci ora il problema?
Limitare la scelta degli utenti NON È MAI una buona cosa.
Ed è per questo che mi fanno inca*zare a bestia queste cose. Linux ha lottato per anni contro il vendor lock-in di MS & Co., che non ha mai permesso alle alternative di andare avanti sul desktop.
Ed ora che acquista un po’ di visibilità, che fa? Fa la loro stessa politica.
Per me è assurdo. Systemd andrebbe evitato come la peste, per quanto mi riguarda. Più gente lo usa, più vengono giustificate queste manovre squallide.
.
.
Le chiacchiere stanno a zero signori miei. O vi informate o non si va da nessuna parte.
di atomix600 - 29 gennaio 2013 - 14:41
@atomix600
Myth: systemd is not modular.
Not true at all. At compile time you have a number of configure switches to select what you want to build, and what not. And we document how you can select in even more detail what you need, going beyond our configure switches.
This modularity is not totally unlike the one of the Linux kernel, where you can select many features individually at compile time. If the kernel is modular enough for you then systemd should be pretty close, too.
Myth: systemd doesn’t allow your to replace its components.
Not true, you can turn off and replace pretty much any part of systemd, with very few exceptions. And those exceptions (such as journald) generally allow you to run an alternative side by side to it, while cooperating nicely with it.
Myth: systemd’s use of D-Bus instead of sockets makes it intransparent.
This claim is already contradictory in itself: D-Bus uses sockets as transport, too. Hence whenever D-Bus is used to send something around, a socket is used for that too. D-Bus is mostly a standardized serialization of messages to send over these sockets. If anything this makes it more transparent, since this serialization is well documented, understood and there are numerous tracing tools and language bindings for it. This is very much unlike the usual homegrown protocols the various classic UNIX daemons use to communicate locally.
di Alessio Biancalana - 29 gennaio 2013 - 14:45
@atomix600,
tecnicamente sei sempre ineccepibile,… piccolo “lapis” per Debian… che non usa Upstart, ma un dependency based boot, un init con dipendenze
di Marco Buratto - 29 gennaio 2013 - 15:17
Certo, giusto, è tutto un complotto. C’è sempre un complotto.
Che p***e però ‘sti complotti…
di malikay - 29 gennaio 2013 - 15:24
@Alessio
Per il primo punto.
È vero ma solo sulla carta.
Rimpiazzare ConsoleKit con logind, integrarlo con udev, rimpiazzare syslog con la versione di systemd ecc. fanno si che il primo punto non sia vero all’atto pratico. E tutte queste cose stanno già avvenendo.
È ovvio che ORA è più modulare. Non tutti lo usano poichè per ora udev è ancora usabile in maniera indipendente.
Ma dal momento in cui udev si integrerà con systemd, non sarà più così visto che quest’ultimo diventerà una scelta necessaria, anche perchè il kernel, supportando unicamente udev, supporterà di riflesso anche systemd…a meno di prese di posizione differenti, di cui dubito. L’ho già detto prima.
E ovviamente nessuno sviluppatore sano di mente userebbe le alternative che reinventano la ruota, quando c’è una soluzione tutto-fare ed ufficialmente supportata. Ecco perchè, una volta morte le alternative (e ho fatto l’esempio di ConsoleKit apposta), gli OS e le distro che non possono/vogliono supportare systemd avranno seri problemi.
.
Per il secondo punto.
Questa frase dice tutto: “with very few exceptions. And those exceptions (such as journald) generally allow you to run an alternative side by side to it, while cooperating nicely with it.”
GENERALMENTE ti permettono di usarle in maniera non esclusiva.
Peccato però che tra le stesse eccezioni ci sia il core stesso di systemd, che ha bisogno necessariamente di cgroup. E qui si ritorna al problema principale.
.
Per il terzo punto. Credo che le critiche siano rivolte al fatto che systemd si porta dietro DBus, che non è un componente di UNIX, ma uno esterno invece di usare le tecnologie native. E che quindi mettere un qualcosa come DBus nel core del sistema non sia una buona soluzione.
di atomix600 - 29 gennaio 2013 - 15:26
@Marco Buratto
Grazie per la correzione su Debian.
di atomix600 - 29 gennaio 2013 - 15:27
Telperion sei un c0glione esaltato.
di gennaro - 29 gennaio 2013 - 15:57
La mia debian testing usa Sysvinit come sistema di Init… Comunque mi sembra che Debian non ha interesse a passare a Systemd come nuovo gestore di init…
di Danielsan - 29 gennaio 2013 - 16:29
@Danielsan giustissimo. Debian non ha interessi a passare a systemd. Come dice lo slogan, è l’OS universale. Questo vuol dire che supporta una marea di architetture e kernel diversi, senza avere troppe differenze nel sistema base.
di winebar - 29 gennaio 2013 - 17:52
@atomix600 e quello che hai detto mi può anche andare bene. Però resta il fatto che sono millemila binari diversi e il fatto che in pochissimo tempo gli sviluppatori di Gentoo siano riusciti a isolare la codebase di udev dovrebbe dirti qualcosa sulla fattura di systemd.
Poi oh, io uso ancora syslog eh, basta configurare un po’ systemd per usare quello che vuoi al posto dei suoi software predefiniti
“Peccato però che tra le stesse eccezioni ci sia il core stesso di systemd”
Si può dire grazie al c***o o siamo in fascia protetta?
grazie che nelle cose obbligatorie di systemd ci sta il core di systemd. Oltre una certa soglia puoi usare anche altro, e ciao 
di Alessio Biancalana - 29 gennaio 2013 - 19:56
@winebar,
verissimo, ricordate che Debian ha in cantiere anche Debian GNU/kFreeBSD.
di Marco Buratto - 29 gennaio 2013 - 20:48
#35
“Si può dire grazie al c***o o siamo in fascia protetta?”
Se consideri che poco sopra al tuo post si è dato del c*glione gratuitamente a telperion, direi che…..SI, si può dire.
.
Comunque non volevo dire che systemd è dipendenza di se stesso.
Quello che volevo dire è che tra tutte le eccezioni che non permettono di sostituire i propri componenti c’è proprio systemd, che non dà la possibilità di slegarsi da cgroup, che è il nodo della questione.
.
Ora che leggo ciò che ho scritto, mi rendo conto di essere stato poco chiaro.
Mi è sembrata la frase di Di Pietro in cui affermava: “mia moglie non è mia moglie”. LOL
di atomix600 - 29 gennaio 2013 - 20:55
> Evidentemente non hai letto il mio post, non capendo a pieno la
> situazione.
Allora dimmi: perché, ad esempio, genivi – completamente astrusa ai discorsi pseudopolitici di linux – ha già reso systemd obbligatorio? Forse è per la sua capacità di interagire con dbus. Forse Gnome non c’entra nulla. Forse, eh.
> Hai presente ALSA?
Pulseaudio non è ALSA e non hanno gli stessi obiettivi. Per di più PA è anche multipiattaforma, e qui si che aveva senso renderlo tale.
PA può non piacere, ma non ho nostalgia dei tempi in cui si avevano oss + alsa + esound/arts, con un numero ristretto di programmi (compresi quelli a riga di comando) che supportavano a scelta questo o quello, e applicazioni che si inchiodavano. Abbiamo UNO standard, per di più di gran lunga migliore del software che c’era prima. Finalmente.
> lui ha replicato dicendo che non valeva la pena spendere tempo
> per altri OS giocattolo, tagliando la corda
Più precisamente, si riferiva a debian gnu/kfreebsd e credo che abbia ampiamente ragione. Per carità, è un esercizio didattico lodevole, ma se lo proponi in un ambiente di produzione, ti portano via con la camicia di forza.
Il riferimento a debian gnu/kfreebsd nasce dal fatto che qualcuno ci vuole portare upstart sopra e di conseguenza Poettering è stato criticato per aver reso difficile fare altrettanto con systemd.
Le solite distro wars in cui stavolta hanno tirato in ballo *bsd senza peraltro aver chiesto loro cosa ne pensavano.
> Non si è parlato di fare porting. Si è parlato di rendere il codice
> portabile, in modo da renderlo condivisibile. È una cosa differente.
La domanda è CHI oggi è rimasto a progettare software tenendo conto di bsd (Xfce e KDE non fanno testo perché ormai non devono riprogettare nulla.)
Non è successo neanche nel caso di upstart:
http://lists.debian.org/debian-bsd/2009/07/msg00122.html
Quoto:
I’ve used APIs that are Linux-specific.
e ancora:
There’s probably a bunch of other Linux-specific things I’ve used without even
being aware of it
e ancora:
I don’t think that this is a bad approach;
Come ho già detto: ci sono delle realtà da non sottovalutare.
>> “Ma dov’è bsd?”
> Nello stesso posto dove in cui si trova Linux; negli Hard Disk.
…di un 1.1% di server.
> Ma gli utenti Linux si ricordano che fino a qualche anno fa erano
> LORO che rompevano i co*lioni a mezzo mondo lamentandosi che
> Microsoft aveva tagliato loro ogni possibilità di evolversi sul
> desktop?
Certo non ero io, che a Linux sul desktop non ci ho mai creduto, a meno che non stiamo parlando di desktop di geek appassionati. Può darsi che si riferissero al fatto che formati e protocolli strategici sono quasi tutti di MS e alleati, quindi non c’è possibilità per Linux di fare breccia. Anche questa è una realtà incontrovertibile.
di SeaStorm - 29 gennaio 2013 - 22:45
“Linux sul desktop non ci ho mai creduto, a meno che non stiamo parlando di desktop di geek appassionati.”
.
ed ora con efi/gpt sempre più geek, geekkissimi…
ASD
Ma va da via i ciap, linux …
LOL
di telperion - 29 gennaio 2013 - 23:12
telperion, se il tuo obiettivo è quello di fare il personaggio, ci sei riuscito.
di SeaStorm - 30 gennaio 2013 - 00:31
#38
“Allora dimmi: perché, ad esempio, genivi – completamente astrusa ai discorsi pseudopolitici di linux – ha già reso systemd obbligatorio? Forse è per la sua capacità di interagire con dbus. ”
Genivi produce distribuzioni? Produce tecnologie chiave multipiattaforma la cui mancanza impedisce l’uso di determinati prodotti? Perchè è di questo che si sta parlando.
Ognuno può richiedere quello che vuole per le SUE soluzioni.
L’importante è che l’uso di prodotti che creano lock-in non diventino dipendenze di progetti multi-piattaforma (GNOME) e progetti usati in più combinazioni (come Linux).
È questo quello che sto dicendo dall’inizio.
.
“Pulseaudio non è ALSA e non hanno gli stessi obiettivi.”
Faresti meglio a rileggere i post stando attento a quello che quoti, prima di rispondere. Almeno evitiamo ridondanze inutili.
Io ti ho fatto una breve e concisa introduzione ad ALSA per poi dirti: a questo aggiungici altre API messe più o meno uguale.
Quello che ottieni è un miscuglio dalla complessità abnorme.
.
“PA può non piacere”
Non si tratta di piacere o meno. Fa tecnicamente pietà almeno quanto lo stack (ALSA) a cui ha cercato di mettere una pezza.
Come ho già detto: è solo un modo per nascondere la polvere sotto il tappeto. Un palliativo fatto alla meno peggio per fare da tampone ad uno solo dei tanti problemi che lo stack audio di Linux si porta da tempo.
Può essere per te una soluzione ai tuoi problemi. D’accordo.
Ma non è la panacea..ci mancherebbe pure che lo fosse. Staremmo freschi se PulseAudio fosse la panacea.
Non è stratificando e complicando ancora di più un qualcosa di già stratificato e complesso che risolvi i problemi.
.
“La domanda è CHI oggi è rimasto a progettare software tenendo conto di bsd (Xfce e KDE non fanno testo perché ormai non devono riprogettare nulla.)”
Quasi tutti i software open source, se consideri che FreeBSD ha più o meno 24.000 port, tra cui prodotti più blasonati come VirtualBox, LibreOffice e persino i driver nvidia.
Fosse come dici tu, FreeBSD dovrebbe avere quattro applicazioni in croce e per giunta non mantenute. Cosa che non è affatto così.
Persino i ragazzi di Chromium hanno lavorato al porting della loro applicazione.
.
“Più precisamente, si riferiva a debian gnu/kfreebsd”
Il che vuol dire: taglia i ponti con tutto ciò che non è Linux.
.
“e credo che abbia ampiamente ragione.”
Anche chi gli ha risposto per le rime aveva ragione. Difatti ha preferito non continuare a dire minc*iate.
.
“Per carità, è un esercizio didattico lodevole, ma se lo proponi in un ambiente di produzione, ti portano via con la camicia di forza.”
Intanto per ora è una technology preview, quindi se la proponi in produzione sei scemo a prescindere dal kernel in uso.
Comunque sia, qualora fosse stabile, sarebbe usabile in produzione ALMENO quanto lo è oggi la controparte Linux, se non di più, date le tecnologie di FreeBSD che Linux non ha (come lo ZFS e le Jail) e lo stack tcp che è noto per essere il migliore in circolazione.
.
“di conseguenza Poettering è stato criticato per aver reso difficile fare altrettanto con systemd.”
Poettering è stato criticato perchè stava prendendo in giro la comunità.
Aveva scritto della roba volutamente non portabile e aveva cercato di piazzarla dentro un progetto NOTORIAMENTE multipiattaforma, tentando di prendere in giro gli sviluppatori dicendo loro che chiunque avrebbe potuto portare systemd su altri OS, quando la cosa è impossibile…a meno di una pesante riscrittura.
.
“Non è successo neanche nel caso di upstart:”
Il che è un non problema visto che il mancato porting di upstart su FreeBSD non crea alcuna mancanza.
Cosa che invece avrebbe creato il mancato porting di systemd, qualora quest’ultimo sarebbe dovuto diventare dipendenza di GNOME.
.
.
.
Con questo concludo. Mi sono stancato.
Ho già detto e stradetto ciò che dovevo dire.
Siamo arrivati a 40 commenti e non mi va di portare avanti la discussione per ripetere a loop le stesse cose per i post a venire.
di atomix600 - 30 gennaio 2013 - 01:36
cmq questo di systemd è hot topic anche in debian.
https://fosdem.org/2013/schedule/event/debian_systemd/
da dibattiti precedenti è invece scaturito questo
“There is reluctance amongst developers to make systemd the default, since Debian GNU/kFreeBSD will not work with systemd”
https://lwn.net/Articles/452865/
e volendo al momento si può fare il passaggio da sysvinit che però fa parte ovviamnete degli “essential package” di un sistema debian quindi da non pochi grattacapi.. mai i workarounds ci sono per chi volesse cimentarsi.
http://wiki.debian.org/systemd
sta cosa dell’integrazione con udev effettivamente se la potevano risparmiare, e se quelli di gentoo forkano in eudev la questione ha una sua rilevanza.
insomma systemd è stuzzicante per la sua forte capacità di parallelizzazione ma mi sento di quotare buratto quando dice “systemd (che è più “evoluto”) pretende di mettere un po’ troppo le mani dove non gli compete”
di gimba - 30 gennaio 2013 - 01:40
debian kfreebsd come linux in un ipotetico universo parallelo, pulseaudio una ciofeca e systemd uno strumento per il dominio del mondo, fatto da redhat che è il centro mondiale della malvagità.
deve essere così per forza, sennò starebbero già lavorando al gimp da tempo e userebbero upstart XD
di dmax_x_linux - 30 gennaio 2013 - 11:42
@SeaStorm
il “personaggio” tentava di far notare, che mentre si fanno 6000 seghe menteli sulla rava e la fava, nel 2013 ancora non esiste un seriointaller pe efi/uefi/gpt, “sicchè” il “povero tapino” con un computer nuovo (neanche tanto è un anno che ci sono ste macchine) non sa che pesci pigliare, godendo come UNA SCIMMIA per i fantastici sistemi di init che NON VEDRA’ MAI …
La sottile distinzione tra accademia e vita reale.
Estiquazzi.
LOL
di telperion - 30 gennaio 2013 - 13:10
@winebar
“Systemd spezza completamente la compatibilità con gli script per rc”
Sicuro? A me risulta invece che gli script sysv sono tranquillamente avviabili con systemd.
Per esempio Fedora ha ancora alcuni servizi (cito a caso: privoxy, yum-cron, preload, ecc.) che si basano ancora su shell script in rcX.d… e systemd me li avvia regolarmente al boot
di Ito - 30 gennaio 2013 - 14:36
Domanda da nubbio: con systemd si dice addio agli init scripts in /etc/init.d/, ma poiché questa caratteristica è definita dal Linux Standard Base, posso praticamente dire che systemd viola LSB?
Cioè un software che si propone come Linux-only perchè ne vuole sfruttare le funzionalità native (anche a scapito di altri OS unix) non rispetta neppure gli standard stessi del mondo Linux? 0.o
di abba - 30 gennaio 2013 - 15:07
@Ito ni, sysmted non è completamente compatibile con gli script sysv. Loro stessi lo dicono. Se non erro fa una traduzione al momento da script sysv in unit file di systemd.
di winebar - 30 gennaio 2013 - 15:16
Systemd viene presentato come “a system and service manager for Linux, compatible with SysV and LSB init scripts”
Da quel che ho visto la compatibilità c’è, se poi sia in grado di far girare tutti gli script sysv del mondo non lo so.
Inoltre, volendo, nel comando ExecStart di un file .service puoi metterci qualunque file eseguibile, anche file bash all’occorrenza
di Ito - 30 gennaio 2013 - 15:41
@Ito come dicevo, non è pienamente compatibile con SysV:
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities
Come puoi vedere, dato che systemd non supporta variabili d’ambiente, non puoi usare $qualcosa perchè non funziona.
Oppure, se lanci qualcosa nei runlevel 2,3 o 4 ti ritroverai quel qualcosa lanciato in tutti i runlevel.
di winebar - 30 gennaio 2013 - 16:32
guarda qua che casino altro che systemd:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557?comments=all
La morte nera …
asd
di telperion - 30 gennaio 2013 - 22:22