CrEv a écrit 4577 commentaires

incoming et outgoing avec ou sans fetch

in = !git fetch && git log --pretty=oneline --abbrev-commit --graph ..@{u}
lin = log --pretty=oneline --abbrev-commit --graph ..@{u}
lout = log --pretty=oneline --abbrev-commit --stat --graph @{u}..
out = !git fetch && git lout

serve

serve = daemon --reuseaddr --verbose  --base-path=. --export-all ./.git

Et ce n'est pas fini, Apple ont refait à peu près les mêmes erreurs avec Thunderbolt, le truc qui :

• était censé être à fibre optique parce que c'est mieux que le cuivre, mais finalement a commencé sur cuivre parce que la fibre optique c'est compliqué en fait ;

Ok, soit.

• était censé être à fibre optique à terme, mais en fait est resté sur cuivre parce que c'est moins cher ;

Oui, ou aussi parce qu'ils arrivent à tirer des perfs intéressantes. Et que le prix joue. Et que au final on s'en fout un peu que ce soit fibre optique ou pas, non ?

• était censé devenir un standard universel, mais a été lancé en exclusivité sur des ordinateurs Apple ;

Heu… mouai.

• a réutilisé la connectique DisplayPort pour ne pas avoir à réinventer un connecteur, et a du coup dû introduire une compatibilité avec DisplayPort vu que les gens allaient forcément y brancher des écrans.

C'est quand même sympa ce point, non ?

Le dernier point est un peu polémique, parce qu'ils ont plutôt bien réussi cela, mais ça n'a vraiment pas dû leur simplifier la conception.

Attend j'ai pas compris, c'est où le point polémique ? Ce qu'ils aient bien réussi ce point ?

Le résultat final n'est pas mauvais, mais c'est quand même bien parti pour rester, comme Firewire, une niche, face à USB toujours en position de standard universel.

Pourtant du displayport si je ne me trompe on n'en voit pas que sur du matos apple, non ?
Et donc ça veut dire qu'on peut imaginer un passage diaplayport -> thunderbolt vu qu'il y a une compatibilité, non ?

Bref, j'ai rien compris où tu voulais en venir.

il est important de peindre les caractères utiles, au minimum «»{}[]|~

Ça dépend à qui tu t'adresses. Je ne connais pas grand mode hors métiers genre dev, admin sys, etc qui ait besoin de []{}|~
Et ces personnes sont (doivent être) capables d'apprendre à utiliser leur outil de travail principal.

