LupusMic a écrit 1481 commentaires

GNOME est probablement plus connu que ne le sera jamais la tablette Gnome de Groupon.

Je n'ai pas dit le contraire. Mais pour invoquer l'argument du parasitage de marque (comme un Nestlé pourrait le faire), il faut que la marque soit connue et qu'il y ait un intérêt et donc une volonté à parasiter la marque.

Sachant que Linux a 1 % de part de marché

De quel marché ?

que GNOME est au moins connu par la moitié

Humidifie un peu plus ton doigt s'il-te-plait. Mon père a utilisé GNOME pendant 5 ans, il n'a jamais retenu le nom de GNOME. Mais il est vrai que c'est un exemple isolé.

Je doute que Groupon vende plus de 300 000 tablettes.

D'ailleurs ça ne marchera jamais GroupOn, qui voudrait acheter en groupe des bien rien que pour les avoir moins chers ?

Bref, mon point c'est que j'ai du mal à justifier l'intérêt de cette campagne. En dehors de payer des dommages et intérêts, de payer des cabinets d'avocats, je ne vois pas.

GNOME est un environnement de bureau.
Gnome est un terminal de points de vente.

Le droit des marques est complexe et parfois surprenant. On peut cependant affirmer sans problème que les marchés visés par ces deux projets de se recouvrent pas, qu'il n'y a pas de concurrence. Mais si on considère l'argument du parasitage, il faudrait déjà que GNOME soit largement connu. Et en dehors de quelques poilus, GNOME n'est connu de personne.

C'est d'ailleurs pour ça que C# a un comportement indéfini B-)

Tout ce que je lis ne met en exergue que des défauts. En effet, SystemD transpose à l'OS ce qui fait la complexité des frameworks de programmation, à savoir le découplage, l'injection de dépendances et un workflow event-driven. J'arrive plus ou moins à accepter le concept au niveau de la programmation d'applications complexes, bardées de tests, mais j'ai du mal à voir un avantage au niveau d'un OS, qui doit pour être manipulé sans risquer un comportement étrange rien que parce qu'un service lointain est désactivé pour une raison ou une autre.

C'est pour ça que je pose la question, ça m'intéresse vraiment de comprendre comment des sysadmins peuvent voir cette explosion de la complexité de l'OS.

Certes, ce ne sont que mes contacts, mais en même temps, qu'aucun n'entrevoit la possibilité de le mettre me rend prudent.

Quels sont les arguments favorables à SystemD de tes collègues ?

Il existe encore des distributions sans SystemD, donc pas besoin de se cotiser. Mais ce que je vois surtout, c'est l'étude de migration vers des BSD pour éviter systemd.

Tu sais très bien que les admin sys n'aiment globalement pas le changement, car ce qui était garanti ne l'est plus, et qu'il faut revalider tout les processus.
C'est très important de permettre la conservation d'un système existant qui fonctionne. Quand je vois le mal qu'ont mes employeurs consécutifs, rien qu'à migrer des applications PHP, je me dis que le passage à SystemD va être très difficile. Et oui, migrer d'un CentOS à FreeBSD sera certainement moins douloureux pour un sysadmin que de basculer sous SystemD, qui brise les fondements d'Unix tels qu'ils sont globalement acceptés par ces professionnels.

De plus, je tiens à préciser que je ne connais aucun ops (sysadmin) qui voit SystemD comme une bonne chose.

Dans quelle situation a-t-on une file de message rattachée à l'utilisateur B mais sans aucun processus ? Parce que dans ce cas je ne vois pas où iraient les messages…

Ben ils restent dans la queue jusqu'à ce qu'ils soient lus.
http://linux.die.net/man/2/msgctl

Et merci d'avoir apporté les précisions qui répondent à mon questionnement.

Côté fonctionnement interne, logind détruit maintenant automatiquement les objets d’IPC (InterProcess Communication, communication interprocessus) appartenant à un utilisateur quand il se déconnecte complètement, pour libérer des ressources. Cela inclut sémaphores, files de messages et mémoires SysV, ainsi que les files de messages et mémoires partagées POSIX. Les objets SysV et POSIX n’ont traditionnellement pas de cycle de vie, cette fonctionnalité corrige cela.

