ben pas moi, en fait toute l'information est masquée au milieu de définitions et noms de classes qui ne servent pas à grand chose...
En fait toutes ces définitions sont contenues dans =~ mais forcément si on ne le connaît pas on ne comprend pas et on doit "deviner" ce que le programme fait.
Par contre si on apprend cet opérateur ben c'est concis _et_ clair
> Que les paramètres reçus par une méthode ne peuvent pas évoluer au sein de la méthode ??? Première nouvelle !
non, mais que si tu passes un int en paramètre dans une fonction il n'est pas possible de modifier sa valeur dans la fonction et que cette valeur soit visible en dehors, au retour.
En gros passer des références quoi...
> T'as le droit de créer des listes (et de les faire renvoyer par la méthode), tu sais ?
oué donc je retourne une liste (il faut donc la créer avant de le retourner, ajouter les valeurs, etc) et au retrour je lis ma liste et extrait toutes les valeurs...
je pense oui que c'est l'habitude.
Java étant assez pauvre, il est facile (mais fastidieux) à lire
Par contre, souvent les programmes en perl vont utiliser beaucoup plus de mot clés (tous les $* par exemple) en plus avec de l'implicite (qui ne pose pas de problème sauf si on en a jamais recontré) et donc forcément c'est plus compliqué si on est pas habitué
mais bon, comme tous les langages faut les apprendre pour les comprendre...
jsute parce que javascript aussi est intéressant comme langage, et permet aussi de s'amuser (un peu) avec les regexp.
Si on prend ton premier exemple de code, ça donnerait :
if(/(\w+)=(\d+)/.test(line)) {
ident = RegExp.$1;
value = RegExp.$2;
}
Autant dire que j'adore le fait d'avoir la regexp entre / / vue comme un objet
Sinon il est vrai que perl c'est bien, mangez-en !
Apprendre perl est assez intéressant, et comme beaucoup une fois qu'on a gouté aux hash à gogo, c'est sympa pour beaucoup de choses.
Mais pour ma part j'ai remplacé tout ce que je faisais en perl pour du ruby. Tous mes scripts annexes tournent en ruby (j'entend par là tout ce qui touche à mes sources, préprocesseurs, rapports, stats, build, etc)
Pour ce qui concerne java, pour en faire de temps en temps, je trouve aussi que c'est un mauvais langage. Ok l'ensemble de lib est intéressant, mais le langage ... beurk.
Il faut toujours écrire beaucoup trop de choses pour avoir un truc sympa, il est trop rigide, et surtout trop pauvre. Les collections sont pas très sympa à manipuler (sauf depuis le 1.6 si je ne me trompe et foreach).
En fait, le langage java est lourd, trop compliqué car inutilement pauvre.
Il parait que ça s'améliore un peu, les annotations sont quand même quelque chose de sympa (même si ça existe ailleurs) mais bon...
impossible de retourner par exemple facilement un liste de valeurs. Si une méthode doit retourner plusieurs valeurs, il faut forcément passer par une structure dédiée (si on veut pas avoir des tableaux partout comme on trouve parfois...)
De même je crois qu'on ne peut pas passer de paramètre modifiable en java...
je crois que t'as eu raison de choisir le vendredi :
> Le clou de la réunion était une chose appelée Ubuntu et un certain Mark Shuttleworth, le charismatique milliardaire sud-africain, qui tient lieu de chef spirituel et financier de cette tribu des codeurs.
Shuttleworth chef financier ... de ubuntu mais du reste ?
chef spirituel ? jamais vu une seule fois ce gars en chef spirituel de qq chose dans le libre...
Si encore c'était Torvalds par exemple je comprendrais, mais Shuttleworth...
sur ubuntu :
> dont le développement a été le plus rapide
forcément puisqu'ils partaient d'une base éprouvée et fonctionnant déjà : debian
y'a des choses intéressantes, mais comme d'hab si ubuntu étais vu à ça juste valeur ça serait intéressant car voir ubuntu et (pire) Shuttleworth comme le gentil chevalier blanc qui va mettre à genous windows et tous les autres ... ben heu ... qu'il aille filer un coup de main à Torvalds ou RMS plutôt
> C'est assez curieux de voir comment google à la côte auprès des libristes malgré son opacité extrême
En fait, google marche bien surtout parce que jusqu'à présent c'est le meilleur (que ce soit en terme de résultats, même si ponctuellement on peut toujours trouver mieux, mais aussi d'interface et de rapidité)
C'est plutôt un choix pragmatique et non de licence ou autre.
En outre, en sortant des versions comme google.com/linux forcément les gens aiment.
A noter aussi que google est sorti au bon moment. Ou plutôt je l'ai connu au moment où on galerait pour trouver des résultats intéressant, où la plupart des moteurs de recherche étaient des annuaires, etc.
C'est pour des raisons très pragmatiques que google fonctionne bien.
Mais il est vrai aussi que google a une très bonne image (sur certains points), en utilisant beaucoup de softs / techno open source, en en libérant certains, gsoc, etc.
Mais oui, l'interface de wikia est intéressant, mais parfois trop lourde, noter les résultats par exemple au moment où je cherche quelque chose d'important je m'en fou, je veux mon résultat, pas le noter... (enfin c'est juste un exemple)
je ne l'avais jamais utilisé avant (sauf peut-être au moment de la sortie)
au niveau de l'interface, au premier abord .. ben pas grand chose de spécial
puis on scroll ... et là c'est sympa : ça charge la suite des résultats quand on approche du bas de la page plutôt que de passer à la page suivante.
A l'usage c'est vraiment sympa.
Par contre, revers de la médaille, ça donne une liste assez vite brouillon, trop de résultats à l'écran justement...
Pour la pertinence je sais pas si ça peut concurrencer google, les tests que j'ai fais était trop limités.
Par contre, google a de beaux jours devant lui pour des raisons très basiques : la page de google se charge _beaucoup_ plus vite.
Du moment que ça se ressent (même si dans l'absolu c'est faible) alors google sera plus attrayant.
Et un deuxième point du même genre : l'url !! http://search.wikia.com : voilà une raison pour beaucoup de personnes de ne pas utiliser wikia... c'est très con je sais, mais entre google.(fr|com|...) et search.wikia.com y'a une énorme différence. Et déjà que les gens ne font que taper dans leur barre d'adresse sans vraiment savoir (ou dans la barre de recherche google de firefox)...
> qui concurrencera bientôt google
mouais... faut voir que google c'est pas uniquement la recherche par contre ;-)
> un développeur employé n'est pas propriétaire de son code. Ni même de ses idées.
sur ?
Je croyais justement que l'employé était propriétaire de ses idées, et qu'il lui était possible (du moment qu'il n'utilise pas ce qu'il avait fait au taff, code ou autre, ni évidemment problème de brevet, exclusivité ou autre) de recréer des implémentation from scratch utilisant les idées qu'il aurait pu avoir durant son boulot.
Bon après évidemment la limite est relativement floue au niveau de l'idée pure, mais je croyais tout de même que c'était possible...
> j'ai toujours eu du mal à le faire marcher sur les autres distrib
C'est à dire ? (problèmes, distribs)
Parce que bon, ça fait bien longtemps que j'ai pas vu un seul problème suite à l'installation de java (ou même problème d'installation)
Au pire, il suffit de changer les "alternatives" quand on en a plusieurs versions en parallèle mais à part ça...
oui mais non...
On peut très bien installer (et plus facilement que sous windows) un firefox d'une version donnée dans son home (sans droits particuliers)
Et adieu les mises à jour centralisées et contrôlées...
> VML (compatible IE6) au lieu de SVG
en même temps, pour trouver un plugin supporté pour IE6 et faire du svg...
si je dis ça c'est justement parce que je fais pour mes applis à la fois du VML et du Canvas. Ca fait une bonne solution je trouve, même si pas parfaite.
> RTF au lieu de XHTML
heu... RTF et XHTML c'est pas vraiment la même chose.
Pourquoi comparer les 2 ?
Faire du RTF je trouve ça logique, c'est portable, les specs sont dispo, c'est lisible sur beaucoup de machines sans problème, etc.
> DOC et XLS au lieu PDF
au lieu de odt/ods oui, mais c'est pas non plus comparable à PDF qui est plutôt un format d'échange, non modifiable.
tout ça pour dire que je trouve ces comparaisons étranges (même si pour le sens je comprend bien ;-))
> ce faible pourcentage de la population de moins 60 ans portant un peacemaker
ha, parce que ça garanti qu'un policier ne tirera pas avec son taser sur quelqu'un de plus de 60 ans ?
Et aussi en passant, le taser est (plus) dangereux si le sujet est mouillé par exemple (je doute que les flics vont demander aux personnes de se sécher avant de l'utiliser, et il arrive dans les émeutes d'utiliser des lances à incendie, non ?).
> Bref si on donne une arme à un policier
Oui mais justement... le problème que je vois c'est que tout le monde pense que c'est tellement inoffensif qu'on veut en donner à d'autres catégories que les policiers (pour certaines catégories d'infirmier par exemple, et je suis pas sur qu'ils aient une formation sur les armes...)
heu oué, mais qui a dit que les taser n'étaient destiné qu'à être utilisé contre les jets de pierres ?
justement, comme tout le monde crois que c'est pas dangereux (comparé à un flingue) ils en veulent partout...
> taser et autre truc qui bien utilisé font mal et voir paralyse la victime temporairement
et accessoirement peuvent aussi tuer... y'a pas écris sur le front de tout le monde s'il porte un pace maker par exemple...
(et les gens sont tellement persuadé que c'est pas dangereux que certains veulent équiper bcp de monde avec, y compris les infirmières en psy par ex...)
> je me suis rendu compte que tu avais raison
a mon avis on avait tous les 2 une part de vrai et une part de faux...
donc PackageKit utilise les outils des distribs (urpm, apt, etc) et Smart directement les formats de paquets (rpm, deb, etc)
Donc en fait, à part avoir une interface graphique identique, ça sert à quoi ?
Ce que je veux dire c'est que ça ne pourra peut-être pas prendre en compte les spécificités de tous les gestionnaires (ne serait-ce que le côté paquets requis / suggérés par exemple) et le seul but est d'avoir la même interface si on change de distrib (ce qui n'est je pense pas si courant, le but est qd même d'avoir un truc pour bosser, non ?)
Alors que smart prend en compte les formats différents de base mais colle son algo dessus donc les traite de la même manière.
(donc en fait, pour reprendre ce que disait IsNotGood, je comprend encore moins pourquoi il voudrait que mandriva reprenne PackageKit au lieu de drakrpm alors que ça ne ferait rien de plus du tout que ça n'apporte à mon avis pas grand chose présenté comme ça...)
> Et aussi: la sécurité basée sur PolicyKit a du pas mal compter dans le choix de RedHat - il y a d'ailleurs un truc similaire dans les outils Drak.
C'est à dire ?
(je connais pas vraiment PolicyKit)
> le développeur principal le fait sur son temps libre donc il fait ce qu'il veut;
ha mais je n'ai jamais pensé le contraire
> PackageKit est une couche au-dessus ; il ne remplace pas le gestionnaire de paquet, il l'utilise au contraire
tout comme smart
> Smart ne répond pas aux mêmes objectifs
Je croyais pourtant
Smart permet d'avoir une interface unifiée pour rpm, deb, tgz, et il est possible d'en installer d'autres.
On peut donc avoir la même interface sur pas mal de distribs, même si le but n'est pas initialement d'en faire un meta package manager.
Donc la question reste la même pour moi, pour redhat/fedora quel est l'intéret de développer PackageKit from scratch plutôt que d'utiliser, adapter Smart_Package_Manager qui me semble faire déjà pas mal de choses dans le même but (et je parle pas du développeur mais plutôt du point de vue de la distribution)
dit, juste comme ça, tu lis ce à quoi tu répond ou pas ?
la question était (en plus clair puisqu'il le faut...) "pourquoi développer PackageKit alors que Smart existe ?"
L'interface graphique de smart ne répond-t-elle pas à une bonne partie des besoins de PackageKit ?
N'était-il pas plus intelligent d'améliorer smart ?
Le problème c'est que c'est toi qui tourne en rond autour de yum alors qu'on te parle de drakrpm, smart, PackageKit.
[^] # Re: T'as tout compris
Posté par CrEv (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 4.
ben pas moi, en fait toute l'information est masquée au milieu de définitions et noms de classes qui ne servent pas à grand chose...
En fait toutes ces définitions sont contenues dans =~ mais forcément si on ne le connaît pas on ne comprend pas et on doit "deviner" ce que le programme fait.
Par contre si on apprend cet opérateur ben c'est concis _et_ clair
[^] # Re: javascript
Posté par CrEv (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 2.
non, mais que si tu passes un int en paramètre dans une fonction il n'est pas possible de modifier sa valeur dans la fonction et que cette valeur soit visible en dehors, au retour.
En gros passer des références quoi...
> T'as le droit de créer des listes (et de les faire renvoyer par la méthode), tu sais ?
oué donc je retourne une liste (il faut donc la créer avant de le retourner, ajouter les valeurs, etc) et au retrour je lis ma liste et extrait toutes les valeurs...
myFunc = function() {
return [1, 2];
}
var [a, b] = myFunc();
C'est quand même plus sympa, non ?
[^] # Re: my 2 cents
Posté par CrEv (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 4.
Java étant assez pauvre, il est facile (mais fastidieux) à lire
Par contre, souvent les programmes en perl vont utiliser beaucoup plus de mot clés (tous les $* par exemple) en plus avec de l'implicite (qui ne pose pas de problème sauf si on en a jamais recontré) et donc forcément c'est plus compliqué si on est pas habitué
mais bon, comme tous les langages faut les apprendre pour les comprendre...
# javascript
Posté par CrEv (site web personnel) . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 0.
Si on prend ton premier exemple de code, ça donnerait :
if(/(\w+)=(\d+)/.test(line)) {
ident = RegExp.$1;
value = RegExp.$2;
}
Autant dire que j'adore le fait d'avoir la regexp entre / / vue comme un objet
Sinon il est vrai que perl c'est bien, mangez-en !
Apprendre perl est assez intéressant, et comme beaucoup une fois qu'on a gouté aux hash à gogo, c'est sympa pour beaucoup de choses.
Mais pour ma part j'ai remplacé tout ce que je faisais en perl pour du ruby. Tous mes scripts annexes tournent en ruby (j'entend par là tout ce qui touche à mes sources, préprocesseurs, rapports, stats, build, etc)
Pour ce qui concerne java, pour en faire de temps en temps, je trouve aussi que c'est un mauvais langage. Ok l'ensemble de lib est intéressant, mais le langage ... beurk.
Il faut toujours écrire beaucoup trop de choses pour avoir un truc sympa, il est trop rigide, et surtout trop pauvre. Les collections sont pas très sympa à manipuler (sauf depuis le 1.6 si je ne me trompe et foreach).
En fait, le langage java est lourd, trop compliqué car inutilement pauvre.
Il parait que ça s'améliore un peu, les annotations sont quand même quelque chose de sympa (même si ça existe ailleurs) mais bon...
impossible de retourner par exemple facilement un liste de valeurs. Si une méthode doit retourner plusieurs valeurs, il faut forcément passer par une structure dédiée (si on veut pas avoir des tableaux partout comme on trouve parfois...)
De même je crois qu'on ne peut pas passer de paramètre modifiable en java...
[^] # Re: En effet le vendredi c'est permis
Posté par CrEv (site web personnel) . En réponse au journal Ubuntu dans le New York Times. Évalué à 6.
(drakxservices sous mandriva depuis ... pfiou toujours ? ;-) )
[^] # Re: Java par définition s'est Open Source
Posté par CrEv (site web personnel) . En réponse à la dépêche Qt 4.5 sera sous licence LGPL 2.1. Évalué à 5.
je croyais que c'était intégré en standard...
# vendredi
Posté par CrEv (site web personnel) . En réponse au journal Ubuntu dans le New York Times. Évalué à 9.
> Le clou de la réunion était une chose appelée Ubuntu et un certain Mark Shuttleworth, le charismatique milliardaire sud-africain, qui tient lieu de chef spirituel et financier de cette tribu des codeurs.
Shuttleworth chef financier ... de ubuntu mais du reste ?
chef spirituel ? jamais vu une seule fois ce gars en chef spirituel de qq chose dans le libre...
Si encore c'était Torvalds par exemple je comprendrais, mais Shuttleworth...
sur ubuntu :
> dont le développement a été le plus rapide
forcément puisqu'ils partaient d'une base éprouvée et fonctionnant déjà : debian
y'a des choses intéressantes, mais comme d'hab si ubuntu étais vu à ça juste valeur ça serait intéressant car voir ubuntu et (pire) Shuttleworth comme le gentil chevalier blanc qui va mettre à genous windows et tous les autres ... ben heu ... qu'il aille filer un coup de main à Torvalds ou RMS plutôt
[^] # Re: I <3 google
Posté par CrEv (site web personnel) . En réponse au journal Google pousse à l'utilisation de la musique libre. Évalué à 7.
Je dois être un peu con, mais il dit quoi ton titre ?
[^] # Re: rms ?
Posté par CrEv (site web personnel) . En réponse à la dépêche Qt 4.5 sera sous licence LGPL 2.1. Évalué à 2.
if (x < foo (y, z))
haha = bar[4] + 5;
else
{
while (z)
{
haha += foo (z, z);
z--;
}
return ++x + bar ();
}
static char *
concat (s1, s2) /* Name starts in column one here */
char *s1, *s2;
{ /* Open brace in column one here */
...
}
do
{
a = foo (a);
}
while (a > 0);
Et après ils vont se plaindre que GNU (hurd) n'avance pas et que personne veut coder dessus...
[^] # Re: wikia search
Posté par CrEv (site web personnel) . En réponse à la dépêche Rétrospective LinuxFR 2008 du logiciel libre. Évalué à 4.
En fait, google marche bien surtout parce que jusqu'à présent c'est le meilleur (que ce soit en terme de résultats, même si ponctuellement on peut toujours trouver mieux, mais aussi d'interface et de rapidité)
C'est plutôt un choix pragmatique et non de licence ou autre.
En outre, en sortant des versions comme google.com/linux forcément les gens aiment.
A noter aussi que google est sorti au bon moment. Ou plutôt je l'ai connu au moment où on galerait pour trouver des résultats intéressant, où la plupart des moteurs de recherche étaient des annuaires, etc.
C'est pour des raisons très pragmatiques que google fonctionne bien.
Mais il est vrai aussi que google a une très bonne image (sur certains points), en utilisant beaucoup de softs / techno open source, en en libérant certains, gsoc, etc.
Mais oui, l'interface de wikia est intéressant, mais parfois trop lourde, noter les résultats par exemple au moment où je cherche quelque chose d'important je m'en fou, je veux mon résultat, pas le noter... (enfin c'est juste un exemple)
[^] # Re: wikia search
Posté par CrEv (site web personnel) . En réponse à la dépêche Rétrospective LinuxFR 2008 du logiciel libre. Évalué à 5.
au niveau de l'interface, au premier abord .. ben pas grand chose de spécial
puis on scroll ... et là c'est sympa : ça charge la suite des résultats quand on approche du bas de la page plutôt que de passer à la page suivante.
A l'usage c'est vraiment sympa.
Par contre, revers de la médaille, ça donne une liste assez vite brouillon, trop de résultats à l'écran justement...
Pour la pertinence je sais pas si ça peut concurrencer google, les tests que j'ai fais était trop limités.
Par contre, google a de beaux jours devant lui pour des raisons très basiques : la page de google se charge _beaucoup_ plus vite.
Du moment que ça se ressent (même si dans l'absolu c'est faible) alors google sera plus attrayant.
Et un deuxième point du même genre : l'url !!
http://search.wikia.com : voilà une raison pour beaucoup de personnes de ne pas utiliser wikia... c'est très con je sais, mais entre google.(fr|com|...) et search.wikia.com y'a une énorme différence. Et déjà que les gens ne font que taper dans leur barre d'adresse sans vraiment savoir (ou dans la barre de recherche google de firefox)...
> qui concurrencera bientôt google
mouais... faut voir que google c'est pas uniquement la recherche par contre ;-)
[^] # Re:
Posté par CrEv (site web personnel) . En réponse au journal Il est déconseillé de partager à l'école.... Évalué à 4.
sur ?
Je croyais justement que l'employé était propriétaire de ses idées, et qu'il lui était possible (du moment qu'il n'utilise pas ce qu'il avait fait au taff, code ou autre, ni évidemment problème de brevet, exclusivité ou autre) de recréer des implémentation from scratch utilisant les idées qu'il aurait pu avoir durant son boulot.
Bon après évidemment la limite est relativement floue au niveau de l'idée pure, mais je croyais tout de même que c'était possible...
[^] # Re: Et la distrib
Posté par CrEv (site web personnel) . En réponse à la dépêche openSUSE 11.1 - nouvelle version du caméléon disponible !. Évalué à 2.
C'est à dire ? (problèmes, distribs)
Parce que bon, ça fait bien longtemps que j'ai pas vu un seul problème suite à l'installation de java (ou même problème d'installation)
Au pire, il suffit de changer les "alternatives" quand on en a plusieurs versions en parallèle mais à part ça...
[^] # Re: Et pendant ce temps...
Posté par CrEv (site web personnel) . En réponse au journal Grosse faille exploitable à distance dans IE. Évalué à 3.
On peut très bien installer (et plus facilement que sous windows) un firefox d'une version donnée dans son home (sans droits particuliers)
Et adieu les mises à jour centralisées et contrôlées...
[^] # Re: Parts de marché ?
Posté par CrEv (site web personnel) . En réponse à la dépêche Faire part de naissance : SPIP 2.0. Évalué à 3.
en même temps, pour trouver un plugin supporté pour IE6 et faire du svg...
si je dis ça c'est justement parce que je fais pour mes applis à la fois du VML et du Canvas. Ca fait une bonne solution je trouve, même si pas parfaite.
> RTF au lieu de XHTML
heu... RTF et XHTML c'est pas vraiment la même chose.
Pourquoi comparer les 2 ?
Faire du RTF je trouve ça logique, c'est portable, les specs sont dispo, c'est lisible sur beaucoup de machines sans problème, etc.
> DOC et XLS au lieu PDF
au lieu de odt/ods oui, mais c'est pas non plus comparable à PDF qui est plutôt un format d'échange, non modifiable.
tout ça pour dire que je trouve ces comparaisons étranges (même si pour le sens je comprend bien ;-))
[^] # Re: Openttd
Posté par CrEv (site web personnel) . En réponse au journal Flux RSS. Évalué à 3.
[^] # Re: désolé
Posté par CrEv (site web personnel) . En réponse au journal Transilien. Évalué à 3.
oui
>> mettre gimp 2.6.3 en français pour une amie sous windows XP
[^] # Re: lol
Posté par CrEv (site web personnel) . En réponse à la dépêche Amarok 2.0 "Ce n'est que le début". Évalué à 3.
la beta c'est justement le web 2.0...
[^] # Re: Pour Mobile
Posté par CrEv (site web personnel) . En réponse au journal Frozen Bubble 2.2.0 is out!. Évalué à 2.
[^] # Re: La raison des violance est simple ...
Posté par CrEv (site web personnel) . En réponse au journal [HS] La révolte en Grèce. Évalué à 3.
ha, parce que ça garanti qu'un policier ne tirera pas avec son taser sur quelqu'un de plus de 60 ans ?
Et aussi en passant, le taser est (plus) dangereux si le sujet est mouillé par exemple (je doute que les flics vont demander aux personnes de se sécher avant de l'utiliser, et il arrive dans les émeutes d'utiliser des lances à incendie, non ?).
> Bref si on donne une arme à un policier
Oui mais justement... le problème que je vois c'est que tout le monde pense que c'est tellement inoffensif qu'on veut en donner à d'autres catégories que les policiers (pour certaines catégories d'infirmier par exemple, et je suis pas sur qu'ils aient une formation sur les armes...)
[^] # Re: La raison des violance est simple ...
Posté par CrEv (site web personnel) . En réponse au journal [HS] La révolte en Grèce. Évalué à 3.
justement, comme tout le monde crois que c'est pas dangereux (comparé à un flingue) ils en veulent partout...
[^] # Re: La raison des violance est simple ...
Posté par CrEv (site web personnel) . En réponse au journal [HS] La révolte en Grèce. Évalué à 7.
et accessoirement peuvent aussi tuer... y'a pas écris sur le front de tout le monde s'il porte un pace maker par exemple...
(et les gens sont tellement persuadé que c'est pas dangereux que certains veulent équiper bcp de monde avec, y compris les infirmières en psy par ex...)
[^] # Re: RIP Mandrake
Posté par CrEv (site web personnel) . En réponse à la dépêche Il faut sauver le soldat Williamson !. Évalué à 4.
a mon avis on avait tous les 2 une part de vrai et une part de faux...
donc PackageKit utilise les outils des distribs (urpm, apt, etc) et Smart directement les formats de paquets (rpm, deb, etc)
Donc en fait, à part avoir une interface graphique identique, ça sert à quoi ?
Ce que je veux dire c'est que ça ne pourra peut-être pas prendre en compte les spécificités de tous les gestionnaires (ne serait-ce que le côté paquets requis / suggérés par exemple) et le seul but est d'avoir la même interface si on change de distrib (ce qui n'est je pense pas si courant, le but est qd même d'avoir un truc pour bosser, non ?)
Alors que smart prend en compte les formats différents de base mais colle son algo dessus donc les traite de la même manière.
(donc en fait, pour reprendre ce que disait IsNotGood, je comprend encore moins pourquoi il voudrait que mandriva reprenne PackageKit au lieu de drakrpm alors que ça ne ferait rien de plus du tout que ça n'apporte à mon avis pas grand chose présenté comme ça...)
> Et aussi: la sécurité basée sur PolicyKit a du pas mal compter dans le choix de RedHat - il y a d'ailleurs un truc similaire dans les outils Drak.
C'est à dire ?
(je connais pas vraiment PolicyKit)
[^] # Re: RIP Mandrake
Posté par CrEv (site web personnel) . En réponse à la dépêche Il faut sauver le soldat Williamson !. Évalué à 3.
ha mais je n'ai jamais pensé le contraire
> PackageKit est une couche au-dessus ; il ne remplace pas le gestionnaire de paquet, il l'utilise au contraire
tout comme smart
> Smart ne répond pas aux mêmes objectifs
Je croyais pourtant
Smart permet d'avoir une interface unifiée pour rpm, deb, tgz, et il est possible d'en installer d'autres.
On peut donc avoir la même interface sur pas mal de distribs, même si le but n'est pas initialement d'en faire un meta package manager.
Donc la question reste la même pour moi, pour redhat/fedora quel est l'intéret de développer PackageKit from scratch plutôt que d'utiliser, adapter Smart_Package_Manager qui me semble faire déjà pas mal de choses dans le même but (et je parle pas du développeur mais plutôt du point de vue de la distribution)
[^] # Re: RIP Mandrake
Posté par CrEv (site web personnel) . En réponse à la dépêche Il faut sauver le soldat Williamson !. Évalué à 2.
la question était (en plus clair puisqu'il le faut...) "pourquoi développer PackageKit alors que Smart existe ?"
L'interface graphique de smart ne répond-t-elle pas à une bonne partie des besoins de PackageKit ?
N'était-il pas plus intelligent d'améliorer smart ?
Le problème c'est que c'est toi qui tourne en rond autour de yum alors qu'on te parle de drakrpm, smart, PackageKit.