| c'est shift-alt-L parce que ça ressemble à un l (l'avantage c'est aussi que ça se fait à une seule main, ça tombe bien sous les doigts)
~ c'est alt-n parce que l'endroit où on le retrouve souvent (hors console) c'est ñ
{[ c'est sur ( et }] sur ), c'est tellement plus logique

Par contre «» c'est pas évident, c'est certains.
Le reste est au contraire très logique et il suffit d'apprendre qu'il existe alt et alt-shift pour modifier.

Sur la touche " on a accès à “ et ”
Sur la touche ' on a accès à ‘ et ’
Sur la touche -_ on a accès à — et –
Sur la touche . on a accès à …
Sur la touche =+ on a accès à ≠ ±
Sur la touche <> on a accès à ≤≥
Sur la touche ? on a accès à ¿
Sur la touche ! on a accès à ¡
Sur la touche % on a accès à ‰

C'est pour ça que j'aime bien cette disposition, à part certains points plus douloureux pour ceux qui programment comme | et ~ et les «» le reste est vraiment logique.

Après ce n'est peut-être pas la disposition la plus optimale (pour ça il y a bépo, dvorak ou autre) mais en terme de découvrabilité c'est agréable comme clavier.

beaucoup de caractères utiles ne sont pas peints sur les touches

Ben oui, c'est exactement ce que j'ai écris…
Mais en même temps vouloir écrire tous les caractères sur toutes les touches c'est juste totalement idiot.

elle n'a aucune chance d'être normalisée […] or l'existant, c'est en majorité de l'azerty classique

Je me doute, mais d'un côté les deux ont une disposition de base azerty commune, pour la plupart des gens ne sachant pas vraiment utiliser un clavier sans regarder ça ne changerait pas grand chose.

(tant pis, je continuerai à utiliser un clavier apple :-D)

Il faudrait surtout imposer à Apple de le suivre car leur clavier fait plus que chie

Pourtant j'aurais plutôt vu l'inverse, utiliser la disposition mac en standard, je trouverais ça beaucoup plus pratique.
Genre le @ très facilement accessible, les majuscules accentuées sont là par défaut (par rapport à une disposition windows classique). Je préfère aussi de très loin la gestion des ({[ et )}] que je trouve beaucoup plus cohérente, tout comme ~, | ou \ par ailleurs.
Après c'est vrai qu'il manque certaines inscriptions pour que ce soit plus simple, genre pour «» ou ‘’ “” (mais ça reste logique pour ces dernier)
Les — et – sont aussi facilement accessibles je trouve, tout comme =≠± <>≤≥

Bref, à part un peu d'inscription je trouve cette disposition tellement plus agréable que je ne comprend pas qu'on utilise pas plus de disposition mac tout court.

Ça serait intéressant qu'il y ait autre chose que V8 pour ça.
A priori il n'est pas si mal que ça, 90% de support d'ES6 (plus que babel) par exemple.
Aujourd'hui il ne tourne que sous windows mais ils ont annoncé bosser sur le support multi plateforme et en premier lieux linux : https://blogs.windows.com/msedgedev/2016/01/13/chakracore-now-open/

et on l'explique à chaque fois

Dans ce cas c'est peut-être signe qu'il y a un problème.

Puis bon, avouez que Google Alphabet c'est la boîte qu'on aime bien haïr ;).

Ben non, justement, pas forcément.
On peut les critiquer sur plein de points, maintenant c'est super loin d'être blanc ou noir.
Et ils font aussi des trucs bien, que ce soit côté code libre que côté données accessibles genre avec le Data Liberation Front.

C'était l'un des objectifs de Google lors du fork : nettoyer à la tronçonneuse le code de webkit, virer des archis inutiles pour Google, virer du code lié à JavascriptCore alors qu'ils utilisent V8, etc.

Que le code GPL soit publié, c'est "juste" une obligation légale, encore heureux qu'ils le publient!

Ben non, même pas.
Ils doivent juste pouvoir fournir ce code aux clients le demandant, c'est ça l'obligation légale.

Regarde de ce côté : https://pixhawk.org/choice

oula oui, là c'est tout de suite plus complexe.
Une pixhawk (et globalement ce qui est embarqué dans les drones) c'est pas bien puissant. D'où l'intérêt des plateformes comme celle mentionnée dans le journal ou intel edison par ex.

Si tu veux faire du traitement vidéo ça risque d'être chaud, caméra + diodes ça me semble chaud mais pourquoi pas.
Après tout dépend ce que tu veux et à quelle précision.
Tu peux très bien imaginer faire communiquer tes drones entre eux (par exemple en bluetooth) et qu'ils s'envoient leurs coordonnées GPS. Maintenant un GPS c'est pas précis (genre 2-4m mini) mais ça fonctionne.
On peut aussi imaginer des choses en ultra wideband mais les test qu'on a fait n'avaient pas été concluant.

Le but serait l'un devant et l'autre qui suit automatiquement ?

Il a une centrale inertielle (accélégro, gyro) magnéto, gps. Tu voudrais quoi d'autre ?
Mini robo dans quel genre ? parce que l'électronique est pas forcément facile à modifier je crois, genre tous les ESC sont ensemble sur une seule carte.
Après sur une pixhawk (ce qu'il y a dans les iris) on peut rajouter d'autres capteurs si on veut.

Du coup je comprends pas vraiment…

Et moi je ne sais pas où est le code source des parrot. Après ça dépend peut-être de quel parrot on parle aussi… Genre le code du bebop je ne crois pas qu'il soit dispo. Ou alors (de ce que j'ai vu, mais je me trompe peut-être) sans centrale inertielle ni algos de vidéo ni wifi… ce qui ne sert pas à grand chose. Alors oui il y a des API, des SDK, mais de là à dire que c'est open source non.
Peut-être par contre qu'il existe des drones plus libre chez parrot, je ne sais pas (je n'ai pas regardé les autres).

