A l’heure où la sauvegarde s’arrêtait, voici ce qu’on pouvait trouver dans /var/log/messages :

server1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
server1 kernel: bnx2: eth0 NIC Copper Link is Down

La résolution du problème passe par une mise à jour du pilote.

On trouve le pilote pour ce chipset à cette page : http://www.broadcom.com/support/ethernet_nic/netxtremeii.php

Après avoir extrait l’archive, on installe les sources :

rpm -ivh netxtreme2-<version>.src.rpm

Installation de kernel-devel pour pouvoir compiler les sources du pilotes :

yum install kernel-devel

Construction du paquet :

cd /usr/src/redhat
rpm -bb SPECS/netxtreme2.spec

Installation du paquet fraichement installé :

rpm -ivh RPMS/<arch>/netxtreme2-<version>.<arch>.rpm

déchargement de l’ancien module :

rmmode bnx2

Chargement du nouveau module :

modprobe bnx2

Suite à cette petite manipulation, plus de soucis de chipset réseau qui ne répond plus. Problème résolu

Rennes métropole espère grâce à cela que les développeurs en herbe créent des applications pour smartphones afin de faciliter la vie dans la capitale bretonne. Selon Noël Philippe, directeur général des services urbains de Rennes Métropole « Le processus classique d’appel à projets pour une collectivité est très lourd. Il faut lancer un appel à candidatures, rédiger un cahier des charges, etc. Dans un an, nous aurions peut-être juste sélectionné nos partenaires. Grâce à l’open source, nous espérons que des applications seront disponibles d’ici quelques mois. »

Dans un premier temps, un usage commercial de ces données devrait être interdit. Il est envisagé d’autoriser par la suite l’usage commercial pour que les développeurs puissent vendre leurs applications.

Toutes les données de transport sont disponibles depuis le 1er Mars à l’adresse data.keolis-rennes.com. Elles seront complétées dans le courant de l’année 2010 par les données des organismes publics et des associations puis seront toutes regroupées sur le portail data.rennes.fr. Les documents seront proposés au format XML avec une API documentée afin de faciliter le développement.
Afin de lancer le projet, la ville de Rennes devrait organiser durant le printemps 2010 une concours d’applications dont les modalités et les lots sont encore à définir.

Ce projet est une première en France. Il a été inspiré par des initiatives similaire à l’étranger (Londre, San Francisco, Portland) et il est possible, suivant son impacte et sa réussite qu’il créé des émules dans d’autres ville française.

Source : http://www.rennes-metropole.fr/espace-presse,76701/

Cette version d’essai fonctionne avec les distributions suivantes :

• Red Hat Entreprise Linux (RHEL) 4 et 5
• CentOS 4 et 5
• Debian 5.0 Lenny
• Ubuntu LTS 8.04 Hardy
• Parallels Virtuozzo Containers (3.0 et 4.0)
• OpenVZ (El 5).

Une fois la version d’essai arrivée à échéance, les tarifs mensuels pour continuer à profiter de ses services vont de 3,95 à 9.95 $ US. D’après Ksplice, les différentes distributions GNU/Linux requièrent en moyenne 1 redémarrage par mois afin de profiter pleinement des mises à jour de sécurités du noyau. Leur service permettrai donc de sauver du temps et de diminuer les pertes de performances dues aux redémarrages.

Les sources sont également disponibles sur cette page.

Caractéristique de TCP

TCP est bien plus compliqué qu’UDP examiné au chapitre précédent. Il apporte en contrepartie des services beaucoup plus élaborés.

