I actually have just one thing I want to pass along, although from two different sources.

• Dante Díaz: Playdeb launched. Now Ubuntu gamers have a repository that can be used to install Linux games. Which games? How about these?
• Tom Dryer: Playdeb - The Gaming Repository for Ubuntu. Tombuntu is nice enough to give us some screenshots of using the Playdeb repo.

What about Google Chrome? I honestly can't say how I feel about it personally. It's only in beta, and while it's a public beta it's only available to Windows users. Since I don't even have a Windows partition any more I can't fire it up. True, I can try it in WINE, but if a web browser won't run natively in Linux I'm not interested in using it. Although it looks like the Terms of Service for using Chrome are pretty heinous. From my own reading of the EULA I have no interest in loading this particular piece of Google code onto my hard drive, even if I do run other Google products.

1. Create a database

for an example, I will create database test_repo in MySQL.

2. Open Kettle, and click tab Repository / Connect to Repostirory

3. Choose new, new

4.  Set-up a connection to MySQL:

Connection name : (test_repo)

Connection type : MySQL

Server host name : 127.0.0.1 (default MySQL)

Database name : test_repo

username : root

password :

You may click "Test" to make sure the connection is OK.

5. Set-up database, Click "Create or Upgrade"

That's all the step. Now you can login to your repository.

A volte accade che dopo aver installato il pacchetto nvidia dei repository o, alternativamente, il file .run, si esegue nvidia-xconfig e ci si ritrova la mappatura della tastiera inglese..

Vabè, non è grave, si risolve in fretta, però è leggermente fastidioso..

Terminale! (root)

• gnome

gedit /etc/X11/xorg.conf

• kde

kate /etc/X11/xorg.conf

• xfce

mousepad /etc/X11/xorg.conf

Modificate questa sezione (InputDevice) aggiungendo una riga:

Section "InputDevice"
Identifier     "Keyboard0"
Driver         "kbd"
Option         "XkbLayout" "it"
EndSection

Ah! Se volete levare anche il logo Nvidia all'avvio aggiungete anche quest'altra riga:

Section "Device"
Identifier     "Card0"
Driver         "nvidia"
VendorName     "nVidia Corporation"
BoardName      "G72 [GeForce 7500 LE]"
Option         "NoLogo" "True"
EndSection

P.S: Aggiungete solo la riga che vi serve, ma non modificate gli altri valori perchè cambiano da pc a pc.

Ora salvate e uscite.

Ora riavviate il pc o digitate sempre dal terminale:

/etc/init.d/gdm restart

P.S 2: In alcune distribuzioni (tipo in Arch, ma non parlo di Ubuntu e Debian perchè sono sicuro al 100% che sia così) il comando da fare è

/etc/rc.d/gdm restart

P.S 3: gdm va sostituito in base a quale DE usate (per KDE kdm)

Ora dovrebbe essere tutto a posto..

P.S 4: A me sta cosa è successa con Debian, con le altre distribuzioni non lo so se accade o no, ma credo che con Ubuntu e Arch non capiti proprio..

wondering how you can make your own iphone theme?  well, the hardest part about it is that if you really want to customize your own icons, you are going to have to make them.  but compiling them doesn't have to be so difficult.  once you have your icons, wallpaper, etc. in place, then all you have to to is compile them through this great WYSIWYG site called http://iphonethememaker.com/.  simply click and choose what you want to change on the theme and hit compile when you are done.  after hitting compile you are given options on uploading it into your phone.  don't worry, they've even thought it out for you so all you need to do is follow their step-by-step instructions.  remember, this is for basic themes but if you are graphics-savvy then you shouldn't have any trouble making something great:)  and you can perhaps even start your own theme repository for Cydia or Installer in the future.

Hope this helps!

Kemudian Ane iseng berpikir bagaimana Ane bisa membuat repository sendiri dalam hardisk. Akhirnya setelah coba-coba Ane menemukan cara yang cukup simple. Namum perlu diingat cara ini hanyalah akal-akalan semata hanya agar kita tak perlu capek memasukkan DVD tiap kali menginstall program. Sebelum Ane sampaikan cara membuatnya, ada baiknya kalo Ane sampaikan dahulu batasan masalahnya (haiyaah... skripsi banget) :

1. Kita akan menggunakan ISO dari DVD repository, yang besarnya mencapai 20.5 GB. ISO ini harus disimpan dalam hardisk, jadi mohon disiapkan free space hardisk sebesar itu :D
2. Dalam tutorial ini Ane anggap kita baru saja menginstall Ubuntu, sehingga masih belum ada repository lain selain default bawaan si Ubuntu.

Okeh berikut adalah langkah-langkah pembuatannya :