Par contre un bebop et un iris c'est en gros la même gamme de prix (500-600€) même si l'équipement n'est pas le même. Et un iris ça se bidouille et surtout ça se programme. On peut changer le code, on y a accès, on l'améliore, on peut rajouter ou supprimer ce qu'on veut, flasher, etc (je l'ai fait).

les drones, les vrais, se pilotent avec une radiocommande de modelisme

Même pas.
Un drone, un vrai, c'est quoi ? Quelle catégorie de drone ? Et drone c'est autonome, non ?
Parce que bon un drone ça peut aussi faire 250kg et avoir une turbine, et pas une lipo et 4 pauv' hélices.
Bref les "vrai" c'est ce qu'on veut.

Et surtout, c'est très dépendant de l'usage.
Si ton but c'est de le piloter précisément alors oui une radio c'est pas mal.
Si le but est, par exemple, de faire de la surveillance c'est cool d'avoir un truc qui ne se pilote pas du tout par un humain.
Si le but est de te filmer de manière autonome en restant entre 5 et 50m de toi, un smartphone c'est suffisant et agréable.

Bref, les "vrais" drone c'est juste du fantasme pour ne pas comprendre qu'il y a différents usages.

Je ne crois pas qu'il soit dispo…
Si tu veux bidouiller du code, tu peux prendre des Iris de 3DR et jouer avec le code source. Par contre le code est… heu… d'une qualité moyenne pour avoir vraiment mis le nez dedans.

Ha oui, parce qu'il n'y a pas que la techno qui permet de s'éclater au boulot, on a un mode de management assez particulier, en gros et pour faire très court c'est autonomie et 0 manager. Même si sans les commentaires c'est plus compliqué, voici quelques slides que j'avais présentés au mixit15.
Et sinon on a une filiale qui démarre à Lyon et une (bientôt 2) personnes à Melbourne.

Bon ben j'en profite même si ça ne rentre pas exactement dans la définition du cool du journal mais j'ai l'impression que ça l'est quand même…
Dans ma boite on fait de l'embarqué (C++, Ada 2012, Spark prochainement) dans un cadre certifié (DO178C jusqu'au niveau A) ou non. Pour de l'aviation et des drones. On bosse pour squadrone qu'on a co-fondé et on a lancé un projet d'autopilot pour drone avec un haut niveau de qualité (en gros similaire à ce qui se fait côté aviation).
On fait du mobile cross plateforme aussi (Android - iOS avec coeur commun en C++).
On fait du web et on essai de garder des technos agréables et productives (en général ruby mais aussi un peu de clojure même si on voudrait en faire plus).
On fait des applis natives (C++ Qt pour du médical, on tente de faire nos produits en electron aussi).
En général on fait le max en TDD et parfois du BDD, on aime avoir un haut niveau de qualité dans nos devs.
On a des plannings en lego (bon ok presque, je suis en train de le finir).
On a aussi des personnes qui bossent sur des systèmes de reconnaissance (obstacle ou autre) par l'image (vidéo).

Ha oui, on est à Grenoble et on embauche.

/pub

Je pense que l'on a aussi tendance à enrober les souvenirs (« c'était mieux avant ® ») mais aussi à se rappeler les bons comme mieux, et les mauvais comme pas si mal. Bref, c'est assez biaisé ;)

