alberthier a écrit 166 commentaires

C'est que le débat de la fin.
Et les sources de ton délire, elles sont où

D'où tu sors ces âneries ? Ton propos est incroyablement nombriliste !

Allez, un début :
http://www.dailymotion.com/video/x2qoq5x_cartes-sur-table-comprendre-les-migrations-vers-l-europe_news

C'est dommage cette évolution.

La simplicité du protocole permet de l'implémenter sur de petits microcontrôleurs (genre PIC32)
On peut faire une simple interface de config avec une série de balises input
Faire du HTTPS sur ce type de matériel est exclu

J'imagine que python & co vont se mettre à la page si HTTP en clair est supprimé, mais pour l'instant, python -m SimpleHTTPServer c'est du HTTP tout court. Ces petits serveurs sans prétention existent dans tous les langages et sont bien pratiques en dev.

HTTPS sur internet, pourquoi pas, mais sur le réseau local, bof, bof…

Exact.
Le projet utilise jQuery 2.x

Visiblement KHTML n'est pas supporté.

lors du lancement de git-webui le navigateur par défaut est lancé, chez toi ça doit être Konqueror.
J'ai vérifié le support des navigateurs principaux dans leur dernière version (Chrome 37, Firefox 32, Safari 7, IE 11)

Merci :)

N'hésite pas à remonter les bugs / manques que tu rencontres

Je ne connaissais pas, c'est visiblement assez similaire dans l'objectif.

Je ne sais pas si avec ungit tu peux cloner le repo depuis un autre PC, avec git-webui tu peux.

Mais c'est sur que l'interface d'ungit est plus originale et très soignée, webui est bien plus simple

Tu peux facilement vérifier le script d'installation; t'enlèves juste | bash:

curl https://raw.githubusercontent.com/alberthier/git-webui/master/install/installer.sh


Si je te fournissais un paquet DEB, ça serait pareil. Je peux mettre le bazar sur ton système avec les scripts de pre/post installation. C'est même pire puisque j'aurais les droits root.

C'est aussi mon frein principal à l'utilisation de KDE.

Il faut bien avouer que gvfs est vraiment très efficace. Vu qu'il crée des points de montages automatiquement n'importe quel soft peut y accéder sans code particuler.

On présente toujours le japon comme la patrie de la robotique, mais personnellement j'ai jamais vu un robot japonnais vraiment bluffant. Ce sont loin d'être des idiots, ils font certainement plein de recherche et de trucs avancés mais ça n'a jamais été appliqué à quoi que ce soit d'autre qu'à des jouets.

Super, des robots hotesse d'accueil qui peuvent faire 200 expressions faciales différentes, waaahhh
Les robots humanoides, je suis encore vraiment sceptique sur leur utilité…
Et à Fukushima ils ont du faire venir des robots des US pour aller dans la centrale, c'est con parce que là pour le coup ça aurait été intéressant d'avoir des robots d'exploration.

Par contre ces derniers temps c'est surtout aux US qu'on voit les travaux en robotique les plus impressionnants. Il suffit de voir les réalisations de Boston Dynamics, de l'université de Pennsylvanie, et j'en passe.
Le plus impressionnant étant Curiosity, OK c'est pas une machine très design, mais elle fait un travail de recherche actuellement infaisable par un humain et pour beaucoup moins cher. Rien que le système d'amarssisage automatique est simplement bluffant : http://www.youtube.com/watch?v=h2I8AoB1xgU la vidéo est hollywoodifiée, mais les mecs ont quand même fabriqué un skycrane !!

Je ne sais pas si c'est exactement ce que tu veux ni même si ce projet fonctionne toujours, mais il existe des bindings Qt/.NET:

http://techbase.kde.org/Development/Languages/Qyoto

Si distribution Linux, c'est utiliser linux comme noyau, OK, Android est une distrib linux.

Je pensais plus à l'environnement dans lequel s'attend à évoluer

Entre Debian, Suse, RedHat, etc… un utilisateur/programmeur va retrouver ses billes, c'est très similaire.
Même sur les linux embarqués produits par Buildroot on retrouve facilement ses petits, on reste en terrain connu.

Si Windows 9 utilise Linux comme noyau en gardant le reste, pour toi ça en ferait une distrib linux. c'est peut être vrai dans l'absolu mais c'est pas ce à quoi vont s'attendre les gens si on leur dit "Windows 9 est un Linux"

