liberforce a écrit 4733 commentaires

Pousser des utilisateurs à aller dans une seule direction décidée par une équipe de développeurs pour des raisons purement techniques ou bien répondre à un besoin utilisateur loin d'être stupide ?

Qui t'a dit que c'était purement technique ? C'est aussi un choix de design. De plus, comment tu estimes le besoin "loin d'être stupide d'un utilisateur" ? Pourquoi le tien serait plus important que celui d'un autre utilisateur ? Pourquoi le développeur qui ne veut pas conserver cette fonctionnalité devrait le faire ? Ce n'est pas juste un caprice: c'est un choix assumé de leur part.

Mes vieux sous KDE (avant) et sous Unity n'ont pas de bureau… Ils enregistrent tout à l'arrache dans ~ malgré le présence des dossiers XDG.

On sait tous que dans le futur de toute façon, même ça risque de disparaître au profit d'un moteur d'indexation, ou de quelque chose directement d'intégré dans le FS…

Un autre soucis du bureau, c'est garder dans le gestionnaire de fichiers du code spécifique pour la gestion de cet unique cas particulier. C'est autoriser le placement des icônes où on veut, là où on ne l'autorise pas d'habitude. Du coup → + de problèmes de maintenance → + de bugs.

Je suis tout à fait d'accord avec ces développeurs. Un des trucs que je détestais dans Windows, c'était le fait que le menu démarrer était tellement bordélique que toutes les applis te demandaient à l'installation de mettre un raccourci sur le bureau (sous-entendu: pour les retrouver plus vite). Le soucis: si tout le monde fait ça, c'est vite le bordel, et au final tu ne retrouves rien. Le bureau représente pour quantité de gens "la zone où ce n'est pas encore rangé". C'est son plus gros problème: quantité d'utilisateurs ne rangeront tout bonnement jamais rien, et laisseront un maelström infâme de fichiers divers, et de résidus de téléchargement sur le bureau. Sous Windows, le bureau n'était aussi pas un dossier associé avec les documents utilisateurs, et donc souvent situé une autre partition. Résultat: après un crash sur une machine que tu dépannes, tu as beau sauvegarder le dossier censé contenir les documents utilisateurs, tu perds tous ceux du bureau si tu ne fais pas gaffe. Or celui ci contient 90% des fichiers dudit utilisateur, c'est ballot. Oui, ça sent le vécu.

On va me dire que c'est un problème de Windowsien. J'en étais en effet suite à cela arrivé à détester ce foutu bureau, même sous Linux. Exemple idiot: tu réduis toutes les applications ouvertes pour pouvoir accéder au bureau pour lancer une application. Tu ouvres cette application, et veux restaurer celle que tu viens de réduire (Ctrl+Alt+D sous GNOME 2). Bien souvent ça ne marchait pas, parce que tu avais ouvert une nouvelle fenêtre. Mais en plus, les gens normaux n'utilisant que très peu les raccourcis clavier, il fallait une icône pour ça. En plus tu te retrouves avec 2 workflows différents pour accéder à tes fichiers. Tout ceci a été réglé en donnant un unique point d'entrée pour les applications, et un unique point d'entrée pour les fichiers. Dans GNOME 2, accéder à tes fichiers, c'est juste aller dans le menu "raccourcis", et sélectionner celui qui contient les fichiers qui t'intéressent. A toi de définir ceux que tu utilises le plus souvent, afin d'avoir ce que tu souhaites en 2 clics. Dans GNOME 3, c'est le même esprit: tes applications favorites sont accessibles toujours au même endroit (dans ton dock), et tes dossiers préférés sont accessibles en 1 clic dans ton navigateur de fichiers.

Je trouve que les icônes sur le bureau, c'est l'incitation à la paresse: on laisse du bordel, on triera plus tard. Certains utilisateurs s'accommodent très bien de cela. D'autres utilisateurs (les moins à l'aise avec l'informatique) ne s'en sortiront tout bonnement pas. Laisser une possibilité aussi proéminente à l'utilisateur de base de se tirer une balle dans le pied n'est à mon avis pas une bonne idée. Un des problèmes les plus fréquents chez les utilisateurs les moins expérimentés, est qu'ils ne savent pas retrouver leurs fichiers. Parce qu'ils ne savent pas les ranger. Du coup, ils utilisent le bureau comme endroit où "là au moins ils savent où c'est parce que c'est sous leurs yeux". Comment mettre en avant les dossiers XDG, censés les aider à trier leurs données tant qu'ils continuent cette mauvaise habitude ? Le seul moyen est de supprimer cette possibilité, l'utilisateur expérimenté étant en capacité en général de contourner la limitation.