1. Copykan file ISO dari kelima DVD repository tersebut ke dalam hardisk. Jika Anda belum memiliki file ISO, Anda dapat membuatnya melalui Tools yang disediakan oleh Brasero Disc Burning (Applications > Sound & Video > Brasero Disc Burning).
2. Bukalah Synaptic Package Manager (System > Administration > Synaptic Package Manager).
3. Bukalah menu Add CD-ROM (Edit > Add CD-ROM). Maka Akan muncul dialog permintaan untuk memasukkan CD. Biarkan dialog ini apa adanya dulu.
4. Bukalah Terminal (Application > Accessories > Terminal). lalu mount ISO DVD yang pertama dengan format : mount -o loop -t iso9660 <file iso> /media/cdrom misalnya mount -o loop -t iso9660 ubuntu-8.04-repository-i386-1_contrib.iso /media/cdrom
5. Kembalilah ke dialog dalam Synaptic Package Manager, pililh opsi OK.
6. Lakukan langkah 3-5 untuk ISO DVD ke-2,3,4 dan 5. Dengan ini kita telah menambahkan ISO DVD tersebut ke dalam repository Ubuntu.
7. Tutup Synaptic Package Manager.
8. Sekarang kita akan menginstall Gmount-iso. Sebuah applikasi yang memudahkan kita untuk memount ISO.
9. Bukalah Application > Add/Remove...
10. Pilih opsi All availabe applicatios pada combo box Show.
11. Pada Search ketikkan gmount-iso. Maka akan muncul program Gmount-iso. Install program tersebut.
12. Kita akan diminta memasukkan DVD, maka lakukan langkah no. 4 terhadap ISO DVD yang diminta.

Nah dengan cara seperti diatas kita sudah bisa menginstall program dari hardisk tanpa perlu memasukkan DVD-ROM. Misalkan ketika kita menginstall program, kita diminta memasukkan DVD ke-X ke dalam CD-ROM. Kita cukup membuka Gmount-iso (Applcation > System Tool > Gmount-iso) lalu mount ISO dari DVD ke-X tersebut ke dalam direktory /media/cdrom .

Bagi Ane cara ini cukup untuk mengurangi rasa jengkel karena kita tidak perlu ribet dengan DVD dan kita tak perlu menunggu DVD-ROM mengenali DVD kita.

LIVNA

[livna]
name=Livna for Fedora Core $releasever - $basearch - Base
baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/
enabled=0
gpgcheck=1
gpgkey=http://livna-dl.reloumirrors.net/RPM-LIVNA-GPG-KEY

FRESHRPMS

[freshrpms]
name=Fedora Core $releasever - $basearch - Freshrpms
baseurl=http://ayo.freshrpms.net/fedora/linux/$releasever/$basearch/freshrpms/
enabled=0
gpgkey=http://freshrpms.net/RPM-GPG-KEY-freshrpms
gpgcheck=1

ADOBE

[adobe-linux]
name=Adobe Systems Incorporated
baseurl=http://linuxdownload.adobe.com/linux/$basearch/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux

ATRPMS

[atrpms]
name=Fedora Core $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/f$releasever-$basearch/atrpms/stable
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
enabled=0
gpgcheck=1

Nah kemaren sore om dedyeuy berbaik hati untuk sharing hasil begadangnya ke ane. Langsung aja ane temuin dia di kampus tamrin sehabis pulang bekerja sekalian minjem dvd fedora 9-nya. Ga duduk cincay lama2 ane langsung cabut go home buat nyoba ntuh bikin mail server tutorialnya si om dedyeuy.

Sampe rumah, istirahat bentar, idupin komputer, instal FC9, nunggu sambil nyemoke+ngupi [ga pake "l"]... Udah rebes, cek NIC dulu, soalnya kemaren pake FC5 ga kedetek tuh NIC. Wah kedetek, siip lah. Colok flashdisk, cari tutorialnya, ketemu. Eng ing eng... file apaan nih? [filename:Email Server di fedora 9 by_dedyeuy.odt] Ya ampyun nih file OpenOffice-Writer, duh capedeh secara tadi ga diinstal Office Productivity-nya ngara biar cepet instal FC9-nya.

Coba cari di Package Management/Add Remove Software, duh ga bisa diinstal, secara tuh program nyedot dari internet. Nyari lagi di FC9 dvd instalasi-nya, wah ada banyak, di direktori Packages, kali ini nyoba pake perintah:

# rpm -ivh install OpenOffice-Writer.x.xx.xxx.rpm

Waduh banyak bangat dependency-nya, mesti nginstal satu2 dong nih. Mmm, malam semakin larut aku sendiri tak ada yang menemani... kira2 begitulah...

Tanpa ada rasa putus asa, nyoba lagi nyari cara biar bisa instal sekaligus tanpa harus instal satu2. Coba, coba, coba lagi, aha... ketemu... pake yum. Tapi bukannya yum juga nyedot dari internet. Yup betul, tapi kita akalin gimana biar ntuh yum nyedot dari dvd juga secara dirumah ane kaga ada line internet.