Si tu te dis "Android utilise Linux comme Debian, ça doit pas être bien différent, ben tu va avoir pas mal de surprises"

C'est très mal connaître Android. Les seules similitudes entre Android et une Debian sont le noyau utilisé et le fait que les deux soient des unix, point barre.

la libc, c'est bionic, une libc pour l'embarqué développée par Google parceque uClibc c'est du GPL.
le shell, je sais pas exactement ce que c'est mais ça doit être une sorte de busybox version BSD.
L'affichage c'est SurfaceFlinger (qui leur reprocherai de se passer de X11)
Le son c'est AudioFlinger (là il y a plus de débat par rapport à PulseAudio)

Si vous voulez comparer Android à un autre OS, cherchez plutôt du coté de BeOS. Vu la similitude, j'imagine qu'après la fin de Be Inc, bon nombre d'ingénieurs Be on commencé à bosser sur ce qui allait devenir Android.

La structure des répertoires: /system/bin au lieu de /usr/bin => comme BeOS
Le mécanisme d'IPC principal: Binder => comme BeOS
Les concepts de base du framework viennent de l'API BeOS:
- android.os.Looper <=> BLooper
- android.os.Handler <=> BHandler
- android.os.Message <=> BMessage
- android.view.View <=> BView
- etc…
Même si les APIs on divergées, les concepts restent les mêmes.

Il y a presque autant de différences entre une Debian et Android qu'entre Debian et Mac OS X

A héberger soi même : leed a l'air interessant. http://projet.idleman.fr/leed/

Lorsqu'on ne configure pas de page d'accueil dans firefox (about:home), comme lorsqu'on vient de l'installer, il propose un champ de recherche google :
http://www.themilwaukeetimesweekly.com/wp-content/uploads/2012/06/firefox-13-about-home.jpg

Pour les utilisateurs de zsh, il y a aussi Oh-My-Zsh qui est intéressant:
https://github.com/robbyrussell/oh-my-zsh/

la liste a devient un objet attaché à l'objet fonction 'foo' qui est réutilisé à chaque appel

C'est vicieux car on a l'impression de donner une valeur par défaut et ce n'est pas le cas.

http://www.artfulcode.net/articles/mutable-default-parameter-values-python/

Du coup pour les valeurs par défaut, il est préconisé de mettre None et de traiter le cas das la fonction:

def append_one(a=list()):
    a.append(1)
    return a

deviendrait

def append_one(a=None):
    if a is None:
        a = list()
    a.append(1)
    return a

J'ai jamais trop cherché, mais il y a une fonctionnalité de Skype dont je me sert souvent avec mes correspondants c'est le partage d'écran. GTalk supporte ça aussi ?

Oui, KJS est bien son ancêtre. Mais je pense qu'ils n'ont plus grand chose en commun.
Le découpage entre WebCore et JavaScriptCore doit être bien fait pour qu'il soit possible de changer d'interpréteur javascript.

WebKit est un moteur complet: rendu HTML (WebCore) + interpréteur Javascript (JavaScriptCore) :
http://trac.webkit.org/wiki/JavaScriptCore

Chez Google, ils ont effectivement remplacé JavaScriptCore par V8 pour Chrome tout en conservant WebCore

Non, il y a toujours toutes les applications avec l'organisation en arbre traditionnelle, mais c'est pas super bien présenté/accessible, effectivement.

Je vois souvent des critiques de cette interface mais j'ai l'impression que ces gens n'ont pas vraiment essayé Unity.
On présente ce shell comme un shell pour des gens ayant peu de connaissances en informatique, mais pour moi c'est plutôt un shell de geek. J'ai l'impression que le fond de la critique c'est plutôt "Unity c'est pas comme avant, une barre de tâches à la Windows"

Unity se sert beaucoup de la touche "Windows" (appellée <Super>) du clavier, c'est une bonne idée je trouve. Peu importe que ce soit MS qui ait introduit cette touche, elle est sur tous les claviers, autant s'en servir et l'utiliser pour interagir avec le shell est une bonne idée.

Les applications se lancent super facilement sans utiliser la souris grâce à la complétion:
<Super>term<Entrée> => lance gnome-terminal
<Super>fire<Entrée> => lance firefox
<Super>ink<Entrée> => lance inkscape