• TCP contient un mécanisme pour assurer le bon acheminement des données. Cette possibilité est absolument indispensable dès lors que les applications doivent transmettre de gros volumes de données de façon fiable. Cette fonction est assurée par un mécanisme d’acquittement (ou accusé de réception). Les paquets de données sont acquittés de bout en bout et non de point à point. C’est à dire que ce sont les machines sources et machines de destinations qui s’occupent de cela et non les routeurs qui se situent entre les 2.
• Le protocole TCP permet l’établissement d’un circuit virtuel entre les 2 machines qui échangent de l’information (Voir a ce propos le commentaire de Guizmo.7). On dit aussi que TCP  fonctionne en mode connecté (par opposition à UDP qui est en mode non connecté). En pratique, l’une des 2 machine doit effectuer un appel que l’autre doit accepter. S’en suit une discutions afin d’établir certains paramètres de communication. Une fois les préliminaires terminés, les protocoles informent les applications respectives que la connexion est établie et que le transfert peut débuter. Durant le transfert, le dialogue entre les protocoles continue, pour vérifier le bon acheminement des données.
• TCP a la capacité de mémoriser les données. Les paquets pouvant prendre chacun un chemin différent pour arriver à destination, il arrive que ceux ci n’arrivent pas dans le bon ordre. Grâce à cette capacité de mémorisation, TCP garde les paquets un certains temps et les reconstitue lorsqu’ils sont tous arrivés afin de présenter les données à l’application.
• TCP simule une connexion en « full duplex ». Pour chacune des 2 machines en connexion, l’opération qui consiste à lire des données peut s’effectuer indépendamment de celle qui consiste à en écrire.

Entête TCP

L’entête TCP est codé sur 20 octets hors options.

• Port Source (16 bits): Port utilisé par l’application sur la machine source.
• Port Destination (16 bits): Port de destination.
• Numéro d’ordre (32 bits): Correspond au numéro du paquet. Cette valeur permet de situer à quel endroit du flux de données le paquet, qui est arrivé, doit se situer par rapport aux autres paquets.
• Numéro d’accusé de réception (32 bits): Acquittement pour les paquets reçus. Cette valeur signale le prochain numéro de paquet attendu. Par exemple, si il vaut 1500, cela signifie que tous les datagrammes <1500 ont été reçus
• Offset (4 bits): Le champ Offset est codé sur 4 bits et définit le nombre de mots de 32 bits dans l’entête TCP. Ce champ indique donc où les données commencent.
• Réservé (6 bits): Champ inutilisé actuellement. Il était à l’origine prévu pour l’avenir. On peut dire aujourd’hui que ce champ restera vide.
• Drapeaux (flags) (6×1 bit): Les drapeaux représentent des informations supplémentaires :
  URG: si ce drapeau est à 1 le paquet doit être traité de façon urgente.
  ACK: si ce drapeau est à 1 le paquet est un accusé de réception.
  PSH (PUSH): si ce drapeau est à 1, le paquet fonctionne suivant la méthode PUSH.
  RST: si ce drapeau est à 1, la connexion est réinitialisée.
  SYN: Le Flag TCP SYN indique une demande d’établissement de connexion.
  FIN: si ce drapeau est à 1 la connexion s’interrompt.
• Fenêtre (16 bits): Champ permettant de connaître le nombre d’octets que le récepteur souhaite recevoir sans envoyer d’accusé de réception.
• Somme de contrôle (Checksum ou CRC): La somme de contrôle est réalisée en faisant la somme des champs de données de l’en-tête, afin de pouvoir vérifier l’intégrité de l’en-tête
• Pointeur d’urgence (16 bits): Indique le numéro d’ordre à partir duquel l’information devient urgente.

Établissement d’une connexion

Une ouverture de connexion TCP s’effectue en 3 temps.

L’émetteur du premier paquet doit avoir connaissance du couple IP : Port de l’application de la machine réceptrice (par exemple, on contact un serveur HTTP sur le port 80 qui lui est dédié). L’émetteur de ce premier paquet est à l’origine de l’établissement du circuit virtuel. C’est une attitude qualifiée de « cliente« .

Le récepteur du premier paquet accepte l’établissement de la connexion, ce qui suppose qu’il était prêt à le faire avant que le client en prenne l’initiative. C’est une attitude de « serveur« .

Le client envoie un segment comportant le drapeau SYN à 1. Le serveur répond avec sa propre séquence (SYN = 1) mais il doit aussi acquitter le paquet précédent, ce qu’il fait avec ACK. Le client répond alors avec un acquittement de la séquence du serveur (ACK = 1).

Une fois achevée cette phase appelée « Three-way handshake », les 2 applications sont en mesure d’échanger des données.

Conclusion

Voilà pour une première partie sur TCP. La seconde partie permettra de voir comment fonctionne la clôture d’une connexion ainsi que l’acquittement des paquets durant les transferts de données.  TCP est bien plus compliquer à aborder qu’UDP et c’est pourquoi je préfère le faire en 2 parties. J’essaierai d’ajouter dans la seconde partie quelques captures de trames afin d’illustrer ceci plus clairement. N’hésitez pas à laisser des commentaires si certaines notions vous paraissent mal expliquées ou trop survolées dans ce billet.