Okeh pertama ane masuk ke direktori /etc/yum.repos.d/ nah disitu ada beberapa file konfigurasi repositori untuk yum. Nah disinilah kita tambahin konfigurasi untuk repositori dari dvd. Caranya :

# vi dvd.repo
[fedora-dvd]
name=Fedora DVD $releasever - $basearch
baseurl=file:///media/DVD1-IL082008/
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora file:///etc/pki/rpm-gpg/RPM-GPG-KEY
ESC
:wq

Nah terus ubah option enabled=1 menjadi enabled=0 pada file yang ada di direktori /etc/yum.repos.d/. Inget yang dvd.repo option enabled-nya diaktifin [=1].

Times to try...
# yum install OpenOffice.org-writer.x.xx.xxx

Sip, udah keinstal tuh OpenOffice-Writenya... Ane buka tuh tutorialnya, langsung praktek... Alhamdulillah dalam waktu 1 jam sudah selesai bikin mail server dan semua lancar [seperti yang om dedyeuy perkirakan, xixixi]. Hmmm, rokok udah abis, kopi tinggal ampas, waktu tidur telah tiba. Tinggal pehamannya diperdalam, nanti tapi, tidur dulu...

# 01:56 Zzzz.. zzz.. zzz...

Abbiamo visto come installare i programmi su Ubuntu senza usare il terminale. Adesso vediamo come gestire i repository.

Il programma grafico che ci permette di farlo è sorgenti software che troviamo nel menu Sistema/Amministrazione.

Vediamo nella prima tab la possibilità di attivare/disattivare i repository principali di Ubuntu.

Cliccando su "scaricare da", inoltre, possiamo cambiare il set dei server. Nella figura sono attivati quelli italiani, ma possiamo scegliere i server principali (quelli localizzati in Inghilterra) oppure quelli di altri paesi. E' importante sapere che questi server sono dei mirror, quindi tra loro identici. Mettendo i server francesi, per esempio, non ci ritroveremo i programmi nella lingua di Napoleone.

Sempre dallo stesso menu possiamo anche far scegliere automaticamente il server più veloce (quello con tempo di ping minore) dopo un breve test.

Vediamo ora come attivare i repository aggiuntivi di Ubuntu. Clickiamo sulla tab "aggiornamenti" e avremo di fronte questa schermata:

I repository di sicurezza (security) e quelli degli aggiornamenti raccomandati (update) dovrebbero essere sempre attivi, poiché correggono vulnerabilità e bug. Gli aggiornamenti "proposed" e "backports" invece sono riservati ad un'utenza medio-esperta, in grado di risolvere autonomamente eventuali problemi, come ad esempio un aggiornamento del kernel che non supporta i driver della scheda video. In questi repository, infatti, arrivano aggiornamenti che devono essere ancora testati prima di finire nei repository principali.

Vediamo come aggiungere dei repository esterni. Ci serviremo del seguente esempio, per la gioia degli amanti degli effetti grafici:

http://freetimesblog.wordpress.com/2008/06/17/installare-la-versione-di-sviluppo-di-compiz-da-repository/

Per prima cosa clickiamo su "software di terze parti", quindi su "aggiungi" e copiamo esattamente la prima riga dei repository (va bene anche un copia e incolla). La seconda  (deb-src) non è necessaria se non si desidera compilare i sorgenti. Tutto qui.

Una delle operazioni spesso richieste è l'aggiunta della chiave di autenticazione gpg.

Spiegazione: la chiave serve a rassicurare il sistema sull'autenticità del server. Uno dei modi più utilizzati per attentare alla sicurezza, infatti, è crackare i server DNS dei provider o delle aziende e fare in modo che, ad esempio, www.google.it punti ad un sito malevolo. La stessa cosa applicata ad APT permetterebbe di installare programmi malevoli facendo credere all'utente di trovarsi di fronte a semplici aggiornamenti.

Vediamo come operare per aggiungere la chiave.

Supponiamo che la guida per i nuovi repository ci chieda di digitare questo comando da terminale:

wget http://download.tuxfamily.org/3v1deb/DD800CD9.gpg -O- | sudo apt-key add

Per capire come agire cerchiamo di analizzare il comando. Wget è il programma che permette di scaricare dal web qualsiasi file. nel nostro caso il file è la chiave di autenticazione del repository. Essa è contenuta nel file http://download.tuxfamily.org/3v1deb/DD800CD9.gpg.

La parte successiva del comando reindirizza tale file al comando apt-key che serve ad aggiungere una chiave nell'archivio di APT.

Ciò che serve a noi è solo il file http://download.tuxfamily.org/3v1deb/DD800CD9.gpg. Quindi prendiamo l'indirizzo e lo scriviamo nella barra di Firefox. Il browser ci chiederà di salvarlo. Mettiamolo dove ci pare, ad esempio sulle nostra home, poi da sorgenti software clickiamo sulla tab "autenticazione" e quindi "importa file chiave". Indichiamogli dove abbiamo salvato il file (ad esempio /home/nomeutente).

