Showing posts with label Red Hat. Show all posts
Showing posts with label Red Hat. Show all posts

Monday, October 28, 2013

Debian: upstart o systemd?

Non è una novità. Da tempo Debian ha lasciato in sospeso questa decisione, rimandando a data da destinarsi, ma negli ultimi giorni si è riacceso il dibattito in tutte le board Debian: abbandonare sysV init per migrare all'upstart di Canonical o a systemd made in Red Hat?


Per chi ancora si sta raccapezzando nel vano tentativo di capire di cosa io stia farfugliando si tratta di una scelta che riguarda un software essenziale per il sistema operativo, dato che a lui compete l'avvio di tutti gli altri processi. Genericamente definito "gestore di sistema e di servizi per Linux" senza di esso non è possibile avviare nessun processo in user space (es. GNOME, KDE..), visto che è lui a dialogare all'avvio con il kernel.
Init's job is "to get everything running the way it should be"
E visto che init, il daemon che sta utilizzando Debian, è vecchio come il bacucco e c'è bisogno di maggiore flessibilità e snellezza, soprattutto se vogliamo accorciare i tempi d'avvio, si sono create diverse alternative, ognuna con vantaggi e svantaggi e differenze sostanziali. E non solo per quanto riguarda il software ma, come Mark Shuttleworth ci vuol far abituare, politiche: perchè mentre tutto il mondo Linux stia migrando a systemd, creato da Lennart Poettering di Red Hat, Ubuntu, distro figlia di Debian, invece ha deciso di sviluppare upstart e continuare in solitaria con quello. Va detto che lo sviluppo di systemd risale all'ottobre 2010, mentre upstart era già stato pubblicato nel 2006 (adottato di default però solo in Ubuntu 9.10), ma nonostante la sostanziale differenza d'età l'adozione di systemd di tutte le altre distribuzioni e stata relativamente celere, mentre la controparte non è mai uscita dall'ovile di Canonical, il che è inspiegabile, apparentemente, visto che upstart a mio parere era già due spanne sopra init (es. parallelismo dei processi). A parte, ironia della sorte, Red Hat, si intende. Ma non è tutto: 3 dei 7 membri del Debian Technical Committee, Steve Langasek, Colin Watson e Ian Jackson fanno parte o hanno fatto parte di Canonical, proprio nello sviluppo di upstart. Ma non finisce qui: è appurato che il 90% delle distro userà invece systemd, ritenendo il suo sviluppo maggiormente aperto alla comunità, più feaures, ma soprattutto visto che il rivale è sviluppato esclusivamente da Canonical e licenziato con la CLA (o CCLA), come Unity e Mir. E la CLA non ci piace.
Le polemiche per entrambi i progetti ci sono sempre state, per anni, ma viste le ultime frecciatine dell'afronauta il dibattito si fa sempre più acceso e i flames nella mailist Debian proliferano come funghi: si prenderà la via più logica, adottando systemd come tutte le altre distro, o i vecchi rancori avranno la meglio e si imporrà upstart? Difficile da dire, visti i tempi biblici che Debian ha sempre avuto per ogni decisione.. inoltre non bisogna scartare altre possibili alternative, come OpenRC di Gentoo, soprattutto visto che né systemd né upstart sono compatibili con sistemi operativi non-Linux. E Debian è un sistema universale, che gira anche su kernel differenti e per poter mantenere una certa compatibilità fra i vari progetti deve mantenere un sostrato di omogeneità di software, nello specifico con quello essenziale per il boot di sistema. Ma è anche vero che l'avere uno standard comune fra le varie distro è la chiave fondamentale per evitare l'eccessiva frammentazione nel sistema Linux, e Debian, assieme a Ubuntu, è la base quasi del 60% dei server Linux
Vanno bene 3, 4.. 10 desktop, 20 client mail.. o gestori di pacchetti.. ma non possiamo dividerci anche su questo. Fintanto che c'è qualcuno che vuole remare contro apposta per mantenere il controllo sul software (open) che sviluppa, penso che le divisioni aumenteranno. E tutto ricadrà sulla comunità e sulla sua credibilità.
Ripigliatevi.
Any source

Thursday, July 25, 2013

Enter, il cloud service provider italiano che investe in OpenStack

