Anonyme a écrit 62265 commentaires

Ils sont un peu gentils, donc on peut utiliser leur système propriétaire sans aucune contradiction ? Et Google et Netflix aussi libèrent des morceaux de leur infrastructure, donc on peut utiliser leurs services sans se poser de questions de dépendances technologiques ?

Personne n'a dit qu'il ne fallait pas se poser de questions de dépendances technologiques. Mais tout ca n'a rien à voir avec la question de "est ce que c'est libre ou pas".

Un service d'hebergement basé sur un logiciel libre ne permet pas automatiquement d'exporter ses données pour les migrer ailleurs. Alors qu'un autre comme github peut permettre de tout exporter.

C'est bien joli tout ça, mais tu as tort. Pour le coup c'est toi qui ne voit qu'une partie de github. Parce que github c'est aussi Github enterprise que tu peux héberger chez toi, sur ton infrastructure (et maintenant aussi su AWS)

En l'ocurrence, le code de .NET est sur github.com, pas sur un Github enterprise.

Github est aussi fait pour tourner sur des serveurs "perso" et non uniquement sur l'infra "grand public" de github.

Non. La societé Github develope un logiciel fait pour tourner sur des serveurs perso, mais ca n'est pas ce qui est utilisé sur github.com.

Il n'empêche que ça fait beaucoup de projets libres qui reposent d'une façon essentielle¹ sur un logiciel propriétaire.

Ils ne reposent pas sur un logiciel proprietaire, mais un service d'hebergement de dépot git.

Mais les developeurs de projets libres reposent egalement sur d'autre services:
- une connexion internet: le FAI utilise il des routeurs libres ?
- de l'electricité: est elle produite par des centrales libres ?

"non mais git c'est décentralisé, ce choix est sans conséquence"; vrai, jusqu'au jour où tu utilises leur bugtracker, leur wiki, leur API pour envoyer des mails sur ta mailing-list, et ce jour arrive très très vite. On peut migrer mais c'est beaucoup de difficultés.

Tout cela n'a rien à voir avec le fait que le service soit basé sur un logiciel libre ou pas.

Entre un wiki hebergé sur un mediawiki, et un wiki hebergé par github, le plus simple à forker sera celui qui est sur github: il y a un dépot git contenant l'historique du wiki qui peut etre cloné par n'importe qui, alors que dans le cas du mediawiki, il faudrat demander à l'admin du serveur un export de la base de données.

d'autant que considérer un service centralisé comme pouvant être libre est un non-sens, de part justement sa nature centralisé.

Effectivement. Et meme si il était décentralisé en fait. Par ce que "service libre", ca ne veut rien dire.

Ai je la possibilité de modifier le service ? Generalement, le mot de passe root permettant d'acceder aux serveurs du service n'est pas fournit.

http://linuxfr.org/nodes/103583/comments/1567357

Je suis assez d'accord et j'irai même jusqu'à dire que Github de part sa politique commerciale a fait bien plus pour le libre que ce que la plupart seraient amené à penser.

Du coup c'est vrai que ça m'agace assez de lire ce genre de critiques sur github, d'autant que considérer un service centralisé comme pouvant être libre est un non-sens, de part justement sa nature centralisé.

J’ai fais un peu de VHDL, en DUT. Pas de Verilog. Mais ce que j’en ai ressorti, c’est qu’il faut complètement revoir sa façon de travailler… alors pour un débutant je crois que Verilog ou VHDL ne fera pas de différence : il faut changer sa façon de voir la programmation.

Comme je n’avais alors jamais rien fait d’autre que du procédural et objet… je n’ai compris qu’à la fin du projet d’électronique -.-

Le fait que tu sois obligé de modifier les propos de ton adversaire prouve que tu as tort.

On n’est pas en train de parler d’un État, du pouvoir qu’à le peuple ou des droits et devoirs qu’il ne peut outrepasser, on parle de Debian.

Github fonctionne très bien avec Tor, j'utilise mon compte github principalement avec Tor sans que ca pose de problème particulier. Et pour la vie privée, il me semble qu'il n'y a pas d'obligation à donner son vrai nom pour créer un compte.

