Moonz a écrit 3657 commentaires

La "sélection sexuelle", c'est quoi exactement ?

Un truc de biologistes. Rien d’aussi sérieux et solide que l’anthropologie, quoi.

Si ton questionnement est sérieux, Wikipedia est assez complet.

LXC et les cgroup il y a l’équivalent avec les jails sous FreeBSD, ils ont pas eu besoin de jeter leur système d’init « complètement dépassé ».

Mais essaye de te poser juste une question de base, rapide à répondre : des mecs sont payés par des boites pour développer la chose, d'autres mecs intègrent ça dans leur distro, mais ça ne sert à rien?

Où ai-je dit que ça servait à rien ? Au contraire, sur un des serveurs que je gère on a été parmi les premiers à adopter systemd (vu les besoins tu peux même pas imaginer à quel point ça a été un soulagement pour le coup). Simplement, si tu m’avais dit à l’époque « bon maintenant les gars on fout du systemd partout » je t’aurai pris pour un fou.

Si ce besoin n'est pas un besoin bizarre à toi que en fait le problème vient plutôt de toi, je ne doute pas que tes besoins seront répondus (soit par systemd, soit par un initd maintenu).

Le besoin est parfaitement couvert par le vieux init complètement dépassé, ne t’inquiète pas pour ça.

Mais le problème ne vient peut-être pas de systemd…

Je croyais que « qui peut le plus peut le moins » ?

Si t'as une faille dans un soft accessible par reseau, tu risques la meme chose quel que soit le soft.

Ben non. Toute faille ne se résume pas à exécution de code arbitraire à distance.

Non, par exemple cette faille facilite un accès non-autorisé webcam/micro sans pour autant donner contrôle de tout le PC.

Peut-être parce qu’à l’époque la majorité des gens n’étaient pas aussi « connectés » ?

Le problème c'est que nombre de personnes sont persuadés que son besoin propre est supérieur à ceux des autres. Ici systemd répond à des besoins de nombreuses personnes et entreprises car l'init d'il y a 30 ans n'était pas adapté à la conception de l'informatique moderne.

Ceci n’est pas un argument. Je résume ce que tu as écrit : « c’est vieux donc c’est nul ».

On attend toujours les besoins « modernes » auxquels FreeBSD ne peut pas répondre (puisque ces abrutis de devs FreeBSD n’ont pas vu La Lumière et s’obstinent à utiliser un truc pas adapté à l’informatique moderne, les cons)

Si tu as une meilleure solution pour répondre au besoin tout en respectant cette phrase, n'hésite pas, propose!

Once again : quel besoin exactement ?

Parce que c’est super facile de dire « systemd répond mieux au besoin » sans définir précisément « besoin », moi aussi je peux le faire : MediaInfo c’est de la merde, ffmpeg répond mieux au besoin.

Parce que moi, sur une de mes machines, j’ai un besoin qui est « traitement complexe dans rc.local », et je peux te dire que systemd se vautre lamentablement là dessus.

Sauf que c'est tout refait avec des technos pourries et des VM super lourdes

Exactement comme Java Web Start quoi.

OSSv4 est à nouveau libre, dispo sous Linux, et a quelques fonctionnalités en plus que Alsa (dont un niveau de son par application, comme PulseAudio). Donc certains l’utilisent, oui.

Et c’est un problème, parce que… ?

Et en quoi est-ce spécifique à Linux ? Phonon, SDL, Xine, Gstreamer que tu retrouves dans le schéma fonctionnent aussi sous Windows. Windows qui lui-même a plusieurs API audio (DirectSound, Core Audio API, DirectMusic…)

(des flèches entre ALSA et OSS?!?)

Oui, Alsa peut utiliser OSS (Alsa -> OSS -> output device) tout comme une application OSS peut « utiliser » alsa (via la couche de compatibilité).

C’est pas une pile audio, c’est une liste de libs audio avec des flèches indiquant qui peut utiliser quoi comme backend juste pour faire croire que c’est compliqué.

Remplace Alsa par CoreAudio et le schéma est tout aussi valide sous MacOS X (à une ou deux exceptions).

C'est du comique de répétition ?

man gst-launch est un très bon début, surtout sa section Pipeline Examples.

mais sans PA, je ne crois pas que j'aurais pu mettre ça en place si rapidement.

