Sytoka Modon a écrit 4551 commentaires

Pas FTP ! FTP n'a rien a voir avec SSH…

SFTP, c'est du SSH avec les commandes FTP/ Bref, presque du sucre syntaxique autour de scp…

L'évolution sécurisé du FTP est le FTPS qui comme le HTTP consiste, en simplifiant, a enrober le FTP dans une chaussette SSL. Il pose bien moins de soucis que le FTP car il n'utilise qu'un seul port.

rien que le volume revendu par un revendeur va faire qu'il n'aura pas les memes prix à la source

Le problème est là, CISCO choisi son pousse carton pour le marché A et lui fait un prix sur ce marché. Sur un autre, il choisit un autre pousse carton et ainsi de suite. En vérité, une grande partie des pousses carton se vaut sur le sujet sinon pourquoi celui-ci sur Orsay, celui-là à Rennes…

Au final, tu n'as aucun choix car CISCO impose celui qu'il a choisit selon ses propres critères bien évidement non public.

Ce système, plusieurs fournisseurs me l'ont confirmé à l'oral par téléphone en les travaillant un peu. Évidement, je n'ai aucune preuve écrite !

Il y a aussi le FTPS. Par rapport au SSH, il ne fais que cela…

Et en plus, dans les marchés public, ils contournent la loi en décidant qui aura tel ou tel marché… En effet, ils décident de manière complètement opaque le fournisseur qui sur le marché X ou Y aura un prix moins chère que les autres et à ma connaissance, il y en a toujours qu'un !

Je parlais de la doc intégrée dans le code source Perl. C'est pas du POD, il y a (de tête) des @class, @apmethod et autre…

A noter que c'est programmé en Perl et, au vu des quelques fichiers que j'ai parcouru, cela me semble du Perl propre et particulièrement lisible.

Question, vous utilisez quelle moulinette pour générer la doc car il me semble clair que les commentaires sont loin d'être idiot et in-structuré ;-)

Il faut rappeler quand même que l'Europe (UE) n'est pas concerné car les brevet logiciels ne sont pas valides sur ce territoire. Les distributions et les grandes fondations feraient bien d'avoir des dépôts physiquement en Europe afin de leur simplifier la vie ;-)

Vive le vieux continent !

Ne pas mélanger protocole et port, on met le port plus loin sur la ligne.

Comme pkg attend un site web particulier, un peu comme les archives .deb, http est le transport mais en face, ce n'est pas un site comme un autre, c'est une base de données bien organisée.

Personnellement, j'aurais pris un autre champ SRV afin de laisser le _http au site web du projet…

Enfin, le jour ou CISCO arrêtera de faire au minimum x10 sur le prix de ses transeivers, j'aurais un peu plus de respect pour cette boite…

Dans le cadre de XMPP, on a (voir http://wiki.xmpp.org/web/SRV_Records)

_xmpp-client._tcp.example.net. TTL IN SRV priority weight port target
_xmpp-server._tcp.example.net. TTL IN SRV priority weight port target

Le choix est expliqué ? Je serais plutôt parti sur

_pkg-server._tcp.pkg.freebsd.org. 60  IN  SRV 10 10 80 pkg0.bme.freebsd.org.

Afin de ne pas toucher au _http…

Sur la démo, il y a un truc que je n'aime pas, les boutons suivants et précédents change de place selon la taille de la photo… Personnellement, je n'aime que les albums ou je met ma souris sur suivant et clique sans réfléchir ;-)

GTK n'est pas GNOME…

Il faut arrêter de tout vouloir optimiser au caractère près et croire que tous les développeurs ne basculeraient pas, pour trois touches, sur un système lisible. De plus, une partie des Makefiles sont crées automatiquement…

target:
 -> @cc -o target.o $(OBJS)

Le gros avantage, c'est qu'on voit si c'est dans le même shell ou non…

target:
 -> @cc -o target.o \
    $(OBJS)
 -> @echo toto