Attenzione ad un particolare: poiché sorgenti software agisce sotto utente root, quando cercheremo il file della chiave assicuriamoci di stare navigando in /home/nomenostroutente e non nella home dell'utente root (che è /root) altrimenti non troveremo nulla.

Alla chiusura del programma ci verrà richiesto di aggiornare i repository, diciamo di sì e il gioco è fatto.

Il primo è il più veloce a mio parere ma quello meno pratico e "moderno":

Apriamo il terminale e digitiamo:

sudo gedit /etc/apt/sources.list

In questa maniera:
Confermiamo e e il file che abbiamo richiesto si aprirà in un editor di testo quale è GEdit



Ora possiamo aggiungere il nostro indirizzo del repository scorrendo la pagina e incolladolo sotto tutti e poi salvare.

Secondo metodo:

Il secondo metodo è più facile da ricordare, basterà infatti aprire il Gestore Pacchetti Synaptic che si trova in

Sistema -> Amministrazione ->

Cliccare su Settings e poi su Repositories.

Selezioniamo la linguetta che cita Third-Party Software

A qusto punto basterà cliccare su Add e in Apt-Line inserire l'indirizzo del Repository.

Finito.

In linea di massima, per dirlo in parole povere i repository sono dei grandi archivi di programmi divisi per categorie.

Forse non ve ne sarete mai accorti ma tutte le volte che aprite il Gestore Pacchetti Synaptic e scaricate un software lo scaricate proprio da questi benedetti repository. Il download da questi garantisce un software perlomeno più sicuro di quelli disponibili su internet ( parlando dei repository ufficiali) e anche sicuramente compatibile con la distribuzione installata.

I repositry di Ubuntu sono divisi in 4 categorie:
- main
- restricted
- universe
- multiverse

Le differenze sostanziali sono la distinzione tra software libero e il tipo di supporto che viene offerto.

Nella categoria main il software viene supportato ufficialmente
Nella categoria restricted in questo caso il software è supportato ma non appartiene alla categoria del software libero.
In quella universe il software è supportato dalla comunità e non ufficialmente
Mentre in quella multiverse si raggruppa tutto il software non libero.

Spero di essere stato utile a qualcuno con questa mini-guida.

Propagating the LINQ entities up the UI layer and back posed several problems:

• "Fat" objects going to the UI and impacting performance and scalability
• Handling associations (foreign key references) was difficult to say the least. I found the process of detaching and reattaching LINQ entities to be fairly painful and my final solution was far from satisfactory in terms of elegance and maintenance.

The use of the Repository pattern likewise had a few problems:

• The data context is scoped at the level of a HttpRequest, prohibiting multi-screen transactions
• Bloated object graph - you naturally would be bringing back the actual LINQ entities to the UI and potentially bringing back a large number of referenced objects.

Using DTO:

• Required the construction of lightweight DTOs (yes, hand-coded DTOs). These have the advantage of being easily serializable to travel over a web service.
• The use of assemblers to handle the hydration of DTOs and the injecting of data back to the database
• Many DTOs mean many assemblers

While every person may have their individual preferences, my preference is to use the DTO approach. After coding my fifth assembler, I decided that enough is enough. Using Reflection, I created a generic assembler that is used to hydrate and extract data from DTOs. I was initially concerned with any performance issues but the result of using reflection has a minimal performance hit. What I've found with DTOs is that while it might seem that there's additional overhead in creating these objects, it literally does not take more than a few minutes at most to build one. The DTOs allow me to limit the scope of data which I am bringing to the UI, which effectively means that I only bring what I need to the UI and avoid bringing bloated objects to the UI.

With the official release of the ADO.NET Entity Framework today in .NET 3.5 SP1, I'm eager to see how the approach to building n-tier applications with OR\Ms may change.

This one was from an institution struggling to sell the repository to the academics. Nothing new there, and in this case the repository has been put on hold for that reason. I don't see any problem with that - if there is no recognised need for a repository, don't just get one to tick the box.

"Tell an academic about Open Access and they'll say "but I never have a problem getting hold of papers", tell them it'll raise their research profile and they'll say "I think (insert prestigious publication of choice) does a better job at that". I don't think the problem is limited to the academics either - software developers within Information and/or Computing services seem to have similar views as do some in the Library community.

It isn't that clear-cut but I don't think the academics concerns are unjustified. It is hard to see the direct and immediate benefits of IRs to them personally - it is just effort and time that they don't have. To my mind the benefits of IRs seem to largely be on the part of the Institution itself - at least at the moment - a place to manage research outputs (and teaching materials) - the digital assets of the organisation that are currently lost in a morass of disk drives and departmental Web servers. This standpoint - one of asset/data management seems to appeal to holders of purse-strings and they are issues any organisation should start grappling with - commercial, public and education sectors.