S’ajoute à ça un système permettant de donner des points aux utilisateurs sur le forum.

Je vous invite donc tous à vous y rendre, ne serait-ce que pour tester toutes ces nouvelles fonctionnalités peu communes sur les sites des communautés des différentes distributions.

www.linuxmint-fr.org

La solution pour pallier au manque d’adresses IPv4 semble donc clair pour tout le monde : switcher vers IPv6. Cette solution inéluctable a pour l’instant pu être retardée grâce à 2 technologies : DHCP et NAT. DHCP pour qu’un appareil éteint de conserve pas une adresse IPv4 inutilisée, permettant de réatribuer cette adresse à un autre appareil. Le NAT quant à lui permet à des machines possédant une adresse privée d’accéder à internet par un système de transformation d’adresse IP. Je reviendrai plus en détail sur cette technologie dans un prochain article.

Pour ne pas s’embêter avec IPv6, les FAI nous sortent donc un nouveau lapin de leur chapeau : le NAT « globalisé ». L’idée est la suivante : partager une adresse publique IPv4 entre plusieurs abonnés. Les box des abonnés recevraient chacune une adresse privée et le FAI s’occuperait du NAT. Ça n’a l’air de rien comme ça, mais ça signifie l’arrêt des serveurs perso hébergés à la maison et du peer to peer car l’abonné serait alors incapable de mettre en place une redirection de port vers sa machine comme on le fait actuellement lorsqu’on configure sa box.

Les sources :

L’annonce du NRO

Le NAT élargie

Un mois après la fin de la formation, je me décide tout de même à le mettre en ligne. Je pense que ce rapport décrit plutôt bien ce que peut être le métier de technicien réseau dans une administration ou une PME. Le problème lors de la mise en place d’un nouveau service n’est pas l’installation et la configuration de ce service mais la migration des anciens services utilisés vers les nouveaux. Surtout lorsque l’ancien service est un système propriétaire vieillissant (Je veux parler ici de Lotus Notes 5).

Squid est un proxy http très utilisé, dont j’ai pu découvrir une partie des possibilités. Egroupware est un groupware fournissant un agenda, un client mail, un carnet d’adresses, un système de réservations des ressources et plusieurs autres choses, le tout dans une interface web. Je vous invite à tester la demo sur le site du projet.

Ce rapport fait 38 pages et voici son sommaire :

1. Remerciements
2. Objectif du stage
3. L’entreprise
   1. Historique
   2. La structure actuelle
   3. Le service informatique
4. Spécifications
   1. Environnement de travail
   2. L’existant
   3. Besoins et contraintes
      1. Squid
      2. Egroupware
5. Mise en œuvre
   1. Proxy
      1. Planning prévisionnel
      2. Mise en œuvre
         1. Squid
         2. Sarg
         3. Squidguard
      3. Problèmes rencontrés
      4. Annexes
   2. eGroupware
      1. Schéma fonctionnel
      2. Planning previsionnel
      3. Mise en œuvre
         1. Configuration de openldap
      4. Problèmes rencontrés
         1. Conflit de schéma openldap
         2. Configuration de felamimail
      5. Préparation de la migration des utilisateurs
         1. Création du carnet d’adresses principal
         2. Importation des agendas Lotus Notes
         3. Importation des carnet d’adresse Lotus Notes
         4. Exportation des mails depuis LotusNotes dans eGroupware
         5. Importation mail depuis roundcube
      6. Annexes
6. Procédure de migration serveur
   1. Sur Revy
   2. Sur Revnew

Lien de téléchargement (pdf)

UDP (Pour User Datagram Protocol) se situe dans la couche 4 du modèle OSI (couche transport). Pour rappel, au niveau de la couche 3 (IP), les datagrammes sont routés d’une machine à une autre en fonction des adresses IP (en fait, le routage se fait en fonction de l’adresse réseau, voir QRQVB : L’adresse IP). Lors de cette opération de routage, aucune distinction n’est faite entre les différents services pour lesquels ces paquets peuvent être destinés. Que ce soit pour une connexion SSH (port 22) ou HTTP (port 80) ou autre, les datagrammes IP sont tous indifféremment mélangés.