Le dock est sympa aussi (il faut aimer le concept de dock) et il y a aussi des raccourcis clavier associés automatiquement:
un appui prolongé sur la touche les affiche. En fait chaque item est numéroté. Chez moi
<Super>+1 => lance ou switch vers nautilus
<Super>+2 => lance ou switch vers firefox
<Super>+e => navigation entre les bureaux virtuels
et il y en a d'autres…

Il n'y a que le Alt-Tab que je trouve des fois un peu pénible : il groupe les instances d'une application et j'ai plutôt l'habitude d'un Alt-Tab qui navigue entre toutes les fenêtres au premier niveau. Mais malgré tout, toute la navigation entre les fenêtres se fait facilement au clavier.

Tout ça pour dire que je trouve qu'Unity est un environnement productif pour moi puisque quasiment tout peut se faire sans souris. Si vous préférez un environnement plus classique XFCE vous ravira, mais si le concept de Dock vous convient, je trouve qu'Unity est un bon choix.

Par ailleurs je me suis rendu compte grâce à Unity que je me servait très peu des barres de menu. Selon moi, ils ont donc eu raison de la déporter en haut de l'écran => plus d'espace et un environnement visuel plus épuré.

Et tout ça est disponible dans Ubuntu 11.10.

Avec Cyanogen tu peux retirer une autorisation à une application après l'installation. Certaines applis demandent des autorisations abusives : genre une appli d'envoi de SMS qui demande l'autorisation d'utiliser le GPS.

Effectivement, si on fait n'importe quoi avec ça, l'appli risque de ne plus fonctionner.

Non, pas de mon point de vue:
Ca veut juste dire que tu peux lancer les logiciels Gnome sans Gnome-Shell. Encore heureux.
Je peux me faire une session qui utilise Plasma de KDE comme shell et qui ne s'architecture qu'autour de logiciels Gnome: nautilus, eye-of-gnome, epiphany, gnome-keyring, etc... C'est ce que fait Unity et maintenant Cinnamon

Je ne suis absolument pas un expert de la question, des gens mieux informés me corrigeront, mais voilà comment je comprend le truc:
Gnome-Shell est coupé en deux morceaux: un coeur en C et des plugins en Javascript.
L'interface visible de Gnome-Shell est en fait un ensemble de plugins javascript. En choisissant ses plugins, on peut obtenir l'interface graphique qu'on veut.
Le problème se situe au niveau du coeur: il doit être assez générique et exhaustif pour que les plugins puissent faire tout ce qu'ils veulent et ce n'est visiblement pas le cas.

Comme je l'ai dit MGSE est une bonne chose pour GNOME, Cinnamon beaucoup moins.

Oui, Linux Mint propose déjà son jeu d'extensions pour donner une ergonomie à la Gnome 2 à Gnome Shell: MGSE. Quand j'ai vu ça, je me suis dit que ça allait dans la bonne direction : Gnome 3 ne fait pas l'unanimité mais fournit l'infrastructure pour faire ce qu'on veut. Visiblement ce n'est pas le cas. Après il ne faut pas désespérer : Cinnamon est peut être justement une tentative de lobbying un peu musclée.

Mine de rien chez Gnome, ils devraient mettre un peu d'eau dans leur vin. Après Unity, Cinnamon est le second shell alternatif pour Gnome 3. Qu'ils veulent proposer un nouveau concept de desktop et d'ergonomie, c'est bien, mais ils devraient aussi s'assurer que des gens avec d'autres vues puissent faire ce qu'ils ont en tête via des extensions plutôt que des forks. Il est bien plus dans l'intérêt de Gnome 3 que MGSE existe plutôt que Cinnamon.

Je en comprends pas vraiment pourquoi avoir forké tout GNOME.
Ce projet a de grandes chances d'être mort d'ici 1 an, c'est un boulot colossal de maintenir un fork de GNOME2
Pourquoi ne pas avoir porté gnome-panel vers GNOME3/GTK3 puisque l'essentiel du mécontentement envers GNOME3 vient de gnome-shell. Ca me semble plus réaliste de continuer à développer gnome-panel + qq outils GNOME2 dans le giron de GNOME3 en plus ils bénéficieraient des développements de nautilus, gedit, etc...