I'm interested in what you say about differentiating the "Repository" from adding records to the Library catalogue and Web/VLE, etc. While I'm not sure the Repository (the capital R is deliberate) crowd would agree, I feel that it is this need to differentiate that has caused some of the problems. If a Web site (perhaps with an associated catalogue record kept by the Library and including a persistent URI, supported by the Web site/VLE) fulfills the Institution's requirements for research output management and dissemination (in addition to being more attractive to users) then so be it. It fulfills the role of the mythical Repository - it is a repository - in that it gets stuff "out there" but it works in the context of that Institution.

Provided the Web site is designed and implemented well (I guess that is the issue repository software is intended to help with) there is no reason why it cannot be upgraded to an IR later if people want/start to see the need for it.

One of the ways I've heard repositories sold to academics in teaching-led institutions is to offer them up as Flickr-like places to share resources and nothing else. You forgo complex metadata (and perhaps QA) in favour of a promiscuous deposit policy. People share their materials and use those of others. There are, of course, IPR issues here, as ever, but the benefit is that stuff that would not normally be kept can be kept safe for future staff - like the reading lists one academic had a one hard copy of and retyped and printed it each year - but did not save the Word document they printed it from - its a true story! :-)

These are just some of my thoughts. I guess the bottom line is, as ever, to really consider what the repository is for. If it is to tick some checklist that says things we should do then it is right to hold on - no technology should be forced to address a need that isn't there. If there is an identifiable need with the institution - and that may come as more and more academics start losing their work to failing hard drives or whatever - then implement it in the way that works at the institution. IRs represent a best effort at defining a standard way of addressing asset management and scholarly communication, but they are by no means a silver bullet or one of those tiny gloves that expands to fit any hand! :-)

Finally, on a practical note, RSP should in theory be able to help with convincing your academics and if it can't then it would learn a valuable lesson on what academics really think - which would be handy for us. So bear us in mind if the R-word appears again on the horizon..."

The question was put to me as this:

"an enquiry regarding the advantages of using repository software over other web based storage solutions"

there is lots in that and in discussing it here at UKOLN I got different views on the question - one thought that the problem with with terminology - do we use the word "repository" or "web-based storage"? I'm not sure that is what you are asking, but if it is, then I think you have to call the repository whatever you and your users feel most comfortable with. "Repository" is a terrible, ugly, hugely overloaded term and not one likely to make sense to anyone! The second thought suggested you were asking about the differences between the two and a third suggested that the query was in fact "why do we not just develop our own, in house, repository software?". All these questions are linked...

The answer, I think, is right back at the start and can be summarised as "it depends on what you want to use it for". That is to say, what are the user requirements that the system is intended to fulfill?

In the RSP Briefing Paper "Repositories, Content Management Systems and Portals", some of these requirements are given:

* Open Access - the ability to make available online the material in the repository and control access including time-based release, as required.

* Accessible to search engines - pretty much goes without saying these days!

* Persistent identifiers - should be self-explanatory. You could call this ongoing access - a commitment from the institution to make the items in the software system available until the end of the Internet or the world - which ever comes first. :-)

* Bibliographic metadata - a set of data associated with an item of content that records useful information such as Author, Title, etc. - in a controlled fashion - enabling search by surname, "give me a list of papers I've contributed to since 1986", etc.

(I'd add here and suggest even more important and useful than bibliographic metadata:

* Management/structure metadata - this is more important than bibliographic and includes things like version - eg. is this the latest version and if not, where can I get that? Also "how many times has this paper been downloaded/cited/viewed?" and other statistical data.)

* Export/import - of content from Web pages, CVs, RAE data, research systems, etc.

* Metadata harvesting - some services are trying to make use of the stored metadata to provide more sophisticated search/browse services. At present, to achieve this they use the OAI Protocol for Metadata Harvesting (OAI-PMH). It is expected that the software system will support this protocol if it is to meet the requirements of research output management software.

This set of requirements has not been plucked from the air - it is a result of the "repository movement" that has over the last eight years investigated what might be required to support what a user needs from any research output storage, disemination and management system ("ROSDMS" is less catchy than "repository" and "repository" less expensive than "publisher" :-)). For further details of this investigation some use cases and other materials are on the Repositories Research Team wiki:

http://www.ukoln.ac.uk/repositories/digirep/index/All_the_Scenarios_and_Use_Cases_Submitted

Having outlined those "one size fits all" requirements, it is important to say that of course every institution is different, everyone has different requirements.

While I would be cautious of starting from nothing and beginning the user requirements analysis again, it is important to allow users and developers to feel ownership of any system built to achieve repository-like functions and some kind of analysis might be a useful way to achieve this. What is the institution trying to achieve by setting up a place to store, disseminate and manage its research outputs and how does that differ or ultimately align with the received wisdom on what such a system needs to support?

Another way of specifying repository-like requirements was presented at a meeting I was at a week ago where the key features were given as:

* Storage/Versioning
* Indexing
* Retrieval
* Access Control/Rights Management
* Cool URIs

None of that screams "specialist system" to me and so you are right to ask if web-based storage can do just as well. I guess the key thing missing from that list is "management" and there is a real worry that without institutional management of research outputs there will very quickly be a mess of departmental Web sites, just like that bad old days of an institutions Web presence. The concept of a "Repository" implies, but doesn't necessarily give, organisational control and a structured approach to looking after research outputs. That concept could be met by "web-based storage" provided it allowed for that structured approach to management of material.

So, the answer isn't simple and at one level all a "Repository" is is a "web-based storage system". I've outlined some of the specialist requirements that "web-based storage system" has been shown by the HE community to need to support. It is up to the institution to mould/map those requirements to the specifics of the institutional need to come up with its own set of requirements.

Then you consider software and you compare your requirements against them and consider the cost/benefit. Does repository-software-X meet our needs? (probably! :-)) Does "web-based-storage-solution-X" meet our needs? What about S3, Sharepoint, Alfresco? A DIY solution?

Perhaps it helps to try not to start by thinking of the "Repository" (call it what you like - PLEASE don't call it "Repository"! :-)) as a piece of software. Better to think of it as a service to the institution. After that think about the technology that fulfills the needs of that service. At one level we call that technology "repository" but we could just as easily call it "web-based storage system" and whatever we call it it could still be CDSware behind the scenes.

In principio esistevano i .tar.gz. Gli utenti dovevano compilare ogni programma che volevano usare sui loro sistemi GNU/Linux. Quando fu creata Debian, fu ritenuto necessario che il sistema incorporasse un metodo di gestione dei pacchetti installati sulla macchina. A questo sistema fu dato il nome dpkg. Fu così che nacque il famoso "pacchetto" nel mondo GNU/Linux, poco prima che Red Hat decidesse di creare il proprio "rpm".

Rapidamente un nuovo dilemma si fece strada nelle menti degli sviluppatori di GNU/Linux. A loro serviva un modo rapido, pratico ed efficiente per installare i programmi, che gestisse automaticamente le dipendenze e che avesse cura di mantenere i file di configurazione esistenti mentre si effettuavano i vari aggiornamenti. Ancora una volta Debian ha aperto la strada dando vita a APT (Advanced Packaging Tool).

Così recita l'introduzione di APT-HOWTO il manuale di Debian per APT, ovvero il sistema di gestione dei pacchetti di Debian e derivate, compresa Ubuntu.

Se mi chiedessero di dire in cosa GNU/Linux è superiore (tecnicamente parlando) a Windows, potrei fare un lungo elenco: sicurezza, stabilità, velocità, ecc. Ma se mi domandassero in cosa GNU/Linux è più facile di Windows, non avrei dubbi: nell'installazione dei programmi.

Quando studiavo informatica alle scuole superiori, anche se erano i primi anni '90, il libro di testo risaliva agli anni '70. Ricordo che la definizione di sistema operativo, allora, comprendeva anche un compilatore. Eppure io usavo MS DOS e non c'era alcun compilatore (solo uno striminzito interprete BASIC), usavo Windows 3.1 e anche lì niente compilatore di default. I compilatori li faceva, all'epoca, la Borland: Turbo Pascal, Turbo C, ecc. La Microsoft avrebbe poi creato da lì a poco il Visual Basic, ma si vendeva a parte.

In effetti negli anni '70 tutto il software era libero e gli utenti compilavano i programmi per conto proprio. Per questo un compilatore era indispensabile. Quando il software libero è tornato in auge grazie a GNU/Linux, si è posto lo stesso problema: come rendere più facile l'installazione dei programmi? E così, dall'installazione per semi-hacker si è passati ad un sistema talmente semplice da far spavento. Eppure tanti neo-utenti GNU/Linux non l'apprezzano e credono che sia complicato installare i programmi... questo solo perché il modo di farlo è diverso, molto diverso, ma più efficiente, veloce e facile.

Bando alle ciance e arriviamo al punto. Come funziona?

In primo luogo bisogna mettersi in testa il concetto di repository. I repository sono dei normalissimi siti web strutturati in un modo preciso, definito dallo standard di APT. In sostanza, essi contengono i programmi già compilati da parte dei manutentori delle distribuzioni. Oltre ai programmi possono contenere anche set di icone, temi, librerie, pagine di manuale, testi e qualsiasi cosa che possa servire agli utenti.

Non c'è quindi bisogno di cercare su Internet il sito del programma, scaricarlo, installarlo. Basta controllare se c'è nei repository. Se il programma non è proprio sconosciuto e se la distribuzione in uso è abbastanza diffusa, quasi sicuramente il programma c'è già. Se non c'è, vedremo come "arrangiarci".

Per accedere ai repository potremmo in effetti scaricare i vari pacchetti e poi installarli singolarmente. Ma per come è fatto GNU/Linux, la cosa potrebbe essere impegnativa. Ogni pacchetto contiene solo lo stretto indispensabile, mentre tutte le librerie necessarie al funzionamento del programma sono solitamente esterne. Differentemente dal mondo del software proprietario, infatti, i programmi possono tranquillamente utilizzare le librerie pensate per altri programmi. In effetti creare un programma open source vuol dire in ultima analisi saper usare al meglio l'enorme quantità di librerie già esistenti.

Potremmo quindi trovarci di fronte alla spiacevole situazione di dover scaricare anche i pacchetti necessari al nostro programma (le cosiddette dipendenze) i quali a loro volta potrebbero necessitare di altri pacchetti, e così via.

Debian risolve brillantemente il tutto tramite APT. Esso è composto da una serie di programmi che ci permettono di automatizzare il tutto. Il più noto di essi è apt-get.

Dato il comando

apt-get install amule

il sistema scorrerà l'indice dei pacchetti alla ricerca di quella che si chiama "amule". Una volta trovato, scaricherà il pacchetto .deb corrispondente, controllerà se necessita di altri pacchetti (le dipendenze) ed eventualmente scaricherà anche quelle, se non sono già presenti nel sistema. Una volta finiti i download, passerà i vari pacchetti al programma dpkg, che li installerà. Il tutto avviene in pochi minuti e di norma non richiede intervento da parte dell'utente.

Ma APT fa di più. I manutentori dei pacchetti, ogni tanto, li aggiornano. Vuoi perché è necessario apportare una correzione, vuoi perché è uscita la nuova versione del programma. APT permette di centralizzare tutti gli aggiornamenti. Una comodità che Windows non potrà mai avere, poiché nel software proprietario l'aggiornamento si paga e, soprattutto, di norma non è legale distribuire software altrui. Insomma abbiamo un sistema di aggiornamenti di tutto ciò che abbiamo sul computer, automatizzato. Non solo il sistema operativo, ma tutti i programmi installati con APT. Bello no?

Ma c'è ancora di più. Una distribuzione, in fondo, è solo una collezione di pacchetti. Il kernel, il software GNU, eventualmente Xorg, Gnome, Kde, ecc. E allora l'aggiornamento del sistema ad una nuova versione non è altro che l'aggiornamento dei pacchetti e ci pensa sempre APT. Il sistema funziona talmente bene che alcune distribuzioni sono in aggiornamento continuo, ovvero non hanno versioni, ma i pacchetti si aggiornano appena disponibili. Ad esempio Debian Sid si installa una volta e rimane sempre aggiornata per tutta la vita...

Capito questo, alcuni suggerimenti pratici per chi usa Ubuntu:

a) leggetevi questa guida: http://guiodic.wordpress.com/2008/07/23/usare-ubuntu-senza-terminale-installare-i-programmi/