C'est complètement surréaliste. Déjà il faudra me définir le concept de déconnexion complète. À mon sens, on a une session ouverte ou aucune, mais il n'y a pas d'état intermédiaire.

Ensuite, comment seraient gérées les IPC inter-utilisateurs, ou qui doivent survivre à leur créateur ? Je pense entre autres aux queues de messages qui permettent de créer des systèmes asynchrones ? En effet, si j'ai un service tournant sous l'utilisateur A qui écrit dans une queue, créée par un utilisateur B, pour qu'un cron job lancé sous l'utilisateur C traite les messages de la queue, que se passe-t-il quand aucun processus de l'utilisateur B n'existe ?

Disons que lorsque c'est pour un meeting qui doit être tenu dans les 5 min, c'est mieux de savoir que ça arrive.

Quand aux plages de travail, en effet, j'approuve, même si personnellement je pense qu'une durée de l'ordre de l'heure est plus adaptée.

En effet, ça reste un vrai problème. Rien que pour pouvoir tester Gnome 3, je suis toujours à prier que le pilote graphique ne crash pas.

Le problème que ça me pose, c'est que je ne peux pas avoir confiance en mon environnement de travail. C'est gênant.

Le problème n'est donc pas la présence d'icônes, mais leur changement selon l'état de l'application. Je n'ai jamais compris les gens qui aiment avoir leur app tray clignoter comme une fête foraine, je ne suis d'ailleurs pas le seul, et c'est pourquoi il est possible de le désactiver dans les bons logiciels.

Quand à la tentation, en effet, avoir mon IM client signifiant que mon boss a besoin d'un document de manière urgente me diverti de mon travail. Assurément.

Il s'agit clairement d'un choix ergonomique qui se défend qui s'approche du "distraction free".

Je vais donc mettre mon téléphone et ma tasse de café derrière mon écran pour éviter d'être distrait par ces systèmes instables (oui, leur état change en permanence).

