Sebastian Dörner, noto sviluppatore di KDE ha recentemente pubblicato sul suo blog un post, riguardante un plugin che introduce il supporto a Git su Dolphin. Lo sviluppo del plugin in questione ha avuto inizio circa un anno fa, ma per un lungo periodo di tempo era stato messo da parte; solamente grazie ad un utente che ne ha trovato alcune tracce su Google, Dorner ha presentato il plugin al grande pubblico.
Questo plugin va ad aggiungere un’altra feature ad un file manager già sufficientemente versatile e completo come Dolphin. Prevalentemente orientato agli sviluppatori che hanno a che fare giornalmente con sistemi di controllo delle versioni come Git e SVN, aggiungerà la possibilità di pushare e clonare codice con un solo click. Ovviamente, ci sarà ancora qualcuno che davanti a questa estensione preferirà utilizzare la cara e vecchia linea di comando, nonostante questo plugin sia davvero interessante e pratico.
Questa piccolo miglioramento per gli sviluppatori, è comunque disponibile per tutte le grandi distribuzioni: per Kubuntu, Archlinux, OpenSuse e Gentoo troviamo le istruzioni direttamente sul blog dello sviluppatore. Il plugin in questione va a far compagnia a quello per Mercurial creato da Vishesh Yadav, durante l’ultimo Google Summer of Code, che sarà parte di KDE 4.8.
Via | Life & everything
Che non fosse un periodo particolarmente fortunato per il kernel Linux lo si era capito. In Agosto un numero imprecisato di server utilizzati per la manutenzione e la distribuzione del codice sorgente sono stati attaccati sfruttando la compromissione delle credenziali di accesso di alcuni sviluppatori, aspetto questo, ancora oggetto di indagini.
Dalle analisi fatte l’infezione risulta non precedente al 12 Agosto e ci sono voluti 17 giorni per rilevare le anomalie prodotte. Il primo server ad essere attaccato è stato Hera, che ha consentito agli intrusi di recuperare e modificare le chiavi per accedere ad altri server. Lo strumento che avrebbe reso possibile questo attacco è Phalanx2, un evoluzione del rootkit Phalanx ossia un kernel rootkit autoinstallante progettato per la famiglia 2.6 che non utilizza il device /dev/kmem (ora disabilitato). Phalanx consente di nascondere file, processi e socket; includendo anche uno sniffer ed uno script di avvio. Per fortuna Phalanx2 è abbastanza facile da riconoscere tramite comportamenti anomali del comando “ls” usato nella visualizzazione della directory “/etc/khubd.p2/”.
Il pericolo di manomissione del codice sorgente del kernel era reale, fortunatamente però, l’utilizzo di un sistema di versioni concorrenti come git, ha consentito di verificare che i circa 40000 file sorgente non erano stati compromessi e ciò perchè per ogni file viene calcolato un codice SHA-1 impedendo così una scrittura “fantasma”. Gli amministratori hanno messo offline le macchine interessate e reinstallato i sistemi, certo è che 17 giorni per accorgersi che qualcosa non va, considerato l’alto profilo dell’obiettivo e la tipologia di rootkit, sono un po’ troppi.
Via | LinuxForDevices
Ghostscript 9.04 è stato rilasciato: si tratta della quarta versione del ramo 9.x ed è un importante spartiacque per l’interprete open source di PostScript e PDF. A partire da questo rilascio, infatti, molte funzionalità non potranno avere dei backport per la serie 8.x, a causa d’incompatibilità. La lista delle novità è molto lunga.
Anzitutto, Ghostscript 9.04 rimuove completamente il supporto a eXternal Fonts (XFonts) già deprecato dalla versione 9.01. Il porting per Windows introduce un supporto sperimentale alle stringhe codificate in UNICODE al posto dell’ASCII esteso, una funzione già prevista su Linux e Mac OS X. Gli errori non bloccano più l’esecuzione.
Un’altra novità molto interessante riguarda l’estrazione sperimentale del testo da tutti i formati di documento supportati da GhostPDL. Questa funzionalità, tuttavia, non prevede l’Optical Character Recognition (OCR). I sorgenti di Ghostscript 9.04 e successivi sono mantenuti utilizzando Git abbandonando definitivamente Subversion.
Via | Ghostscript
Git.js è un’applicazione, creata da Daniel Benjamin Lucraft, per controllare il DVCS con JavaScript. La soluzione è ancora incompleta, tuttavia presenta due implementazioni interessanti: la prima riguarda Node.js con un client dedicato da riga di comando mentre la seconda consiste in Application Programming Interface (AMI) per HTTP.
Al momento, la parte dedicata a Node.js è in grado di mostrare il log di un repository, stampare una lista dei branch esistenti e visualizzare informazioni sugli oggetti presenti. Le API permettono di creare repository in memoria, scaricare gli oggetti dai branch via HTTP, navigare attraverso di essi e creare dei file diff in HTML.
Il limite più evidente di Git.js è l’impossibilità d’effettuare dei commit o di creare dei branch: entrambe le funzioni sono in fase di sviluppo. Git.js si presenterà in futuro come un pacchetto npm per Node.js, avrà ulteriori API per HTTP e un’applicazione web per dimostrarne il funzionamento e renderlo più semplice da utilizzare.
Via | ReadWriteWeb
Google Code ha cominciato a supportare nativamente Git tra i sistemi di Distributed Version Control System (DVCS) disponibili sulla propria piattaforma. L’aveva anticipato Chris Di Bona, parlando di Android e del futuro del desktop di Linux. Non ci sono ancora comunicati ufficiali, però Git è utilizzabile registrando nuovi progetti.
Git s’aggiunge così a Subversion e Mercurial tra le opzioni disponibili su Google Code. Il supporto è già approdato anche su Eclipse Labs, la piattaforma promossa da Google ed Eclipse Foundation per i progetti sviluppati con Eclipse. Nonostante l’assenza d’annunci ufficiali, sono state redatte le domande più frequenti sul supporto.
L’utilizzo di Git prevede 4Gb di spazio come tutti gli altri DVCS, tuttavia il limite per ogni invio di codice è a 500Mb e Google sostiene di volerlo aumentare in futuro. Per sfruttare Git nel proprio repository, occorre installare la versione 1.6.6 o superiore del DVCS. Google Code potrebbe avere scelto Git per contrastare GitHub.
Via | The H Online
GitHub è diventato in poco tempo l’hosting che riceve più commit nei confronti dei repository di software libero e open source più utilizzati. Ovviamente, non sono tutte applicazioni per Linux: spesso si tratta di soluzioni per il web e non mancano i progetti su Windows. Molti sono programmi per Mac, così GitHub ha creato un client.
GitHub for Mac è un’applicazione completa per gestire il proprio account e i repository registrati su GitHub. Permette di aggiornare, modificare e rivedere il codice come qualsiasi interfaccia grafica per Git: l’unica differenza con queste ultime è nell’integrazione diretta con GitHub. Un aspetto utile, almeno quanto è “limitante”.
Il programma in sé utilizza libgit2, objective-git e una versione modificata di Chameleon (proprietaria, benché permetta alcune forme di ridistribuzione). Considerando l’esistenza di applicazioni semi-ufficiali per Git su OS X, GitHub for Mac non ha un grande valore aggiunto. Forse, bisogna attendere che riceva degli aggiornamenti.
Via | GitHub
Lo scorso autunno vi avevamo presentato Sparkleshare, un progetto open source che vuole implementare un sistema simile a quanto offerto da Dropbox.
Se qualcuno non fosse interessato per l’utilizzo di C# o volesse qualcosa di più semplice DVCS-Autosync potrebbe rappresentare la soluzione ottimale. Si tratta di un progetto minimale che monitorizza una directory e quando rileva un cambiamento si sincronizza con un repository remoto. Il DCVS principale di utilizzo è Git e come tale è sicuramente quello che ha meno probabilità di avere problemi, ma è possibile utilizzare il progetto anche con altri sistemi come Mercurial.
In pratica si tratta di uno script in Python che quando avvengono modifiche effettua un commit sul DVCS e si sincronizza con le altre istanze utilizzando messaggi XMPP. Il software è stato sviluppato sotto licenza GPLv2+.
Via | DVCS-Autosyn
Markus Winand considera Git come un ottimo esempio per i database di tipo NoSQL sulla base di una serie di motivazioni: anzitutto, Git non ha un frontend per SQL, né ha bisogno d’appoggiarsi a un backend in SQL. Inoltre è un sistema distribuito. Motivazioni inattaccabili, quanto povere per una tesi del genere: Git non è un database.
Eppure l’idea di Winand non è campata per aria e trova riscontro in un progetto di Tim Caswell, il creatore di WebApp su node.JS. Wheat, infatti, è un engine per la creazione di blog che s’appoggia a node.JS e utilizza proprio Git per il salvataggio delle informazioni. È un’applicazione inconsueta per il DVCS, comunque funzionante.
Da qui a definire Git un database di tipo NoSQL ce ne passa… oppure no? In sé, la definizione di NoSQL copre qualsiasi progetto utilizzato per immagazzinare i dati in modo non relazionale. Specialmente se distribuito. È un concetto molto generico, perciò anche Git potrebbe rientrarci. Il dibattito è aperto: e voi cosa ne pensate?
Via | ReadWriteWeb
Gitmarks è un sistema per il salvataggio dei preferiti creato da Hilary Mason su GitHub: scritto in Python, funziona dal terminale ed è basato su Git. Una soluzione interessante per chi volesse sostituire Delicious, dal quale può importare i bookmark, prima che possa essere troppo tardi. Gitmarks è sia open source sia free software.
Basato sul concetto di P2P, Gitmarks può essere avviato direttamente su GitHub (sul quale aggiunge delle funzionalità sociali) oppure sul proprio server. La lista dei comandi è essenziale: ai preferiti si possono associare, oltre al titolo, una serie di etichette. L’archivio dei link salvati può essere interrogato utilizzando GREP.
Oltre alla riga di comando, Gitmarks è dotato di un comodo bookmarklet per il browser. A dispetto dell’estrema semplicità del codice, Gitmarks è un progetto convincente: la formula di rilascio sotto GPLv3 su GitHub lo rende particolarmente duttile, è già stata inviata una richiesta per migliorare il tagging degli indirizzi salvati.
Via | ReadWriteWeb
Gli sviluppatori di GitHub hanno annunciato che il loro servizio è arrivato al milionesimo repository.
Secondo Scott Chacon, vice presidente della sezione Research & Development, circa il 60% dei repository sono progetti interi, mentre il restante 40% sono soltanto code snippet. Lanciato poco più di due anni fa GitHub si è ormai imposto come la soluzione di hosting per i progetti open source che utilizzano Git.
Se i progetti open source non devono pagare, le aziende che vogliono mantenere il loro repository privato hanno bisogno di accedere alla versione premium.
Via | GitHub
Gitolite è un gatekeeper basato su ssh per la gestione di repository ssh.
Il progetto consente di utilizzare una normale chiave ssh per l’accesso autenticato ai repository Git e permette agli amministratori del sistema di decidere in maniera precisa chi può accedere a quali rami e con quali permessi.
Il progetto si presenta come molto utile sia in ambito lavorativo sia per chi non ha la possibilità di creare utenti aggiuntivi per ogni sviluppatore che partecipa al progetto. È scritto in perl e rilasciato sotto licenza GPLv2.
Via | Gitolite
Giggle è un frontend scritto in Gtk+ per Git.
Il programma è stato sviluppato inizialmente durante un Hackathon tre anni fa e da allora ha conosciuto un periodo senza sviluppo, ma ora si sta progredendo verso la versione 0.5
Recentemente è stata rilasciata la versione 0.4.95 ed il software è disponibile già pacchettizzato per Debian, Fedora, OpenSuse ed Ubuntu.
Via | Giggle
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, chi siamo
© 2004-2011 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