La couche 4 du modèle OSI ajoute un mécanisme qui permet l’identification du service  concerné. Plusieurs programmes de plusieurs utilisateurs pouvant simultanément circuler sur le réseau, il est indispensable de faire un tri entre les applications. Ici, l’idée est d’associer la destination du paquet à une fonction. L’identification de cette fonction ce fait à l’aide d’un chiffre nommé Port.

En tête UDP

Lors de l’étude des datagramme IP, nous avions vu le contenu de l’entête du paquet (partie verte). Ici,  nous allons observer le contenu de l’entête du message (partie jaune) lorsque l’on traite un paquet UDP.

Le paquet UDP est composé de 8 octets.

Les 2 premiers octets contiennent le port source. Codé sur 16 bits donc. C’est le numéro de port de l’émetteur du paquet. C’est aussi le numéro de port sur lequel le destinataire doit envoyer sa réponse.

Les octets 3 et 4 stockent le port de destination. C’est sur ce port que sera remis le paquet lors de sa livraison à la machine ciblée.

Le port étant un entier positif de 16 bits, on en déduit que les bornes sont 0 – 65535 (2^16). Cependant, le port 0 n’est pas exploitable.

Les octets 5 et 6 contiennent la longueur de l’entête UDP et du message. Sa longueur minimal est 8 (entête UDP avec 0 données à transporter) et sa longueur maximal 2^16 = 65535 (64ko).

Les 2 derniers octets contiennent le cheksum. C’est la somme de contrôle de l’entête UDP et des données qui suivent.

Ports réservés

Toute machine qui utilise la pile TCP/IP se doit de connaitre un certains nombre de services bien connus, aussi appelé « well known port number » pour pouvoir dialoguer avec les autres machines sur internet. Sur une machines Unix, cette liste est placée dans le fichier /etc/services et se doit d’être lisible par tous les utilisateurs et toutes les applications. Voici un extrait du contenu de ce fichier :

Nom             Port/Protocol     Commentaire

netstat		15/tcp
 qotd		17/tcp		quote
 msp		18/tcp		# message send protocol
 msp		18/udp
 chargen	19/tcp		ttytst source
 chargen	19/udp		ttytst source
 ftp-data	20/tcp
 ftp		21/tcp
 fsp		21/udp		fspd
 ssh		22/tcp		# SSH Remote Login Protocol
 ssh		22/udp
 telnet		23/tcp
 smtp		25/tcp		mail
 time		37/tcp		timserver
 time		37/udp		timserver
 rlp		39/udp		resource	# resource location
 nameserver	42/tcp		name		# IEN 116
 whois		43/tcp		nicname
 tacacs		49/tcp				# Login Host Protocol (TACACS)
 tacacs		49/udp
 re-mail-ck	50/tcp				# Remote Mail Checking Protocol
 re-mail-ck	50/udp
 domain		53/tcp				# name-domain server
 domain		53/udp
 mtp		57/tcp				# deprecated
 tacacs-ds	65/tcp				# TACACS-Database Service
 tacacs-ds	65/udp
 bootps		67/tcp				# BOOTP server
 bootps		67/udp
 bootpc		68/tcp				# BOOTP client
 bootpc		68/udp
 tftp		69/udp
 gopher		70/tcp				# Internet Gopher
 gopher		70/udp
 rje		77/tcp		netrjs
 finger		79/tcp
 www		80/tcp		http		# WorldWideWeb HTTP
 www		80/udp				# HyperText Transfer Protocol

Les ports 1 à 1023 sont réservés aux « well known ports ». Ils ne peuvent être utilisés que par des applications qui s’exécutent avec des droits privilégiés (root). Les autres ports peuvent être utilisés librement sans privilège particulier et sont en général employés par les applications clientes. Par exemple, sur ma machine, en ce moment, mon client IRC utilise le port 59175 pour communiquer avec le serveur irc holmes.freenode.net.

Mode non connecté

Contrairement à TCP, UDP est conçu pour permettre un échange de données entre 2 applications sans échange préliminaire. UDP est utilisé si les données à transmettre n’ont pas besoin d’être fragmentées en plusieurs paquet. La paquet est ainsi envoyé sans s’assurer qu’il arrive bien à destination. UDP est appelé mode de transport non connecté par opposition à TCP. Plus particulièrement, les paquets a destination d’une application UDP sont conservés dans une pile de type FIFO. Si l’application destinatrice ne les “consomme” pas assez rapidement, les plus anciens paquets risquent d’être écrasés par les plus récents… Un risque supplémentaire de perte de données.

