Le rôle de flash ne semble d'ailleurs pas d'afficher des images animées (ne contenant que du texte animé en fait) contrairement à ce qu'on pourrait croire, mais d'envoyer l'utilisateur vers un site dont je n'ai pas compris l'intérêt. Surement de la pub.
En gros: un des pires sites 1.0 que j'aie vu, je lui préfère le site de lynx.
Le but de LXC est de re-implémenter proprement les fonctionnalités d'OpenVZ
On comprend alors pourquoi c'est plus mis en avant. Par contre je dois admettre être étonné que Debian privilégie un successeur beaucoup moins mûr et notamment au niveau sécurité que le prédécesseur. Des infos à ce sujet? Des explications sur ML peut-être? (je suis juste curieux, hein, moi et la virtualisation…)
… et trop nombreuses comparé à la taille du texte.
Personnellement, ça ne me donne pas envie de lire l'ensemble quand je ne vois que des séries d'images prenant toute la hauteur de mon écran et entrecoupées d'une ou deux lignes de texte seulement.
Je conçois qu'il s'agisse d'un logiciel de travail sur des vidéo, donc très lié à une IHM, mais je pense que là, ça fait trop.
Un exemple bête: dans les 5 premières captures, 4 pourraient être réduites drastiquement.
Enfin, ce n'est que mon avis sur la forme de la dépêche. Je n'ai pas lu le fond du coup.
Quand on parle de l'alliage utilisé en électronique, alors, personnellement, je préfère ne pas en respirer trop. Vue l'odeur et les diverses réactions chimiques qui se produisent lorsque l'on soude, je doute que ce soit bénin à forte dose.
Mais bon, ici on parle d'une plaque de taille assez modeste, donc…
Quel est le rapport? Ils vendent un produit et un service, donnent au client le produit, mais pas le service, et ça ne serait pas de leur faute parce qu'en fait ils achètent la machine a quelqu'un d'autre? La blague…
Techniquement parlant, il y a quand même une boucle et 3 conditions, c'est plus compliqué que juste afficher un texte :P
A part ça, y'a pleins de logiciels qui sont encore moins complexes et qui doivent utiliser des bibliothèques. Un exemple bête, imagines un frontend de ls: il exécute ls, il récupère la sortie et l'affiche de façon graphique. L'intérêt? Il ajoute des cases à cocher avec les options genre :
if HumanReadable then command+=" -h "
et permets donc de bâtir des commandes ls a des gens qui ne savent pas se servir du man ni de l'auto-complétion.
Mais, j'admets, c'était juste pour t'embêter :=)
Plus sérieusement, on peut considérer que les bibliothèques elles-même sont des programmes, et certaines doivent bien être basées sur la lib standard. Mais bon, c'est hors-sujet et n'a rien à voir avec le fait que la GPL soit virale (ce qui est un fait, même qu'elle est faite pour)
Que veux-tu, certains aiment ne lire qu'un seul fichier à la fois. Je me demande comment ils font pour fusionner des dépôts rapidement par contre. Avec 2 écrans, un par fichier? Mouarf
Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)
Il me semble que, sous Debian, cron (et son copain anacron) sont installés par défaut,
Ça dépends.
Ils le sont si tu sélectionnes les outils de bases lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps (cela dis, il semble que j'ai installé anacron sur ma machine, je sais pas pourquoi. J'imagine que je voulais jouer avec et que j'ai omis de le supprimer :) ).
Il semble que leur principal usage soit de compresser les journaux trop vieux, et je dois admettre que vu le peu d'usage que je fais des journaux (je les lis jamais: je sais c'est mal) je me moque un peu de leur présence.
Les logs de cron et d' anacron devraient être lisibles avec :
En gros, j'ai 3 lignes le 26 avril, et pleins le 1er mai. Rien d'autre, et pourtant ce système est bien plus vieux. Aucune info sur ce qui est fait exactement.
Ce lancement de tâches selon des contraintes temporelles, nécessaire au bon fonctionnement du système d'exploitation, peut être fait avec cron, ou avec systemd.
Ces tâches sont loin d'être nécessaires. Cron (et consort) sont des dépendances de logrotate, lui-même n'étant qu'une dépendance recommandée du système (de rsyslog en fait), rien de plus.
De même qu'aptitude recommande apt-xapian-index (dont je ne vois absolument pas l'intérêt et que je n'installe donc jamais), qui ensuite dépend du paquet python-apt n'implique pas que python-apt est un outil nécessaire au bon fonctionnement du système.
Il y a exactement 19 paquets qui dépendent directement d'anacron (flemme de regarder pour cron, mais si ils ont été bien fait, ça devrait être pareil) dont 10 pour lesquels il s'agit d'une dépendance, 4 qui le recommandent, et 5 qui le suggèrent.
Les 10:
checksecurity
fiaif
gnome-schedule
gnumed-server 16
gnumed-server 17 (je précise les versions ici pour montrer qu'en fait, c'est même pas vraiment 10…)
kde-config-cron 4.8
kde-config-cron 4.10 (idem)
logrotate 3.8.3-3
logrotate 3.8.3-4 (encore)
task-laptot 3.14
Les 4:
email-reminder
task-desktop 3.14+nmu2
update-notifier 0.99.3debian11
update-notifier-kde 1.2.4
Les 5:
backup-manager
bcron-run
cron (mouarf)
cronie (hum)
popularity-contest
Dis-moi qu'est-ce qui, dans ces logiciels, est réellement vital au système? Pour moi, rien… D'ailleurs, comme je l'ai dis, je fonctionne habituellement sans (et vais d'ailleurs re-supprimer cet outil dont je n'ai que faire).
J'ai compris ton propos, et je disais juste que la surconsommation de RAM causée par systemd me semble raisonnable, vu le matériel moderne.
Dans l'ensemble, je suis d'accord.
Mais pas sur du matériel bas de gamme, même moderne, comme l'est mon eeepc (par moderne, j'entends pas "tout neuf", mais avec des générations de matos ayant encore cours, comme les proc x64 bi-coeur multi-thread par exemple. La quantité de RAM ne me semble pas avoir grand chose à voir avec la modernité par contre. Mais sa techno, si: la DDR3, ça va encore non? Il semble que la DDR4 soit prévue à la vente grand public pour 2015 après tout…).
Ce problème ne peut-il pas être réglé avec nice et son copain ionice ?
Probablement, mais je suis encore un débutant sous linux (ça fait que 3 ans que j'ai switché mon OS principal, et j'ai encore pas mal a apprendre pour qu'il fasse de plus en plus uniquement ce que je lui demande, de façon optimale).
Enfin bon, plutôt que de jouer avec les priorités des processus, le plus simple et le plus efficace reste de sélectionner des logiciels qui font ce qu'on leur demande, tout en étant moins gourmands.
Dans le cas de la compilation, clang++ à juste banni g++ de mes habitudes.
Dans le cas des processus d'init, je trouve encore un intérêt et un rôle utile à sysVinit, bien que je ne serais pas contre une solution de remplacement qui soit capable de lire les fichiers utilisés par systemd, mais qui n'apporte pas de dépendances dont je n'ai que faire. Et dont je ne suis manifestement pas le seul à n'avoir que faire: quand le sujet est abordé sur la ml de debian, je constate que je ne suis pas le seul a éprouver des réticences à installer dbus et autres truckit.
Le principe est le suivant : un service est lancé uniquement lorsqu'on fait appel à lui, pas avant. L'opération est transparente pour l'utilisateur.
J'ai effectivement entendu parler de ça, et c'est d'ailleurs pourquoi mon avis sur systemd est très mitigé:
* d'un côté il crée des dépendances dont je n'ai pas l'usage et à un coût réel d'exécution
* d'un autre côté, il permets d'améliorer pas mal de choses: facilité de maintenance des scripts d'init, parallélisation du démarrage des services, montage des partitions à la demande, arrêt/démarrage des services pour qu'ils ne fonctionnent que si on en a besoin.
La plupart de ces avantages sont très très utiles pour un serveur, je pense (y compris le temps de démarrage réduit: quand un serveur doit redémarrer, autant que ça soit le plus bref possible), mais pour une machine d'utilisateur final, à part quelques services à lancer à la demande comme cups, samba, ou les outils des DEs (sur-?)évolués comme KDE/Gnome, l'intérêt est restreint. Et ces mêmes outils ne sont pas forcément utiles à toutes les machines.
D'ailleurs, je me demande si cups+samba+sysVinit consomment autant que systemd seul? C'est une vraie question hein, vu que je n'utilise pas les 2 démons cités, je n'ai absolument aucune idée de leur consommation.
Reste ssh, que je démarre généralement quand j'en ai besoin (c'est à dire uniquement quand je suis chez moi et que je me sers du PC portable comme d'une télécommande pour la tour). Selon top, au repos, il consomme 1Mo, à peu près…
dans les cas où c'est possible, cela permet d'économiser de la RAM. ;-)
Je suis conscient de cet avantage (comme dit plus haut) mais je me demande si la RAM ainsi économisée compense réellement la surcharge induite par l'usage de systemd sur un poste d'**utilisateur final et normal** genre bureautique (la moyenne des utilisateurs utilisent quoi, à part quelques jeux, un navigateur web, et un logiciel de traitement de texte?).
Sur un serveur, je n'en ai aucune idée. De prime abord je dirais que oui, vue la quantité de services lancés, mais à bien y réfléchir, de nos jours la tendance semble plutôt être a 1 service par serveur virtuel, avec N machines virtuelles installées par serveur physique (voire par grappe de serveur physiques) histoire de réguler la charge. Après, je ne connais pas trop ce domaine donc… je dis sûrement de la merde :D
Sur un poste de développeur web, ça me semble évident que systemd soit intéressant, vu que j'imagine qu'il faut utiliser des serveurs de diverses sortes régulièrement pour tester. Pour un poste de dev "classique" par contre, je ne vois pas l'intérêt.
C'est quand même surprenant ta fixette, je connais pas ou peu de monde à ce point bloqué par cette phase de génération de moc en regard des énormes avantages que présente Qt en échange.
Relis un peu plus haut. La dernière fois que j'ai eu affaire à ce truc, ça a été loin d'être si évident. Bien entendu, ça remonte à plusieurs années et, depuis, mes connaissances et les logiciels que j'utilise on pas mal évolué (j'ai notamment découvert cmake, moi qui ne connaissais que la compilation via les IDE ou en ligne de commande à cette époque).
Je suis conscient qu'ils ont un gros héritage technique, qu'ils ont manifestement (à en lire les réponses) plutôt pas mal réussi à gérer et surtout réduire (modularité du code, notamment).
Je suis aussi conscient que C++11 est bien trop récent pour qu'ils en utilisent les nouveautés dans le coeur (quoique, vu qu'ils se basent sur des outils libres, peut-être qu'ils ont une branche stable ou c'est supporté?) mais il me semble que depuis 2003 (date du standard précédent) il est possible de faire la même chose que ce que Qt fait (au sujet des signaux je parle bien entendu) sans utiliser cet outil.
Pour le coup, oui, je trouve ridicule de conserver cet outil.
Au fait, je me demande ce que donne l'utilisation de cmake sous windows? Avec nos distros linux, cet outil voit sa tâche largement facilitée par le fait que les fichiers de dev soient dans des endroits standards, mais sous windows, ce n'était pas encore le cas la dernière fois que j'ai regardé.
Faudra que je teste, peut-être demain, je dois bien avoir une vieille licence d'xp qui traine…
Si tu utilises grub, il faut rajouter single à la ligne kernel (lien).
LILO :)
Grub2 est devenu pénible à configurer, d'où mon passage à LILO.
Systemd est plus qu'un système d'init
Attention, passage truffé de suppositions ;)
Je crois que c'est justement ce qui bloque pas mal d'opposants.
Quel intérêt de changer pour un composant qui fasse plus de choses si on ne s'en sers que comme d'un système d'init?
Par exemple, tu cites cron. Très bien, mais sur mes machines je n'utilise pas cron, je n'en ai pas l'utilité: j'éteins mes bécanes (oui je sais, je pourrais utiliser l'hibernation. Mais même dans ce cas, on peut utiliser les scripts j'imagine) quand je m'en sers plus, donc si j'ai besoin de faire quelque chose régulièrement je peux facilement le mettre au moment du boot ou de l'extinction. La plupart du code contenu dans les scripts d'init sers à gérer un service: pour une simple "tâche évènementielle" je pense que ce n'est pas nécessaire de s'encombrer de toute la structure "start/restart/stop/status" si le but est juste de lancer une tâche.
A bien y réfléchir, la mécanique des runlevel est plus puissante que je l'imaginais… j'ai encore trop de réflexes de mes années windows et je n'aurai pas imaginé avant ce message utiliser les runlevels pour planifier une action à l'extinction de ma machine :)
selon des contraintes temporelles
Je pense que là, on met le doigt sur un autre problème, justement. Ce que je vais dire rejoins assez ce commentaire d'une autre autre dépêche: quel intérêt pour un ordinateur de bureau utilisé par quelqu'un de normal?
Lancer une tâche toutes les 20 minutes ou à heure fixe? Je ne vois personne dans mon entourage qui le fasse… Bien sûr, pour faire des mises à jour automatiques sur une machine qui est toujours allumée, c'est utile. C'est aussi super sur un serveur qui doit faire des backup réguliers et n'a comme réelle donnée pour savoir quand que le temps.
Mais voila, tout ça, c'est super pour des serveurs (ou même du matériel embarqué), pour un ordinateur de bureau c'est bien plus contestable.
systemd est une avancée mais surtout pour ceux qui administrent des serveurs ou des machines professionnelles, qui ne s'éteignent jamais. Pour les autres utilisateurs qui ne veulent qu'activer/désactiver des services au lancement de la machine, je n'en suis pas sûr: renommer /etc/rc2.d/S02mpd en /etc/rc2.d/K02mpd n'est pas complexe, et je parie qu'il existe des GUI pour le faire (enfin, non, je parie pas, je sais qu'il y en a au moins une, mais impossible de remettre la synapse sur son nom…).
qui consiste à dire qu'on se fiche de l'occupation mémoire des logiciels qu'on écrit parce que le client bah "il a qu'a acheter de la ram".
Nous parlons d'une surconsommation de RAM (de systemd par rapport à sysvinit) de 30 ou 40 Mo.
Sur la citation que tu as faite, je parlais d'une tendance générale dans l'industrie du logiciel, et pour être précis d'une tendance qui tends à m'exaspérer fortement, pas de systemd en particulier.
Pour en revenir à systemd et son augmentation de 30Mo, ou mieux, en prenant ton test Debian/ArchLinux, j'ai toujours préféré les données relatives: 30Mo supplémentaires ne veulent rien dire en soit, je préfère parler de 100% d'augmentation.
Ca parle beaucoup plus ainsi.
Par exemple, si on parle d'une augmentation de la consommation de 30Mo de LibreOffice d'une version X à une version Y, si la version X consommait 1000Mo (j'invente hein) alors ce n'est une augmentation que de 3%. Pas loin d'être négligeable donc. Alors que la version X consommait 30Mo, et la version Y passe à 60Mo, il vaut mieux que le gain en fonctionnalités vaille le coup pour moi. (surtout que dans un cas comme dans l'autre, rien ne dis que j'utiliserai ces nouvelles fonctionnalités)
Dans le cas de systemd, ça semble être le cas… même si suis assez sceptique sur la nécessité de certaines dépendances en dur que je n'utilise pas (je pense ici à dbus). Encore une fois, c'est une simple augmentation de 30Mo de la consommation de ma machine (j'invente, encore) mais si je dois rajouter une consommation moyenne de 60Mo, ça peut vouloir dire que ma machine va beaucoup plus swapper quand je compile, et le disque dur est d'une lenteur impressionnante, et quand j'utilisais GCC pour compiler autorealm, si je voulais utiliser mon CPU à fond (avec 4 thread donc) ma machine devenais complètement hors de contrôle pendant près de 15 minutes (du coup je tournais à mi-régime et ça compilait en +/-4 minutes. J'ai ensuite découvert clang, et je suis passé à +/-2 minutes :) )
Je pourrais acheter de la RAM bien sûr, mais dans ce cas c'est l'autonomie de ma batterie qui va diminuer il me semble.
Enfin, je ne suis pas un expert sur la question… mais je pense que si systemd est bel et bien une avancée sur pas mal de points, il a malgré tout des conséquences négatives qui font qu'il faut qu'un autre système d'init, un qui ne fasse que ça, soit toujours maintenu. Peu m'importe que ce soit sysVinit, openRC ou je ne sais quoi, mais j'adhère assez à la philosophie UNIX qui dit que les programmes efficaces ne font qu'une seule chose mais la font bien (ça ne m'empêche pas de voir qu'il y a plein de contre exemples).
Tu le dis toi-même, certaines libs boost dépendent d'autres lib boost.
J'aurai dû ajouter l'adjectif "rares" :) (et le fait que la seule dépendance que j'aie eu pour le moment est envers la lib "system" qui est devenue partie intégrante du standard. Mais je suis loin de les avoir toutes utilisées…)
Et si on continue sur les points forts de boost, il faut préciser que la plupart de ses lib ne sont que des headers. Niveau simplicité d'usage, on peut difficilement faire mieux (et Qt passe donc hors catégorie sur ce point, voir la suite).
Le principe KISS est justement respecté avec l'interdépendances des libs,
On dirait que ça a bien évolué alors. Tant mieux. Plus que la chaîne de compilation à simplifier, alors?
Parce que ce point à été (et restera encore un certain temps je pense) un vrai point bloquant.
On peut dire ce qu'on veut, mais la mécanique des signaux si chère à Qt possède ce défaut majeur qui est de rendre la compilation bien plus casse-pieds, alors que les autres framework s'en passent très bien.
Dès lors que tu ne veux pas utiliser l'IDE officiel, tu galères. En tout cas, à l'époque de mon BTS KDevelop galérais (y'a 7 ans en gros) lui qui était pourtant écrit avec Qt (je me rappelle qu'il fallait invoquer l'outil à la main… moc, c'est ça?), il y a 3 ans Visual Studio 2008 galérait (je sais pas maintenant si c'est plus simple, mais j'en doute), Code::Blocks galèrait encore y'a 3 ans, utiliser la ligne de commande sous windows imposait d'utiliser une ligne de commande customisée par et pour Qt (mais qui ne connaissais du coup que les modifs faites par et pour l'installateur de Qt, irrecevable pour moi)…
Il n'y a bien que Qt Creator et CMake qui ne galèrent pas. Pour le coup, vu que je n'utilise plus trop d'IDE, je pourrais peut-être m'y remettre, mais l'idée de risquer d'en chier avec la compilation pour une fonctionnalité dont tout les autres framework se passent allègrement me rebute.
J'imagine qu'on va me dire qu'il utiliser l'outil qu'une seule fois et blablabla… mais de mémoire, il faut l'utiliser à chaque modification de l'interface, ce qui peut arriver souvent… Enfin, arrivais, avant l'arrivée des technos ou l'interface n'est plus codée en dur. Mais là encore, les autres le font aussi bien sans ajouter leur outil dans la chaîne.
Ce qui est certain de toute façon, c'est que pour au moins un projet que j'aimais bien (rolisteam), et pour lequel j'avais envie de contribuer et tant pis pour la lib Qt sous-jacente que je ne maîtrisais pas (j'avais des souvenirs du BTS mais ça datait déjà) je n'ai jamais réussi à compiler, sauf à utiliser QtCreator, mais ce truc n'a vraiment jamais été à mon goût, moi qui préfère les interfaces minimalistes.
Pour faire court: j'apprécie quand les outils que j'utilise ne sont pas liés les uns aux autres.
Je considère que si jamais je détecte un bug dans un tel outil, je peux le corriger.
Ça m'est d'ailleurs déjà arrivé, parce qu'un outil n'intégrant pas 10 000 fonctionnalités différentes, autrement suivant les principes du KISS, est bien plus simple à fixer.
Voila pourquoi je n'apprécie pas les gros framework comme Qt ou WxWidgets (contrairement à ce que j'ai pu laisser entendre pour des fins de trollage :p).
Vu que j'ai pas le choix, je m'en sers, mais c'est principalement parce que je ne connais pas de bibliothèque de toolkit n'accomplissant que leur tâche.
Oui, dans l'absolu, je préfèrerai un outil qui me permette de gérer les thread, un autre qui gère la traduction, un différent pour l'IHM, un distinct pour l'encodage, etc…
Même qu'ils soient regroupés sous un même nom, tant que je peux les utiliser complètement indépendamment les uns des autres, comme pour boost (quoique, certaines lib boost dépendent d'autres lib boost).
A mon sens, Qt est un langage qui ne s'assume pas: modification de la chaîne de compilation, ré-implémentation et volonté de remplacement de la STL, etc.
Il me semble idéal pour remplacer Java quand on veux plus de perf, en échange d'une syntaxe un peu plus complexe, par exemple.
Langage basé sur le C++, et qui se compile en générant du C++ ok, mais c'est bien ainsi que C++ à commencé: ça ne faisait que générer du C à partir de code C++, grâce à l'outil cfront. Ensuite, j'imagine qu'il fallait encore compiler…
Il y a juste un point qui m'intrigue dans le document que tu cites (le 2nd):
The only way is to rewrite it to work that way, or
to have more than one scheduler in the kernel. I don't want to do the former,
and mainline doesn't want to do the latter.
La dernière fois que j'ai fouillé dans les options de compilation du noyau il me semblait pourtant avoir vu plusieurs schedulers ?
C'est pas comme si je remets en cause les dires du monsieur, vu ma compréhension (ou mon manque de compréhension plutôt) de la chose, je m'abstiens volontiers, mais j'aimerai comprendre tout de même…
mais pour ça il y a ia32-libs (nom du paquet chez ubuntu).
Sous Debian stable aussi, mais ça va passer en multiarch très prochainement (prochaine release), ce qui signifie qu'au lieu de n'avoir que ia32-libs, tu vas devoir installer toutes les dépendances en version i386, et tant pis si tu les as déjà en amd64 manifestement. (y'a eu pas mal de bruit sur la ml à ce sujet)
Vu qu'Ubuntu est basée sur Debian, j'imagine qu'ils vont suivre le mouvement… bien que je sois surpris que ce ne soit pas déjà le cas, vu qu'en théorie ils sont basés sur debian sid qui utilise ce principe depuis pas loin d'un an…
Un des point très intéressant de l’architecture x86-64 qu'AMD a inventée en 2003 est de pouvoir faire tourner des programmes 32 bits sur un systèmes 64 bits. Mais tu le savais je pense.
En fait, il me semble que ça dépende d'une option du kernel (IA332), mais je ne suis pas un expert.
64bit kernels can execute 32bit programs since the IA32 instructions support is included in the kernel
En fonction de la distribution utilisée, cette option peut être présente ou pas, mais il y a aussi le problème des dépendances utilisées. Je pense que tu sais qu'il existe plusieurs façons de gérer ça. Dans le cas de Debian, la stable actuelle utilise une lib dédiée qui sert à faire la jonction entre les 2 mondes, tandis que l'actuelle testing nécessite l'installation des libs en version 32 bits.
Ce n'est donc pas si évident que tu ne sembles l'indiquer: si on utilise majoritairement des logiciels 32 bits (genre skype ou via wine) il peut être intéressant d'utiliser une distro 32 bit, même si personnellement je préfère les 64 bit.
Il y a eu une discussion sur la ml debian internationale au sujet du 32 bit, il faudrait que je la retrouve. (Il me semble qu'un certain Ralf avait fait une réponse très instructive sur les intérêts du 64 bit)
Le problème est que les évolutions coûtent parfois une quantité déraisonnable de ressources, et certains, dont je fais partie, considèrent que ça ne devrait pas être le cas.
Mais effectivement, j'ai fini par sélectionner plus rigoureusement mes logiciels pour ne pas avoir de fonctionnalité qui ne me sert à rien et ainsi alléger l'ensemble.
[^] # Re: Web 1.0
Posté par freem . En réponse au journal Le web à 20 ans. Évalué à 1.
En fait flash est utilisé toutes les 2 sections.
Le rôle de flash ne semble d'ailleurs pas d'afficher des images animées (ne contenant que du texte animé en fait) contrairement à ce qu'on pourrait croire, mais d'envoyer l'utilisateur vers un site dont je n'ai pas compris l'intérêt. Surement de la pub.
En gros: un des pires sites 1.0 que j'aie vu, je lui préfère le site de lynx.
[^] # Re: On peut espérer...
Posté par freem . En réponse au journal OpenVZ sur Debian : Que prévoyez-vous avec Wheezy ?. Évalué à 1.
On comprend alors pourquoi c'est plus mis en avant. Par contre je dois admettre être étonné que Debian privilégie un successeur beaucoup moins mûr et notamment au niveau sécurité que le prédécesseur. Des infos à ce sujet? Des explications sur ML peut-être? (je suis juste curieux, hein, moi et la virtualisation…)
[^] # Re: Une dépêche ou pas dêpeche ??
Posté par freem . En réponse au journal Essai de Lightworks Beta 11.1.h sous GNU/Linux. Évalué à 4.
Non, parce que les images hollydiennes, çapucépalibre.
je suis déjà dehors :)
# Captures trop grosses ...
Posté par freem . En réponse au journal Essai de Lightworks Beta 11.1.h sous GNU/Linux. Évalué à -1.
… et trop nombreuses comparé à la taille du texte.
Personnellement, ça ne me donne pas envie de lire l'ensemble quand je ne vois que des séries d'images prenant toute la hauteur de mon écran et entrecoupées d'une ou deux lignes de texte seulement.
Je conçois qu'il s'agisse d'un logiciel de travail sur des vidéo, donc très lié à une IHM, mais je pense que là, ça fait trop.
Un exemple bête: dans les 5 premières captures, 4 pourraient être réduites drastiquement.
Enfin, ce n'est que mon avis sur la forme de la dépêche. Je n'ai pas lu le fond du coup.
[^] # Re: Boutique de quartier ?
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 3.
C'est vrai… mais c'est vrai de tous les commerçants, si on y pense bien. Y compris de Dell si on lit l'histoire plus haut.
Non. Il y a aussi l'avantage de pouvoir négocier, et celui de la proximité en cas de problème.
[^] # Re: Le support Dell
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 2.
Si tu parles du métal, je pense que non.
Quand on parle de l'alliage utilisé en électronique, alors, personnellement, je préfère ne pas en respirer trop. Vue l'odeur et les diverses réactions chimiques qui se produisent lorsque l'on soude, je doute que ce soit bénin à forte dose.
Mais bon, ici on parle d'une plaque de taille assez modeste, donc…
[^] # Re: Pas le même support
Posté par freem . En réponse au journal Dell, le degré zéro du service client.. Évalué à 7.
Et?
Quel est le rapport? Ils vendent un produit et un service, donnent au client le produit, mais pas le service, et ça ne serait pas de leur faute parce qu'en fait ils achètent la machine a quelqu'un d'autre? La blague…
[^] # Re: Le libre n'est pas viral
Posté par freem . En réponse à la dépêche L'accord cadre « Open Bar » Microsoft/Défense en cours de renégociation. Évalué à 1.
Le pendu alors?
Techniquement parlant, il y a quand même une boucle et 3 conditions, c'est plus compliqué que juste afficher un texte :P
A part ça, y'a pleins de logiciels qui sont encore moins complexes et qui doivent utiliser des bibliothèques. Un exemple bête, imagines un frontend de ls: il exécute ls, il récupère la sortie et l'affiche de façon graphique. L'intérêt? Il ajoute des cases à cocher avec les options genre :
et permets donc de bâtir des commandes ls a des gens qui ne savent pas se servir du man ni de l'auto-complétion.
Mais, j'admets, c'était juste pour t'embêter :=)
Plus sérieusement, on peut considérer que les bibliothèques elles-même sont des programmes, et certaines doivent bien être basées sur la lib standard. Mais bon, c'est hors-sujet et n'a rien à voir avec le fait que la GPL soit virale (ce qui est un fait, même qu'elle est faite pour)
[^] # Re: :/
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Que veux-tu, certains aiment ne lire qu'un seul fichier à la fois. Je me demande comment ils font pour fusionner des dépôts rapidement par contre. Avec 2 écrans, un par fichier? Mouarf
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par freem . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2.
Je me doutais un peu de ta réaction, mais c'est un choix réfléchi :)
Ça dépends.
Ils le sont si tu sélectionnes les outils de bases lors de l'installation du système, mais il se trouve que c'est quelque chose que je ne fais plus depuis bien longtemps (cela dis, il semble que j'ai installé anacron sur ma machine, je sais pas pourquoi. J'imagine que je voulais jouer avec et que j'ai omis de le supprimer :) ).
Il semble que leur principal usage soit de compresser les journaux trop vieux, et je dois admettre que vu le peu d'usage que je fais des journaux (je les lis jamais: je sais c'est mal) je me moque un peu de leur présence.
En gros, j'ai 3 lignes le 26 avril, et pleins le 1er mai. Rien d'autre, et pourtant ce système est bien plus vieux. Aucune info sur ce qui est fait exactement.
Ces tâches sont loin d'être nécessaires. Cron (et consort) sont des dépendances de logrotate, lui-même n'étant qu'une dépendance recommandée du système (de rsyslog en fait), rien de plus.
De même qu'aptitude recommande apt-xapian-index (dont je ne vois absolument pas l'intérêt et que je n'installe donc jamais), qui ensuite dépend du paquet python-apt n'implique pas que python-apt est un outil nécessaire au bon fonctionnement du système.
Il y a exactement 19 paquets qui dépendent directement d'anacron (flemme de regarder pour cron, mais si ils ont été bien fait, ça devrait être pareil) dont 10 pour lesquels il s'agit d'une dépendance, 4 qui le recommandent, et 5 qui le suggèrent.
Les 10:
Les 4:
Les 5:
Dis-moi qu'est-ce qui, dans ces logiciels, est réellement vital au système? Pour moi, rien… D'ailleurs, comme je l'ai dis, je fonctionne habituellement sans (et vais d'ailleurs re-supprimer cet outil dont je n'ai que faire).
Dans l'ensemble, je suis d'accord.
Mais pas sur du matériel bas de gamme, même moderne, comme l'est mon eeepc (par moderne, j'entends pas "tout neuf", mais avec des générations de matos ayant encore cours, comme les proc x64 bi-coeur multi-thread par exemple. La quantité de RAM ne me semble pas avoir grand chose à voir avec la modernité par contre. Mais sa techno, si: la DDR3, ça va encore non? Il semble que la DDR4 soit prévue à la vente grand public pour 2015 après tout…).
Probablement, mais je suis encore un débutant sous linux (ça fait que 3 ans que j'ai switché mon OS principal, et j'ai encore pas mal a apprendre pour qu'il fasse de plus en plus uniquement ce que je lui demande, de façon optimale).
Enfin bon, plutôt que de jouer avec les priorités des processus, le plus simple et le plus efficace reste de sélectionner des logiciels qui font ce qu'on leur demande, tout en étant moins gourmands.
Dans le cas de la compilation, clang++ à juste banni g++ de mes habitudes.
Dans le cas des processus d'init, je trouve encore un intérêt et un rôle utile à sysVinit, bien que je ne serais pas contre une solution de remplacement qui soit capable de lire les fichiers utilisés par systemd, mais qui n'apporte pas de dépendances dont je n'ai que faire. Et dont je ne suis manifestement pas le seul à n'avoir que faire: quand le sujet est abordé sur la ml de debian, je constate que je ne suis pas le seul a éprouver des réticences à installer dbus et autres truckit.
J'ai effectivement entendu parler de ça, et c'est d'ailleurs pourquoi mon avis sur systemd est très mitigé:
* d'un côté il crée des dépendances dont je n'ai pas l'usage et à un coût réel d'exécution
* d'un autre côté, il permets d'améliorer pas mal de choses: facilité de maintenance des scripts d'init, parallélisation du démarrage des services, montage des partitions à la demande, arrêt/démarrage des services pour qu'ils ne fonctionnent que si on en a besoin.
La plupart de ces avantages sont très très utiles pour un serveur, je pense (y compris le temps de démarrage réduit: quand un serveur doit redémarrer, autant que ça soit le plus bref possible), mais pour une machine d'utilisateur final, à part quelques services à lancer à la demande comme cups, samba, ou les outils des DEs (sur-?)évolués comme KDE/Gnome, l'intérêt est restreint. Et ces mêmes outils ne sont pas forcément utiles à toutes les machines.
D'ailleurs, je me demande si cups+samba+sysVinit consomment autant que systemd seul? C'est une vraie question hein, vu que je n'utilise pas les 2 démons cités, je n'ai absolument aucune idée de leur consommation.
Reste ssh, que je démarre généralement quand j'en ai besoin (c'est à dire uniquement quand je suis chez moi et que je me sers du PC portable comme d'une télécommande pour la tour). Selon top, au repos, il consomme 1Mo, à peu près…
Je suis conscient de cet avantage (comme dit plus haut) mais je me demande si la RAM ainsi économisée compense réellement la surcharge induite par l'usage de systemd sur un poste d'**utilisateur final et normal** genre bureautique (la moyenne des utilisateurs utilisent quoi, à part quelques jeux, un navigateur web, et un logiciel de traitement de texte?).
Sur un serveur, je n'en ai aucune idée. De prime abord je dirais que oui, vue la quantité de services lancés, mais à bien y réfléchir, de nos jours la tendance semble plutôt être a 1 service par serveur virtuel, avec N machines virtuelles installées par serveur physique (voire par grappe de serveur physiques) histoire de réguler la charge. Après, je ne connais pas trop ce domaine donc… je dis sûrement de la merde :D
Sur un poste de développeur web, ça me semble évident que systemd soit intéressant, vu que j'imagine qu'il faut utiliser des serveurs de diverses sortes régulièrement pour tester. Pour un poste de dev "classique" par contre, je ne vois pas l'intérêt.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Relis un peu plus haut. La dernière fois que j'ai eu affaire à ce truc, ça a été loin d'être si évident. Bien entendu, ça remonte à plusieurs années et, depuis, mes connaissances et les logiciels que j'utilise on pas mal évolué (j'ai notamment découvert cmake, moi qui ne connaissais que la compilation via les IDE ou en ligne de commande à cette époque).
Je suis conscient qu'ils ont un gros héritage technique, qu'ils ont manifestement (à en lire les réponses) plutôt pas mal réussi à gérer et surtout réduire (modularité du code, notamment).
Je suis aussi conscient que C++11 est bien trop récent pour qu'ils en utilisent les nouveautés dans le coeur (quoique, vu qu'ils se basent sur des outils libres, peut-être qu'ils ont une branche stable ou c'est supporté?) mais il me semble que depuis 2003 (date du standard précédent) il est possible de faire la même chose que ce que Qt fait (au sujet des signaux je parle bien entendu) sans utiliser cet outil.
Pour le coup, oui, je trouve ridicule de conserver cet outil.
Au fait, je me demande ce que donne l'utilisation de cmake sous windows? Avec nos distros linux, cet outil voit sa tâche largement facilitée par le fait que les fichiers de dev soient dans des endroits standards, mais sous windows, ce n'était pas encore le cas la dernière fois que j'ai regardé.
Faudra que je teste, peut-être demain, je dois bien avoir une vieille licence d'xp qui traine…
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -5.
Il y a aussi des framework qui n'imposent pas de restriction aussi ridicule. J'irai même jusqu'a dire que Qt est le seul à le faire…
[^] # Re: Re: Quelles distributions utilisent systemd par défaut ?
Posté par freem . En réponse au journal SystemD et Arch autosuggestion. Évalué à 2.
LILO :)
Grub2 est devenu pénible à configurer, d'où mon passage à LILO.
Attention, passage truffé de suppositions ;)
Je crois que c'est justement ce qui bloque pas mal d'opposants.
Quel intérêt de changer pour un composant qui fasse plus de choses si on ne s'en sers que comme d'un système d'init?
Par exemple, tu cites cron. Très bien, mais sur mes machines je n'utilise pas cron, je n'en ai pas l'utilité: j'éteins mes bécanes (oui je sais, je pourrais utiliser l'hibernation. Mais même dans ce cas, on peut utiliser les scripts j'imagine) quand je m'en sers plus, donc si j'ai besoin de faire quelque chose régulièrement je peux facilement le mettre au moment du boot ou de l'extinction. La plupart du code contenu dans les scripts d'init sers à gérer un service: pour une simple "tâche évènementielle" je pense que ce n'est pas nécessaire de s'encombrer de toute la structure "start/restart/stop/status" si le but est juste de lancer une tâche.
A bien y réfléchir, la mécanique des runlevel est plus puissante que je l'imaginais… j'ai encore trop de réflexes de mes années windows et je n'aurai pas imaginé avant ce message utiliser les runlevels pour planifier une action à l'extinction de ma machine :)
Je pense que là, on met le doigt sur un autre problème, justement. Ce que je vais dire rejoins assez ce commentaire d'une autre autre dépêche: quel intérêt pour un ordinateur de bureau utilisé par quelqu'un de normal?
Lancer une tâche toutes les 20 minutes ou à heure fixe? Je ne vois personne dans mon entourage qui le fasse… Bien sûr, pour faire des mises à jour automatiques sur une machine qui est toujours allumée, c'est utile. C'est aussi super sur un serveur qui doit faire des backup réguliers et n'a comme réelle donnée pour savoir quand que le temps.
Mais voila, tout ça, c'est super pour des serveurs (ou même du matériel embarqué), pour un ordinateur de bureau c'est bien plus contestable.
systemd est une avancée mais surtout pour ceux qui administrent des serveurs ou des machines professionnelles, qui ne s'éteignent jamais. Pour les autres utilisateurs qui ne veulent qu'activer/désactiver des services au lancement de la machine, je n'en suis pas sûr: renommer /etc/rc2.d/S02mpd en /etc/rc2.d/K02mpd n'est pas complexe, et je parie qu'il existe des GUI pour le faire (enfin, non, je parie pas, je sais qu'il y en a au moins une, mais impossible de remettre la synapse sur son nom…).
Sur la citation que tu as faite, je parlais d'une tendance générale dans l'industrie du logiciel, et pour être précis d'une tendance qui tends à m'exaspérer fortement, pas de systemd en particulier.
Pour en revenir à systemd et son augmentation de 30Mo, ou mieux, en prenant ton test Debian/ArchLinux, j'ai toujours préféré les données relatives: 30Mo supplémentaires ne veulent rien dire en soit, je préfère parler de 100% d'augmentation.
Ca parle beaucoup plus ainsi.
Par exemple, si on parle d'une augmentation de la consommation de 30Mo de LibreOffice d'une version X à une version Y, si la version X consommait 1000Mo (j'invente hein) alors ce n'est une augmentation que de 3%. Pas loin d'être négligeable donc. Alors que la version X consommait 30Mo, et la version Y passe à 60Mo, il vaut mieux que le gain en fonctionnalités vaille le coup pour moi. (surtout que dans un cas comme dans l'autre, rien ne dis que j'utiliserai ces nouvelles fonctionnalités)
Dans le cas de systemd, ça semble être le cas… même si suis assez sceptique sur la nécessité de certaines dépendances en dur que je n'utilise pas (je pense ici à dbus). Encore une fois, c'est une simple augmentation de 30Mo de la consommation de ma machine (j'invente, encore) mais si je dois rajouter une consommation moyenne de 60Mo, ça peut vouloir dire que ma machine va beaucoup plus swapper quand je compile, et le disque dur est d'une lenteur impressionnante, et quand j'utilisais GCC pour compiler autorealm, si je voulais utiliser mon CPU à fond (avec 4 thread donc) ma machine devenais complètement hors de contrôle pendant près de 15 minutes (du coup je tournais à mi-régime et ça compilait en +/-4 minutes. J'ai ensuite découvert clang, et je suis passé à +/-2 minutes :) )
Je pourrais acheter de la RAM bien sûr, mais dans ce cas c'est l'autonomie de ma batterie qui va diminuer il me semble.
Enfin, je ne suis pas un expert sur la question… mais je pense que si systemd est bel et bien une avancée sur pas mal de points, il a malgré tout des conséquences négatives qui font qu'il faut qu'un autre système d'init, un qui ne fasse que ça, soit toujours maintenu. Peu m'importe que ce soit sysVinit, openRC ou je ne sais quoi, mais j'adhère assez à la philosophie UNIX qui dit que les programmes efficaces ne font qu'une seule chose mais la font bien (ça ne m'empêche pas de voir qu'il y a plein de contre exemples).
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -3.
J'aurai dû ajouter l'adjectif "rares" :) (et le fait que la seule dépendance que j'aie eu pour le moment est envers la lib "system" qui est devenue partie intégrante du standard. Mais je suis loin de les avoir toutes utilisées…)
Et si on continue sur les points forts de boost, il faut préciser que la plupart de ses lib ne sont que des headers. Niveau simplicité d'usage, on peut difficilement faire mieux (et Qt passe donc hors catégorie sur ce point, voir la suite).
On dirait que ça a bien évolué alors. Tant mieux. Plus que la chaîne de compilation à simplifier, alors?
Parce que ce point à été (et restera encore un certain temps je pense) un vrai point bloquant.
On peut dire ce qu'on veut, mais la mécanique des signaux si chère à Qt possède ce défaut majeur qui est de rendre la compilation bien plus casse-pieds, alors que les autres framework s'en passent très bien.
Dès lors que tu ne veux pas utiliser l'IDE officiel, tu galères. En tout cas, à l'époque de mon BTS KDevelop galérais (y'a 7 ans en gros) lui qui était pourtant écrit avec Qt (je me rappelle qu'il fallait invoquer l'outil à la main… moc, c'est ça?), il y a 3 ans Visual Studio 2008 galérait (je sais pas maintenant si c'est plus simple, mais j'en doute), Code::Blocks galèrait encore y'a 3 ans, utiliser la ligne de commande sous windows imposait d'utiliser une ligne de commande customisée par et pour Qt (mais qui ne connaissais du coup que les modifs faites par et pour l'installateur de Qt, irrecevable pour moi)…
Il n'y a bien que Qt Creator et CMake qui ne galèrent pas. Pour le coup, vu que je n'utilise plus trop d'IDE, je pourrais peut-être m'y remettre, mais l'idée de risquer d'en chier avec la compilation pour une fonctionnalité dont tout les autres framework se passent allègrement me rebute.
J'imagine qu'on va me dire qu'il utiliser l'outil qu'une seule fois et blablabla… mais de mémoire, il faut l'utiliser à chaque modification de l'interface, ce qui peut arriver souvent… Enfin, arrivais, avant l'arrivée des technos ou l'interface n'est plus codée en dur. Mais là encore, les autres le font aussi bien sans ajouter leur outil dans la chaîne.
Ce qui est certain de toute façon, c'est que pour au moins un projet que j'aimais bien (rolisteam), et pour lequel j'avais envie de contribuer et tant pis pour la lib Qt sous-jacente que je ne maîtrisais pas (j'avais des souvenirs du BTS mais ça datait déjà) je n'ai jamais réussi à compiler, sauf à utiliser QtCreator, mais ce truc n'a vraiment jamais été à mon goût, moi qui préfère les interfaces minimalistes.
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Pourquoi ne pas laisser au noyau la charge de faire son boulot efficacement, c'est à dire: gérer les processus?
[^] # Re: Le libre n'est pas viral
Posté par freem . En réponse à la dépêche L'accord cadre « Open Bar » Microsoft/Défense en cours de renégociation. Évalué à 1.
Pour le jeu ou il faut deviner un nombre aléatoirement choisis, tu utilises autre chose que la lib standard toi?
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à -5.
Pour faire court: j'apprécie quand les outils que j'utilise ne sont pas liés les uns aux autres.
Je considère que si jamais je détecte un bug dans un tel outil, je peux le corriger.
Ça m'est d'ailleurs déjà arrivé, parce qu'un outil n'intégrant pas 10 000 fonctionnalités différentes, autrement suivant les principes du KISS, est bien plus simple à fixer.
Voila pourquoi je n'apprécie pas les gros framework comme Qt ou WxWidgets (contrairement à ce que j'ai pu laisser entendre pour des fins de trollage :p).
Vu que j'ai pas le choix, je m'en sers, mais c'est principalement parce que je ne connais pas de bibliothèque de toolkit n'accomplissant que leur tâche.
Oui, dans l'absolu, je préfèrerai un outil qui me permette de gérer les thread, un autre qui gère la traduction, un différent pour l'IHM, un distinct pour l'encodage, etc…
Même qu'ils soient regroupés sous un même nom, tant que je peux les utiliser complètement indépendamment les uns des autres, comme pour boost (quoique, certaines lib boost dépendent d'autres lib boost).
A mon sens, Qt est un langage qui ne s'assume pas: modification de la chaîne de compilation, ré-implémentation et volonté de remplacement de la STL, etc.
Il me semble idéal pour remplacer Java quand on veux plus de perf, en échange d'une syntaxe un peu plus complexe, par exemple.
Langage basé sur le C++, et qui se compile en générant du C++ ok, mais c'est bien ainsi que C++ à commencé: ça ne faisait que générer du C à partir de code C++, grâce à l'outil cfront. Ensuite, j'imagine qu'il fallait encore compiler…
[^] # Re: Vu de l'intérieur
Posté par freem . En réponse à la dépêche L'accord cadre « Open Bar » Microsoft/Défense en cours de renégociation. Évalué à 3.
Et celui du compilo qui compilera leur compilo.
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par freem . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 1.
D'ac, j'ai donc du confondre avec ceux des entrées/sorties. Merci de l'info.
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par freem . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 1.
Il y a juste un point qui m'intrigue dans le document que tu cites (le 2nd):
La dernière fois que j'ai fouillé dans les options de compilation du noyau il me semblait pourtant avoir vu plusieurs schedulers ?
C'est pas comme si je remets en cause les dires du monsieur, vu ma compréhension (ou mon manque de compréhension plutôt) de la chose, je m'abstiens volontiers, mais j'aimerai comprendre tout de même…
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par freem . En réponse à la dépêche Sortie du noyau Linux 3.9. Évalué à 6.
Oh, allez…. c'est pas comme si on pouvait pas parler de systemd sans déclencher un troll quand même si?
[^] # Re: œuf dur
Posté par freem . En réponse au message Installer une distrib 32b ou 64b sur portable 64b ?. Évalué à 3. Dernière modification le 29 avril 2013 à 14:03.
Sous Debian stable aussi, mais ça va passer en multiarch très prochainement (prochaine release), ce qui signifie qu'au lieu de n'avoir que ia32-libs, tu vas devoir installer toutes les dépendances en version i386, et tant pis si tu les as déjà en amd64 manifestement. (y'a eu pas mal de bruit sur la ml à ce sujet)
Vu qu'Ubuntu est basée sur Debian, j'imagine qu'ils vont suivre le mouvement… bien que je sois surpris que ce ne soit pas déjà le cas, vu qu'en théorie ils sont basés sur debian sid qui utilise ce principe depuis pas loin d'un an…
[^] # Re: RAM
Posté par freem . En réponse au message Installer une distrib 32b ou 64b sur portable 64b ?. Évalué à 1.
En fait, il me semble que ça dépende d'une option du kernel (IA332), mais je ne suis pas un expert.
http://www.sysresccd.org/Kernel
En fonction de la distribution utilisée, cette option peut être présente ou pas, mais il y a aussi le problème des dépendances utilisées. Je pense que tu sais qu'il existe plusieurs façons de gérer ça. Dans le cas de Debian, la stable actuelle utilise une lib dédiée qui sert à faire la jonction entre les 2 mondes, tandis que l'actuelle testing nécessite l'installation des libs en version 32 bits.
Ce n'est donc pas si évident que tu ne sembles l'indiquer: si on utilise majoritairement des logiciels 32 bits (genre skype ou via wine) il peut être intéressant d'utiliser une distro 32 bit, même si personnellement je préfère les 64 bit.
Il y a eu une discussion sur la ml debian internationale au sujet du 32 bit, il faudrait que je la retrouve. (Il me semble qu'un certain Ralf avait fait une réponse très instructive sur les intérêts du 64 bit)
[^] # Re: Trollons
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Evidemment que le thread est mieux dans ce cas. Maintenant, décompresser un fichier n'a pas grand chose à voir avec l'IHM que je sache…
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.
Le problème est que les évolutions coûtent parfois une quantité déraisonnable de ressources, et certains, dont je fais partie, considèrent que ça ne devrait pas être le cas.
Mais effectivement, j'ai fini par sélectionner plus rigoureusement mes logiciels pour ne pas avoir de fonctionnalité qui ne me sert à rien et ainsi alléger l'ensemble.