Au menu des nouveautés :
- Réécriture complète du code, passage de PHP à Python avec Twisted Matrix ;
- Génération à la volée de diagrammes et de camemberts, au souhait de l'utilisateur ;
- Personnalisation totale de la page d'accueil, pour chaque utilisateur ;
- Refonte de l'ergonomie de l'outil et de la manipulation des critères d'affichage des connexions réseaux ;
- Possibilités de recherches beaucoup plus avancées ;
- Export des données affichées en CSV pour traitement personnalisé ;
- Passage à la licence GPLv3.
Bien entendu, Nulog2, permet, comme la v1, d'exploiter des logs authentifiés par un pare-feu NuFW. Il est donc très simple de créer ses propres indicateurs à placer sur sa page d'accueil, par exemple "Histogramme des derniers paquets droppés des trois dernières heures de l'IP 10.56.140.47 ou de l'utilisateur Martin". Nulog2 est intégré au liveCD NuFW.Live, sortie en RC1 le 17 janvier 2008. Ce liveCD de démonstration de NuFW et des outils associés (et donc entre autres Nulog) est distribué par INL pour faciliter les tests de NuFW et des outils associés. Les éventuels retours de testeurs seront donc les bienvenus par l'équipe de développement !
Bien sûr, Nulog2 est conçu pour fonctionner pour des pare-feus authentifiants NuFW, mais s'interface également très bien sur des pare-feu Netfilter sans authentification.
Nulog2 sera également présenté sur le stand d'INL au salon Solutions Linux.
Aller plus loin
- Page d'accueil de Nulog2 (280 clics)
- Captures d'écran de Nulog2 (176 clics)
- Projet NuFW (135 clics)
- NuFW.live : le LiveCD de NuFW (48 clics)
- INL : concepteur et auteur de l'application (44 clics)
- L'annonce linuxfr de la alpha1 (15 clics)
# paquet Debian
Posté par err404 (site web personnel) . Évalué à 2.
malgré l'indication 2.0 il s'agirait tout de même de la version 1 ?
et le tilde il signifie quoi dans tout ça ?
[^] # Re: paquet Debian
Posté par Misc (site web personnel) . Évalué à 2.
cf http://www.debian.org/doc/debian-policy/ch-controlfields.htm(...)
Je pense que les devs debian pourront mieux expliquer que moi.
[^] # Re: paquet Debian
Posté par _pollux_ (site web personnel) . Évalué à 5.
Le tilde est utilisé parce que le caractère - sert a différencier le numéro du paquet debian, du numéro de l'application.
En gros, x.y-1 et x.y-2 c'est la même application (même sources), c'est juste le packaging qui est différent.
# De PHP à un framework Python
Posté par forc3 . Évalué à 3.
J'aurais bien voulu connaître la motivation de quitter PHP pour aller vers Python ?
Choix technologique ?
Changement de développeurs ?
Le retour d'expérience pourrait être utile à tout le monde...
[^] # Re: De PHP à un framework Python
Posté par Misc (site web personnel) . Évalué à 3.
La vérité sort de la bouche des infobots :
11:35:29| misc> blame php
11:35:30| fajita> blame php is PHP should be presumed to be at fault until conclusively proven otherwise. And even thereafter, if it's convenient.
fajita étant le bot du canal #apache et #apache-fr :)
( sinon, le fait de devoir maintenir un soft en php4 et php5 ( support sarge et etch et distro récentes en même temps), le fait que php ne soit pas si génial que ça comme language avec de nombreux effets de bord, le fait qu'il y a rien de la puissance de twisted en php sont à mon avis des arguments plus plausibles )
[^] # Re: De PHP à un framework Python
Posté par Eric Leblond (site web personnel) . Évalué à 10.
le passage d'un langage à un framework
le passage de PHP à Python
Le choix 1 est simple : J'ai commencé à travaillé sur nulog 1 (connu comme ulog-php à l'époque) aux alentours de 2001/2002 . La notion de framework n'était pas encore bien implantée (voir même n'existait pas). Début 2007, nulog commençait à devenir difficille à faire évoluer et nous avons donc décidé de lancer un projet de réécriture au sein d'INL (dont je fais parti). Le projet Nulog 2 a ainsi été initié avec dès le départ la décision d'utiliser un framework et une architecture MVC.
Le choix 2 s'explique par plusieurs points:
Grandes qualités du framework Twisted, notamment capacité à offrir des vues dans des protocoles variés (SOAP, XML-RPC, IRC, HTTP).
Présence de bons développeurs Python à INL, développeurs capable d'épauler Romain Bignon, développeur principal de Nulog 2.
Langage PHP trop laxiste et surtout lié au web alors que l'on souhaitait ne pas se limiter à ce media.
L'ensemble de ces raisons nous ont fait abandonner PHP pour passer à Python/Twisted.
[^] # Re: De PHP à un framework Python
Posté par Jul (site web personnel) . Évalué à 1.
ex :
sur deux PHP 5.3.2 j'ai eu les changements de comportements différents sur le même code :
cas 1 trim change de comportement :
$a=array ("a " => array ( "b" => " c ") );
v1 : trim ($a) => array ("a" => array ("b" => "c" ))
v2 : trim ($a) => array
cas 2 implicit explicite :
avec mes php.ini identiques j'ai eu le code suivant qui a marché un cas sur deux
class log {
private $cfg;
private function w($msg) { $cfg["insource"] && echo "<!-- $msg -->" }
}
Dans un cas php a pardonné que j'oublie $this->cfg
dans l'autre il a fait un warning sans crasher :/ J'aurais mis du temps à trouver le bug si j'avais pas regardé les logs
Et j'ai un 3 éme bug sur le changement de comportement des fonctions de localisation que je ne détaillerais pas.
Et ceci sur deux versions de PHP identiques sauf au niveau du patchlevel :/
Donc même si il y a des frameworks (cake/symfony) en php je pourrais pas faire entièrement faire confiance à un framework aussi bon soit-il quand l'interpréteur est aussi versatile.
PS ce n'est pas parce qu'en logiciel libre on utilisait pas le jargon de framework au début que
1) il n'existait pas (leur existence remonte à 1990 notamment dans les GUI notamment propriétaire, et dans la littérature dans les années 1986),
2) le MVC est un design pattern : une façon de concevoir son code en séparant la vue des données. Un DP ne nécessite pas de code normalement, juste de bien concevoir son code. Mais bon quand il y a un "cadriciel ou framework" faut être maso pour s'en priver.
[^] # Re: De PHP à un framework Python
Posté par Jérôme FIX (site web personnel) . Évalué à 3.
$a=array ("a " => array ( "b" => " c ") );
v1 : trim ($a) => array ("a" => array ("b" => "c" ))
v2 : trim ($a) => array
D'un autre côté, trim attend une chaîne de caractères en paramètre, tu lui passes un tableau.
Ok il devrait te jeter plutôt que de faire une conversion implicite du tableau en chaîne de caractères; ce qu'il fait d'ailleurs si tu actives le niveau d'erreur :
Notice: Array to string conversion in /var/www/html/test.php on line 4
Call Stack:
0.0002 92264 1. {main}() /var/www/html/test.php:0
0.0003 93208 2. trim() /var/www/html/test.php:4
Donc l'erreur est encore une fois entre la chaise et le clavier.
Concernant la différence entre tes deux installations ... est tu vraiment sûr que ce sont les mêmes avec les mêmes options de compilation, la même configuration.
[^] # Re: De PHP à un framework Python
Posté par Jul (site web personnel) . Évalué à 1.
Pour les options de compilations j'ai pas regardé. C'étaient 2 debian, mais je soupçonne que les sources apt étaient pas les même. Le projet étant charrette, et devant gérer des merdouilles sièges clavier (mienne comprises) tout le temps, le sysadmin qui sommeille au fond de moi n'a pas pu investiguer.
Néanmoins, même si j'aurais bien aimé comprendre, après m'en être ouvert à d'autres anciens collègues qui ont quitté le PHP j'ai eu des échos de soucis similaires.
[^] # Re: De PHP à un framework Python
Posté par Jérôme FIX (site web personnel) . Évalué à 3.
[^] # Re: De PHP à un framework Python
Posté par Jul (site web personnel) . Évalué à -4.
Il est donc pas fiable => death penalty
[^] # Re: De PHP à un framework Python
Posté par desfrenes (site web personnel) . Évalué à 2.
;-)
[^] # Re: De PHP à un framework Python
Posté par Jul (site web personnel) . Évalué à -3.
PS j'ai pas pris apache 2 car je comprend tellement pas la licence que je suis même pas sûr que ce soit libre.
[^] # Re: De PHP à un framework Python
Posté par Misc (site web personnel) . Évalué à 6.
Ensuite, la license apache v2 est approuvé par l'osi, par debian, et elle est compatible gpl v3.
Et elle est aussi sur la liste de la fsf : http://www.gnu.org/licenses/license-list.html
Pour un type qui marque : "Je n'ai aucun soucis pour travailler dans des environnements et des technologies non libre." sur son site web ( http://corpo.julbox.net/ ), je reconnait que ce genre de remarques me laissent dubitatif.
[^] # Re: De PHP à un framework Python
Posté par Jul (site web personnel) . Évalué à 0.
Pour apache comme pour tout autre licence, je ne vais pas prendre une licence que je ne comprend pas. Un point c'est tout.
Et oui je fais du perl ou du php en environnement windows, mais je préfère aller confronter les logiciels libres en environnement de prod réel que faire des grands blablas sur la supériorité du libre. J'aime bien quand un client qui fait du c# se dit que lui aussi peut faire des projets libre ou en utiliser, ou que perl est peut être mieux que MS visual C++ pour développer. C'est sûrement plus dur que de convaincre un passionné du libre, et plus gratifiant quand on y arrive.
Tiens d'ailleurs tu remarqueras que python a une implémentation libre en .net éditée, maintenue financée par microsoft.
http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPytho(...)
Les développeurs en technologie proprio s'y mettent, et ça ne me dérange pas. Car le libre n'est pas seulement dans la licence, ça consiste aussi et surtout à partager ses sources, à permettre d'utiliser, d'étudier, et de redistribuer. Alors que ce soit sous windows, mac, linux, que ce soit en perl, en ruby, en php en c#, je m'en fous.
Voilà je suis pragmatique avant tout, et cela ne me pose pas de problème. Quand j'ai pas confiance dans quelque chose, je le surveille, je le cloisonne, jusqu'à ce que j'ai mieux.
En ce qui me concerne je commence à trouver des imperfections à tous les langages, à tous les OS, et je fais avec.
[^] # Re: De PHP à un framework Python
Posté par Jul (site web personnel) . Évalué à 1.
http://www.codeplex.com/
Dont le pré-requis est :
you MUST choose a licence, et les licences proposées inclues les licences OSI (sauf gpl v3)
Et la licence du service :
http://www.codeplex.com/CodePlex/license
stipule que microsoft ne se donne aucun droit sur la création.
Enfin, si faire du libre ça veut dire mépriser ceux qui font du libre en java, en csharp ou autre, on va peut être devenir sectaire, parce que la je vois pas où dans le libre il est dit que le logiciel libre doit être fait avec des technos "garanties 100% libre". Surtout que cela peut être sujet à caution (les cpus intel sont pas libre, les comité de normalisation ISO/IEEE/mpeg sont pas très ouverts ....)
[^] # Re: De PHP à un framework Python
Posté par Antoine . Évalué à 1.
[^] # Re: De PHP à un framework Python
Posté par Gniarf . Évalué à 2.
[^] # Re: De PHP à un framework Python
Posté par Antoine . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.