b) attenetevi a queste regole pratiche per installare i programmi:

1. Attivate tutti i repository della prima scheda su Sistema/Amministrazione/Sorgenti software
2. Prima di tutto cercate il nome del programma su Synaptic (o Adept se usate KDE). Se lo trovate, installatelo da lì. Controllate anche se ci sono dei pacchetti suggeriti, ma prima di installarli leggete la loro descrizione.
3. Se non lo trovate, provate su getdeb.net, il portale con vari programmi utili già pacchettizzati. Una volta scaricati i pacchetti basta cliccarci sopra due volte.
4. Se non c'è neppure su getdeb.net, provate a cercare su Google le parole repository, ubuntu, nome del programma. Se trovate un repository, accertatevi che sia per la versione di Ubuntu che usate, dopodiché aggiungetelo tramite Sorgenti software (scheda "software di terze parti").
5. Se non trovate un repository, provate a cercare su google: deb package ubuntu nome del programma è possibile che qualcuno abbia già pacchettizzato il programma che cercate magari sul proprio blog.
6. Se anche questo tentativo fallisce, provate con i pacchetti per Debian Sid: http://packages.debian.org ATTENZIONE: se Gdebi vi dà errore, meglio desistere.
7. Se neppure Debian ha il pacchetto che vi serve, allora visitate il sito del programma. Cercate se esiste un repository per Ubuntu e/o Debian mantenuto da loro, oppure, un pacchetto deb
8. Solo se tutti questi tentativi falliscono, allora rassegnatevi a compilare il programma per conto vostro.

Devo dire che, nella pratica, capita abbastanza raramente di arrivare al punto 8.

- maintains a Repository of packages available for the running system (OS and Architecture specific) and resolves dependencies among various packages.
- looks up the repository and automatically downloads the requested packages and its dependencies when installation is triggered.
- can be used to easily upgrade the system to a defined release or level.
- system administrators can create repositories of packages which can be pulled by users, thus allowing easy maintenance of systems across the network and centrally stored packages to reduce memory requirements.

