cosmocat a écrit 2100 commentaires

Utilisateur uniquement de Firefox depuis les versions beta de Phoenix, car c'est le seul navigateur qui défend l'utilisateur, je dois avouer que Chrome est quand même meilleur pour ce qui est l'expérience de développement Web.

Et donc pas mal de dev utilisent Chrome en parti pour cette raison. Et je trouve ça dommage car ce sont souvent les informaticiens qui font de l'évangélisation/publicité.

Et on commence à voir pas mal site / spa qui merdent avec Firefox et qui sont Chrome only. 😕

Dernier exemple, après 10 min d'utilisation de slack (à cause du taff), impossible de faire un changement dans la conf d'un channel.

J'utilise OSM sur mon téléphone via l'application OSMAnd depuis peu. J'ai véritablement halluciné de la qualité des cartes notamment en mode randonné. La concurrence, Google Maps en premier, est loin derrière.

Je partage l'avis mais aujourd'hui les utilisateurs attendent souvent plus de services autours de la carte (Streetview, recherche, …) et à ce niveau OSM n'est pas au niveau ce qui peut être un frein à son utilisation.

(Un utilisateur et contributeur occasionnel d'OSM)

Ça tombe bien, Google vient de mettre à jour les chiffres. Android est sur 2.5 milliards d'appareils ce qui est au total plus que Windows et iOs réunis.

Donc comme minix est sur un sous ensemble de Windows, CQFD.

Peut être faudrait-il reprendre les concepts de base et repartir sur une implémentation en Rust de base plus sure ?

https://gitlab.redox-os.org/redox-os/redox ?

Si quelqu'un qui s'y connait un peu plus que moi en noyau linux et est assez motivé pour aller mettre 2 lignes de résumé sur la page wikipedia des noyaux pour les 6 dernières version du noyau, ça serait cool…

https://fr.wikipedia.org/wiki/Noyau_Linux#Chronologie

La différence principale entre Pijul et Git est que Pijul fonctionne avec des changements (ou patches), là où Git ne fonctionne qu'avec des snapshots (clichés ou versions).

J'ai du mal à vraiment saisir quels sont les avantages intrinsèques à la gestion par patch et ceci comparé à Git.

Car dans les faits, pour des optimisation de place et d'échange entre dépôt, Git stocke aussi dans les pack files des "diffs" (donc des patchs), c'est juste qu'on le voit pas en tant qu'utilisateur.

Mais surtout, pour beaucoup d'opération Git recalcul ces patchs (affichage de logs, rebase, …) pour pouvoir faire certains opérations donc rien de fondamentalement différent de Pijul.

Donc qu'est ce que PiJul permet qui n'est fondamentalement pas possible de faire avec Git qui recalcul les patchs quand cela est nécessaire?

Après, je ne remet pas en cause le fait que le choix d'utiliser des patchs fait que peut-être amène à une interface utilisateur plus cohérente…

Un article sur le sujet avec le nom de la personne qui fait çà

https://arstechnica.com/gaming/2019/04/you-can-now-download-the-source-code-for-all-infocom-text-adventure-classics/

J'aurais dit la même chose (voir même une pull request) mais il semble qu'il n'y ait pas de dépôt "principal" dans lequel créer des issues.

De fait, je pense qu'il vaut mieux cloner un dépôt pour avoir l'email de historicalsource et lui envoyer un mail, en espérant que ça soit une adresse utilisée (ce qui semble le cas).

Et peut-être lui demander de créer ce dépot "principal" pour pouvoir communiquer facilement…

Pour ceux qui ont un peu de difficulté avec l'anglais, je l'ai vu passé en français :

https://www.zdnet.fr/actualites/le-poste-de-travail-linux-est-en-difficulte-39883239.htm

99,9% des gens ne savent pas taper au clavier, et ce n'est pas élitiste de dire ça

Je n'ai pas dis que dire ça était élitiste, j'ai dit que souhaiter rendre la vie de ces 99,9% plus difficile parce qu'on est dans le 0,1% est élitiste.

Les 99.9 des gens ne sont pas incapable d'avoir une dispo de clavier imprimé et collée à coté de l'écran. C'est à la portée de tout le monde. Ils choisissent juste un moyen sous-optimal ¯(ツ)/¯

C'est pas qu'ils choisissent, c'est que ça ne leur vient même pas à l'idée. Et c'est bien ça le problème…

He! He! Encore une fois, une remarque un peu élitiste (et bien coupée de la réalité.)

Essayes de me donner le pourcentage de personnes qui font çà?
Et après tu comprendras que pour les autres (disons 99,9% des gens), avoir le clavier physique qui correspond est un nécessité.

C'est bien de prendre son cas de monomaniaque pour une généralité mais un jour il faut ouvrir les yeux…

Donc espérons que certains constructeurs proposent les 2 maps pour que par un effet d'auto-renforcement, des meilleurs dispositions (BEPO ou AZERTY Afnor) que l'actuel AZERTY soient disponibles.

PS: Je sais que ta méthode est la meilleure pour apprendre à taper (mon frère la faite et a en très peu de temps obtenu presque la même vitesse de frappe que moi) mais il faut savoir être pragmatique et réaliste.

Si tu as besoin d'un marquage quelconque sur ton clavier, c'est que tu regardes ton clavier, donc que tu apprends mal à t'en servir.

Un peu élitiste comme vision mais, pour moi, pas représentative de la réalité pour 2 raisons.

Lorsque tu es en phase d'apprentissage (le cas qui nous interresse ici pour faire la transition), c'est quand même beaucoup plus facile de regarder le clavier lorsque tu as un trou de mémoire que d'aller chercher la map en ligne ou de l'avoir toujours d'imprimée.

Également, tu peux savoir taper sans regarder pour plus de 80% des touches et aimer pouvoir regarder de temps en temps pour les rares caractères peu répandus…

Preuve supplémentaire. Le caractère pour la combinaison altgr + 7

Macron
« Diacritique combinant » : Ce caractère se combine avec le caractère tapé juste après, comme l'accent circonflexe dans l'AZERTY traditionnel.

Est-ce que quelqu'un sait s'ils ont mis la disposition bépo telle quelle ou s'ils l'ont légèrement modifiée?

En tout cas, espérons que cette norme permettra d'avoir des constructeurs qui les proposeront (car c'est toujours plus facile d'apprendre à taper sur un clavier physique correspondant à la map utilisée).

C'est pas grave mais chapeau quand même!

hmmm….. Il me sembe avoir déjà entendu parlé de "red hat".

C'est quoi? et cela se situe où??

Hmmm!?!

les retraits/disparitions :

l'interface GTK+ n'est plus prise en charge (cf Wireshark passe à Qt en 2013) et portaudio n'est du coup plus nécessaire

J'ai vu passer ce Tweet qui parle d'une lib de calcul en c++ libéré par la même occasion : https://mobile.twitter.com/migueldeicaza/status/1103720067328438272

En voilà une : "Le démontage des gifles" mais je sais pas si ça veut vraiment dire quelque chose…

Le journal où en parler : https://linuxfr.org/users/gabin_2-2/journaux/le-degonflage-des-mythes-wayland-degonfles-sur-reddit

https://lwn.net/Articles/776102/

So this was a fairly unusual merge window with the holidays, and as a
result I'm not even going to complain about the pull requests that
ended up coming in late. It all mostly worked out fine, I think. And
lot of people got their pull requests in early, and hopefully had a
calm holiday season. Thanks again to everybody.

The numbering change is not indicative of anything special. If you
want to have an official reason, it's that I ran out of fingers and
toes to count on, so 4.21 became 5.0. There's no nice git object
numerology this time (we're about 6.5M objects in the git repo), and
there isn't any major particular feature that made for the release
numbering either. Of course, depending on your particular interests,
some people might well find a feature they like so much that they
think it can do as a reason for incrementing the major number.

So go wild. Make up your own reason for why it's 5.0.

Because as usual, there's a lot of changes in there. Not because this
merge window was particularly big - but even our smaller merge windows
aren't exactly small. It's a very solid and average merge window with
just under 11k commits (or about 11.5k if you count merges).

The stats look fairly normal. About 50% is drivers, 20% is
architecture updates, 10% is tooling, and the remaining 20% is all
over (documentation, networking, filesystems, header file updates,
core kernel code..). Nothing particular stands out, although I do like
seeing how some ancient drivers are getting put out to pasture
(cought*isdn*cough).

As usual even the shortlog is much too big to post, so the summary
below is only a list of the pull requests I merged.

Go test. Kick the tires. Be the first kid on your block running a 5.0
pre-release kernel.

         Linus

Un japonais avait fait un fork qui a évolué depuis.
Et c'est lui qui relance la version principale en intégrant ses modifs, dont le 3 way-merge ! Même si il y a des améliorations à faire pour que ce soit satisfaisant…

Pour ce que ça vaut comme fiabilité (sous Windows) :

https://github.com/git-for-windows/build-extra/pull/203#issuecomment-416610675

Ajouter des fichiers binaires dans git à une mauvaise réputation, mais c'est surtout parce que git n'est pas capable de les fusionner en cas de conflit et parce qu'ils s'accumulent avec le temps

Pas seulement, c'est aussi lourd lors du clone (contrairement à lfs qui télécharge que les binaires qui vont populer le répertoire de travail).

Ce qui peut être très pénalisant quand tu dois cloner souvent comme par exemple les serveurs de build.