Je déteste être distrait, c'est pourquoi je fais en sorte de désactiver tout ce qui clignote, ou les changement d'interface inutile (du genre, le changement d'ordre de la liste de contact dans GMail). Si l'état de mon écran change, c'est pour m'informer d'un événement important.

Ceci dit, je n'ai jamais été dérangé par le changement de minute/heure/jour. Le changement de seconde est plus discutable. Pas plus que le crash d'une application dans un bureau voisin ne me dérange.

Par contre, quand je veux changer de bureau pour aller autre part, oui, j'aime avoir d'un battement de cil l'information dont j'ai besoin. Et j'ai souvent besoin de savoir dans quel bureau je suis, quel jour nous sommes (ça change tous les jours) et quelle heure il est (encore plus mouvant).

Bref, je hais Gnome 3.

Tout ce qui est utile.

D'ailleurs, « self-admiring » ne devrait-il pas être traduit par « narcissique » ?

En effet, il est tout à fait impossible que ton FAI re-route les requêtes DNS vers de méchants serveurs DNS.

C'est tout à fait faux. SQLite est très performant, mais il y a quelques petites choses à savoir, telles que l'usage des transactions en écriture.

N'est-ce pas là le critère principal d'une bonne intégration ?

Nope. En fait, les module de ce type sont des exemples de ce qu'il ne faut pas faire : introduire du code dans le serveur, alors qu'il peut, et devrait, être exécuté en dehors. Ici le problème est que PHP n'est pas intégré à Apache, mais y est greffé.

"Inimaginable" ? C'est donc qu'elle n'est même pas réelle ? :-)

Ah ben on va faire de la sémantique : inimaginable qualifie quelque chose, un concept, un phénomène, qui dépasse notre entendement. Ce qui n'est pas réel peut être imaginable, bien qu'inconcevable.

En 2000, tu avais le choix entre "MacDo" d'une part, quelques restaurants médiocres et totalement inabordables d'autre part. Le choix MacDo était donc le choix rationnel, loin d'une quelconque appétance pour la "saleté" qui reste totalement fantasmée.

Je suis tout à fait d'accord. Les problèmes qu'avaient entraîné les scripts CGI ont fait le lit d'outils comme PHP. PHP avait la qualité de ne pas être trop compliqué et de limiter ce que peut faire le propriétaire des pages en contournant le tabou des scripts CGI. Quand on a que des tomates pourries à manger, ben on les mange pour ne pas crever de faim.

• très bonne intégration avec Apache (les solutions en Perl et Python n'arrivaient pas à la cheville de mod_php)

Très mauvaise intégration, entraînant des problèmes de sécurité divers. En fait, il faudrait parler d'intégration simple à déployer et maintenir. Mais ce modèle a posé de nombreux problèmes par le passé, ayant entraîné des horreurs (openbasedir et autres mécanismes de pseudo-sécurité).

• un fichier .php == une page

Alors certes, cela simplifie la vie de celui qui veut créer un compteur et quelques gadget pour un site personnel. Malheureusement, cette conception entraîne /de facto/ la création d'une surface d'attaque inimaginable.

conséquence des deux premiers, disponibilité très large chez les hébergeurs pas chers

C'est là qu'on est d'accord. PHP est à la programmation Web ce que MacDo est à la restauration. Et j'en mange trop (des deux).

APIs d'interaction avec MySQL en standard

Encore une fois, c'est vrai que c'est très pratique et permet de garantir des comportements, mais malheureusement, c'est un mauvais design. Une bonne pratique en sécurité, c'est de tout désactiver pour activer ce dont on a besoin. Mettre à disposition une API pour la dizaine de BDD qu'on n'utilisera jamais n'est pas un bon modèle de sécurité. Mais encore une fois, c'est un compromis coût/qualité.

MS DOS
Basic
MS Windows
Spreadsheets
etc

En fait, l'excellence technique est souvent la garantie de l'échec. Je pense que c'est dû à un problème de viabilité économique. La propreté et l'excellence demandent plus de temps (et donc d'argent) à concevoir et à assimiler. Du coup, ce sont des solution qui sont entre la civilisation et la barbarie qui réussissent, avec une nette tendance à pencher vers la barbarie.

Un autre facteur important à prendre en compte est aussi l'aspect décomplexant d'une solution bancale. Un débutant sera mins gêner pour écrire du code dégueulasse dans un environnement dégueulasse, qui permet le code dégueulasse créé d'être cependant fonctionnel. C'est comme un sol : sur un sol propre, on a pas envie de marcher parce qu'on ne veut pas saloper (et entre maman gueuler qu'elle vient juste de nettoyer et qu'elle a pas envie de passer la serpillière toutes les 5 minutes !).

Quiconque est expert en PHP connait http://phpsadness.com/

Qui est ce « on » ? Parce que bon, je ne vois pas l'intérêt de ce « verbe ». Traduire ou compiler sont tout à fait adapter.

Ce qui voudrait dire qu'il faut vérifier la version de PHP avant d'exécuter un script. Je rappelle que le succès de PHP est entre autres raisons du à sa totale absence de propreté.

Ah ben j'avais zappé ta réponse, désolé.

Je ne trouve pas Vec<Vec<Vec<int>>> plus clair que vector<vector<vector<int>>>>, si au moins tu avais donné la version canonique std::vector<std::vector<std::vector<int>>>> ;) De toute façon, on ne déclare pas ça, c'est à encapsuler.

Je ne vois pas trop l'intérêt d'un mot clé pour déclarer une fonction. Pour une classe/structure non plus d'ailleurs, mais bon.

D’autre part, je n’ai pas énormément utilisé le langage mais ça ne m’a posé aucune difficulté. Pas plus que les abréviations telles que std, def, var, int, len, str, etc. Je pense que tu n’as pas testé et que si tu testerais, tu te rendrais compte que ce n’est pas absolument pas un problème.

Le plus gros problème que ça me pose, c'est que ça donne un mauvais exemple à suivre.

http://en.wikipedia.org/wiki/Hyperion_(Simmons_novel)

Avec IP over Shrike.