Common Package Management Systems are yum (Yellowdog Update Modifier) that is distributed with Fedora and apt (Advanced Packaging Tool) that's distributed with Ubuntu.

__tipped__

Come prima cosa andiamo ad editare il seguente file:

/etc/apt/sources.list

il quale contiene la lista dei repository e andiamo ad aggiungere i seguenti repository:

deb http://xnv4.xandros.com/xs2.0/upkg-srv2 etch main contrib non-free
deb http://dccamirror.xandros.com/dccri/ dccri-3.0 main
deb http://www.geekconnection.org/ xandros4 main
deb http://download.tuxfamily.org/eeepcrepos/ p701 main etch
Quindi creiamo il seguente file /etc/apt/preferences che servirà a dare una priorità alle 
applicazioni provenienti dal repository standard di Xandros predefiniti...
all'interno andiamo a inserire questi dati...
Package: *
Pin: origin update.eeepc.asus.com
Pin-Priority: 950

Package: *
Pin: origin
Pin-Priority: 925

Package: *
Pin: origin xnv4.xandros.com
Pin-Priority: 900

Package: *
Pin: origin dccamirror.xandros.com
Pin-Priority: 850

Package: *
Pin: origin www.geekconnection.org
Pin-Priority: 750

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=testing
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600
A questo punto aggiorniamo il metadata del repository
$ sudo apt-get update

Tramite apt possiamo per esempio installare una nuova applicazione

$ sudo apt-get install nomeapplicazione

Oppure scaricare direttamente gli aggiornamenti di Xandros
$ sudo apt-get -s dist-upgrade

Oggi niente cose complicate, anzi. Cerchiamo di semplificarci la vita. Ho pensato ad alcuni post per spiegare come fare da interfaccia grafica ciò che di solito nelle guide viene spiegato con l'uso del terminale. I post sono incentrati su Ubuntu, ma possono essere applicati anche ad altre distribuzioni che usano GNOME. Dove possibile cercherò di dare qualche indicazione anche su Kde.

Penso che farà piacere un po' a tutti.

Vediamo come "tradurre" in grafica il seguente comando da terminale:

sudo apt-get install emesene

"sudo" è la parolina magica che è un po' la gioia e il dolore di tanti nuovi utenti. Serve ad ottenere i diritti di amministrazione del sistema, senza i quali non possiamo compiere operazioni "pericolose" come installare o disinstallare i programmi.

"apt-get" è il programma testuale che farà due cose: rintracciare il programma che ci serve nei repository (che sono speciali siti web dove vengono conservati i pacchetti dei programmi, dei "depositi" appunto) e, dopo averlo scaricato, installarlo. "Install" è l'azione che chiediamo, cioè installare. Se scriviamo "remove" invece chiederemo il contrario, ovvero disinstallare. "Emesene" è il nome del programma che vogliamo installare.

Vediamo come si fa da grafica. Andiamo su Sistema > Amministrazione > Gestore Pacchetti Synaptic.

Ci verrà chiesta la password, come nel caso del terminale, dopodiché si avvierà il programma Synaptic (notate l'assonanza con APT: SynAPTic : questo significa che Synaptic è un'interfaccia grafica per APT, quindi è assolutamente equivalmente. Usare apt-get da terminale o Synaptic da grafica è esattamente la stessa cosa).

Ora clickiamo su "Cerca" e scriviamo "emesene".

La ricerca possiamo farla solo sul nome oppure su nome e descrizione. In questo secondo caso vedremo anche i pacchetti la cui descrizione contiene la parola inserita. Ad esempio se abbiamo bisogno di un word processor potremmo scrivere "word processor" così verrebbero fuori diversi pacchetti.

Ora premiamo invio e dopo pochi secondi uscirà il pacchetto con il nome "emesene". Clickiamo sul quadratino e la riga si evidenzierà, così:

Ora clickiano su "Applica". Diamo conferma nuovamente e il sistema scaricherà il pacchetto, dopodiché lo installerà. Se clickiamo su "Dettagli" vedremo il terminale che esegue apt-get ;)

Se non ci piace e vogliamo togliere Emesene apriremo nuovamente Synaptic, cercheremo "emesene", clickeremo sul quadratino e selezioneremo "rimuovi" o "rimuovi completamente" nel caso volessimo cancellare anche i file di configurazione.

Allora, è tanto difficile installare i programmi su Ubuntu?

In confronto con Windows dovevamo:

1. cercare su google il programma
2. andare nella sezione Download del sito
3. scaricarlo
4. installare il programma rispondendo a 200 domande inutili
5. accorgerci che era una versione trial
6. cercare un crack su emule
7. scansionare con l'antivirus
8. spostare il crack nella cartella del programma
9. applicare il crack.

Scegliete :)

Con Kde useremo Adept, la logica è la stessa di Synaptic quindi non la rispiego ;) .

Alla prossima.