Nous verrons comment TCP peut palier à ce problème dans la prochaine QRQVB

I -  Diagnostiquer soi-même

1 – La première étape est la collecte d’informations.

Si un programme plante ou ne fait pas ce qu’il est censé faire, il faut se poser et réfléchir calmement. Ouvrez un nouveau fichier dans votre éditeur de texte favori et écrivez-y ce que vous faisiez quand le problème est apparu ainsi que tous les messages d’erreurs reçus. Ces messages d’erreurs doivent être recopiés exactement tel qu’ils sont apparus. Utilisez le copier/coller si cela est possible.

Ouvrez un terminal et tapez tail /var/log/messages. Cette commande affichera les 10 dernières lignes des logs du système. Si celui ci contient un ou des messages qui sont clairement en rapport avec votre problème, recopiez les également. Les erreurs des applications graphiques sont en général dans le fichier .Xsession-errors ou .xsession-errors dans votre dossier /home. La commande pour visualiser les 10 dernières lignes est donc tail ~/.xsession-errors. Comme pour le fichier /var/log/messages, ajoutez les lignes en rapport avec votre problème dans votre fichier de départ.
Si vous n’avez trouvé aucune information dans ces fichiers, essayez de lancer l’application concernée depuis votre terminal. Lors de l’apparition du bug, des messages devraient s’afficher.

Si votre système ne démarre plus suite à un problème, démarrez alors sur une autre distribution (soit en dual-boot si vous en avez soit depuis un live-cd). Il est toujours bon d’avoir un live-cd sous la main pour ce genre d’opération. Une fois que vous avez démarré sur le live-cd, montez votre partition root et récupérez les informations dans les fichiers cités plus haut.

2 – Le problème est-il reproductible?

S’il est possible de reproduire le problème facilement, faites-le. N’oubliez pas de le faire sur des fichiers peu important ou sur une copie du fichier concerné afin de ne pas endommager vos données.

3 – Est-ce un problème matériel ?

Les problèmes non reproductibles sont souvent dus au matériel. Si vous pensez que c’est le cas, regardez alors dans le fichier /var/log/boot ainsi que /var/log/kern.log ou /var/log/kernel.log suivant votre distribution pour voir si le kernel reconnait bien votre matériel. Ce fichier étant très long, la commande tail ne vous sera pas d’un grand secours. Utilisez plutôt less /var/log/boot et parcourez les pages à la recherche d’un message en rapport avec votre problème. Recopiez également ce message dans votre fichier de départ.

4 – Lisez la documentation du programme.

Ceci est à faire en particulier si le programme ne réagit pas de la manière souhaitée. Lisez l’aide en ligne du programme et utilisez également le manuel universel (dans un terminal : man nom_du_programme).

5 – Recherchez votre message d’erreur sur internet

Copiez/collez le message d’erreur dans un moteur de recherche ou un meta-moteur tel que ixquick et ajoutez-y le nom du programme. Vous trouverez certainement des messages sur des forums d’utilisateurs qui ont le même problème que vous. Lisez le thread complet, vous y trouverez peut-être une solution.

6 – Réfléchissez avec logique

Si, arrivé ici, vous commencez à avoir une idée sur la cause du problème, vous pouvez peut être tester cette idée. Il y a beaucoup de petites commandes simples qui peuvent vous aider à recueillir plus d’informations sur votre problème et votre système, qui vont seront d’un grand secours. lspci pour lister votre matériel, lsusb pour lister les périphériques usb, cat /proc/cpuinfo pour avoir les caractéristiques de votre CPU, free -m pour connaitre le taux de charge de votre RAM

7 – Maintenant, vous pouvez penser à demander de l’aide.

Si après tout ça, vous n’avez toujours pas résolu votre problème, il est temps de demander de l’aide sur un forum d’utilisateurs. Avant de passer à cette étape, rappelez vous que les utilisateurs des forums ne sont pas payés pour répondre à vos questions. Ce sont seulement des utilisateurs ayant une certaine expérience et qui font cela bénévolement.

II – Obtenir de l’aide

1 – D’abord, observer

