Je m'étonne que tu aies besoin d'autant de terminaux.
En fait, déjà, je n'utilise quasiment plus de gestionnaire de fichier. Pour ce que j'en fait ça ne servirait à rien la plupart du temps (il n'y a que quand je dois gérer des images par exemples).
Ensuite, j'ai en général :
une console posé sur les sources git du projet sur lequel je bosse -> diff, commit, historique, etc. Je ne fais pas grand chose de plus dedans, je veux qu'elle soit toujours dispo (ça rentre dans ton 1)
une console qui est en ssh sur un serveur, pour voir les logs par exemple
à multiplier en général par 2, car je switch parfois un peu trop fréquemment de projet ou j'ai des choses en arrière plan
une console qui me permet de gérer mon vagrant (en général, ça n'est pas toujours indispensable)
souvent un irssi
ncmpcpp
htop
sous i3 (comme d'autres) c'est tellement facile d'ouvrir une console à la volée, que lorsque je dois faire une action, quelle soit le bureau, en général j'ouvre une console, fait mes 2 3 trucs, édite un fichier dans emacsclient, ferme la console
si j'ai besoin, je peux rajouter 2 à 3 consoles supplémentaires en ssh sur des serveurs de préprod/prod
Cela allègera d'autant ton espace de travail, et résoudra la problème du démultiplexeur de terminal.
En fait, mon problème n'est pas tellement à ce niveau, mon espace est plutôt léger et organisé, je ne perd que peu de temps à me déplacer dans mes fenêtres.
Mutt est pas mal, ce n’est pas la poudre verte que certains en font
Je pense bien, mais en fait je trouve thunderbird pas assez ergonomique et agréable. Et en fait il n'y a pas 36 clients mails sous linux finalement…
Et comme je suis actuellement dans ma phase i3/tmux/jefaisauclavier je me suis dit que ça pouvais être intéressant…
mais j'ai fait un peu de gnus.
Well… nobody's perfect!
Mais heu !
D'ailleurs je me pose la question de le réutiliser, surtout que j'ai toujours un emacs --daemon qui traine, et que mon $EDITOR est un emacsclient…
Ha non, jamais pensé. Mais là par contre ça me tente moins pour la simple et bonne raison que j'ai un tt-rss sur un serveur perso et que je l'utilise donc n'importe où. A la rigueur si j'avais un client en console pour lui… ;)
En fait c'est surtout que j'apprécie assez peu thunderbird (je le trouve peu pratique, pas super lisible, pas génial quoi).
Je n'ai par contre jamais essayé mutt, mais j'ai fait un peu de gnus. D'ailleurs ça pourrait aussi être une solution.
Mon passage sous i3 m'a redonné plutôt le goût pour des logiciels plus simples et plus léger (ok, emacs…) et finalement mutt me semble relativement intéressant. Surtout si je le couple avec un tmux et emacs daemon (pour vim j'ai commencé à le tester mais j'ai encore trop de mal)
Je cherche donc à avoir quelque chose de plutôt léger, simple, assez peu intrusif, mais qui fait juste son job.
Bon ok, d'ailleurs pour mon problème, je pourrais aussi simplement remplacer tmux et autres par emacs… :)
Oui, mais non… :)
j'ai longtemps utilisé kde, mais ça ne m'attire pas du tout ces derniers temps.
J'ai essayé de m'y remettre il n'y a pas longtemps, mais je suis justement reparti sous i3 (après avoir essayé gnome 3, mais là j'ai vraiment pas tenu longtemps)
En fait le côté light de i3 (ou équivalent) est quand même hautement addictif.
Et je n'utilise aucun logiciel kde, du coup ça perd beaucoup de son intérêt.
Dans une utilisation perso je dirais oui, mais là bof
(en fait les logiciels que je lance sont quasiment tous en texte, à part sublime, chrome et thunderbird)
En effet, de ce que j'ai compris de ton journal, tmux fait complètement double emploi avec ton gestionnaire de fenêtre quand à l'aspect tiling.
Exactement
Pourrais tu énoncer plus clairement ce qu'il manque a i3wm pour te passer de tmux ?
Ha mais c'est le contraire, je me pose la question de virer i3 car tmux rempli la part de tiling dont je me sert pour les terminaux. Et un gestionnaire non pavant pourrait suffire pour mes autres programmes (en gros deux navigateurs, un éditeur de texte en plein écran et un thunderbird - sauf si je trouve le courage de le remplacer par un mutt)
Pour le moment oui, à 3 ans et -2 mois ils suivent :)
Et ma femme reste du même avis.
Mais attention, je ne dis surtout pas que c'est facile, loin de là.
En fait ce qui change beaucoup entre service et éditeur de logiciel, c'est surtout qui décide quoi (même si dans les deux cas ce n'est ni blanc ni noir, mais la balance penche dans un sens ou un autre assurément).
Dans le cas d'une boite de service, tu développes ce que le client veut. C'est lui qui décide au final. Et il y a tout le côté malsain de la boite de service en tant que telle. Je sais qu'il existe des boites de services qui sont capables de dire non au client, et de ne pas faire tout ce qui est idiot, qui ont une vrai idée de la qualité. J'en connais peu par contre, et ça reste l'exception.
Dans le cas d'un éditeur de logiciel, c'est principalement toi qui décide du logiciel. Evidemment il faut qu'il corresponde au minimum à une cible d'utilisateurs, sinon ça ne fonctionnera pas beaucoup. Mais reste que c'est toi qui est à l'initiative principale. En fait ce n'est même pas d'avoir plusieurs clients et non un, c'est plus complexe que ça. Ce que je trouve intéressant c'est même de faire le logiciel pour répondre à un besoin, les clients étant "annexes". (ça reste un point de vue caricatural, c'est pour opposer plus facilement les deux points de vue)
Après, qu'il y ait des cahiers de charge et autre, oui ça arrive. Je suis plutôt friand des méthodes agiles, où cette notion est quelque peu différente (et j'ai la chance de bosser de la sorte depuis maintenant quelques années).
Je crois qu'il s'agit d'une petite incompréhension.
Pour le coup, comme l'a indiqué baud123 je bosse actuellement dans une boite où un logiciel est libre
En fait, j'ai volontairement grossi le trait, en le stéréotypant. Et évidemment si tu le prend à la lettre tu tombe sur du logiciel pas libre pour un sous.
J'opposais surtout "logiciel créé par sous-traitance à une boite de service pour un besoin précis" à "logiciel développé par un éditeur" hors projet pour un client, hors service, que le logiciel soit vendu directement sous licence, ou fourni gratuitement, ou libre, avec par exemple des services à côtés.
Et il est vrai que je suis passé au raccourcis "logiciel sous licence" car en forcissant le trait je pensais que la comparaison serait plus évidente.
Plus compliqué, oui.
Impossible, non.
Après c'est un choix, et une question de priorité.
S'il le fallait, je repartirais ailleurs pour avoir une meilleur situation, je ne suis pas fixé, et je préfère ça à avoir un job dans lequel je ne me plais pas du tout.
Pour le reste, peut-être que je m'exprime mal, mais j'oppose surtout service et édition (plutôt que création) de logiciel. Typiquement logiciel sous licence.
Par exemple, dans les boites où je suis passé il n'est jamais question de TMA.
Je parle d'édition de logiciel où le logiciel n'est pas créé pour répondre à un cahier des charges pour un projet. En fait on est justement hors projet.
Je sais pas comment décrire, car j'ai l'impression que tu vois l'histoire par la porte projet/service. Mais c'est loin d'être la seule vision.
En fait, pour faire simple, ce dont je parle n'est ni société de service ni "client final".
Mais vraiment éditeur de logiciel, sous licence, acheté par d'autres.
/me n'a pas l'impression d'être plus clair qu'avant…
C'est sur qu'il est parfois compliqué de ne pas passer par des SSII. Et de mon côté c'est un vrai choix, assumé. Je veux dire par là que j'ai refusé, à chaque fois que je cherchais du boulot, des postes. J'ai aussi été amené à me déplacer (au début 200km/jours pour aller bosser, chez un éditeur), puis Metz en étant à Nancy, puis carrément déménager à 400km.
Evidemment ce n'est pas simple, ça m'a coûté de l'argent (entre du chomage jusqu'à trouver une boite intéressante, trajets/déménagements) et ce n'est pas tout le temps possible (je l'ai fait avec peu (et non pas) d'attaches, aujourd'hui avec des gosses c'est plus complexe. Mais si je devais je le ferais encore.
Le côté futuriste que tu décris pourquoi pas. Mais finalement ça reste à peu près sur le même modèle, un modèle de service à la base.
Ce que je vois, c'est beaucoup plus le côté création de logiciel et non service/projet. Ok, ça ne correspond pas à tous les jobs, mais c'est ce que je recherche en priorité.
Et au final il y en a des boites comme ça, plus qu'on ne le croit. Bon par contre c'est rarement des grosses boites (lorsqu'on atteint 100 personnes c'est déjà beaucoup).
Après, lorsque j'écris mon bla bla je ne passe que rarement par la case compromis (ça serait beaucoup moins drôle). Mais il existe tout de même des boites de services qui elles sont bien, correctes, avec des projets intéressants, des conditions correctes, et techniquement bien. J'en connais peu, mais il y en a.
l'usage abusif de termes anglais ou ésotériques alors que la traduction exacte en français existe
Hum, là je ne suis pas d'accord.
Déjà, je fais un effort pour en enlever (sinon il y en aurait beaucoup plus)
Et surtout, la traduction exacte n'existe pas toujours.
Peut-être, mais il n'existe par contre pas d'équivalent en français à ma connaissance, et surtout le terme est à mon avis compréhensible par beaucoup étant donné que la majorité des conférences/documents sur le sujet sont en anglais.
S'il y avait un terme français pourquoi pas, en attendant non.
côté ops
Ok, j'aurais du écrire côté opérationnel
scalabilité
Ce n'est pas que la mise à l'échelle, c'est surtout la capacité à être mis à l'échelle, à résister au changement lors de la mise à l'échelle.
D'ailleurs l'article wikipedia sur scalability est plutôt clair, indiquant (et je partage cet avis) qu'il « n'a pas d'équivalent communément admis en français »
Sur les autres, ok.
Maintenant, de manière globale, la majorité des contenus sont en anglais. Et oui il m'arrive souvent d'en prendre des termes qui sont plus parlant que leurs équivalents français lorsqu'ils existent.
De la même manière je ne parlerai pas de cadriciel, mais de framework. Côté néologisme c'est pas mal non plus. A la rigueur en partant sur des dérivés de l'industrie pourquoi pas, mais les machiniciels me donnent en général des boutons.
En fait, il y a eu quelques corrections (et suggestions de liens) de Nyco, baud123 et Benoit (si je ne me trompe, mais je ne sais pas quel compte)
Donc merci à eux.
C'est la première fois que je tente l'espace collaboratif. Je pense que je vais bientôt ouvrir une nouvelle dépêche pour l'épisode suivant, si certains sont intéressés c'est possible.
Oui, en gros c'est ça :)
D'ailleurs c'est quelque chose d'assez facile à faire. Et pour le coup une partie sera bientôt dispo sur le dépôt principal qui permettra de gérer des comptes différents et facilement directement depuis le code de l'appli de lecture (par contre l'objectif est du test, donc c'est pas une api complète, mais ça y ressemble un peu)
dommage qu'on ne puisse mettre du choix multiple ;)
Après avoir eu des boites où c'était un mélange de réunion/mail, je suis vraiment content d'être dans une boite où l'une des premières choses qu'on fait est de rejoindre un canal IRC (en fait pas pour moi j'ai enfin compris tout l'intérêt de irssi avec le mode proxy :) )
C'est cool, sympa, git/capistrano/jenkins crash ses logs dedans
parfois, la discussion est plus sympa/pratique de la sorte alors qu'on discute avec le gars derrière l'écran, mais pas d'interruption
En fait je me rend compte que les autres endroits où j'étais, c'est le mail qui était utilisé à la place. Mais c'est pas génial. Par contre c'est complémentaire.
Ok, j'ai l'impression de radoter un peu dans la réponse, mais je pense que l'incompréhension est surtout lié à un point (je te laisse le trouver c'est pas compliqué ;))
Sous le lecteur, TEA propose clef en main une certaine idée du livre numérique. La liseuse est faite pour mettre en œuvre cette idée du livre numérique, de sorte que cette idée imprègne la technologie même de la liseuse
Attention, il ne faut pas confondre TEA et la liseuse TeaBook Open Reader.
D'ailleurs tu peux très bien aller acheter un livre numérique sur le site de cultura ou decitre et simplement télécharger l'epub. Et dans ce cas (si l'éditeur n'a pas obligé de DRM, dans ce cas ce serait en effet un poil plus complexe) ben tu l'as ton bouquin. Tu peux le copier, le dupliquer, le placer sur plusieurs liseuses, dans plusieurs logiciels, l'archiver, etc.
Il faut voir le lecteur dont la dépêche parle comme un lecteur supplémentaire, pas forcément comme le seul est unique lecteur. C'est aussi ce qui permet d'avoir des usages différents.
TEA propose que le livre numérique soit dans les nuages, associé à une enseigne de ventes et à un compte client. Or, cette façon de concevoir le livre numérique contredit à mon avis, le projet affiché : « lire en toute liberté ».
TeaBook Open Reader est un lecteur en partie de ce type. Mais :
TEA n'est pas uniquement TeaBook
je peux très bien intégrer un epub acheté / téléchargé ailleurs dans la bibliothèque de mon TeaBook, je ne suis pas contraint à une enseigne
libre à quiconque de prendre le lecteur et d'y enlever tout lien avec un serveur externe, une enseigne ou un compte client. C'est avant tout un lecteur qui peut être utilisé hors connexion.
API de gestion des comptes : Cette API est partie intégrante du produit, pourtant elle n’est pas nécessaire à la lecture des livres.
Oué enfin je peux quand même lire mon livre serveur coupé puisque la lecture hors ligne existe. La partie compte est nécessaire pour imaginer acheter depuis le lecteur, pour synchroniser la lecture, les marques pages, etc mais ne change rien pour la lecture proprement dite.
J’ai été pris de vertige en imaginant qu’une telle API permettait de réaliser les rêves les plus fous des éditeurs : publicité ciblée, authentification à chaque lecture, verrouillage du nombre de lectures possibles… Là encore, ce sont des possibilités offertes par la technologie de TEA, difficilement accessibles avant cela.
Quid de la possibilité d’accéder facilement à ma bibliothèque hébergée chez plusieurs enseignes ? Dois-je vraiment argumenter pour expliquer ça contraint la lecture plus que ça ne la libère ?
Il est possible d'ajouter à une bibliothèque des livres provenant d'ailleurs, manuellement.
Et il faut voir que le côté instance pour un libraire à d'autres avantages comme par exemple pouvoir bénéficier des conseils, mises en avant ou autre comme si j'allais dans la librairie en bas de chez moi. Le but à ce moment est de continuer à être en relation avec mon libraire habituel, même s'il est question d'ebook.
Design propriétaire
Sur ce point (design, nom) il faut le voir de la même manière que firefox pour mozilla. Le code est ouvert, la marque non.
DRM : Je ne dis pas que c’est mal, je dis juste que ce n’est pas libre
Le code publié ne contient rien du tout concernant les DRM.
Vous proposez une liseuse dont toute la technologie est faite pour que les enseignes maîtrisent totalement la liseuse, la lecture et le lecteur,
non
revoir le lien par exemple sur le manifeste de TEA
TeaBook n'est pas le seul lecteur existant, c'est un lecteur et l'achat d'ebook (en utilisant des technos de TEA) peut se faire dès à présent sans passer par TeaBook (qui n'est pas en prod actuellement)
Je crois que la lecture se porterait mieux sans ce genre de technologie.
J'aimerais bien dans ce cas que tu nous présentes ce que ça pourrait être alors. Quelles solutions apporter au multi lecteur avec synchro des marques pages, annotations, etc par exemple ?
Je trouverai même le concept génial.
Peut-être que tout n'est pas toujours clair (moi je suis dev, pas forcément super bon en communication hein) mais le concept est génial. Et est plus vaste que TeaBook Open Reader.
Ce qui est justement l'un des objectifs de TEA, indiqué dans son manifeste :
Pour que chaque lecteur puisse lire, manipuler et commenter ses livres numériques où il veut, quand il veut, et comme il veut, indépendamment du distributeur et du matériel de lecture…
tout simplement, une bibliothèque distante (c'est déjà expliqué plus haut, si je veux lire sur 3 machines différentes c'est quand même beaucoup plus facile) avec synchronisation et sauvegarde de l'emplacement de lecture (pouvoir reprendre la lecture sur un autre ordi sans rien avoir installé, juste en consultant l'appli)
En fait ça existe déjà. Par exemple pour utiliser du vbscript sur IE.
Et je pense que pour Dart c'est fait de la sorte (mais comme dit, il faut un navigateur le supportant)
gestion centralisée de la bibliothèque des clients,
Attention, là on parle (de teabook open reader) d'un lecteur. Pas de la plateforme de vente.
Alors oui pour pouvoir offrir des fonctionnalités comme la synchronisation de l'emplacement de lecture, des annotations, des bookmarks, etc entre plusieurs devices il faut bien synchroniser ces données à un moment donner et le passage par un point central est plus simple.
Mais rien du tout n'oblige à utiliser ce lecteur ou cette bibliothèque plutôt que de télécharger le livre et de le lire sur le support / dans le logiciel de son choix.
priorité donnée à la location des ebook plutôt qu'à leur achat.
Alors là j'aimerais vraiment bien savoir d'où ça vient…
Car il n'est aucunement question de location d'ebook mais d'un lecteur permettant de lire ceux qui ont été acheté, téléchargés, y compris sur une autre plateforme d'ailleurs.
Il n'y a pas de limitation lecteur <-> plateforme de vente
Je vois déjà venir les premières contributions :
publicité ciblée,
d'ailleurs les première contributions c'est aussi ce que vous voudrez en faire hein…
compteur du nombre de lectures.
on parle toujours de lire le livre que l'utilisateur a déposé (ou poussé lors de son achat). Oui si tu veux je peux rajouter le nombre de fois que l'utilisateur à ouvert son livre, maintenant je suis pas certain que ça ait un intérêt.
PS: /bla bla/
heu… comment dire…
Mentir sur quoi d'ailleurs ?
Un lecteur d'epub a été développé.
Il n'est lié à aucune plateforme de vente, il permet juste de se connecter à une API qui elle fourni la gestion des comptes, des livres dispos etc.
Ce lecteur est sous licence libre.
Il n'y a pas de gestion de DRM.
Il est tout à fait possible de développer une plateforme, qui implémente cette API.
Un concurrent peut en développer une s'il le veut.
Tu peux en développer une si tu veux, et d'ailleurs en interdisant dessus tout livre avec DRM.
Donc je résume, tu as un lecteur (le sujet de la dépêche) qui est libre, qui ne gère pas les DRM, que tu peux modifier comme tu veux mais en fait c'est mal.
Je vous prie de m'excuser d'avance s'il apparaît que je n'ai rien compris, et je vous prie de m'expliquer ce qui m'a échappé.
J'espère que c'est un peu plus clair, mais si ce n'est toujours pas le cas n'hésite pas.
Pour le coup ce que je trouverais mal fichu serait d'avoir à installer à logiciel sur chacun de mes terminaux de lecture, puis de les connecter à un serveur pour pouvoir synchroniser ma lecture. Là c'est transparent et je trouve ça plus agréable.
Maintenant, je comprend ton point de vue, mais je pense par contre que ce n'est pas qu'une question de mode mais aussi de simplicité pour un utilisateur classique.
Oui et non.
Oui, c'est plus qu'un simple logiciel de lecture.
Sauf que tu peux l'utiliser hors connexion. Tu peux lire tes livres sans accès au site, sans installer de logiciel ou d'extension. En fait sans autre chose que ton navigateur.
Pas top, comme conception
Merci.
Allez, un exemple à la con : tu as plusieurs machines (imaginons un pc au boulot, un chez toi, et une tablette). Tu commences un livre sur ton pc perso. Tu passes au salon, tu veux le continuer sur ta tablette. A ta pose au boulot, tu souhaites en lire quelques pages.
Ben avec un serveur, l'avantage c'est qu'à chaque fois que je vais ouvrir mon livre, il sera à l'endroit où je l'ai arrêté.
Sans cela, je fais comment ? Je télécharge le livre sur mes 3 machines ? Je me souviens où j'ai arrêté la lecture à chaque fois ?
pour un truc aussi bête que de la lecture d'EPUB.
Heu… un truc aussi bête que la lecture d'EPUB ?
La je suis pas certain que ce soit aussi simple. Et oui la cible est plus large que simplement un pur lecteur d'epub (bien que rien que sur ce point il y ait beaucoup beaucoup de choses à faire). Par exemple, pouvoir connecter l'application avec un site de vente d'epub, que les livres achetés soient automatiquement placé dans ta bibliothèque (donc pas d'étape du genre télécharger le livre, aller dans ton lecteur, le placer dedans). Et tes livres sont, si tu le souhaite, dispo hors ligne.
Nan mais c'est une petite pique sympa, faut surtout pas le prendre mal :)
En fait je pense surtout que go a la capacité d'aller beaucoup plus loin que la prog système / le scripting, bien que ça en soit l'usage majoritaire aujourd'hui.
Et voilà un assez bon exemple.
J'ai pas encore codé avec ce binding, mais lorsque je trouverai le temps je pense que je vais l'essayer un peu, ça a l'air sympa.
Ben nono j'en sais rien, mais en fait je ne vois pas vraiment le problème…
Souvent pour faire ce genre de choses j'utilise des machines virtuelles avec partage de mes sources. Là sur ma machine j'ai 2 vms qui contiennent du nginx, du ruby, du rails, du mongodb, du redis. Il est où le problème ?
Il a vraiment tout installé sur sa machine
En fait je pose la question inverse : pourquoi n'aurait-il pas tout ça sur sa machine ? (ou une vm dédiée)
Et en général, ça marche comment ?
configure (ou make si c'est mal fait ce qui est souvent le cas) va te cracher une liste imbitable de dépendances non résolues. Tu vas les installer et relancer, jusqu'à ce que ça tombe en marche.
Ok c'est un peu exagéré mais finalement pas très loin.
L'autre solution aurait été de décrire l'installation de la sorte :
git clone ...
cd linuxfr
bundle install
Et là tu résous les erreurs lorsqu'elles arrivent (genre tu n'as pas bundler pour commencer)
Mais franchement je vois pas trop ce qui est étonnant dans ce descriptif.
Et d'ailleurs, rien ne t'empêche de prendre toutes les commandes intéressantes, de les coller dans un script qui s'appelle configure. Ensuite tu fais un alias make=bundle install et tu sera pas bien loin de ce que sembles apprécier.
[^] # Re: démutiplexeur de terminal
Posté par CrEv (site web personnel) . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 2.
En fait, déjà, je n'utilise quasiment plus de gestionnaire de fichier. Pour ce que j'en fait ça ne servirait à rien la plupart du temps (il n'y a que quand je dois gérer des images par exemples).
Ensuite, j'ai en général :
En fait, mon problème n'est pas tellement à ce niveau, mon espace est plutôt léger et organisé, je ne perd que peu de temps à me déplacer dans mes fenêtres.
[^] # Re: Cahier des charges incomplet
Posté par CrEv (site web personnel) . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 2.
Non, mais je connais son blog pour mercurial
Je pense bien, mais en fait je trouve thunderbird pas assez ergonomique et agréable. Et en fait il n'y a pas 36 clients mails sous linux finalement…
Et comme je suis actuellement dans ma phase i3/tmux/jefaisauclavier je me suis dit que ça pouvais être intéressant…
Mais heu !
D'ailleurs je me pose la question de le réutiliser, surtout que j'ai toujours un
emacs --daemonqui traine, et que mon$EDITORest unemacsclient…Ha non, jamais pensé. Mais là par contre ça me tente moins pour la simple et bonne raison que j'ai un tt-rss sur un serveur perso et que je l'utilise donc n'importe où. A la rigueur si j'avais un client en console pour lui… ;)
[^] # Re: Cahier des charges incomplet
Posté par CrEv (site web personnel) . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 1.
Merci pour le lien, je l'avais zapé celui-là.
En fait c'est surtout que j'apprécie assez peu thunderbird (je le trouve peu pratique, pas super lisible, pas génial quoi).
Je n'ai par contre jamais essayé mutt, mais j'ai fait un peu de gnus. D'ailleurs ça pourrait aussi être une solution.
Mon passage sous i3 m'a redonné plutôt le goût pour des logiciels plus simples et plus léger (ok, emacs…) et finalement mutt me semble relativement intéressant. Surtout si je le couple avec un tmux et emacs daemon (pour vim j'ai commencé à le tester mais j'ai encore trop de mal)
Je cherche donc à avoir quelque chose de plutôt léger, simple, assez peu intrusif, mais qui fait juste son job.
Bon ok, d'ailleurs pour mon problème, je pourrais aussi simplement remplacer tmux et autres par emacs… :)
[^] # Re: HS mais...
Posté par CrEv (site web personnel) . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 8.
ha oué, pas faux :)
Tiens, un pansement pour tes yeux…
[^] # Re: Pour les KDEistes
Posté par CrEv (site web personnel) . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 1.
Oui, mais non… :)
j'ai longtemps utilisé kde, mais ça ne m'attire pas du tout ces derniers temps.
J'ai essayé de m'y remettre il n'y a pas longtemps, mais je suis justement reparti sous i3 (après avoir essayé gnome 3, mais là j'ai vraiment pas tenu longtemps)
En fait le côté light de i3 (ou équivalent) est quand même hautement addictif.
Et je n'utilise aucun logiciel kde, du coup ça perd beaucoup de son intérêt.
Dans une utilisation perso je dirais oui, mais là bof
(en fait les logiciels que je lance sont quasiment tous en texte, à part sublime, chrome et thunderbird)
[^] # Re: Cahier des charges incomplet
Posté par CrEv (site web personnel) . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 2.
Exactement
Ha mais c'est le contraire, je me pose la question de virer i3 car tmux rempli la part de tiling dont je me sert pour les terminaux. Et un gestionnaire non pavant pourrait suffire pour mes autres programmes (en gros deux navigateurs, un éditeur de texte en plein écran et un thunderbird - sauf si je trouve le courage de le remplacer par un mutt)
[^] # Re: dwm + dmenu + screen
Posté par CrEv (site web personnel) . En réponse au journal Tiling interne ou externe, telle est la question. Évalué à 3.
oué mais là ça ne résout pas vraiment le problème
[^] # Re: Est-ce est-ce Dezi ?
Posté par CrEv (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 4.
Pour le moment oui, à 3 ans et -2 mois ils suivent :)
Et ma femme reste du même avis.
Mais attention, je ne dis surtout pas que c'est facile, loin de là.
En fait ce qui change beaucoup entre service et éditeur de logiciel, c'est surtout qui décide quoi (même si dans les deux cas ce n'est ni blanc ni noir, mais la balance penche dans un sens ou un autre assurément).
Dans le cas d'une boite de service, tu développes ce que le client veut. C'est lui qui décide au final. Et il y a tout le côté malsain de la boite de service en tant que telle. Je sais qu'il existe des boites de services qui sont capables de dire non au client, et de ne pas faire tout ce qui est idiot, qui ont une vrai idée de la qualité. J'en connais peu par contre, et ça reste l'exception.
Dans le cas d'un éditeur de logiciel, c'est principalement toi qui décide du logiciel. Evidemment il faut qu'il corresponde au minimum à une cible d'utilisateurs, sinon ça ne fonctionnera pas beaucoup. Mais reste que c'est toi qui est à l'initiative principale. En fait ce n'est même pas d'avoir plusieurs clients et non un, c'est plus complexe que ça. Ce que je trouve intéressant c'est même de faire le logiciel pour répondre à un besoin, les clients étant "annexes". (ça reste un point de vue caricatural, c'est pour opposer plus facilement les deux points de vue)
Après, qu'il y ait des cahiers de charge et autre, oui ça arrive. Je suis plutôt friand des méthodes agiles, où cette notion est quelque peu différente (et j'ai la chance de bosser de la sorte depuis maintenant quelques années).
[^] # Re: Est-ce est-ce Dezi ?
Posté par CrEv (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 4.
Je crois qu'il s'agit d'une petite incompréhension.
Pour le coup, comme l'a indiqué baud123 je bosse actuellement dans une boite où un logiciel est libre
En fait, j'ai volontairement grossi le trait, en le stéréotypant. Et évidemment si tu le prend à la lettre tu tombe sur du logiciel pas libre pour un sous.
J'opposais surtout "logiciel créé par sous-traitance à une boite de service pour un besoin précis" à "logiciel développé par un éditeur" hors projet pour un client, hors service, que le logiciel soit vendu directement sous licence, ou fourni gratuitement, ou libre, avec par exemple des services à côtés.
Et il est vrai que je suis passé au raccourcis "logiciel sous licence" car en forcissant le trait je pensais que la comparaison serait plus évidente.
[^] # Re: Est-ce est-ce Dezi ?
Posté par CrEv (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 3.
Plus compliqué, oui.
Impossible, non.
Après c'est un choix, et une question de priorité.
S'il le fallait, je repartirais ailleurs pour avoir une meilleur situation, je ne suis pas fixé, et je préfère ça à avoir un job dans lequel je ne me plais pas du tout.
Pour le reste, peut-être que je m'exprime mal, mais j'oppose surtout service et édition (plutôt que création) de logiciel. Typiquement logiciel sous licence.
Par exemple, dans les boites où je suis passé il n'est jamais question de TMA.
Je parle d'édition de logiciel où le logiciel n'est pas créé pour répondre à un cahier des charges pour un projet. En fait on est justement hors projet.
Je sais pas comment décrire, car j'ai l'impression que tu vois l'histoire par la porte projet/service. Mais c'est loin d'être la seule vision.
En fait, pour faire simple, ce dont je parle n'est ni société de service ni "client final".
Mais vraiment éditeur de logiciel, sous licence, acheté par d'autres.
/me n'a pas l'impression d'être plus clair qu'avant…
[^] # Re: Est-ce est-ce Dezi ?
Posté par CrEv (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 3.
ho pas de problème pour jouer le trouble-fête :)
C'est sur qu'il est parfois compliqué de ne pas passer par des SSII. Et de mon côté c'est un vrai choix, assumé. Je veux dire par là que j'ai refusé, à chaque fois que je cherchais du boulot, des postes. J'ai aussi été amené à me déplacer (au début 200km/jours pour aller bosser, chez un éditeur), puis Metz en étant à Nancy, puis carrément déménager à 400km.
Evidemment ce n'est pas simple, ça m'a coûté de l'argent (entre du chomage jusqu'à trouver une boite intéressante, trajets/déménagements) et ce n'est pas tout le temps possible (je l'ai fait avec peu (et non pas) d'attaches, aujourd'hui avec des gosses c'est plus complexe. Mais si je devais je le ferais encore.
Le côté futuriste que tu décris pourquoi pas. Mais finalement ça reste à peu près sur le même modèle, un modèle de service à la base.
Ce que je vois, c'est beaucoup plus le côté création de logiciel et non service/projet. Ok, ça ne correspond pas à tous les jobs, mais c'est ce que je recherche en priorité.
Et au final il y en a des boites comme ça, plus qu'on ne le croit. Bon par contre c'est rarement des grosses boites (lorsqu'on atteint 100 personnes c'est déjà beaucoup).
Après, lorsque j'écris mon bla bla je ne passe que rarement par la case compromis (ça serait beaucoup moins drôle). Mais il existe tout de même des boites de services qui elles sont bien, correctes, avec des projets intéressants, des conditions correctes, et techniquement bien. J'en connais peu, mais il y en a.
[^] # Re: Espace de rédaction : une très bonne idée, mais gare au franglais !
Posté par CrEv (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 4.
Merci :)
Hum, là je ne suis pas d'accord.
Déjà, je fais un effort pour en enlever (sinon il y en aurait beaucoup plus)
Et surtout, la traduction exacte n'existe pas toujours.
Peut-être, mais il n'existe par contre pas d'équivalent en français à ma connaissance, et surtout le terme est à mon avis compréhensible par beaucoup étant donné que la majorité des conférences/documents sur le sujet sont en anglais.
S'il y avait un terme français pourquoi pas, en attendant non.
Ok, j'aurais du écrire côté opérationnel
Ce n'est pas que la mise à l'échelle, c'est surtout la capacité à être mis à l'échelle, à résister au changement lors de la mise à l'échelle.
D'ailleurs l'article wikipedia sur scalability est plutôt clair, indiquant (et je partage cet avis) qu'il « n'a pas d'équivalent communément admis en français »
Sur les autres, ok.
Maintenant, de manière globale, la majorité des contenus sont en anglais. Et oui il m'arrive souvent d'en prendre des termes qui sont plus parlant que leurs équivalents français lorsqu'ils existent.
De la même manière je ne parlerai pas de cadriciel, mais de framework. Côté néologisme c'est pas mal non plus. A la rigueur en partant sur des dérivés de l'industrie pourquoi pas, mais les machiniciels me donnent en général des boutons.
[^] # Re: C'est qui X, Y et Z ?
Posté par CrEv (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #44. Évalué à 4.
En fait, il y a eu quelques corrections (et suggestions de liens) de Nyco, baud123 et Benoit (si je ne me trompe, mais je ne sais pas quel compte)
Donc merci à eux.
C'est la première fois que je tente l'espace collaboratif. Je pense que je vais bientôt ouvrir une nouvelle dépêche pour l'épisode suivant, si certains sont intéressés c'est possible.
[^] # Re: bibliothèque personnelle
Posté par CrEv (site web personnel) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 2.
Oui, en gros c'est ça :)
D'ailleurs c'est quelque chose d'assez facile à faire. Et pour le coup une partie sera bientôt dispo sur le dépôt principal qui permettra de gérer des comptes différents et facilement directement depuis le code de l'appli de lecture (par contre l'objectif est du test, donc c'est pas une api complète, mais ça y ressemble un peu)
Ben j'espère bien ;)
# hier sait
Posté par CrEv (site web personnel) . En réponse au sondage Vos outils de collaboration en entreprise. Évalué à 3.
dommage qu'on ne puisse mettre du choix multiple ;)
Après avoir eu des boites où c'était un mélange de réunion/mail, je suis vraiment content d'être dans une boite où l'une des premières choses qu'on fait est de rejoindre un canal IRC (en fait pas pour moi j'ai enfin compris tout l'intérêt de irssi avec le mode proxy :) )
C'est cool, sympa, git/capistrano/jenkins crash ses logs dedans
parfois, la discussion est plus sympa/pratique de la sorte alors qu'on discute avec le gars derrière l'écran, mais pas d'interruption
En fait je me rend compte que les autres endroits où j'étais, c'est le mail qui était utilisé à la place. Mais c'est pas génial. Par contre c'est complémentaire.
[^] # Re: Félicitations
Posté par CrEv (site web personnel) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 5.
Ok, j'ai l'impression de radoter un peu dans la réponse, mais je pense que l'incompréhension est surtout lié à un point (je te laisse le trouver c'est pas compliqué ;))
Attention, il ne faut pas confondre TEA et la liseuse TeaBook Open Reader.
D'ailleurs tu peux très bien aller acheter un livre numérique sur le site de cultura ou decitre et simplement télécharger l'epub. Et dans ce cas (si l'éditeur n'a pas obligé de DRM, dans ce cas ce serait en effet un poil plus complexe) ben tu l'as ton bouquin. Tu peux le copier, le dupliquer, le placer sur plusieurs liseuses, dans plusieurs logiciels, l'archiver, etc.
Il faut voir le lecteur dont la dépêche parle comme un lecteur supplémentaire, pas forcément comme le seul est unique lecteur. C'est aussi ce qui permet d'avoir des usages différents.
TeaBook Open Reader est un lecteur en partie de ce type. Mais :
Oué enfin je peux quand même lire mon livre serveur coupé puisque la lecture hors ligne existe. La partie compte est nécessaire pour imaginer acheter depuis le lecteur, pour synchroniser la lecture, les marques pages, etc mais ne change rien pour la lecture proprement dite.
Non. L'API (offerte par la technologie de TEA) ne permet pas cela. Il y a une doc de l'API sur le wiki sur github, tu veras qu'on en est loin.
Maintenant, lorsque je vois http://www.numerama.com/magazine/13484-kindle-amazon-efface-a-distance-des-centaines-de-livres-achetes-legalement-maj.html ou http://www.bekkelund.net/2012/10/22/outlawed-by-amazon-drm/ je me dis que ce que tu crains existe déjà et que l'API de TEA ne le permet pas en l'état.
Mais finalement ce que tu crains est théoriquement possible (enfin c'est plus complexe quand même) dès que tu as un logiciel connecté et que ce logiciel est le point central obligatoire.
Il est possible d'ajouter à une bibliothèque des livres provenant d'ailleurs, manuellement.
Et il faut voir que le côté instance pour un libraire à d'autres avantages comme par exemple pouvoir bénéficier des conseils, mises en avant ou autre comme si j'allais dans la librairie en bas de chez moi. Le but à ce moment est de continuer à être en relation avec mon libraire habituel, même s'il est question d'ebook.
Sur ce point (design, nom) il faut le voir de la même manière que firefox pour mozilla. Le code est ouvert, la marque non.
Le code publié ne contient rien du tout concernant les DRM.
J'aimerais bien dans ce cas que tu nous présentes ce que ça pourrait être alors. Quelles solutions apporter au multi lecteur avec synchro des marques pages, annotations, etc par exemple ?
Peut-être que tout n'est pas toujours clair (moi je suis dev, pas forcément super bon en communication hein) mais le concept est génial. Et est plus vaste que TeaBook Open Reader.
[^] # Re: Félicitations
Posté par CrEv (site web personnel) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 2.
Ce qui est justement l'un des objectifs de TEA, indiqué dans son manifeste :
[^] # Re: EPUB = ZIP + XML + HTML
Posté par CrEv (site web personnel) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 4.
tout simplement, une bibliothèque distante (c'est déjà expliqué plus haut, si je veux lire sur 3 machines différentes c'est quand même beaucoup plus facile) avec synchronisation et sauvegarde de l'emplacement de lecture (pouvoir reprendre la lecture sur un autre ordi sans rien avoir installé, juste en consultant l'appli)
[^] # Re: text/javascript
Posté par CrEv (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #43. Évalué à 4.
En fait ça existe déjà. Par exemple pour utiliser du vbscript sur IE.
Et je pense que pour Dart c'est fait de la sorte (mais comme dit, il faut un navigateur le supportant)
Mais oué ça serait plutôt cool :)
[^] # Re: Félicitations
Posté par CrEv (site web personnel) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 7.
Oui, et ?
Attention, là on parle (de teabook open reader) d'un lecteur. Pas de la plateforme de vente.
Alors oui pour pouvoir offrir des fonctionnalités comme la synchronisation de l'emplacement de lecture, des annotations, des bookmarks, etc entre plusieurs devices il faut bien synchroniser ces données à un moment donner et le passage par un point central est plus simple.
Mais rien du tout n'oblige à utiliser ce lecteur ou cette bibliothèque plutôt que de télécharger le livre et de le lire sur le support / dans le logiciel de son choix.
Alors là j'aimerais vraiment bien savoir d'où ça vient…
Car il n'est aucunement question de location d'ebook mais d'un lecteur permettant de lire ceux qui ont été acheté, téléchargés, y compris sur une autre plateforme d'ailleurs.
Il n'y a pas de limitation lecteur <-> plateforme de vente
d'ailleurs les première contributions c'est aussi ce que vous voudrez en faire hein…
on parle toujours de lire le livre que l'utilisateur a déposé (ou poussé lors de son achat). Oui si tu veux je peux rajouter le nombre de fois que l'utilisateur à ouvert son livre, maintenant je suis pas certain que ça ait un intérêt.
heu… comment dire…
Mentir sur quoi d'ailleurs ?
Un lecteur d'epub a été développé.
Il n'est lié à aucune plateforme de vente, il permet juste de se connecter à une API qui elle fourni la gestion des comptes, des livres dispos etc.
Ce lecteur est sous licence libre.
Il n'y a pas de gestion de DRM.
Il est tout à fait possible de développer une plateforme, qui implémente cette API.
Un concurrent peut en développer une s'il le veut.
Tu peux en développer une si tu veux, et d'ailleurs en interdisant dessus tout livre avec DRM.
Donc je résume, tu as un lecteur (le sujet de la dépêche) qui est libre, qui ne gère pas les DRM, que tu peux modifier comme tu veux mais en fait c'est mal.
J'espère que c'est un peu plus clair, mais si ce n'est toujours pas le cas n'hésite pas.
[^] # Re: Pas un simple logiciel de lecture
Posté par CrEv (site web personnel) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 6.
Pour le coup ce que je trouverais mal fichu serait d'avoir à installer à logiciel sur chacun de mes terminaux de lecture, puis de les connecter à un serveur pour pouvoir synchroniser ma lecture. Là c'est transparent et je trouve ça plus agréable.
Maintenant, je comprend ton point de vue, mais je pense par contre que ce n'est pas qu'une question de mode mais aussi de simplicité pour un utilisateur classique.
[^] # Re: Pas un simple logiciel de lecture
Posté par CrEv (site web personnel) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 9.
Oui et non.
Oui, c'est plus qu'un simple logiciel de lecture.
Sauf que tu peux l'utiliser hors connexion. Tu peux lire tes livres sans accès au site, sans installer de logiciel ou d'extension. En fait sans autre chose que ton navigateur.
Merci.
Allez, un exemple à la con : tu as plusieurs machines (imaginons un pc au boulot, un chez toi, et une tablette). Tu commences un livre sur ton pc perso. Tu passes au salon, tu veux le continuer sur ta tablette. A ta pose au boulot, tu souhaites en lire quelques pages.
Ben avec un serveur, l'avantage c'est qu'à chaque fois que je vais ouvrir mon livre, il sera à l'endroit où je l'ai arrêté.
Sans cela, je fais comment ? Je télécharge le livre sur mes 3 machines ? Je me souviens où j'ai arrêté la lecture à chaque fois ?
Heu… un truc aussi bête que la lecture d'EPUB ?
La je suis pas certain que ce soit aussi simple. Et oui la cible est plus large que simplement un pur lecteur d'epub (bien que rien que sur ce point il y ait beaucoup beaucoup de choses à faire). Par exemple, pouvoir connecter l'application avec un site de vente d'epub, que les livres achetés soient automatiquement placé dans ta bibliothèque (donc pas d'étape du genre télécharger le livre, aller dans ton lecteur, le placer dedans). Et tes livres sont, si tu le souhaite, dispo hors ligne.
[^] # Re: Graphisme en go
Posté par CrEv (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla‐bla #43. Évalué à 3.
Nan mais c'est une petite pique sympa, faut surtout pas le prendre mal :)
En fait je pense surtout que go a la capacité d'aller beaucoup plus loin que la prog système / le scripting, bien que ça en soit l'usage majoritaire aujourd'hui.
Et voilà un assez bon exemple.
J'ai pas encore codé avec ce binding, mais lorsque je trouverai le temps je pense que je vais l'essayer un peu, ça a l'air sympa.
[^] # Re: Justement !
Posté par CrEv (site web personnel) . En réponse au journal Les entrées de suivi ouvertes les mieux notées. Évalué à 5.
Ben nono j'en sais rien, mais en fait je ne vois pas vraiment le problème…
Souvent pour faire ce genre de choses j'utilise des machines virtuelles avec partage de mes sources. Là sur ma machine j'ai 2 vms qui contiennent du nginx, du ruby, du rails, du mongodb, du redis. Il est où le problème ?
En fait je pose la question inverse : pourquoi n'aurait-il pas tout ça sur sa machine ? (ou une vm dédiée)
[^] # Re: Un grand merci.
Posté par CrEv (site web personnel) . En réponse au journal Les entrées de suivi ouvertes les mieux notées. Évalué à 4.
Et en général, ça marche comment ?
configure (ou make si c'est mal fait ce qui est souvent le cas) va te cracher une liste imbitable de dépendances non résolues. Tu vas les installer et relancer, jusqu'à ce que ça tombe en marche.
Ok c'est un peu exagéré mais finalement pas très loin.
L'autre solution aurait été de décrire l'installation de la sorte :
Et là tu résous les erreurs lorsqu'elles arrivent (genre tu n'as pas bundler pour commencer)
Mais franchement je vois pas trop ce qui est étonnant dans ce descriptif.
Et d'ailleurs, rien ne t'empêche de prendre toutes les commandes intéressantes, de les coller dans un script qui s'appelle
configure. Ensuite tu fais un aliasmake=bundle installet tu sera pas bien loin de ce que sembles apprécier.