Sauf que tu as dit une connerie pour faire une analogie : « il faudrait voter que tous les paquets compilent obligatoirement sur toutes les architectures », ce à quoi il a répondu : « quand ce n’est pas le cas, le mainteneur se voit assigner un bug report qu’il va s’efforcer de corriger ».

En réalité, on voit qu’il n’y a que très peu de paquets (en proportion en tout cas) qui ne sont pas disponible sur tout les architecture. Si on regarde dans le détail, je suis sûr que c’est les même paquets qui ne sont disponible que sur i386 et adm64. Autre exemple, je suppose que les paquets linux-image-generic ne sont pas disponible sur debian-kfreebsd.

Il me semble qu'il existait un projet visant à maintenir la continuité de testing après son gel, seulement je ne parviens pas à retrouver de la documentation dessus et je ne sais pas si ce projet est toujours d'actualité ou non.

Cela dit, il ne me semblait pas que Sid était également gelé lors du gel de Testing, Pour avoir utilisé Sid pendant un moment, il m'a toujours semblé que les paquets continuaient à arriver dedans sans que la migration vers Testing ne se fasse tout bêtement.

Pour etre précis, license CC-BY-NC-SA.

Franchement, tu aurais pu parler de JSON à la place de XML, c’est quand même bien plus sexe :P

Un OS non, mais la société qui édite une distribution basée sur un OS oui.

Et si ce que Samuel nous a indiqué dans un autre journal est vrai, il semblerait qu'au niveau des structures importantes en termes économiques ou administratifs, seules les distributions linux proposant des certifications pour des conditions matérielles et logicielles spécifiques sont aptes à prétendre se faire une place chez eux.

Redhat est une société tamponnée USA et SuSe une société tamponnée Deutschland.

Connaissant la nature habituelle des journaux du sieur Pajilewski, il y a fort à parier que c'est la société teutonne qui a
remporté le marché. Du coup il est légitime de se poser la question des avantages que peut voir le DoD dans une distribution telle que SuSe pour supplanter la suprématie d'une distribution bien de chez eux.

A moins que le tamponnage USA de SGI leur ait suffit.

D'ailleurs si tu as des infos à ce sujet Samuel, merci de faire tourner.

Autorité de certification commerciale […] Aucun contact direct

C'est valable pour beaucoup de certificats SSL
Les certificats du type DV (Domain Validated) tout automatique avec la procédure que tu as indiqué mais , dès que tu demandes des certificats du type OV (Organisation validated) alors la les choses se compliquent avec justification juridique de l'organisation.
Ensuite les certificats EV, pareil, les contrôles sont plus fins, requête OCSP a chaque connexion sur le site … c'est pas mal.
Ensuite les certificats avec des niveau de RGS, et, il me semble, que c'est qu'a partir du 2* que la remise en face a face a lieu. Les contrôles sont a chaque niveau de plus en plus fins et forcement les coûts de délivrance sont de plus en plus élevés, mais des assurances sont liées :-)
Tout ca étant reconnu dans les navigateurs web bien entendu !
Alors, ce n'est pas parce que c'est commercial que c'est mal, faut bien payer les gens qui font les contrôles et ca prends beaucoup de temps.

Et grep avec son ami sort, ils puent de la gueule  ?

<humour anti systemd ;) >


perl6 ca n'est pas une évolution de perl5, c'est un autre language (pour l'instant encore experimental, mais il n'y a pas d'urgence). En ce qui concerne perl5, il continue d'évoluer et fonctionne toujours aussi bien.

Opentrust, certeurope, certinomis par exemple … Ce sont des ACs françaises pur jus !

demander le soutien d'un AC certifiée française et se faire offrir un certificat.

sinon une bonne lecture de man bash/sh/ksh devrait te mettre sur la voie pour la ligne d'erreur à effacer

Ouais, ouais ok, la plupart ne sont pas genant. Il y a des solutions donne, Tiens je me souviens d un bug genant, une version ISO de debian avait oubliez grub et lilo sur le cd1, vraiment casse bonbon !

Sans doute une réference au Perl Golf:
http://c2.com/cgi/wiki?PerlGolf

certe mais c'est pas super user friendly pour ne pas tout casser :).

tu as un exemple de bug gênant ?

3.ne pas attendre trop longtemps entre les mise à jour, sinon risque de conflit majeur entre 2 ou plus version.

faisable oui, humain non