Commencez par choisir votre forum. Il est préférable dans un premier temps de choisir le forum de votre distribution, puis le forum du programme concerné. Si ce forum possède une FAQ, lisez-la. Lisez aussi les règles du forum. Si votre question ne respecte pas les règles, il y a de grandes chances pour que vous n’obteniez pas de réponse.

2 – Ne soyez pas hors-sujet

Trouvez le sous-forum qui correspond à votre problème. Ne postez pas votre message dans plusieurs sous-forums, ceci est très mal vu.

3 – Choisissez bien le titre de votre topic.

N’utilisez pas de sujet tel que « Besoin d’aide » ou « J’ai un problème ». Ceci a tendance à irriter les gens. Votre titre doit indiquer le plus clairement quel problème vous avez. Ainsi, une personne qui pense pouvoir vous aider sera plus encline à lire votre sujet et poster une réponse. Soyez aussi précis que possible. Par exemple « Impossible d’obtenir une adresse IP » sera plus utile que « Je n’arrive pas à aller sur internet ».

4 – Donnez des informations

Dans le corps de votre message, donnez le nom et la version de votre distribution, le nom et la version du programme utilisé et les informations sur votre matériel si cela est nécessaire. Recopiez-y aussi les messages d’erreurs (c’est là que le fichier que vous avez créé au devient utile). Indiquez ce que vous avez fait pour tenter de résoudre le problème. En faisant cela, vous montrerez aux autres que vous ne vous êtes pas jeté sur le forum dès que le problème est apparu.

5 – Pas de langage SMS

Ça saoule! Ça n’aide pas à vous faire comprendre et on vous répondra d’autant moins.

6 – Ne perdez pas une opportunité d’apprendre

Ne suivez pas les conseils aveuglément. Vous êtes ici pour apprendre quelque chose. Si on vous demande d’utiliser un outil en ligne de commande, utilisez les pages man pour savoir à quoi sert cet outil. Vous pourrez ensuite réutiliser cet outil si vous rencontrez un problème similaire. Si on vous demande de poster un fichier pour plus d’informations, recherchez l’utilité de ce fichier. Les fichiers systèmes importants possèdent souvent une page man dédiée.

7 – Dites merci

Les logiciels libres reposent sur la communauté. Personne n’est payé pour vous aider. Les personnes qui vous aident le font car elles ont elles-mêmes reçu de l’aide dans le passé et veulent rendre la pareille. En plus de dire merci, vous pouvez également aider les autres qui ne savent peut-être pas quelque chose que vous savez. Vous ressentirez alors une certaine satisfaction que les logiciels propriétaires ne peuvent vous apporter.

Décevant

Windows Millennium Edition

La dernière version de Windows qui tournait encore avec DOS. Tout ceux qui s’en sont approché ont pu voir l’ampleur de la catastrophe…

Windows Vista

Annoncé comme le système d’exploitation le plus cher en terme de développement, les résultats furent catastrophiques. Manque de pilotes, problème de compatibilité des logiciels, consommation de ressources excessive.

Netware 6.5

Avec e-Directory, le rêve inassouvi d’un concurrent direct à Active Directory de Microsoft.

Windows Mobile

Lorsque les PDA ont fusionné avec les téléphones portables, PALM, Symbian ont été dépassé par l’iPhone d’Apple. Dorénavant, l’iPhone est la cible à éliminer et Windows Mobile est loin derrière.

GNU Hurd

Le nec plus ultra du vaporware open source.

Les meilleurs

Windows Server 2008 R2

Avouons ici que c’est quand même un bon OS (si on met de coté le fait que le code soit fermé et malgré l’hilarante faille SMB2) et les entreprises lui font confiance.

Mac OS X

Ça juste marche! Les cotés positifs sont les graphismes et l’intégration. Les utilisateurs le trouvent intuitif et c’est ce qui fait son succès malgré le prix.

Solaris/OpenSolaris 10

Un autre cas d’excellence. Sun (bientôt Oracle) a construit un des dérivés Unix les plus fiable. De plus Solaris est devenue ouverte et relativement libre.

GNU/Linux (> 2.6.18)

Un noyau et des utilitaires libres, rapides et efficaces. Les distributions les plus populaires : Ubuntu, Novell / Suse, Mandriva, Fedora pour le desktop et Red Hat qui dominent le marchés des serveurs d’entreprises.

Google Android

Un système d’exploitation ouvert pour les téléphones ne fut pas facile à imposer. Google l’a fait.

Article original sur ITWorld