Juste un journal, pour dire que j'ai testé et approuvé l'excellent quickly ( https://launchpad.net/quickly ). Qui permet, en gros, de faire du RAD (rapid application deployment ;-). C'est "un peu" un assistance (à la manière django/ror) en ligne de commande, qui permet de créer un template d'application, avec tout qui va bien.
Le codeur a alors juste besoin de coder, et quickly s'occupe de tout le reste jusqu'à la publication du deb signé dans un repository (ppa/launchpad). C'est fichtrement efficace.
Difficile de faire plus pratique, pour développer une application pygtk sous ubuntu. (mais quickly sait et devrait pouvoir gérer d'autres templates, ce n'est pas fermer)
Pour tester la chose, je me suis lancer dans le développement/déploiement de 2 petits outils gpl, en pygtk. (en fait 2 outils maison que je n'avais jamais pris le temps de releaser, et c'est là : où quickly apporte vraiment un plus).
* FreeTP : http://www.manatlan.com/page/freetp
Frontend gtk qui permet d'uploader simplement des fichiers sur le système de partage de fichiers de free : dl.free.fr
* AutoWifi : http://www.manatlan.com/page/autowifi
Application gtk (en systray), qui surveille les SSID wifi, et tente de réaliser l'autologin sur les hotspots libres qui demandent une authentification par formulaire web. Pour l'instant, ça ne gère que les hotspots freewifi et fon (et ça marche !)/ Mais rajouter une gestion de hotspot est simple (système de plugin)
tout ça est dispo dans mon ppa : https://launchpad.net/~manatlan/+archive/ppa
Bon évidemment, pour le coup, c'est assez lié à ubuntu (debian). Mais quickly upload les versions sources, et par conséquent, ça ne devrait pas être trop complexe de packager ça pour d'autres distribs.
Bref, tout ça pour dire, que quickly est vraiment un concept intéressant, et qui facilite réellement les choses.
Journal [ubuntu inside] Quickly superbe ... et annonce : freetp et autowifi
8
fév.
2010
# FreeWIFI : sécurité ?
Posté par Julien04 (site web personnel) . Évalué à 10.
Concernant le login automatique sur le formulaire https FreeWIFI, tu vérifies le certificat https pour être sur de ne pas être sur un faux hotspot avant d'envoyer le login/pass ?
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 8.
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 4.
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 1.
[^] # Re: FreeWIFI : sécurité ?
Posté par ribwund . Évalué à 1.
Il faut que tu t'arranges pour que twill/mechanize accepte une librairie de socket modifié (ou alors tu monkeypatch urllib2).
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 3.
Mais je n'avais pas vu cette nouveauté 2.6 ... et il y a apparemment tout ce dont j'aurai besoin.
Pour résumer : il suffirait que :
- je récupère le certif (au format PEM) avec ssl.get_server_certificate( ("wifi.free.fr",443) )
- et que je le compare avec une version embedded
s'ils sont identiques : je suis assuré d'être au bon endroit
s'ils sont différents, c'est soit un portail captif, soit free qui a changé de certif
est-ce suffisant ?
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
le code est fait (avec verif certif fon/freewifi et fonctionne) suis prêt à releaser ...
suis pas à l'aise avec le ssl, mais je suppute que je récupère, avec ssl.get_server_certificate( ("wifi.free.fr",443) ), le certificat plublic de l'autorité de certif ... un hacker qui mettrait en place une page https, aurait peu de chance de se faire certifier par cette même autorité ... c'est ça ? ... alors est-ce suffisant ?
[^] # Re: FreeWIFI : sécurité ?
Posté par GeneralZod . Évalué à 2.
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
mais je sais pas où trouver le certif racine ...
du coup, je demandais juste si ma technique (tel que décrite plus haut) est valable et suffisante
[^] # Re: FreeWIFI : sécurité ?
Posté par GeneralZod . Évalué à 2.
https://www.verisign.com/support/roots.html
Ils sont également fournis avec la plupart des navigateurs, pour Firefox, c'est dans une base sqlite3 chiffré cert8.db. Tu peux manipuler la base avec les nss-tools ou les bindings python pour nss.
> du coup, je demandais juste si ma technique (tel que décrite plus haut) est valable et suffisante
Si tu as déjà le certificat racine, pourquoi coder à la main une fonction qui existe déjà ? À moins d'être un spécialiste de la sécurité, je ne me risquerais pas à un tel exercice à ta place.
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
donc si je comprends bien .... pour valider "wifi.free.fr"
je prends le CA racine de l'autorité de certif qui a signé le site wifi.free.fr ...
(il est là : https://www.geotrust.com/resources/root_certificates/certifi(...) )
et j'appel :
ssl.get_server_certificate( ("wifi.free.fr",443) , ca_certs = "Equifax_Secure_Global_eBusiness_CA-1.cer" )
si ça ne lance pas d'exception (validation failed) : je peux considérer que le serveur est OK ...
note : ça me retourne un certif ... qui est le même que si j'appel cette méthode sans l'argument "ca_certs" renseigné ... ça me perturbe un peu ... mais why not
tu confirmes ?
[^] # Re: FreeWIFI : sécurité ?
Posté par GeneralZod . Évalué à 2.
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
Je mettrai en place ces validations de certifs freewifi et fon ce soir
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
Si je comprends toujours bien, ce fichier contient l'ensemble des certificats racine des authorités de certifications.
Mais en fournissant cet ensemble de certificat, n'ai je pas plus de chance de tomber sur un gars qui aurait monté son "portail captif fake" en se faisant signer par une de ces autorités (genre cacert.org) ...
Et qui du coup, serait valider par la méthode python ...
car si je ne fourni qu'un fichier contenant l'unique certificat de l'autorité racine à laquelle je m'attends : j'aurai tendance à trouver ça plus secure .. non ?
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Ensuite je supposes que ton application est prévue pour fonctionner de manière générique. Donc faire confiance aux certificats que ta distribution à choisi d'avoir confiance c'est le meilleur moyen (en laissant la possibilité de changer ça pour l'utilisateur).
Finalement tu as aussi tous les certificats séparé dans ce même répertoire. Donc à toi de décider. Mais perso j'aimes bien qu'une application utilise ce que mon système au lieu de réinventer un Xème système. Surtout que l'utilisateur peut librement ajouter ou supprimer des certificats avec dpkg-reconfigure ca-certificates.
Mais si ça marche avec ta fonction, j'en sais rien. Mais je supposes qu'elle le fait.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
"ma fonction" (celle de ssl) et ce fichier CRT, devrait simuler globalement ce que fait un navigateur ... si j'ai bien tout compris.
Par conséquent, si un hacker fabrique un "portail captif fake" (pour s'amuser à récuperer les comptes freewifi), et qu'il a réussi à ce faire signer par un des certificats de ce paquet.
Je ne le verrai pas ...
En potassant wikipedia, sur la notion SSL, et clé privé / clé public. Si je veux être sure de garantir la véracité du portail authentifieur. J'utilise ce qui est dit précédemment, et je récupère les infos du certificats (qui qqpart, est la "clé public" en qqsorte)... et je vais contrôler que le certificat appartient bien à "free.fr" ... et là, si j'ai tout compris, la boucle et bouclé, et je suis certain de l'identité portail ... j'ai tout bon ?
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Sinon si un méchant arrive à flouter VeriSign, ... ou même cacert.org, tu peux rien faire. Il y a donc X.509 qui définit tous ces trucs avec CA, certificats et tous ça ... Donc soit tu t'en tiens et tu fais confiance aux autorités, soit tu fais ton propre truc. Mais bon je sais pas si tu es le plus qualifié pour décider qui est autorité de certification et qui ne l'est pas. Laisses ça à Debian/Ubuntu/Mozilla/... et contentes-toi de faire une bonne vérification.
Ensuite tu dois aussi vérifier les CRL, ta fonction elle le fait ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
je ne pense pas ...
mais je comprends bien qu'il faudrait le faire pour être exhaustif.
Je crois que je vais m'en tenir à ma première méthode.
Dans un reseau de confiance, je recupere le "certificat serveur" du vrai site https ... (celui signé par l'autorité de certif)
et dans autowifi, je vais juste comparer ce certif récupéré tantôt, avec le certificat serveur actuel du site https authentifieur.
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
mais je comprends bien qu'il faudrait le faire pour être exhaustif.
Si tu ne vérifies pas la CRL, ça sert à rien de faire la moindre vérification (à part consommer du temps processeur).
Sinon c'est pour le reste, si j'ai bien compris :
- Tu prends le certificat du site disons example.com
- Quand tu trouves un réseau wifi tu te connectes et tu récupères le certificat du serveur
- Tu compares les deux certificats.
Si c'est ça, autant rien faire. Le principe de X.509 c'est une autorité qui signe des certificats. Tu dois vérifier si le certificat est signé par une autorité (et en fait toute la chaîne jusqu'au certificat racine (parce qu'un autorité peut avoir signé une autorité qui elle signe une autre autorité qui elle signe un certificat) et si le nom donné par le certificat correspond au nom du serveur.
Ensuite tu vérifies la CRL de l'autorité (parce que si le type est un méchant qui a obtenu un certificat qui a ensuite été révoqué, c'est bien de le savoir).
Il faut aussi vérifier les contraintes du certificat.
Si le but est de vérifier un truc (bidon) pour dire qu'on a vérifié un truc, c'est inutile, autant ne rien vérifier.
Regardes la page 15 à 20 pour te rendre compte de toutes les astuces qu'il existe pour attaquer SSL : http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/B(...)
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
oui, ça fait peur ...
mais je ne peux pas non plus me permettre de vérifier toute la chaine, et la CRL aussi ...
Je veux bien utiliser les "certif racine des authorités" (du paquet debian) pour faire mon micmac (que tu as bien décris). Ca ajoute la couche "vérification du certif par les authorités". Et s'il venait a être révoqué, le racine dispaitrait du paquet debian (non ?), du coup c'est un peu comme testé la CRL, le côté live en moins.
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
le CA va recevoir des requêtes pour signature (CSR). Un fois ces requêtes signées, cela fait des certificats utilisables pour les fonctions prévues (les contraintes). La différence entre un CA et un certificat c'est le champs CA:FALSE ou CA:TRUE. Un CA c'est un certificat X.509 comme un certificat X.509 serveur, comme un certificat X.509 client, ...
La CRL c'est une liste qui contient les certificats révoqués par le l'autorité de certification, donc le CA. Celle-ci est signée par le CA et va contenir, grosso-modo, ça :
Certificat_avec_ID_1: revoqué: date: ...
Certificat_avec_ID_2: revoqué: date: ...
Certificat_avec_ID_3: revoqué: date: ...
Donc toi tu prends cette CRL, tu contrôle la signature (et la chaîne entière, en vérifiant tout (y compris CRL)).
Et un la revoquation d'un CA c'est un peu différent, si je ne me trompe pas :
Tu signes le nouveau CA avec le CA que tu va révoquer, tu créés une CRL signée avec le nouveau CA contenant l'ancien CA. Mais ça je suis pas sûr.
Donc c'est relativement lourd comme procédure, en effet, mais ne pas la mettre en place, c'est utilisé du SSL pour dire qu'on fait du SSL, mais c'est du SSL sans sécurité.
Tu peux regarder si un outil existe et fait ce travail ou une librairie (qui existe certainement).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
Tu as l'air de maîtriser le sujet.
Bon, j'ai releasé un 0.20 infinimment plus secure que les précédentes ! Mais qui ne l'est pas totallement non plus. Mais comme vu dans tes slides : ça ne semble quasiment pas possible de sécuriser tout ça de bout en bout.
elle contrôle :
- qu'on soit bien sur la page https du formulaire d'authent
- que le certificat server soit bien valide avec les certificats racines publiques des authorités de certification (via le package de certificat)
- et récupère ce dernier, pour le comparer bit à bit avec un original embedded.
Il n'y a pas de contrôle dans la CRL. Cependant, je me dis que si le certif de "fon" venait à être révoqué ... très vite fon remettrait un certificat ok (et il faudrait que je release une version dans la foulée, pour refonctionner (a cause du embedded)). Donc, pas la peine (pour mon cas) de mettre toute cette mécanique en place.
Après tout, ce n'est que pour protéger un login/motdepasse, que l'utilisateur peut révoquer à chaque instant (chez freewifi en tout cas), et qu'il faut changer régulièrement pour être sécure.
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par manatlan (site web personnel) . Évalué à 2.
mais dans mes recherches, j'ai bien compris que SSL ne garantissait qu'une seule chose : l'échange crypté ... et que les authorités de certifications c'était une vaste fumisterie, qui consistait à vendre du vent, car n'importe quel navigateur ou bout de code est capable d'accepter les certif "self-signed", et par conséquent le MITM a encore de beau jours devant lui. ( http://it.slashdot.org/article.pl?sid=08/06/24/2345223 )
et qques infos pythons pertinentes : http://www.heikkitoivonen.net/blog/2008/10/14/ssl-in-python-(...)
[^] # Re: FreeWIFI : sécurité ?
Posté par thedude . Évalué à 3.
Non, bien plus que ca.
Il garantit aussi la non alteration des donnees en cours de route.
Et il permet aussi d'identifier de facon sure les pairs de la communication (bien que le ssl client soit tres peu repandu, il est tout a fait possible).
et que les authorités de certifications c'était une vaste fumisterie, qui consistait à vendre du vent, car n'importe quel navigateur ou bout de code est capable d'accepter les certif "self-signed"
Un navigateur, ou n'importe quel applicatif qui accepte sans moufter un certif auto signe merite d'aller droit au bucher.
Apres, que l'utlisateur clique sur oui, oui, amenes moi au site de pr0n quand meme, c'est un autre probleme.
Les navigateurs maintenant sont vachement plus integristes sur les certifs signes par une autorite inconnue.
Ensuite, dire que Verisign et autres vendent du vent...
Oui et non.
Oui, parce que dans le fond, ils vendent pas grand chose (quoique...), ils vendent la signature d'un certif, c'est effectivement cher paye pour une serie de bits. Et encore, si tu savais combien on vendait une cle triple des generee aleatoirement dans mon ancienne boite, ca faisait sourire.
Non, parce qu'ils vendent une certaine confiance.
ClampinCA.org, maintenu par jean rene et guy sur leur temps libre, j'aurais un certain doute sur le fait que leur cle prive soit toujours privee.
Quand c'est verisign ou autre, ben le fait qu'aucun certificats delivres par ces gars la n'a pu etre spoofe, donc c'est que ca marche pas si mal que ca.
Mais ca reste une confiance qu'ils vendent, t'as parfaitement le droit de ne pas leur faire confiance, quand l'essentiel de l'industrie se repose sur les qq roots CA, ben on peut se dire que bon, doivent pas etre si clampins au final.
Apres, tu peux ne pas leur faire confiance, SSL marche toujours aussi bien, c'est ca qu'est beau.
, et par conséquent le MITM a encore de beau jours devant lui. ( http://it.slashdot.org/article.pl?sid=08/06/24/2345223 )
et qques infos pythons pertinentes : http://www.heikkitoivonen.net/blog/2008/10/14/ssl-in-python-(...)
Moui, alors du man in the middle synchrone sans faire hurler le soft client qui etablit la connexion, va falloir se lever tot quand meme...
On en revient au meme: si le client clique oui oui quand son soft lui dit que le site a qui il parle n'est pas forcement celui qu'il pretend etre, le probleme n'est pas trop dans le protocole.
Plutot dans l'utilisateur, ou dans le soft qui a une mauvaise facon de presenter le warning.
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
Verisign avait refilé un certificat de signature de code Microsoft a un type rien à voir. http://support.microsoft.com/kb/293817
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
C'est ça le travail de l'autorité de certification, de garantir que X est bien X. Donc tu as une confiance qui est établie comme ça. Ce n'est pas un réseau de confiance comme GPG, mais bien une hiérarchie de confiance. Il y a ceux au sommet qui font le travail pour garantir l'identité et après il signe le certificat. C'est comme ça que ta banque est reconnu comme ta banque et que personne peut venir s'interposer. Sinon ton navigateur met un message d'avertissement si le certificat n'est pas reconnu (par une autorité).
Ensuite pour mon site perso, l'authentification se fait à travers un certificat à moi que c'est moi qui est généré parce que je me fais confiance, le flux est crypté et c'est ça qui m'intéresse (et j'ajoute mon propre CA dans mon navigateur comme ça je suis avertit si mon certificat a été changé (donc si on m'a piraté)). Au travail on utilise aussi des CA "self-signed" (bien que j'aimerais passer à cacert.org, justement).
C'est donc pas "une vaste fumisterie" car le jour où ta banque produit une erreur, je te déconseille fortement de continuer, le système est perfectible (perso je suis pour qu'on puisse obtenir un CA signé par notre pays d'origine (gratuitement) et uniquement les pays soient au sommet de la hiérarchie. Quand tu reçois ton CA, il contient ton nom, prénom et un id. Ensuite tu peux générer tes certificats, ta banque peut t'authentifier par certificat, ... mon rêve quoi :-)
Sinon pour pycurl, je penses qu'il est intéressant d'utiliser ça. Peu importe s'il fait toutes les vérifications "aujourd'hui", demain il les fera peut-être. Vaut mieux se baser sur une librairie qui va forcément évoluer (ou pas de bol c'est celle qui disparaît :-).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par claudex . Évalué à 2.
La Belgique tend vers cela avec la carte d'identité électronique qui peut servir à signer des documents ou se connecter sur le site des impôts. Il existe même des lecteurs de carte compatible Linux. Pense à déménager pour réaliser ton rêve :-)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
Comme quoi supprimer le gouvernement de temps à autre, ça a du bon.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: FreeWIFI : sécurité ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 2.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: FreeWIFI : sécurité ?
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Centré, c'est le mot !
Posté par genesis83 . Évalué à 2.
[^] # Re: Centré, c'est le mot !
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
Ce qui est navrant, c'est que de belles innovations soient critiquées uniquement car elles sont faites sur Ubuntu par des utilisateurs d'Ubuntu.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Centré, c'est le mot !
Posté par genesis83 . Évalué à 3.
Si tu souhaites pouvoir l'utiliser hors d'ubuntu, tu dois patcher/forker.
DistUtilsExtra.auto.setup(name='quickly',
version="'%s'" % VERSION,
description='build new Ubuntu apps quickly',
long_description='Quickly enables for prospective programmer a way to easily build new ' \
'apps for Ubuntu based on templates and other systems for helping them ' \
'write their code in a guided manner. This also includes packaging and ' \
'deploying code.',
url='https://launchpad.net/quickly',
license="GPL v3",
author='Quickly Developer Team',
author_email='quickly@lists.launchpad.net',
cmdclass={'install': InstallAndUpdateDataDirectory}
)
[^] # Re: Centré, c'est le mot !
Posté par dinomasque . Évalué à 9.
Quand je pense à toutes ces ignobles qui développent des tas d'applications qui ne m'intéressent pas alors qu'ils pourraient utiliser plus judicieusement leur temps à développer les applications que j'utilise !
BeOS le faisait il y a 20 ans !
[^] # Re: Centré, c'est le mot !
Posté par genesis83 . Évalué à -1.
[^] # Re: Centré, c'est le mot !
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Centré, c'est le mot !
Posté par GeneralZod . Évalué à 8.
Le mainteneur de quickly, Rick Spencer travaille pour Canonical, d'ailleurs le copyright de quickly est assigné à Canonical. Même si quickly est réutilisable autre part, ça reste un projet très ubuntu-centric, fortement couplé à bazaar et Launchpad. À l'heure actuelle, quickly n'est pas architecturé pour être utilisable dans un autre contexte, pas de support de plugins, rien que l'intégration d'un autre VCS demanderait de réécrire une bonne partie de quickly.
Un des problèmes récurrents pour les packagers sont les applications exclusivement développés *pour* Ubuntu. Ça va du projet aux dépendances farfelues, du projet sans VCS, sans tarball juste des deb ("parce qu'il n'y a que des fichiers python", super pratique pour les autres !), au projet qui te dit carrément merde (chez XBMC, c'est limite un préalable à toute contribution)
Au bout d'un moment, il est normal que ça agace beaucoup de personnes.
Reste que quickly part d'une bonne idée : un générateur de templates d'applications desktop comme on peut en retrouver pour les applications web, avec une couche d'abstraction pour faciliter les choses pour les non programmeurs. Je le verrais bien en remplaçant de RAD type Visual Basic, et il couvrerait un réel besoin.
Une application sympathique développé par Jono Bacon à l'aide quickly :
https://wiki.ubuntu.com/Lernid
Le résultat est appréciable quand on sait que quickly n'existe que depuis près de 6 mois.
[^] # Re: Centré, c'est le mot !
Posté par manatlan (site web personnel) . Évalué à 2.
et c'est leur ferme de serveur qui s'occupe de packager les paquets correctement pour la cible. c'est assez bien golé.
[^] # Re: Centré, c'est le mot !
Posté par dinomasque . Évalué à 1.
BeOS le faisait il y a 20 ans !
[^] # Re: Centré, c'est le mot !
Posté par genesis83 . Évalué à 2.
[^] # Re: Centré, c'est le mot !
Posté par dinomasque . Évalué à 1.
Vas-tu t'insurger à chaque évolution de Qt parce qu'il ne permet que de faire des applications Qt alors que tu préfères les applications Java/GTK/Gnustep ?
BeOS le faisait il y a 20 ans !
[^] # Re: Centré, c'est le mot !
Posté par genesis83 . Évalué à 2.
[^] # Re: Centré, c'est le mot !
Posté par manatlan (site web personnel) . Évalué à -2.
et il faudrait que ce type ait également une vaste culture générale (de l'ordre de l'impossible)
ne rien faire non plus, car la tâche est énorme, n'est pas la solution. ça ne fait rien avancer !
alors, oui, ... il y a bien un gars, tout seul, qui a initié qqchose, tout en étant sponsorisé par canonical ... lui : il fait avancer "le bousin", quand même.
il est un peu normal, qu'il s'occupe principalement d'ubuntu qqpart.
il va pas coder quickly pour redhat tout en étant payé par canonical. C'est un non sens !
c'est terrible cette discrimination systématique envers ubuntu/canonical ...(qui contrairement à ce que tu dois certainement pensé : fait bien plus avancé linux / le libre que qui que ce soit d'autres ... en le rendant populaire (cercle vertueux))
si tu veux vraiment te plaindre ... plaind toi qu'il n'y a aucun développeur réellement libre, qui sur son temps libre, développe gratuitement/bénévolement un quickly ultra généraliste multi distribrutions, multi languages, multi gui, multi vcs ...avec la ferme de serveur qui va derrière pour réaliser les builds en realtime.
alors soit tu inities ce projet titanesque, soit tu aides le gars et apportent des patchs (voir en essayant de te faire sponsoriser par mandrake, redhat, ...)
sinon, je ne peux que te conseiler de passer à ubu ;-) ... ce n'est qu'une debian (la distrib mère par excellence) revampée après tout.
[^] # Re: Centré, c'est le mot !
Posté par zebra3 . Évalué à 5.
Pourtant, en un sens, Red Hat paye des développeurs pour coder pour Canonical, au travers du noyau Linux, de la libc, de GCC, de GNOME, etc
Est-ce que Canonical renvoie du code upstream dont Red Hat pourrait profiter ? Ben non, tout le dev d'Ubuntu est sur Launchpad.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Centré, c'est le mot !
Posté par genesis83 . Évalué à 2.
[^] # Re: Centré, c'est le mot !
Posté par imr . Évalué à 6.
[^] # Re: Centré, c'est le mot !
Posté par zebra3 . Évalué à 6.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Centré, c'est le mot !
Posté par manatlan (site web personnel) . Évalué à 2.
[^] # Re: Centré, c'est le mot !
Posté par GeneralZod . Évalué à 2.
Parce que c'est quasiment les seuls a avoir eu autant de problèmes, souvent des problèmes d'intégration qui auraient pu être facilement évités si les bras cassés en question avaient pris la peine de se renseigner auprès d'upstream.
http://0pointer.de/blog/projects/pa-in-ubuntu.html
[^] # Re: Centré, c'est le mot !
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Centré, c'est le mot !
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Je ne suis pas convaincu pas l'argument populiste, ça fait peut être avancer les parts de marché de linux, bien moins que ce que ne va faire google avec android/chromeOS, mais je suis nettement moins convaincu de l'impact pour le libre.
Combien d'utilisateur de firefox/vlc se fichent éperdument du libre et les fouetteront à la poubelle aussi tôt qu'une alternative privatrice offrira une avancée technique ?
Évidemment, c'est mieux si tout le monde utilise du libre, car cela aurait sans doute effectivement un impact positif sur la politique des revendeurs matériel, malheureusement la politique d'ubuntu si favorable à l'intégration de (micro)logiciels privateurs en annihile tout l'intérêt.
Bien sûr c'est une opinion très subjective, je ne prétend pas que cette politique ne peut aucunement conduire à de bonnes choses pour le libre, je n'en sais rien, mais j'en doute.
# RAD
Posté par georgeswwbush . Évalué à 1.
[^] # Re: RAD
Posté par Gniarf . Évalué à 3.
[^] # Re: RAD
Posté par manatlan (site web personnel) . Évalué à 3.
je sais bien ;-), c'était pour la joke ...
# Contournement du vrai problème
Posté par Octabrain . Évalué à -1.
blague mise à part, je trouve ça ridicule qu'on en soit réduit à "générer" du code template, pourquoi il a-t-il à le faire si il est toujours le même ? Le code prêt-à-coller, c'est une immense connerie. Je vais troller : c'est pour les devs J2EE qui savent juste faire clic-clic dans eclipse (voilà qui va plaire à ploum).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.