karchnu a écrit 393 commentaires

  • # Nom de domaine .netlib.re

    Posté par  . En réponse au journal Hébergement mutualisé pas cher. Évalué à 1.

    Si tu cherches un nom de domaine vraiment pas cher (0€ TTC), tu peux te diriger vers net libre qui fournit un nom de domaine en .netlib.re. C'est gratuit et basé sur du soft libre. Il n'y a pas de conditions arbitraires pour garder le nom de domaine (comme un trafic minimal, ce qui est demandé par le .tk par exemple) donc aucune crainte à ce niveau.

  • [^] # Re: Grosse colère ?

    Posté par  . En réponse au journal LinuxFr.org n'aime pas discuter du hors sujet [titre réécrit]. Évalué à 9.

    Combo 1er avril + vendredi. Ça fait pas bon ménage.

  • [^] # Re: ce sera rétro compatible ce truc ?

    Posté par  . En réponse au journal Bash dans Windows. Évalué à 2.

    À la mise à jour (gratuite et à mon initiative), mon shell continue de fonctionner exactement de la même manière, ma distribution est stable, les outils ne changent pas (ou très rarement).

    Et je comprends tout à fait la frustration de bosser avec powershell, les commandes ne sont clairement pas aussi simples et intuitives… et XML. XML rah ! La seule (selon moi fausse) bonne idée est de passer des références dans les pipes au lieu de tout copier.

  • [^] # Re: Ça semble si bien, et pourtant…

    Posté par  . En réponse au journal Redox OS. Évalué à 1.

    Les news sont quasiment du niveau d'un message de commit avec quelques images de leur interface graphique. En quoi ça aide à comprendre le projet dans son ensemble ?

    Oui, chacun fait comme il veut pour coder son projet. Pour un OS, partir avec un minimum de doc est par contre indispensable. Dire qu'il y a pire ailleurs n'est pas un argument.

    Oui, les développeurs sont arrogants, quand on dit en gras dans une page we will not replicate the mistakes made by others c'est assez limite.

    --

    Mais oui, comme toi, je suis assez content qu'on ait ce projet sous la main, pour voir ce que ça pourrait apporter de développer un OS from scratch avec un langage moderne qui apporte réellement des avantages, en permettant de debug plus facilement, de repérer voire éliminer certaines catégories de bugs, etc.

  • [^] # Re: Ça semble si bien, et pourtant…

    Posté par  . En réponse au journal Redox OS. Évalué à -9.

    Attaque ad hominem suivi d'un "regarde le livre là, qui n'explique pas le projet, que je ne peux de toute façon pas comprendre moi-même puisque je ne sais pas lire le langage utilisé". Ce commentaire montre exactement ce que je disais : il manque de la documentation.

    Oh, et en passant : en 1991 on ne faisait peut-être pas de documentation avant de coder, mais le but du projet est bien de ne pas reproduire les erreurs passées ? Là c'est raté.

  • [^] # Re: Ça semble si bien, et pourtant…

    Posté par  . En réponse au journal Redox OS. Évalué à 1.

    Ça ne répond pas à ce que j'ai dit : on n'a aucune info sur ce qui a été fait, pour un projet qui se veut novateur et qui prétent apporter plein de nouvelles choses, pourquoi partir directement sur du code sans explications ou marche à suivre ?

    Comme ça a été dit : pour l'instant c'est joli en tant que PoC, après faudra voir si ça a une quelconque chance d'être utile sur le long terme. L'utilisation d'un langage jeune, l'arrogance des développeurs et le manque de documentation mettra peut-être un terme au projet. Wait & see.

  • # Ça semble si bien, et pourtant…

    Posté par  . En réponse au journal Redox OS. Évalué à 6.

    … je ne peux m'empêcher de penser que si la documentation est totalement incomplète (même sur des parties critiques) mais qu'elle inclut déjà des bons morceaux de troll, ça ne fait pas très sérieux. Tout comme le fait qu'il y ait déjà des jeux (type snake) qui sont implémentés.

    Jeux + trolls > documentation critique au projet ?

    S'il n'y avait pas déjà des bouts de code j'aurai dit que ça ne vaut rien du tout, que ce n'est qu'un doux rêve, là il y a le code et pas de documentation. Est-ce que ça veut dire que personne n'a pensé au projet dans son ensemble avant d'aller dans son éditeur de code préféré ?

  • [^] # Re: Donc en résumé

    Posté par  . En réponse à la dépêche IT-Edit 2.0, un éditeur de texte avec terminaux intégrés. Évalué à 3.

    Lancer des commandes externes c'est avant tout pour intégrer le résultat dans ton éditeur, et allez plus vite dans l'édition de ton texte, ton code, etc.

    Un exemple simple :

    :r!ls

  • # Donc en résumé

    Posté par  . En réponse à la dépêche IT-Edit 2.0, un éditeur de texte avec terminaux intégrés. Évalué à 4.

    Si je résume ce que j'ai vu sur le site et ici-même, on a un éditeur basique qui sait lancer des commandes externes, parfois dans des terminaux, parfois graphiquement.

    Qu'est-ce que je peux faire ici et que je ne pouvais pas faire en (juste) configurant des raccourcis pour mon environnement de bureau ? Vim sait déjà lancer des commandes externes, c'est même l'une de ses plus grandes qualités, et avoir un terminal à côté de son éditeur ça revient juste à lancer un autre terminal (potentiellement un raccourcis de l'environnement de bureau là encore). Donc quel est l'intérêt de tout ça ?

  • [^] # Re: Que les larbins se taisent…

    Posté par  . En réponse au journal Sale temps pour les informaticiens lanceurs d'alerte. Évalué à 6.

    C'est bien pour cela qu'on a le droit à la désobéissance civile uniquement si on nous demande de faire quelque-chose d'illégal ET qui met en danger la vie d'autrui.

  • [^] # Re: Pourquoi ?

    Posté par  . En réponse à la dépêche Swift sous GNU/Linux - Introduction. Évalué à 8.

    Ce schéma n'apporte aucune information, si ce n'est un avis totalement subjectif et incomplet.

  • # Pourquoi ?

    Posté par  . En réponse à la dépêche Swift sous GNU/Linux - Introduction. Évalué à 10.

    Pourquoi voudrait-on de cet outil ? N'y a-t-il pas déjà des dizaines d'autres langages qui sont disponibles ayant les mêmes fonctionnalités (voire plus) sur nos systèmes favoris ? Quel avantage j'aurais à me mettre à Swift ? Pourquoi ne pas ajouter quelques fonctionnalités à des langages déjà existants plutôt que de partir sur Swift ? Ne serait-ce pas une hype passagère ?

  • [^] # Re: Ca va en s'améliorant

    Posté par  . En réponse à la dépêche Et si JavaScript allait droit dans le mur ?. Évalué à 4.

    Avoir un outil qui consomme tellement de ressources est clairement un symptôme. Quand un outil est bien pensé il ne va pas mettre à genoux ton ordinateur.

  • [^] # Re: Tableau comparatif

    Posté par  . En réponse au journal Et sinon, il y a toujours le Pine A64+. Évalué à 1.

    Pour mon ordinateur de bureau, juste pour le travail ou pour les activités les plus basiques, pas besoin de changer ma carte graphique pour prendre la dernière en vogue qui me pompe 300W. Je trouve d'ailleurs agréable l'idée d'avoir un tout petit ordinateur qui se planque derrière ma télé. J'ai pas besoin de 16 Go de RAM pour afficher mes mails, une vidéo, compiler un document LaTeX ou aller sur IRC.

    Pour des activités qui demandent vraiment beaucoup de puissance (ce qui m'arrive quasiment plus vu que j'ai arrêté de jouer il y a un moment), ok, faudra plutôt penser à virer le format ATX pour passer à plus petit, tout en conservant la flexibilité d'un ordinateur qu'on se monte soi-même.

  • [^] # Re: Les sauts

    Posté par  . En réponse à la dépêche Khaganat, un projet ludique et culturel. Évalué à 5.

    Ça fait déjà quelques commentaires qui parlent de ça et je ne comprends toujours pas : pourquoi détester autant le saut ? D'un point de vue du gameplay ça peut être intéressant, par exemple pour escalader une montagne certes, mais aussi pour sauter par dessus une barrière (oui, c'est tout bête mais pourquoi dans un jeu je me forcerai à respecter les passages piétons ? C'est assez pénible de le faire dans la vraie vie je ne vais pas me l'imposer dans un jeu), etc. Est-ce à cause de l'aspect jeu de rôle hérité de Ryzom ?

    J'ai un peu de mal à considérer l'aspect « Rêvez sans limite » vendue sur le wiki si en vrai le jeu se résume à recréer un univers aussi enfermé dans le role-play que Ryzom. C'était précisément ce qui m'a rebuté dans ce jeu : rien n'est présent en terme de gameplay, tout se joue dans l'imaginaire, tant et si bien que des joueurs ne passent même plus par la case jeu en ligne mais vont uniquement sur le forum. Ça a son public, mais je n'en fais pas partie.

    Les graphismes de Ryzom ne sont pas trop moches, et j'ai toujours pensé qu'il était possible d'en faire un jeu beaucoup plus attractif pour les joueurs occasionnels comme moi (hors de question que je passe des dizaines d'heures uniquement à lire l'histoire de l'univers du jeu). Et du coup, je trouve l'initiative de faire un gros bac à sable très intéressante. :)

  • [^] # Re: Serveur et données

    Posté par  . En réponse à la dépêche Khaganat, un projet ludique et culturel. Évalué à 1.

    Bon courage pour la documentation, c'est probablement l'aspect le plus critique à travailler si on se replonge dans du vieux code.

  • [^] # Re: Tableau comparatif

    Posté par  . En réponse au journal Et sinon, il y a toujours le Pine A64+. Évalué à 2.

    Quad-core à 2GHz, on s'approche peu à peu des caractéristiques suffisantes pour s'en servir d'ordinateur de bureau. Vivement fin 2016, on va peut-être virer nos ordinateurs fixes et se prendre un petit ordinateur qui consomme 5W et un petit SSD pour remplacer nos bonnes vieilles tours. :)

  • # Les sauts

    Posté par  . En réponse à la dépêche Khaganat, un projet ludique et culturel. Évalué à 1.

    Est-ce qu'il est prévu de pouvoir effectuer des « sauts » ? Parce que c'est tout bête, mais je trouvais que ça manquait dans Ryzom. Un élément de gameplay intéressant à ajouter serait le déplacement par véhicules aériens. :)

    Très bon projet, et j'irai regarder le code dès que j'aurai un peu de temps ! :)

  • [^] # Re: Compatible Linux ?

    Posté par  . En réponse au journal Et sinon, il y a toujours le Pine A64+. Évalué à 1.

    Apparemment Allwiner et Sunxi se sont contactés, voir le forum de Pine64.

  • [^] # Re: Compatible Linux ?

    Posté par  . En réponse au journal Et sinon, il y a toujours le Pine A64+. Évalué à 1. Dernière modification le 01 mars 2016 à 10:57.

    Idem pour moi, je suis backer du projet, mais je ne m'en fais pas tant que ça sur le support du matériel. On a une page sur linux-sunxi qui permet de savoir où en est le portage du noyau. Même si ça peut prendre un peu de temps, avec l'aide de quelques geeks on peut arriver à un support mainline.

    Après, je ne suis pas expert, pour moi il faut que le processeur soit supporté par le noyau (ce qui devrait être assez simple, vu que c'est de l'ARM assez classique bien que le modèle soit récent), et qu'on puisse gérer le boot sur un noyau quelconque facilement. Le boot loader c'est u-boot de ce que j'en comprends, il y a une version android un peu nulle qui fonctionne, donc avec un peu de rétro-ingénieurie on devrait arriver à faire la même chose pour un kernel mainline Linux tôt ou tard.

    Est-ce que j'ai mal compris quelque-chose ?

    Et vu le nombre d'unités qui se sont vendues, ça ne m'étonnerait pas de voir une communauté émerger de tout ça.

  • # Not sure if

    Posté par  . En réponse au journal Tout est écrit!. Évalué à 6.

    Je n'arrive pas à savoir si c'est du génie ou si c'est complètement stupide. Help. Je ne dors plus. :(

  • # Chiffrement de bout en bout

    Posté par  . En réponse au journal Quelques nouvelles en vrac de XMPP. Évalué à 2.

    Pour le chiffrement de bout en bout, il y a le groupe de travail JOSE de l'IETF qui a sorti quelques RFC sur des formats pouvant être utilisés pour le chiffrement (entre autres). C'est l'un des buts affichés directement dans leur RFC décrivant des cas d'usage.

  • [^] # Re: .tk

    Posté par  . En réponse à la dépêche Netlibre, un nom de domaine gratuit, facilement administrable. Évalué à 1.

    Encore une fois, vous passez à côté du sujet. Je vous invite à lire le reste de mes commentaires sur le sujet.

    Et si un autre service vous satisfait (.tk, .ovh, .whatever), grand bien vous en fasse. :)

  • [^] # Re: intégration avec d'autres gestionnaires

    Posté par  . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 0.

    Yes, I thought I could use chroot with my user but it's not the case. So I understand the need, but I still believe that we should have something like chroot in userspace, to be generic and easy to maintain. LXC is not easy to get working without root privileges, but maybe in near future… let's see ! :)

  • [^] # Re: intégration avec d'autres gestionnaires

    Posté par  . En réponse à la dépêche Sortie de HomeLinux, version 1.0.0. Évalué à 3.

    À creuser en effet. Je pense que la gestion du "/" peut se gérer simplement avec un chroot, voire un LXC en userspace. Au fond, l'idée que tu proposes est assez identique à un LXC/chroot => bac à sable où tu peux installer ce que tu veux (et là apt fonctionne bien, sans ajouter de code). Difficile de faire un bac à sable plus complet, tu peux installer toute une distribution dedans.

    La gestion du téléchargement et de l'installation automatique de trucs chopés sur github c'est sans doute utile pour quelques personnes, mais ce n'est qu'un tout petit plus par rapport à un apt. Pour l'idée d'avoir facilement un outil à disposition pour installer ses projets, là encore apt fait bien le travail, tu peux t'installer un dépôt et créer des paquets facilement.

    Peut-être que mon avis n'est pas pertinent, je passe peut-être à côté de quelque-chose, un besoin précis qui serait couvert par ton programme et seulement lui, mais je ne vois pas.