D'ailleurs, en 1 minute, je vois au moins 2 possibilités de contourner cette "limitation" (j'appellerais plutôt ça un garde-fou salvateur, mais bon): une extension GNOME Shell: https://extensions.gnome.org/extension/237/desktop-icons-switch/
Dans le commentaire de l'extension, il est indiqué que l'utilitaire gnome-tweak-tool peut également être utilisé. Et pour ceux qui apprécient réellement cette disposition, je leur conseille la clé desktop-is-home-dir qui affiche sur le bureau le contenu de ton $HOME au lieu de $HOME/Bureau.

Quant au fait que cette possibilité disparaisse… Les développeurs ont souvent des moyens limités pour la maintenance, et quand ils voient quelque chose qui leur semble mauvais dans leur application, ils ont tendance à le supprimer pour alléger/simplifier le code.

Il vaut savoir avancer. J'aimais beaucoup la vues spatiale de Nautilus introduite dans GNOME 2.6. Depuis, elle a été supprimée, je me suis adapté, et au final, pas grand chose n'a changé, mon workflow a évolué, et une fois que tu as compris comment utiliser les choses, tu n'es pas moins efficace.

Si tu arrives à te débarrasser de ça, je sens que tu vas être content à en faire des cumulets ! :-D

Tu peux jeter un coup d'œil à Anjuta. Mais un bon éditeur + un Makefile de base, ou un générateur de Makefile type CMake fait bien l'affaire aussi. Perso, j'utilise vim + ctags, avec un Makefile à la main (2 lignes), ou CMake. Les options, franchement apprendre à caser -Wall -O2, ça me paraît pas surhumain.

Tu veux dire que le calcul de taille est récursif par défaut ?

Ils ne peuvent pas "rebooter" l'affaire via HADOPI, en revanche les ayants droits peuvent se retourner contre l'épouse en intentant un procès en contrefaçon. Ils sont sûrs de gagner, elle a avoué, puisqu'elle a attesté sur l'honneur l'avoir fait.

Je ne crois pas, il me semble avoir lu sur pcinpact également que la HADOPI laissait de côté ceux qui téléchargeaient comme des porcs, parce qu'ils laissaient ça aux ayants droit pour qu'ils poursuivent pour contrefaçon. Donc il ne leur reste que les petits poissons, et forcément, toutes les histoires risquent de se ressembler… Ça ne va pas améliorer l'image de la HADOPI, qui se vante d'avoir bien rempli sa mission. 12M€ investis pour condamner des voleurs contrefacteurs de bonbons…

On notera surtout que sa femme a fait une déclaration sur l'honneur pour indiquer que c'est elle qui avait effectué le téléchargement illégal. On a donc un innocent qui se fait condamner, grâce à cette magnifique invention qu'est le « défaut de sécurisation ». Si ta voiture se fait flasher, et que c'est pas toi qui conduit, que le conducteur se dénonce, c'est lui qui raque. Ici, il se dénonce, mais c'est quand même le propriétaire de la bagnole qui est déclaré coupable et qui raque.

Justice, où es-tu ?

Pour info, il y a eu une conf sur Opus lors de la GStreamer Conference 2012: voici les slides et la vidéo.

Merci de faire vivre le site !
Au fait Xate, t'aurais le temps pour fêter ça autour d'une mousse à l'occase ? :-p

En indiquant pour quelle catégorie le film est destiné, est-ce qu'il ne remplirait un rôle d'information et de déresponsabilitation juridique ?

En plus si les imprimantes 3D se développent bien, dans quelques années je la télécharge moi la voiture :-p

C'est en effet pour du streaming, le but à atteindre étant la faible latence. Mais il est possible de transmettre de la musique de cette manière, le codec ayant été étudié pour s'adapter à la bande passante nécessaire. La partie d'Opus inspirée du codec Silk gère la voix, la partie inspirée de CELT gère la musique.

A priori Opus a pour vocation d'être plus flexible que CELT, mais je n'ai pas vu dans l'article sur la cohabitation ou l'obsolescence de CELT.

Opus n'est pas un format de fichiers, comme MP3. Il est conçu pour l'audio en temps réel […]. Il est prévu pour un grand nombre d'utilisations audio distinctes : téléphonie sur IP, mais aussi, par exemple, distribution de musique en temps réel. Il est prévu pour être utilisable lorsque la capacité du réseau est minimale (dans les 6 kb/s) aussi bien que lorsqu'elle permet de faire de la haute fidélité (mettons 510 kb/s, cf. section 2.1.1). Ses deux principaux algorithmes sont la prédiction linéaire (plus efficace pour la parole) et la transformation en cosinus discrète (plus efficace pour la musique).