Quando si parla di soluzioni software Open Source impiegate nell'IT vengono sempre alle mente multinazionali estere, quasi come se fossa una esclusiva e che noi Italiani non fossimo in grado di capire i vantaggi dell'uso dell'open source.

Fortunatamente anche le aziende italiane sanno sfruttare l'Open Source. Una di questi è Enter, un internet e cloud service provider tutto nostrano che ha fatto del cloud computing uno dei suoi core business principali.

Per le sue soluzioni cloud ha infatti deciso di investire in OpenStack per i suoi datacenter, un software Open Source davvero molto interessante. Rispetto alle soluzioni cloud proposte dai big vendor, Openstack è uno IaaS che consente un approccio diverso: letteralmente, una “catasta” di moduli cloud continuamente espandibile.

OpenStack è un progetto IaaS cloud computing di Rackspace Cloud e NASA. A oggi oltre 120 società si sono unite al progetto tra cui Samsung, Citrix Systems, Dell, AMD, Intel, Canonical, SUSE Linux, Red Hat, HP, e Cisco. OpenStack è un software libero open source rilasciato sotto licenza Apache.

Come avrete capito è un software largamente utilizzato anche dai big del mondo Linux. Fa dunque piacere che una azienda italiana si dedichi all'uso di tecnologie open source.

Se volete maggiori informazioni su OpenStack e su Enter potete recarvi sul sito http://www.enterthecloud.it/ dove troverete tanto materiale interessante.
Any source

Tuesday, July 9, 2013

Seth Vidal, il creatore di YUM, muore in un incidente stradale

Apprendo dal blog di jonobacon una triste notizia per tutti gli utenti Linux. Seth Vidal, il creatore di YUM (Yellow dog Updater, Modified), il package management usato da Fedora, CentOS, Red Hat e molte altre distribuzioni Linux basate su RPM, è morto a lo scorso 8 luglio 2013 in un incidente stradale.
Seth Vidal era in sella alla sua bici quando un automobilista, pare per evitare il traffico, lo ha travolto da dietro. Soccorso, Seth è morto in ospedale.

Benché la sua giovane età (aveva 36 anni), Seth Vidal si è distinto fin da subito nel panorama del software libero per diversi programmi. Ha sviluppato yum inizialmente presso la Duke University, e il software si è evoluto fino a diventare parte integrante di diverse distribuzioni Linux, tra cui Fedora e RHEL. Dopo aver lasciato Duke University, Seth ha continuato a lavorare in Red Hat, dove ha continuato a sviluppare YUM e vari altri progetti. Oltre a questo era membro del Fedora Project Board.