Ha non, ce n'était pas dans ce sens. Plutôt que c'était une bonne méthode d'apprentissage.

Je ne dis pas que j'irais écrire mon code sur du papier aujourd'hui. Juste que d'avoir appris à faire autrement était une bonne chose. Au fond c'est comme avoir appris à faire des calculs de tête alors qu'on a tous des calculatrices / ordi / … qui peuvent le faire à notre place.
Et pour le coup assembleur + loin de l'environnement d'exécution force à apprendre et prendre conscience de pas mal de choses pour pouvoir imaginer le programme (puisqu'il faut comprendre, de tête, vraiment ce qui va se passer). Et une fois qu'on l'a appris, on peut l'utiliser y compris avec des outils. Malheureusement utiliser uniquement des outils et du VDD (var_dump debug) / PFD (printf debug) ou autre, c'est pas top pour ça.

Ça me fait penser que j'ai encore des cahiers entier de programmes écrits en MASD (assembleur pour HP).
Genre en vacances j'écrivais mes programmes au crayon, et en rentrant je les rentrais sur mon ordi pour les compiler.

C'est con mais au fond je suis content d'avoir connu cette façon de faire, encore plus avec de l'assembleur.

Si j'ai vraiment besoin de calculer, j'utiliser Google Doc / Numbers /

Et sinon j'ai toujours un HP48 et un HP49 (mais les boutons ont très mal vieilli :/). Elles fonctionnent toujours toutes les 2, c'est sympa !

Ben oué.
Ça tombe bien d'ailleurs, je bosse sous mac et je ne suis pas le seul dans ma boite.
Et ce même quand je bossais sur des softs embarqués pour des drones.

Après oui beaucoup de boites d'infos ont la facheuse tendance à n'acheter que du matos de merde aux devs, c'est pas comme si ça pouvait être important. Mais bon, il suffit de changer de boite.

Merci pour l'explication de texte. Ça veut donc dire "candidat à la release", c'est à dire que sauf bugs de dernière minutes c'est la version de release.
Bref.

imagine si il y a un journal pour chaque RC de distro même déjà les connues

Ho ben désolé de ne pas basé mon avis sur quelque chose qui n'existe pas. Il n'y a pas (et jamais eu) un journal pour chaque RC de chaque distro. Donc à partir de là cet argument, comment dire…
Franchement qu'il y ait un journal pour une beta, une RC, du moment qu'il raconterait quelque chose (genre ce qui a changé, les sujets actuellement en test, etc) je trouverais ça bien. Si on ne peut même plus balancer des journaux sur des softs open source je sais pas trop où ça va…

Mouai.
Annoncer une RC dans les journaux je trouve ça normal et bien. Justement, ce n'est pas une dépêche. Par contre on peut avoir envie de tester une RC (qui est donc censée être fiable tout de même) sans pour autant suivre l'actualité de la distro. Si on ne peut plus annoncer une RC (ou même une beta) dans les journaux, où va le monde^W^W linuxfr ?

Le seul truc c'est que les jour'nal bookmark say mal.

En effet, ce genre de modèle réduit n'a pas réellement une vitesse de translation importante (en tout cas pas dans l'axe de l'hélice), d'autant qu'on lui demande surtout de faire du vol sur place stabilisé, et que du coup les hélices baignent dans leurs turbulences relatives.

C'est 'achement variable. De plus en plus on cherche à faire des petits "drones" qui suivent des gens, des véhicules, etc. Et là il faut parfois avoir une vitesse (et une accélération) relativement importante dans quasiment tous les axes. On est assez loin du vol sur place stabilisé.
Après je suis d'accord que ça ne correspond pas à tous les usages non plus.

un modèle réduit quadricoptère à 4 pales ne serait pas si illogique que ça

Voui, de la même manière j'ai déjà vu quelques hexacoptères avec des hélices à 3 pales. Ça faisait un truc assez petit, assez faible rayon de l'hélice et au final un "drone" plutôt compact.