[Opus] a deux « couches », LP (prédiction linéaire) et MDCT (transformée en cosinus discrète). L'une ou l'autre (ou même les deux en même temps) est active pour encoder le signal audio, donnant ainsi à Opus la souplesse nécessaire. La couche LP est dérivée du codec Silk. Elle permet le débit variable mais aussi le constant (section 2.1.8). La couche MDCT, elle, est basée sur CELT.

Pas d'accord, c'est une info qui a un rapport avec le libre, et qui montre de plus que commercial et libre ne sont pas incompatibles. Je pense que de nombreux lecteurs de Linuxfr aimeraient pouvoir vivre du libre. Le fait que tu aies recherché un modèle économique, franchi le pas alors que cela a dû traverser l'esprit de pas mal de monde est très intéressant. Donc n'hésite pas à nous donner des nouvelles de la réussite ou des difficultés de ton projet, ou à faire un retour d'expérience dans un journal sur les grandes étapes de la création de ton activité.

Il semble que oui. D'après Wikipédia c'est Xiph.org et Skype qui en sont à l'origine:
Opus_Interactive_Audio_Codec

Comme dit en dessous, tu passes à côté du problème. Si realloc renvoie NULL, tu auras un SEGFAULT la ligne suivante, dès qu'on essaiera d'écrire avec sprintf. Du coup ta fuite mémoire vient forcément d'ailleurs.

Transposition au suffrage universel, toussa…

Init répond à une problématique simple, permettre de lancer des services simplement, les uns à la suite des autres
Systemd répond à une autre problématique

Et après on se demande pourquoi systemd c'est bien… Peut être pour lancer lesdits service en parallèle, sans avoir à gérer les dépendances dans les scripts ? Gérer du chargement à la demande, ce qui permet d'économiser des ressources ? Ne pas lancer n instances de shell ? Les seuls à avoir une bonne raison de gueuler, c'est les admins dont les habitudes changent, et les *BSD qui de toute façon queulaient déjà parce que udev était spécifique à Linux. Mais qu'on ne vienne pas me dire que techniquement, systemd est juste différent de ce qui se faisait. C'est pas juste différent, c'est surtout plus performant !

Je pense que toutes les distributions devraient continuer à maintenir les deux systèmes.

Cool. C'est toi qui files un coup de main pour la maintenance ?

La conception est bizarre aussi (dépendance à Linux etc)

C'est sûr, c'est super étonnant qu'un système d'init cherche à tirer parti de toutes les fonctionnalités de l'OS plutôt que d'un sous-ensemble… =)

Il n'essaie pas d'imposer Linux. Ce qu'il veut, c'est pouvoir tirer parti de fonctionnalités performantes, qui sont parfois spécifiques à Linux. Or, si tu dois faire un système qui est compatible avec tout le monde, tu dois te limiter au plus petit dénominateur commun. Tu perds donc soit en fonctionnalité, soit en vitesse. Mais le but même du bazar c'est d'être le plus rapide possible ! Pour faire un boulot efficace, il faut donc une version spécifique à chaque OS, et il ne veut pas s'amuser à les développer et les maintenir lui même, ce qui peut se comprendre.

J'adore ce type de questions… J'ai oublié ma boule de cristal chez moi, et comme tu as l'air de penser que nous habitons tous dans ta tête et que par conséquent nous savons tous de quoi tu parles, c'est assez difficile de répondre.

Si tu prenais un peu plus de temps pour décrire exactement ton problème, et ta configuration, ce serait plus facile pour nous de prendre du temps pour te répondre, qu'en penses tu ?

http://www.linuxfr-france.org.invalid/article/these/smart-questions/smart-questions-fr.html

Bin quand t'as lu le bouquin, ça pique les yeux, c'est tout. M'enfin j'ai rien contre TMX, j'ai tous ses albums.

Ah oui mais non, c'est John Caffey en VF. M'enfin TMX a jamais brillé en orthographe.

Oui enfin faut pas oublier la réponse de Miguel, parce que Allan Cox et Linus se sont un peu enflammés:

Linus, My involvement with Gnome stopped about five years ago, and I merely stayed in the periphery because I used Gnome as a user and we built C# programs that used Gnome libraries. So it is unfair to the Gnome guys to attach my position to their project.