Mi unisco al cordoglio dei familiari :(

      The Daily Durham
     WRAL.com 
Fedora Mailing List
Immagine via Google+
Any source

Thursday, June 13, 2013

Red Hat sceglie GNOME Classic per Red Hat Enterprise Linux 7

È dall'arrivo di GNOME Shell che in rete si è fatto un gran parlare circa la possibilità di usare o meno la Shell in ambito lavorativo. Molti, fra cui il sottoscritto, pensano che la Shell sia inadeguata in ambito lavorativo in quanto l'interazione con la UI è spesso macchinosa.

La conferma di ciò è appena arrivata da parte di Red Hat che, tramite Denise Dumas (direttore tecnico di RHEL), fa sapere che Red Hat Enterprise Linux 7 utilizzerà GNOME Classic come ambiente desktop predefinito. Per chi ancora non lo sapesse la modalità GNOME Classic è una modalità aggiunta recentemente a GNOME Shell che, tramite una serie di estensioni, cerca di emulare quanto più possibile il comportamento di GNOME 2.
Ecco uno screen dalla mia Ubuntu GNOME 13.04

E poi non dite che non uso GNOME Shell :P

Dumas definisce GNOME Shell troppo "moderna" e dunque poco adatta agli utenti aziendali. Dumas aggiunge:
We introduced a classic mode [to Fedora 19] which, if you're comfortable with Gnome 2, you're going to find classic mode a no-brainer.
We think that people who are accustomed to Gnome 2 will use classic mode until they're ready to experiment with modern mode. Classic mode is going to be the default for RHEL 7, and we're in the final stages now. We're tweaking it and having people experiment with it. The last thing we want to do is disrupt our customers' workflows.
I think it's been hard for the Gnome guys, because they really, really love modern mode, because that's where their hearts are. But they've done a great job putting together classic mode for us, and I think it's going to keep people working on RHEL 5, 6 and 7 who don't want to retrain their fingers each time they switch operating systems -- I think classic mode's going to be really helpful for them.
ovvero che l'ultima cosa che vogliono è interrompere i flussi di lavoro dei loro clienti aziendali.
 
Impossibile non condividere questa scelta. Checché se ne dica GNOME Shell è troppo "scomodo" da usare in ambienti produttivi dove l'utente ha bisogno di una UI di facile utilizzo (da qui il redivivo interesse da parte di molti pinguini nei confronti di DE classici come KDE e Xfce).
Voi cosa ne pensate? Condividete i motivi della scelta?

Any source

Wednesday, February 27, 2013

Linus Torvalds: non cambierà Linux per fare un de*** t*** a Microsoft

Linus Torvalds si sa, è un tipino senza peli sulla lingua e ama sottolineare le cose con linguaggio colorito (amo questo lato del suo carattere). La gente lo fa arrabbiare continuamente e lui giustamente risponde a tono.
L'ultima arrabbiatura arriva a causa di Red Hat rea di aver proposto di includere nel Kernel Linux alcune patch volte ad agevolare nativamente il dual boot di Linux su macchine certificate Windows 8 che fanno uso di un firmware UEFI con la funzionalità Secure Boot abilitata. Come ben sapete ci sono alcune difficoltà tecniche che però sono state risolte tramite alcuni accorgimenti da parte delle varie distro come ad esempio Canonical che ha recentemente rilasciato la versione 12.04.2 di Ubuntu contenente il supporto all'UEFI.
Lo scorso giovedì David Howells, uno sviluppatore di Red Hat, ha chiesto a Linus Torvalds, tramite la mailing list del Kernel Linux di aggiungere alcuni binari PE al Kernel Linux per offrire supporto nativo all'UEFI. Ecco il messaggio

Hi Linus,
Can you pull this patchset please?
It provides a facility by which keys can be added dynamically to a kernel that
is running in secure-boot mode. To permit a key to be loaded under such a
condition, we require that the new key be signed by a key that we already have
(and trust) - where keys that we "already have" could include those embedded in
the kernel, those in the UEFI database and those in cryptographic hardware.
Now, "keyctl add" will already handle X.509 certificates that are so signed,
but Microsoft's signing service will only sign runnable EFI PE binaries.
We could require that the user reboot into the BIOS, add the key, and then
switch back, but under some circumstances we want to be able to do this whilst
the kernel is running.
The way we have come up with to get around this is to embed an X.509
certificate containing the key in a section called ".keylist" in an EFI PE
binary and then get the binary signed by Microsoft. The key can then be passed
to the kernel by passing the signed binary: (segue la patch)
In pratica ha chiesto di inserire un binario PE segnato della Microsoft con una chiave dinamica da aggiungere al kernel in modalità secure-boot (chiedo help ai tecnici per migliorare il post :P, non è che ci capisco tanto di questi tecnicismi).

La risposta di Torvalds

Ovviamente Linus Torvalds non ha preso tanto bene questa richiesta e ha risposto:
Guys, this is not a dick-sucking contest.If you want to parse PE binaries, go right ahead.
If Red Hat wants to deep-throat Microsoft, that's *your* issue. That
has nothing what-so-ever to do with the kernel I maintain. It's
trivial for you guys to have a signing machine that parses the PE
binary, verifies the signatures, and signs the resulting keys with
your own key. You already wrote the code, for chissake, it's in that
f*cking pull request.
Why should *I* care? Why should the kernel care about some idiotic "we
only sign PE binaries" stupidity? We support X.509, which is the
standard for signing.
Do this in user land on a trusted machine. There is zero excuse for
doing it in the kernel.
               Linus 
Non traduco la risposta perché è di facile comprensione (non fate i santarellini, quelle parole le capite anche se non sapete tanto bene l'inglese :P).
In pratica Torvalds non intende in nessun modo modificare il Kernel per "prostrarsi" a Microsoft.
Trovate l'intera discussione all'indirizzo https://lkml.org/lkml/2013/2/21/196

Any source