Pour utiliser Linux depuis de nombreuses années, j'ai longtemps été plus que satisfait par ce système (exploité sous KDE), mais plus de 15 ans après, j'ai l'impression que son évolution n'a pas été à la hauteur de ce que j'en espérais. En effet, Linux ne m'offre toujours pas des fonctionnalités pourtant utiles et répandues chez la concurrence depuis des années, et – pire – n'a pas vraiment fait mieux sur des points ergonomiques pourtant de premier plan. Pire ! Des fonctionnalités pourtant appréciées depuis des années sont régulièrement retirées sous couvert de simplification, ou des logiciels parfaitement fonctionnels remplacés par d'autres réécrit de 0, et pas exempts de défauts.
J'allais m'apprêter à conchier Linux, KDE, et l'écosystème du Libre avec force et arguments, mais j'ai été appelé à la rescousse par ma charmante voisine pour un problème informatique, et j'ai passé ma soirée entière à dévéroler du Windows 8 et Windows 7…
Putain, que j'aime Linux !
N'empêche que depuis tout ce temps, j'aimerais bien que mon bureau linux me permette enfin d'accéder à l'agenda lorsque je clique (ou clic droit) sur un jour du calendrier, de manière à y inscrire directement un rendez-vous, ou qu'il soit enfin possible d'avoir un vrai NetLimiter en espace utilisateur (trickle est à des années lumière d'un NetLimiter), qui permette enfin de régler dynamiquement les limites de bande passante de chaque téléchargement/accès réseau individuellement ou de leur ensemble, ou encore d'avoir ses foutus signets partagés localement entre tous les navigateurs de manière standardisée sans avoir à faire des imports/exports ou synchronisations et sans dépendre d'un service en ligne, ou encore qu'un grand ménage soit enfin fait dans le bordel des fichiers de configuration et de données des applications dans le home/, par exemple et pour ne me contenter que des remarques sur la souplesse ergonomique que j'ai encore en tête.
Mais en fait ça va, je crois que je vais être patient encore un moment…
Bonne soirée et bon week-end, loin de toute fenêtre et en bord de mer pour ma part ! :-)
# Correction
Posté par Foutaises . Évalué à 2.
« j'aimerais bien que mon bureau linux me permette enfin d'accéder à l'agenda lorsque je clique (ou clic droit) sur un jour du calendrier »
[^] # Re: Correction
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# xdg
Posté par saltimbanque (site web personnel) . Évalué à 10.
Hormis que ça n'a probablement aucune importance, y'a eu du progrès.
Par exemple depuis $HOME
ls -la | wc -l
66
[buddho@localhost ~]$ ls -la .config | wc -l
41
[buddho@localhost ~]$ ls -la .local/share | wc -l
44
[buddho@localhost ~]$
[buddho@localhost ~]$ ls -la .cache | wc -l
39
En tout cas je remarque qu'en tout premier lieu je zieute dans ~/.config avant tout autre lieu.
[^] # Re: xdg
Posté par Astaoth . Évalué à 1.
Ce qui manque avec xdg, c'est une gui pour le configurer. Sinon j'ai déjà eu des bugs alakon du genre un nombre infini de process xdg-open lancé, et d'autres qui se lancent en continu, au point de réussir à utiliser toute ma ram.
Emacs le fait depuis 30 ans.
# signets synchro? Facile!
Posté par freem . Évalué à 6.
Pas moi. Je n'utilise quasiment pas linux, ou plutôt, je ne l'utilise pas de manière consciente. J'utilise Debian, ouai. Linux, uniquement parce qu'il se trouve que c'est le kernel que Debian utilise. Ça pourrait être un BSD, que ça me poserais pas plus de soucis que ça. Ce que j'aime, au fond, c'est les émulateurs de terminal 1000 fois supérieurs à celui de windows, l'interpréteur de commande bash qui est tellement puissant qu'il relègue la souris dans la zone du bureau ou réside la chope à bière, aptitude qui me permets de maintenir mon système au jour le jour sans installer 3 milliards de merdes et sans jamais rien casser… du moins, jamais sans me prévenir que ça va péter.
Rien à voir avec le kernel, vraiment.
Tiens, je pensais que ça existait ce genre de jouets. Les trucs style calendar le font pas? Ils sont donc encore plus inutiles que je ne le pensais, c'est triste.
C'est clair, ça serait pas mal.
Le problème, c'est que pour ça, il faudrait… hem… faire un truc extrêmement difficile pour un éco-système dont la force vient de la diversité: standardiser. Uniformiser. Pour créer une API acceptée par tous les développeurs, y compris les NIH (dont je fait partie, je le sais et je n'en ai pas honte) qui codent pour le fun (voila pourquoi j'en ai pas honte) des applications que d'autres sont libres d'utiliser ou pas.
En fait, il faudrait un PulseAudio pour le réseau. Sauf que le réseau, il est bien plus complexe à gérer que le son, puisqu'il dépend pas mal de l'extérieur. Pour ne pas dire complètement. Et PA semble avoir causé pas mal de remous comme ça… de remous et de casse si j'en crois mes lectures (mais on ne lis que ceux qui ont eu des problèmes, donc…).
Pour finir d'enfoncer des portes ouvertes… c'est au navigateur de savoir gérer sa bande passante correctement. Je doute que tu utilises 20 000 logiciels pour squatter ton réseau, pas vrai? En gros, je vois 2 types de logiciels qui exploitent régulièrement le réseau sur une machine personnelle: le brouteur, et un gestionnaire de téléchargement. Très sincèrement, c'est clair: si seulement les brouteurs intégraient un gestionnaire de téléchargement digne de ce nom, ça serait tellement plus confortable. Bon, ça réglèrai pas le problème d'apt qui squatte toute la bp quand on lance une maj, mais… ça serait déjà pas mal. Mais, pas la faute à Linux, ni même aux distros ça: ils préfèrent se concentrer sur le tape-à-l'œil, le chteumeuleu 5, pour faire plaisir à ceux qui ne savent pas trop ce dont il s'agit et ne peuvent s'empêcher de cliquer là ou ça gigote.
Hum… Si je ne m'abuse, il est trivial d'ajouter à un fichier (echo foo >> my_file) une ligne contenant un lien. Bon, ok, je chambre un poil. Certes. Mais, ce problème n'est lié ni à linux, ni à windows, ni à quelque démon obscur. Juste au fait que les navigateurs se font la guerre.
Et personne n'oserai repprocher à mozilla ou chromium de ne pas être compatibles entre eux pour leurs données internes, pas vrai?
Ah, mais, c'est ta faute ça. Pourquoi n'utilises-tu donc pas que des applications qui suivent FreeDesktopOrg? Beaucoup le font. Il ne doit pas en rester tant que ça qui ne le font pas, excepté les trucs de barbus genre vim, bash & co. Et je doute fort que les patcher soit si difficile pour changer une localisation de fichier de config, si vraiment tu ne peux te passer de ces outils (comme moi) et que ça te gêne tant que ça (pas comme moi).
Enfin bon, si je comprend bien, tu aimerais que ton bureau, te répondes au doigt et à l'œil? Et ce, sans avoir à le customiser au p'tits oignons toi-même?
Je meurs d'envie de répondre qu'il y à déjà les outils pour faire ce dont tu rêves, mais que la seule chose qui fait que ce n'est pas encore fini, c'est que ça manque de volontaire… mais on m'accuserai de te provoquer j'imagine.
Perso, j'ai trouvé une solution très acceptable: j'ai fabriqué mon DE à partir de pièces détachées trouvées dans aptitude. Ça marche super bien, c'est hyper léger, hyper réactif, je contrôle tout du bout des doigts sans bouger les poignets, c'est… le pied, si j'ose dire :)
Bref, sors-toi les doigts, la solution la plus adaptée à tes besoins existe déjà, il faut juste que tu mettes les pièces ensemble. Si tu as la flemme, très bien, mais assumes ton choix de ne pas investir ton temps pour en perdre moins par la suite. Et si d'aventure je me trompais, si tous les logiciels dont tu as besoin n'existent pas, je t'encourage à les créer, que ce soit pas toi-même, ou en les faisant faire, d'une manière ou d'une (oui, ça peut vouloir dire embaucher des gens, mais, après tout, c'est pour ton confort personnel), par les autres.
[^] # Re: signets synchro? Facile!
Posté par freem . Évalué à 4.
Allez, juste une précision (foutu timing à la con) sur le gestionnaire de tickets. Parce que, en fait, je te chambrais pas tant que ça, c'est réellement simple à gérer pour faire un truc trivial.
Via xclip. Et ton gestionnaire de fenêtre. Et Xorg.
Tu ne tilte pas?
Avec Xorg, quand tu sélectionnes un texte, il est automatiquement copié dans un presse-papier spécial. Tu colles un binding dans ton gestionnaire de fenêtre, qui utilise xclip pour ajouter le contenu du presse papier du bouton central à la fin d'un fichier HTML, qui n'est pas fini proprement (pas de
</BODY></HTML>donc). Les brouteurs sont assez malins pour s'en sortir de nos jours. T'en fais pas pour eux.Bref, tu as plus qu'à mettre ce fichier en page par défaut ou en signet dans tous tes navigateurs, et le tour est joué. Si tu veux centraliser, tu peux scriptouiller avec ssh pour synchro ce fichier, mais je suis parti pour faire un truc vraiment trivial, la on «complexifie».
Pas super clean, de la bidouille, certes. Mais, sans cahier des charges plus précis que ce que tu as donné, ça semble correspondre à ton besoin. Et me mets pas au défi de faire une arborescence, t'as un super logiciel nommé système de fichier qui sers à faire ce genre de trucs sur ta machine. Hé oui, les fichiers et les dossiers, ça fait des arbres. Donc, y'a moyen de faire un truc plus chiadé, en y passant moins de 4H, qui soit compatible avec tous les brouteurs compatibles Xorg.
Faut juste que celui qui en a besoin se sorte les doigts.
[^] # Re: signets synchro? Facile!
Posté par Zenitram (site web personnel) . Évalué à 8.
Ce n'est pas difficile, à partir du moment où il y une volonté. Par exemple, il y a une norme HTML, une JavaScript, etc… que plusieurs navigateurs intègrent, et c'est très complexe.
Avant la complexité, il faut voir la chose la plus importante avant : la volonté de vivre ensemble.
C'est la seule chose qui manque.
(LSB? FDO? beaucoup y voient des chieurs et c'est tout, et c'est une guerre d'égo)
[^] # Re: signets synchro? Facile!
Posté par freem . Évalué à 2.
Tu as oublié de citer le reste du paragraphe, qui exprime d'où viens, pour moi, une partie de la complexité:
Je n'ai pas dis que la complexité était purement technique. L'open source est globalement et, selon moi, chaotique. Je pense aussi que c'est de ce chaos qu'une partie de la force est tirée.
Organiser et standardiser l'ensemble des applications open source me semble très complexe, et pas nécessairement souhaitable: après tout, si une solution supérieure (que ce soit une supériorité par la comm' ou la technique n'est pas la question ici) se pointe, la majeure partie des projets finira par l'adopter.
On à eu des exemples de par le passé:
C'est sûr, ils ne font pas l'unanimité: certaines applications ne vont pas voir d'intérêt à adapter un code historique à ces nouvelles technologies, certains ne vont pas être d'accord avec les principes sous-jacents ou l'architecture logicielle, et cætera.
Est-ce si mal? Ces projets «dissidents» sont peut-être aussi ceux qui apporterons l'idée qui relèguera ces technologies aux oubliettes en implémentant une alternative plus efficace (peu importe que cette efficacité soit technique ou humaine). Ou peut-être pas. On ne saura pas s'ils se contentent de suivre tout le monde.
Les logiciels sont écrits par des humains. Les humains ont un égo. Rien de choquant pour moi.
D'ailleurs, je me demande quel est le ratio des applications mainstream qui sont gérées par des gens sans égo? Linux, les outils GNU, LibreOffice, Firefox, KDE, Gnome… je doute que ces projets seraient ce qu'ils sont si les personnes qui maintiennent le cap n'avaient pas un certain égo.
Bon, ok, ils n'ont sûrement pas que leur égo pour eux, heureusement. Ils ont aussi la volonté de faire avancer les choses, et la capacité. Mais il me semble probable que la capacité vienne de la volonté, qui est elle-même assez liée à l'égo.
Par contre, le nombre de journaux ou quelqu'un se contente de rappeler qu'il y à trop de fragmentation dans tel domaine ou que tel logiciel n'est pas assez parfait pour son besoin, ça pullule.
Certes, il faut un minimum d'égo pour oser les publier, mais le reste semble absent. Où est la volonté d'améliorer la situation? Et sans volonté, point de capacité pour moi.
Par exemple, si tous les gens qui écrivent ce genre de choses commençaient par se mettre d'accord pour utiliser les mêmes DEs, éditeurs de texte et compagnie, puis s'accordaient pour décider d'une seule direction vers laquelle aller, et enfin supportaient les efforts de développement pour progresser dans cette direction (que ce soit en payant des gens pour le faire ou en le faisant eux-même, peu importe) alors ils auraient un peu plus de poids. En montrant qu'ils sont capables d'assumer leurs idées par des actes.
Bien entendu, pour réduire la fragmentation et non pas l'accentuer, il leur faudrait choisir un environnement logiciel déjà existant, et non en créer un nouveau.
Popcorn, quelqu'un? Je veux voir ça. Les uns vont préférer gnome, les autre kde, certains autres unity. Un groupe utilisera firefox, l'autre chromium. Dans chaque groupe, certains vont préférer utiliser claws-mail, tandis que les autres lui préférerons mutt.
Moi, j'aime bien la diversité, la fragmentation des logiciels libres. Je pense que c'est nécessaire à l'émergence de nouvelles façons de penser, de faire, de talents. Que les motivations soient le fun, l'argent, la célébrité, contredire un type qu'on n'apprécie pas… peu importe. Au pire, les projets n'aboutirons pas, et alors?
De toute façon, si quelqu'un décide d'écrire un nouveau logiciel, d'une manière différente, c'est clairement parce qu'il n'ira pas contribuer par le code à ceux qui existent déjà, donc il n'y à pas de perte d'efforts, contrairement à ce que l'on rabâche régulièrement.
Je crois que (yep, j'ai pas de chiffres) la plupart des auteurs de logiciels libres font ça pour le fun à la base. En quel honneur devrait-on donner de notre temps gratuitement à coder sans avoir droit d'y prendre plaisir, pour suivre les idées d'un groupe avec lequel on est pas nécessairement d'accord? Jusqu'à preuve du contraire, personne n'est omniscient, et même les majorités peuvent se tromper. Même les standards peuvent être mauvais.
Mieux, il y une nouvelle alternative qui naît, de nouvelles idées implémentées, qui pourra influencer l'existant. Au final, c'est une contribution.
Et si le prix à payer, c'est que les utilisateurs soient perdus par la mer des alternatives, alors qu'il en soit ainsi. Je ne veux pas d'une distribution unique, je ne veux pas d'un navigateur internet unique, je ne veux pas non plus d'un bureau ou d'un gestionnaire de fenêtre sans concurrents. Je n'utilise qu'i3, mais je suis content que ratpoison ou awesome existent.
[^] # Re: signets synchro? Facile!
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 24 mai 2015 à 17:06.
Qu'est-ce qu'il y a de supérieur à utiliser les unités impériales (pouces, pieds, miles…) plutôt que les unités métriques (centimètre, mètre, kilomètre…) et de compliqué à se décider?
Désolé, mais la difficulté est une belle excuse à une simple non envie de se mettre d'accord sur une "langue" de base commune qui n'enlève rien à la possibilité d'offrir le meilleur dans d'autres cas.
La diversité, c'est sympa, je n'ai pas dit le contraire.
Mais faire 10x exactement la même chose en pratique, juste la forme qui change, ce n'est pas de la diversité qui apporte quelque chose, et celle-ci est bien moins sympa.
Et il ne faut pas se leurrer, au final ceux qui "gagnent" sont aussi celui qui arrivent à fédérer, à un moment on devient trop petit pour pouvoir faire quelque chose de sympa, de la diversité, faute de moyens.
Juste pour info : tu as de la diversité dans les navigateurs web (Firefox, Chrome, IE, Safari…) uniquement parce qu'on a réussi à faire un langage commun (HTML, JS…). Pareil pour Internet.
Toi, tu dis aimer "Optimisé pour IE, ha non en fait ne marche que sur IE", "Optimisé pour Mac", "marche que sur le réseau AOL" (ou "MSN", ha l'époque des Internets cloisonnés…), désolé mais non, ce n'est pas de la "bonne" diversité, c'est juste un refus de vivre ensemble qui n'a rien à voir avec la diversité.
Retiens bien que la où il y a le plus de diversité est bien la où il y a des standards communs, pas le contraire, en pratique tu veux un Internet accessible que par IE sous Windows en passant par Orange qui rejetterait Linux et Free (standard pas commun "pour la diversité", pas grave si au nom de cette diversité les sites ne sont pas compatibles avec ton machine).
[^] # Re: signets synchro? Facile!
Posté par Renault (site web personnel) . Évalué à 5.
Note qu'avec les cgroups (niveau noyau) tu peux fixer une limite en bande passante, de cpu, de ram, etc. Pour chaque application. Après l'application peut gérer cette bande passante allouée comme elle le souhaite.
[^] # Re: signets synchro? Facile!
Posté par Astaoth . Évalué à 2.
En bref, un gestionnaire de connexion, … comme Network-Manager ?
Emacs le fait depuis 30 ans.
[^] # Re: signets synchro? Facile!
Posté par freem . Évalué à 3.
Network manager peut limiter la bande passante utilisée application par application? Je n'étais pas au courant, pour moi il ne sert qu'à dire "tiens, je détecte tel réseau, je vais m'y connecter avec tels identifiants plutôt qu'utiliser tels autres identifiants pour me connecter sur tel autre réseau".
Pas la même fonctionnalité donc. Je me trompe?
[^] # Re: signets synchro? Facile!
Posté par Astaoth . Évalué à -3.
Ah je n'avais pas saisi que tu voulais faire ca par application.
Sinon à l'heure actuelle network manager ne limite rien du tout, je répondais juste par rapport au "pulseaudio" du réseau pour centraliser et "standardiser" (un peu) l'api du réseau. Pour ajouter les limitations de bande passante, j'ai vaguement envie de dire yakafaire si ca te tient tellement à coeur. Au moins c'est libre, tu peux proposer tes patchs ou demander l'ajout de la fonctionnalité et espérer que quelqu'un s'y mettra.
Emacs le fait depuis 30 ans.
[^] # Re: signets synchro? Facile!
Posté par freem . Évalué à 1.
J'ai ouï dire que PA permettait de modifier le volume par application même si celles-ci ne le permettent normalement pas. Enfin, «ouï dire»… je devrais dire «lu».
Même qu'il s'agirait de son seul intérêt par rapport à Alsa. Je peux me tromper. En tout cas ce qui est sûr, c'est que chez moi le son marche à la perfection sans avoir de PA derrière. Du coup j'en vois pas l'utilité.
Ah ben dans ce cas c'est stupide, parce que l'API du réseau, c'est à dire la connexion, l'envoi et la réception des données est parfaitement standardisée dès qu'on sort de chez Microsoft Windows. D'ailleurs, même sous windows, il n'y à que, genre, 1 ou 2 appels à changer, je crois. Pas la mer à boire. Non, vraiment, les APIs réseau n'ont pas trop besoin de standard pour l'accès brut.
En fait,on y accède exactement de la même façon que l'on accède à un fichier. Pas à coups de fopen/fwrite/fread/fclose qui sont une partie des IO standard C, certes, mais à coups de open/write/read/close. Qui sont des fonctions dites bas-niveau (je te laisse consulter le manuel si tu veux les détails), mais elles sont les mêmes sur tous les systèmes POSIX.
Bon, y'a manifestement quelques différences entre les divers systèmes POSIX (ou qui essaient de s'en approcher au maximum sans l'être officiellement, tel… linux, par exemple) mais c'est assez ténu.
Et moi j'ai vaguement envie de dire yakamieuxlireakituparles. Ce n'est pas moi qui râle du manque de fonctionnalités ou de l'insuffisance théorique des fonctionnalités proposées actuellement. Même si, ouai, j'admets avoir du mal à voir l'intérêt d'un gestionnaire de réseau qui tourne non-stop dans l'état actuel du bouzin.
Pour être précis, je suis personnellement resté au bon vieux /etc/network/interface. Ça m'évite d'avoir pléthore de daemons lancés pour… des prunes. Parce que l'on change tellement rarement de réseau lors du même boot, que je vois absolument pas l'intérêt pour moi (pour moi, j'insiste) d'un gestionnaire de réseau. Enfin, si. Ça permets de se connecter en 2 clics à un réseau, quel qu'il soit, à condition d'en connaître les identifiants d'accès.
C'est simple à utiliser, mais bon, je ne trouve pas le fichier interfaces particulièrement complexe. Un simple utilisateur n'aura pas nécessairement le même avis, et d'ailleurs la dernière fois que j'ai voulu accéder à un réseau non protégé (style hôtel) j'étais bien emmerdé avec mon fichier interfaces. Mais c'est anecdotique, donc quand j'ai eu besoin de faire ça, j'ai juste installé je-ne-sais-plus-quel-gestionnaire-réseau, interdit à dbus et lui de se lancer tout seul au boot, et les ai lancés à la main quand j'en avais besoin.
# éternel problème de la contribution
Posté par Adrien . Évalué à 10.
Juste pour info, tu es prêt à payer combien pour avoir les fonctionnalités qui te manquent ?
[^] # Re: éternel problème de la contribution
Posté par j_m . Évalué à 10.
Il est au moins prêt à écrire une tartine dessus. C'est déjà pas mal.
J'aime bien les discussions sur l'ergonomie des logiciels. A titre personnel, ça me fait réfléchir à ce qui ferait passer un de mes codes depuis la catégorie des fonctionnalités qu'on n'utilise pas parce qu'elles ne sont pas pratiques vers la catégorie des fonctionnalités utilisées effectivement.
En plus, quand ton truc est déjà codé, adapter l'ergonomie est tellement con et tu as tellement envie que ton travailles soit apprécié que tu prends toute bonne idée comme du pain béni.
[^] # Re: éternel problème de la contribution
Posté par Adrien . Évalué à 4.
Des tas de gens écrivent tout et n'importe quoi, surtout pour critiquer : le nombre de journaux et commentaires inutiles sur systemd, pulseaudio, Ubuntu ou Gnome est très parlant.
Dans l'éco-système Linux, le problème est toujours le même au final : soit une bonne volonté code la fonctionnalité qu'on veut, soit on paye quelqu'un pour le faire, il n'y a pas de miracle. Le problème étant que passer à une contribution payante est parfois nécessaire… mais très difficile à réaliser côté utilisateur.
À quoi ça sert d'aller cracher sur les solutions, parce que pour UN usage ça ne convient pas tout à fait ? À mon sens, le journal aurait proposé une contribution (temps, argent, etc.), on aurait un vrai intérêt dans la démarche. Là le type râle et c'est tout.
[^] # Re: éternel problème de la contribution
Posté par groumly . Évalué à 8.
J'ai vraiment du mal avec cette reponse.
Ca donne l'impression qu'il suffit qu'"on" donne de l'argent (combien?) a "quelqu'un" et ca va devenir merveilleux d'un coup.
Desole, mais non. C'est pas un probleme de ressource d'ingienerie, c'est un probleme de produit.
La super feature que tu vas financer s'integre dans un produit et un design. Le produit, c'est un tout coherent, pas un frankenstein de feature demandees au hasard par n'importe qui. C'est aussi l'art de prendre des decisions pas facile, de refuser de resoudre un probleme juge non pertinent, et ce genre de choses. Ecrire le code, c'est certes pas trivial, mais ca sert pas a grand chose si ya pas une vision tres claire de ce qu'est cense faire le produit.
Tant que le desktop linux sera gere a l'arrache sans aucune vision, en rajoutant des bouts a droite a gauche au ptit bonheur la chance, ca restera la meme merde.
Product manager, c'est pas un boulot facile. Faut avoir de bonnes idees, les valider, savoir ne garder que les meilleurs, apprendre a ecouter les utilisateurs (dont la premiere regle est de ne surtout pas faire ce qu'ils demandent, mais comprendre pourquoi ils le demandent, determiner le probleme et ensuite seulement resoudre ledit probleme).
Typiquement, la demande de creer un evenement depuis le jour de la barre de menu/dock. C'est probablement tres utile pour cette personne, je n'en doute pas une seconde. Mais c'est pas forcement utile pour un grand nombre de personne (en gros ceux qui recoivent des invitations, plutot que ceux qui les envoient), et ajoute de la complexite qui potentiellement ne sert pas a grand chose. Ca prend du temps qui n'est pas passe a resoudre un autre probleme potentiellement plus important (genre la resolution des conflits quand on prepare un meeting, par exemple).
Bref, il faut quelqu'un familier avec les usages courants d'un calendrier, identifier les groupes d'utilisateurs les plus importants, peser le pour et le contre etc. Et c'est pas quelque chose qu'on trouve generalement chez les developeurs du libre. Ni meme les developeurs tout court, qui tendent a etre des uber geeks obsedes par des power features dont 90% des gens se foutent (serieux, faites du hallway testing, ou lancez des tests sur usertesting.com, c'est impressionant le gouffre entre la sphere high tech et le reste du monde).
Quand aux contributions, qu'elles soient financieres ou en temps, faut pouvoir les gerer. Les donations, c'est une plaie d'un point de vue fiscal, et ca pose aussi le probleme que si t'acceptes la thune pour faire qqchose, tu peux pas l'utiliser pour autre chose (genre le don pour feature a sexy mais pas utile ne peut pas etre utilise pour feature b moins visible mais beaucoup plus importante).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: éternel problème de la contribution
Posté par Julien.D . Évalué à 4.
Donner ne suffit peut-être pas, mais sans ça, se plaindre ne fait pas beaucoup avancer les choses. « J’ai un problème et je paye 100 € pour que quelqu’un me programme le petit logiciel qui va bien » ça a plus de chances de réussite.
Mes pc à l’arrache avec des patchs à droite à gauche sans aucune vision et au ptit bonheur la chance allons très bien, merci. :)
T’as un agent du fisc actuellement qui regarde ce que tu codes par-dessus ton épaule ? :)
Soyons sérieux et reprenons.
Tout ce que tu dis est vrai dans une logique d’entreprise, mais l’environnement GNU/Linux c’est une bonne partie de gens passionnés qui font ça pour eux et pour le fun avec peu de moyens, alors tes arguments même s’ils sont vrais n’ont pas la même importance pour tous les programmeurs qui font souvent ça bénévolement et qui redistribue leur code avec plaisir.
Alors oui, certains logiciels ont une interface pas horrible ou ils leur manquent une fonctionnalité ou ont un bug…
Mais si cela te gène, fais comme eux et participe, d’une façon ou d’une autre. Faire des remontés de bug ! C'est le truc super utile pour un développeur mais pourtant ce n'est pas un réflexe pour tous d'envoyer à l'auteur un petit message pour l'aider à corriger le truc. Je trouve d'ailleurs ça très dommage.
Directement à partir du dock, je sais pas mais ouvrir ton logiciel de calendrier et créer un évènement ça ne doit pas prendre tellement de temps.
Je trouve cette remarque blessante envers tous ceux qui au contraire essayent de casser cette fausse idée que GNU/Linux est moche. Et depuis quelques années c’est encore plus vrai. J’ai écrit une dépêche sur Elementary OS par exemple, et malgré certaines critiques tout le monde ou presque admet que l’interface de la distribution est très soignée.
N’oublions pas non plus que GNU/Linux, c’est beaucoup de petits fichiers de configuration et de scripts, je dis ça par rapport à ta remarque « en rajoutant des bouts a droite a gauche », c’est un peu dans le code génétique du système. Tu peux mettre autour autant d’interface que tu veux, derrière le rideau c’est toujours pareil et ça fonctionne plutôt bien, et quand c'est pas le cas, tu arrive rapidement à trouver d'où vient le problème.
[^] # Re: éternel problème de la contribution
Posté par freem . Évalué à 5.
Oh non, c'est sûr. Ouvrir un accès à une base de données. Balancer une requête d'écriture. Garder en mémoire le moment fatidique. Quand le moment fatidique approche, le rappeler à l'utilisateur.
Facile.
Bon, derrière, ça implique de choisir un moteur de base de données. D'architecturer correctement la-dite base, en fonction de l'ensemble des fonctionnalités désirées (présentes et futures, hein, pas juste celles que l'on imagine au moment exact ou l'on imagine le logiciel). Et tant qu'à faire il faut un mécanisme d'IPC pour dialoguer avec l'outil qui signalera à l'utilisateur l'arrivée du moment fatidique. Audio ou visuel, d'ailleurs, le signal?
La complexité, c'est une affaire de code, mais aussi de choix technique. Admettons qu'on prenne un SGBDR, solution de facilité (bien sûr qu'on peut simplement utiliser un fichier plat, voire peut-être même jouer avec des outils standard style
atetcron, mais je doute que ce serait la solution retenue par la majorité des développeurs). Ben, ça implique d'avoir potentiellement un nouveau daemon qui tourne non-stop, les SGBDR sont des outils avec un fort coût mémoire et CPU. Je ne parle même pas du problème de configuration, en général ces outils protègent leurs bases avec des couples login/password (oui, je suis au courant pour sqlite, j'ai dit: en général).Ensuite, le mécanisme d'IPC, y'a un truc relativement standard de nos jours. Dbus qu'il s'appelle. Encore une dépendance à un daemon.
Bref, pour une fonctionnalité qui ne sera peut-être pas utilisée par la majorité des utilisateurs, on ajoute quand même pas mal de dépendances, de risques de bugs et de failles, de lourdeur.
Alors, est-ce vraiment si simple de faire le choix d'implémenter cette fonctionnalité?
Bon, pour le reste, je suis plutôt d'accord… avec vous deux:
[^] # Re: éternel problème de la contribution
Posté par Okki (site web personnel, Mastodon) . Évalué à 7.
Sous GNOME, on a déjà tout ça. On peut entrer un événement dans l'Agenda, et le moment venu, le centre de notifications nous signale l'événement qui va bien.
Et on arrive pratiquement à faire ce que demande Foutaises. Ou du moins, on le peut déjà, mais pas en un seul clique. Depuis le centre de notifications, on peut cliquer sur une journée du calendrier. Les notifications normalement présentes à gauche du calendrier, sont alors remplacées par les événements du jour qu'on vient de sélectionner.
Maintenant, si on clique sur la journée écrite en toutes lettres en haut à gauche, ça ouvre l'agenda… qui ne se pré-positionne pas sur la journée en question, il est vrai. Alors, même si c'est encore améliorable (le centre de notifications et l'Agenda ne sont arrivés qu'avec la dernière version de GNOME), la situation n'est pas non plus aussi catastrophique que pouvait le laisser entendre le journal.
[^] # Re: éternel problème de la contribution
Posté par Zenitram (site web personnel) . Évalué à 2.
Ce qu'il essaye de dire et que tu ne veux pas accepter (comme plein d'autre monde, je te rassure), c'est qu’on pourra donner tout l'argent qu'on veut, si ça se déchire ça fera un produit de merde.
L'argent n'est pas le seul problème. C'est même le deuxième problème, après la volonté de se mettre d'accord sur un produit cohérent.
(en pratique, tu vas filer 1 million à 1000 personne, et ben plutôt que de se mettre d'accord, tu va avoir 1000 produits de merde pas fini, pas un seul intéressant, tous bons pour la poubelle, plutôt que quelques produits de qualité qui répondront à plusieurs besoins).
[^] # Re: éternel problème de la contribution
Posté par Julien.D . Évalué à 2. Dernière modification le 24 mai 2015 à 18:53.
J’apprécierais qu’on ne m’attribue pas des paroles qui ne sont pas les miennes car en réalité je suis d’accord avec lui sur cette partie.
Comme je l’ai dis, l’environnement GNU/Linux est codé par beaucoup de passionnés qui partage la même passion, mais qui ne communique pas forcément beaucoup avec d’autres pour lancer leurs produits. Pourquoi ?
Parce que s’investir dans une équipe de programmation a un coût initial plus élevé : démarche d’aller vers les autres, comprendre la base de code déjà existante, suivre des conventions, etc. En continuant à développer chacun de son côté, on a plein de logiciels mais pas forcément avec toutes les fonctionnalités qu’on attend de lui. Mais on a moins de problèmes pour se lancer.
Et je pense au contraire que s’il y avait un financement, ce coût pourrait être inférieur ou égal à la rétribution financière et encourager à la mise en commun des compétences, des idées et de la volonté de chacun.
Un exemple flagrant c’est les gestionnaires de bibliothèques musicaux (à distinguer d’un simple lecteur), on en a vu trois en peu de temps sur linuxfr.org, tous fait par des Français en plus. Pourquoi ne pas travailler ensemble ? Des raisons ont été évoquées, bien entendu. Mais cela cache en réalité le fait que le coût dont je parle est là, toujours présent, et dissuade de lancer un projet collectif.
Il y aurait beaucoup d’autres chose à dire sur la participation dans le libre et je ne peux pas parler de tout :)
[^] # Re: éternel problème de la contribution
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 9.
De quel desktop parles-tu ?
[^] # Re: éternel problème de la contribution
Posté par Adrien . Évalué à 2.
Ma pensée est plutôt que critiquer sans rien proposer, ça ne sert à rien, au contraire : ça démotive les troupes. Et oui, l'argent est aujourd'hui une contribution intéressant pour certains projets : avoir des gens payés à plein temps permet des choses qui ne sont simplement pas possible avec des bénévoles.
[^] # Re: éternel problème de la contribution
Posté par freem . Évalué à 2.
Genre les contributions audio-visuelles, le truc qui manque cruellement à tant de projets? Ou la locations des serveurs? ;)
[^] # Re: éternel problème de la contribution
Posté par Antoine . Évalué à 3.
Pas du tout. Une bonne critique permet de prendre conscience de l'existence d'un problème, qui souvent n'est pas forcément perçu par les développeurs. Même une diatribe un peu acerbe peut parfois inciter à améliorer certains points.
[^] # Re: éternel problème de la contribution
Posté par barmic . Évalué à 5.
Je ne suis pas d'accord avec ton analyse.
Pour moi il y a quelques projets amonts (Gnome, KDE,…) et les distributions qui ont une vision produit du bureau. Les exemples les plus parlant c'est Gnome et Ubuntu (ont leur reproche même d'en faire trop). Et c'est projet, entre autre, font de l'intégration de brique de base. On commence par créer GPG et ensuite on développe Seahorse, on crée la possibilité de limiter le débit (ou de faire de la QoS) dans les couches basses (dans netfilter ou via CFS) et ensuite on intègre ça dans un bureau,…
Donc :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: éternel problème de la contribution
Posté par Kerro . Évalué à 4.
Je suis spectateur de cette discussion et je ne pige pas depuis le début : pourquoi parler-vous de développer un truc pour limiter les débits au niveau du noyau alors que ça existe depuis plusieurs années ?
La commande « tc » permet de s'occuper de cela, et netfilter permet de gérer par application.
Il « ne reste plus qu'à » créer un service qui écoute un programme en espace utilisateur pour recevoir les réglages et envoyer les statistiques.
Si ça se trouve ça existe déjà.
[^] # Re: éternel problème de la contribution
Posté par barmic . Évalué à 3.
Mon propos est plus général site cette fonctionnalité particulière.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: éternel problème de la contribution
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 26 mai 2015 à 09:54.
un truc comme pyshaper ?
[^] # Re: éternel problème de la contribution
Posté par Psychofox (Mastodon) . Évalué à 2.
Je me suis trompé d'url, je redirigeais vers la man page. Voila l'url correcte de pyshaper :
http://freenet.mcnabhosting.com/python/pyshaper/
[^] # Re: éternel problème de la contribution
Posté par Antoine . Évalué à 2.
C'est pas très gentil de critiquer ainsi KDE.
[^] # Re: éternel problème de la contribution
Posté par lolop (site web personnel) . Évalué à 4.
Il me semble que les gens de Gnome (et de KDE de leur côté) ont une vision de ce à quoi ils veulent aboutir, et y travaillent. Après il y a tous les autres logiciels sous Linux qui ne s'intègrent pas dans ces schémas, mais qui fonctionnent et rendent service.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: éternel problème de la contribution
Posté par iznobe . Évalué à 0.
Du coup les fonds recuperés en donation devrait etre recu que dans un unique branche : celle du management qui veut absolument rien dire en soi et c' est justement la tout l' interet , que le manager pourra allouer la ou cela lui semble important .
chez les abeilles il y a toujours une reine , sinon la ruche meurt .
le gros probleme du libre es bel et bien la selon moi , il doit y a voir un ligne directrice principale dans tous domaine sans pour autant vouloir diriger ou ordonner .
De plus il est evident que sans certaines standardisation les choses n ' avance pas , l ' exemple le plus flagrant est bel et bien internet comme deja cité aupravant sans quoi on n' en serait pas la aujourd hui .
Il est evident que meme si mac windobe ou le monde linuxien ont des ideologies totalement differentes , sans accord pour standardiser et uniformiser les choses importantes ( comme l' a été internet ) le developpement des choses la seront forcement ralenties et cela ne supprimera en rien , le plaisir que pourra procurer le coding de certaines personnes pour peu que ca soit fait avec une esprit " de bonne volonté et surtout de bonne foi envers la non entrave au developpement .
donc si personne ne paye un " gestionnaire " de distrib , il y a tres peu de chance que la distrib en question ressemble a autre chose que du rafistollage et assemblage de bout de code trouver a droite a gauche .
UN peu comme si on voulait construire une maison sans architect , sans plan , sans maçon attitré , vous imaginez le resultat , c ' est exactement ca a mon sens le monde des distro linux .
C ' est bien dommage , ca pourrait etre si magnifique et detroné les autres d' une telle force quand on voit la puissance et le potentiel qu il ya dessous .
# Ne pas confondre !
Posté par superna (site web personnel) . Évalué à 7. Dernière modification le 23 mai 2015 à 09:50.
Ne confond pas Linux et ton écosystème bureautique !
En 15 ans Linux est devenu LE système d'exploitation le plus utilisé, dans les téléphone, TV et autres petits appareils… et il a énormément évolué et offre des possibilité autant voir plus avancées que les autres OS fermés ou ouverts.
Faire un environnement graphique sympas, qui permet de cliquer sur les dates pour ajouter au calendrier demande un quantité de temps et d'argent astronomique et des concessions, beaucoup de concessions sur la diversité d'API et de librairies utilisées. Mac OS X est un bon exemple, ils ont sacrifié beaucoup pour offrir exactement ce que tu décris.
Il faut faire un choix, soit se contenter de l'existant open source qui est d'une qualité remarquable vu la diversité hallucinante qu'ils doivent supporter ou sacrifier l'open source pour avoir une qualité bureautique ! Ou faire les deux, le compromis c'est pas si mal non plus ;-)
[^] # Re: Ne pas confondre !
Posté par xcomcmdr . Évalué à 6.
Linux n'est pas un système d'exploitation, mas un noyau.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Ne pas confondre !
Posté par freem . Évalué à 3.
Du coup, la question est: l'environnement de bureau fait-il partie du SE? La plupart des discussions que j'ai eues à ce sujet semble indiquer que les développeurs ne le pensent pas.
[^] # Re: Ne pas confondre !
Posté par tuxicoman (site web personnel) . Évalué à 3.
Attends encore 15 ans et tu auras un OS Windows/Linux ou MacOS/Linux à la place de GNU/Linux. Je me délecterai de ta critique sur ton OS à ce moment :p
# Orage
Posté par Marotte ⛧ . Évalué à 10.
Pour ça tu peux installer Orage c’est le calendrier du projet Xfce. Une fois installé tu n’a plus qu’à remplacer l’horloge basique avec l’horloge Orage. Ainsi ton calendrier sera accessible en cliquant sur l’horloge…
Il y a peut-être d’autres solutions je ne sais pas.
[^] # Re: Orage
Posté par Watchwolf . Évalué à 2.
Je pense que par Agenda il parlait d'un calendrier avec la gestion des évènements et non pas juste la liste des dates par mois.
[^] # Re: Orage
Posté par Faya . Évalué à 5.
Orage gère les événements. Par exemple : http://dontsurfinthenude.blogspot.com/2013/08/sync-orage-and-google-calendar.html
Et ça marche avec n'importe quel fournisseur de ical
# limiter
Posté par Benjamin Henrion (site web personnel) . Évalué à -1.
"qu'il soit enfin possible d'avoir un vrai NetLimiter en espace utilisateur"
Bah c'est pas très compliqué à faire si tu mes tes apps dans container docker, que tu donnes un bridge par container (http://docs.docker.com/articles/networking/#building-your-own-bridge), et que tu utilises TC pour limiter la bande passante de chaque container.
Maintenant je ne suis pas un spécialiste des network namespaces, mais ca pourrait aussi etre utile?
[^] # Re: limiter
Posté par Ph Husson (site web personnel) . Évalué à 2.
Tant qu'à faire, tu mets une machine virtuelle qui limite limite au niveau de l'interface ethernet, encore plus simple ! Et c'est encore plus secure !
docker n'est qu'un ensemble de scripts autour de "vraies" technos (comme les namespaces), évidement que si c'est faisable avec docker, c'est faisable sans trop de complexité avec autre chose.
En l’occurrence, pas besoin de namespace network (qui serait un bordel sans nom à gérer avec du NAT au milieu, mais qui est pas forcement une mauvaise option si on veut un système sécurisé), on peut utiliser iptables pour marker des paquet en fonction du pid, de l'uid et/ou du cgroup, et après cette mark peut être utilisée par le shaper.
En plus simpliste, iptables intègre des rate limiters (mais c'est en nombre de paquets par seconde).
La seule vraie question est de séparer les process par cgroups, heureusement systemd est là ! (pas taper.)
[^] # Re: limiter
Posté par briaeros007 . Évalué à 2.
pourquoi taper ?
C'est une des avancées de systemd, il serait triste de ne pas l'indiquer au contraire ;)
Qu'il ait des inconvénient ne veut pas dire qu'il n'ait pas d'avantage :)
Par contre, pourquoi du NAT apporterais plus de sécu que des règles de firewall, à part, peut être,la fuite d'information sur le addressage interne de la machine (mais dans ce cas il suffit de faire la NAT juste avant la sortie de la machine).
[^] # Re: limiter
Posté par Ph Husson (site web personnel) . Évalué à 2.
Ma formulation est volontairement flou.
Je fais partie des gens qui considère que le NAT n'est jamais une solution de sécurité en soit, et effectivement ici non plus, le NAT n'apporte pas intrinsèquement de sécurité.
Juste, le NAT fait qu'il est plus facile de comprendre/faire des schémas de ce qu'il se passe, et le pare-feu se fait de la manière classique, à savoir selon l'adressage réseau.
Aussi, le filtrage par cgroups est moins testé, et a plus de chances d'avoir des failles. (typiquement je vois pas d'option à lxc pour rester dans le même namespace réseau, mais après c'est peut-être plus philosophique de leur part)
[^] # Re: limiter
Posté par freem . Évalué à 2.
Tu veux quand même pas dire une VM par application potentielle quand même? Bourrin… mais, certes, ça marche. Tu mets ton PC a genoux en 30s chrono par contre.
[^] # Re: limiter
Posté par Ph Husson (site web personnel) . Évalué à 3.
Pas beaucoup plus qu'un docker en fait…
C'était de l'ironie sur le fait que docker est un marteau piqueur pour cet usage.
# Tu parles de tout sauf de linux
Posté par Psychofox (Mastodon) . Évalué à -1.
Je crois que tu confonds linux avec un autre logiciel mais je n'en connais aucun qui fait à la fois gestion de calendrier, gestionnaire de signet et limiteur de bande passante.
# ma vision ( subjective )
Posté par iznobe . Évalué à 0.
Bonjour , j ' irais meme plus loin , perso je ne suis pas dev ni codeur ni rien ^ , mais en fait tout ce que tu viens de dire resume bien la situation , et pour resumer en quelques mots je dirais que c ' est un probleme purement de gestion / managment .
Alors le libre oui , la diversite oui , le pleasure coding aussi , mais sans aiguillage , sans gestion et sans management ben voila le resultat , les distribs sont des frankenstein, avec des calendars qui servent a rien …. des programmes que seuls les devs qui les ont develloppés savent utilisés , et qu un utilisateur lambda doit etudier a fond pendant 15 jours mini si il veut arriver a maitriser un tant soi peu .
Du coup les fonds recuperés en donation devrait etre recu que dans un unique branche : celle du management qui veut absolument rien dire en soi et c' est justement la tout l' interet , que le manager pourra allouer la ou cela lui semble important .
chez les abeilles il y a toujours une reine , sinon la ruche meurt : il faut des gens tout en haut , un systeme pyramidal .
le gros probleme du libre es bel et bien la selon moi , il doit y a voir un ligne directrice principale dans tous les domaines sans pour autant vouloir diriger ou ordonner .
De plus il est evident que sans certaines standardisation les choses n ' avance pas , l ' exemple le plus flagrant est bel et bien internet comme deja cité aupravant sans quoi on n' en serait pas la aujourd hui .
Si mac windobe ou le monde linuxien ont des ideologies totalement differentes , sans accord pour standardiser et uniformiser les choses importantes ( comme l' a été internet ) le developpement de ces choses la seront forcement ralenties et cela ne supprimera en rien , le plaisir que pourra procurer le coding de certaines personnes pour peu que ca soit fait avec une esprit " de bonne volonté et surtout de bonne foi envers la non entrave au developpement " au contraire car il sera + facile de comprendre le code , ajouter sa pierre a l ' edifice , trouver des idées , de la doc .
Donc si personne ne paye un " gestionnaire " de distrib , il y a tres peu de chance que la distrib en question ressemble a autre chose que du rafistollage et assemblage de bout de code trouver a droite a gauche .
Un peu comme si on voulait construire une maison sans architecte , sans plan , sans maçon , sans plombier sans electricien attitrés , vous imaginez le resultat , c ' est exactement ca a mon sens le monde des distro linux .
C ' est bien dommage car ca pourrait etre si magnifique et detroné les autres d' une telle force quand on voit la puissance et le potentiel qu ' il ya dessous .
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.