En plus, pour éviter l'arobase en début de ligne, on pourrait avoir deux types de flèches… Bref, c'est juste une proposition pour avoir un truc plus lisible pour un coût faible.

TIMTOWTDI ;-)

La proposition a tout de même été porté par Damian Conway, c'est pas de moi. De plus 'unless' et 'if not' ont exactement la même longueur. L'idée est la même qu'en français, éviter si possible les phrases interro-négative et sinon, essayer d'être le plus clair possible.

d'utiliser la tabulation pour les commandes dans les makefiles

Il est clair que c'est une énorme boulette MAIS elle aurait pu être corrigée depuis longtemps. Par exemple, il aurait été facile de faire une règle telle que

s/^\s*->\s*/\t/

En gros, toute ligne commençant par '->' est équivalente à une ligne commençant par une tabulation. Au bout d'une dizaine d'année, la tabulation aurait petit à petit disparu et un jour, on aurait pu la rendre obsolète. Pas mal d'année de perdus…

next unless ($file =~ /^morgue.*\.txt$/);

Selon certain, le 'unless' est une fonction peu connue en dehors de perl donc il est parfois conseiller d'écrire

next if not $file =~ /^morgue.*\.txt$/;

En perl, les parenthèses qui ne servent pas, je ne les mets pas ;-)

Il est préférable de spécifier que l'on souhaite ouvrir en mode lecture seule.

open(my $file, '<', "path/to/file");

Généralement, on fait un "open() or die…"

Je pensais que c'étais dans C++14 mais déjà dans gcc… J'ai un train de -- ;-)

Peut être voulait'il parler de l'AD ;-)

Si on veut limiter les problèmes et simplifier la programmation fortement concurrente, il est important que les variables soient par défaut immutable comme en Erlang. La déclaration explicite ici me semble une très bonne chose. Ensuite, pour la performance, il faut parfois savoir aussi éviter les copies, comme le futur 'move' du C++ et le tout mutable par adresse du Fortran. Bref, pas facile de construire un langage équilibré mais pour le web et la robustesse aux threads et autres coroutines, l'immutable par défaut me semble de plus en plus une bonne approche.

C'est aussi une approche très fonctionnelle écrite avec une typo plus déclarative !

Oui, enfin j'attends toujours Catia et Soliworks sous GNU/Linux… Quand à Ansys, leur merde de Workbench tourne mal car c'est du .NET 32 bits qui tourne via un émulateur (oui, ils osent vendre cela dans leur coffret Linux).

c'est standard pour connecter à n'importe quel base de données et il y a des environnements pour le web qui font une grosse partie du boulot. Par exemple, Mojolicious est un (il y en a d'autres) framework à la mode. Je suis tombé l'autre jour sur cette petite application qui ne sers pas à grand chose mais donne un exemple intéressant coté code.

https://github.com/ldidry/lstu/

Cela donne cela en pratique

http://lstu.fiat-tux.fr/

En Perl, je n'utilise comme la plupart des personnes QUE des modules dans le CPAN. Le CPAN est un outil collaboratif, un des premiers réseaux social dédié (après le CTAN). Donc tu utilises pour ton module (bibliothèque) la même licence que Perl c'est à dire GPL + Perl Artistic. Ainsi, le CPAN grossit, est libre et cohérent et on ne se pose pas la question de la licence pour les bibliothèques. C'est une zone de grand partage réutilisable par tous.

L'écosystème de Python me semble bien plus répartis. Avec PIP, il télécharge les paquets on ne sais trop ou et les installe.

Voila, je me positionne face a un écosystème existant, je ne cherche pas à comparer ici les licences libres.

C'est un peu le soucis de Python… Avec Perl, tu upload ton module sur le CPAN et comme tout le monde, tu met la licence Perl (Artistic) et ca va bien.

Il n'empêche, NX et X2GO marche super bien… Il faut aussi avoir l'honnêteté de dire que certaine chose marche bien.