Ça se fait en un pipeline simple sous gstreamer. Je crois pas que ça prenne des années non plus. Point bonus tu peux même réencoder ça en vorbis et le stocker.

Tu oublies le mathématicien : 1, 2, 3, beaucoup.

Dans la catégorie blague grasse :

Trois uniques survivant d’un naufrage se retrouvent sur une île déserte : un informaticien, une femme et un homosexuel. Rapidement, la tension monte entre la femme et l’homosexuel. Au bout d’un moment, la femme va voir l’informaticien et lui dit « cette tapette commence à me taper sur le système. Je te propose que cette nuit, pendant qu’il dort, on l’assomme et qu’on le rejette à la mer. On pourra ainsi reprendre une activité sexuelle normale ». Quelques heures plus tard, l’homosexuel vient voir l’informaticien et lui fait cette proposition : « j’en ai raz le cul de cette hystérique. Si ça te dit, ce soir on l’assomme, on la rejette à la mer et on pourra reprendre une activité sexuelle normale ».

La nuit suivante, l’informaticien assomma et rejeta à la mer la femme et l’homosexuel, et put ainsi reprendre une activité sexuelle normale.

Parce qu’Objective-C est un excellent langage, et que les API d’iOS sont très proches de celles de NextStep (par transitivité avec Cocoa ;)), qui est le meilleur framework qu’il m’ait été donné de voir (concepts extrèmement simple et très puissant, framework très cadré tout en restant très souple à l’usage).

La seule raison pour laquelle j’ai arrêté le dev iOS c’est que je hais l’« ergonomie » de tous les produits Apple (mention spéciale au getionnaire de fenêtre de MacOS X et aux claviers des MacBook qui me donnent envie de jeter le portable par la fenêtre dès que j’en ai un dans les mains).

(il a grandi, il utilise le terminal qu'en dernier recours).

Plus je grandis, plus j’utilise le terminal et plus les interfaces graphiques sont un dernier recours.

C’est grave docteur ?

J’ai des backups (dans le méchant cloud)

N’empêche que un SSD qui grille chez moi = interruption de service + intervention manuelle qui peut prendre des heures (le temps d’aller en racheter un, en priant pour que ce soit ni un dimanche, ni un jour férié, ni à 9h du soir), souvent au pire moment (puisque par définiton tu te rends compte qu’il grille que quand tu l’utilises, contrairement à Google qui monitore son matos H24 y compris quand je suis au lit). Un disque dur qui grille chez Google, ça fait partie de leur fonctionnement normal, avec 0 downtime pour l’utilisateur. Et un disque dur/SSD qui lâche, contrairement à ce qui est sous-entendu plus haut, ça arrive.

(tiens, avant-hier mon disque dur externe a littéralement grillé (fumée) quand je l’ai branché, je dois décidémment être dans une période de merde…)

Pour l'affaire Verizon, tu prends un abonnement téléphonique hors US ? C'est sur que cela va dans le sens de la simplicité, des petits prix … non définitivement l'auto-hébergement c'est d'une complexité et ça coute un bras.

C’est vrai que l’auto-hébergement du service de téléphonie portable c’est bien plus crédible.

Il n’est pas impossible que les récentes emmerdes d’Apple avec le fisc américain aient un rapport avec cette « résistance », à mon avis… Surtout à la lumière des derniers scandales du même type (utilisation de la menace des « contrôles fiscaux » contre des opposants politiques).

• c'était quand le dernier crash sans prévenir ( cad sans alertes de smartmontools ? )

Il y a une semaine, SSD qui me lâche sans bonne raison (quasi-neuf, je vais d’ailleurs aller faire jouer la garantie). Toutes les données perdues. Heureusement, rien d’important dessus.

• c'était quand la dernière fois que Google/Yahoo/Whatever a viré un de vos mails ?
• c'était quand la dernière fois que Google/Yahoo/Whatever a une indisponibilité complète ?
• c'était quand la dernière fois que Google/Yahoo/Whatever a supprimé un service que vous utilisiez ?

Jamais.

Conclusion ô combien étonnante, Google > SSD perso niveau fiabilité.

Je ne vois pas non plus pourquoi tu aurais besoin d’une authentification forte pour te connecter à gmail.