bubar🦥 a écrit 6975 commentaires

s/3D/gpu

Le "marché de niche", point de vue Nivida, ce n'est pas Android.
C'est plutôt les accès gpu sur des lames et des serveurs.

AMD est très présent sur ce secteur -les serveurs-. La virtualisation continue de prendre de l'ampleur. Il n'est donc pas déconnant que AMD cherche à optimiser son offre sur ce sujet aussi : la 3D pour les machines virtuelles in_the_cloud. On verra bien à qui (à quoi, quel gpu) leurs premières améliorations du driver libre sont destinées. J'met une main à couper que cela sera pour les gpu que l'on peut trouver sur les serveurs.

C'est très intéressant, ça. Merci (beaucoup)

Au pire, Apple se fait de la pub en insistant sur l'innovation graphique et ergonomique. Samsung réplique dans un esprit de "prio art". Bref de la com' tout ça.

Rien, absolument rien, qui ne concerne une quelconque innovation. Rien, absolument rien, qui ne justifie une intervention légale. Alors la sur-enchère "interdiction d'importation et de vente", c'est juste "n'importe quoi".

Pour rappel, la contrefaçon c'est lorsqu'on imite une marque afin de bénéficier de sa notoriété (sur la qualité, la finition, l'innovation, le social, la fabrication, etc... peu importe). Là, Samsung ne vends pas un produit en mettant le nom de "apple" dessus que je sache ? Tout est différent de A à Z.

Et ils s’excitent pour 4 icones carrés ? Symbole d'une ergonomie ? Zut j'aurai dû déposer le gourdin, moi, hop tout ce qui est de même forme enfreint mon brevet ! C'est vraiment n'importe quoi les brevets informatiques.

Ils ont pompés quoi (au pire) ??
Le fait d'avoir des icones carrés, une charte graphique uniforme ?
Le fait d'avoir un fond coloré pour les 4 icones du bas, permettant de toujours accéder aux fonctions basiques ?

Faut arrêter le délire, c'est un parfait exemple de ce que les "brevets informatiques" non absolument rien de "brevets".

Regardons ces photos, on va très nettement qu'il y a copie : des portes, des roues, un capot avant, et peut être même une aération sur le devant !! Ho plagiat !! Au voleur !! ils ont copiés !! Ha non, c'est juste que c'est pratique d'avoir une aération sur le devant, et que presque tout le monde le fait.

voiture2

voiture1

Avec cet exemple, on peut placer Samsung et Apple dans les deux cas, ça marche quant, pas de jaloux chez les fanboys.

Fortune !
+1, je partage :-)

//humour (détente, souriez, toussa)

c'est quant même savoureux de voir que le projet de portage de la GNUlibc sur le noyau freebsd, donc la GNUification d'un bsd, vu d'aujourd'hui à l'heure ou des BSD veulent de plus en plus se débarrasser de GNU (llvm meilleur exemple) finalement va aujourd'hui ralentir Debian GNU/*

BSD win, partout. Ha non, ça va être GNU. qu'is not unix, d'ailleurs.

//fin du troll

mount va être patché ou on va bientôt devoir utiliser systemctl ?

Pourquoi continuer d'utiliser un outil lorsqu'un autre le remplace ? ça à l'air anodin, et de prime abord il est plus simple de répondre "pour ne pas casser les habitudes". Oui c'est un bon exemple du côté "bricolage totalement insupportable" qu'on rencontre parfois (souvent ?) sur les unix aux tafs. C'est bien _ au début_ car c'est pratique. A la longue ça va traîner un tas d'outils et de scripts maison basés sur des outils obsolètes mais patchés et maintenus "pour la compatibilité". Or la "compatibilité" ce n'est pas ça, ça c'est du bricolage. La compatibilité c'est que le nouvel outil soit capable de prendre en charge l'ensemble des fonctionnalités de l'ancien. Non ?

J'ai un peu dévié de ta question, et ce n'est pas une réponse à ta question, mais plutôt la continuité d'une interrogation. Je pense que systemd va apporter aussi cela, c'est un effet de bord, mais un effet de bord intéressant : il participe à décimer le côté "jojo la bricole" que, perso, j'ai rencontré bien trop souvent, et qui est la cause de pas mal de problèmes pour le suivi à long terme des systèmes.
Exemple, en reprenant mount. Dans ma fstab, j'ai un /boot noauto,comment=systemd.automount. Ben c'est sacrément confortable (comme un autofs sur du local) Simple, non ? (comparé à d'autres possibilités pour faire la même chose)

vais-je pouvoir continuer à les utiliser aussi pour (continuer à faire comme je veux)

Oui. Il ne semble pas plus compliqué de le faire à la main aujourd'hui, que de le faire avant sched_autogroup et/ou systemd. L'option par défaut change, sans empêcher une configuration maison. Les "nouveaux" outils facilitent également la tâche, par exemple on est loin aujourd'hui de la complexité initiale de la configuration de cgroups, la libcgroup et /etc/cgconfig.conf fait bien l'affaire et s'intègre avec l'usage de systemd.

//ma vie : d'ailleurs je suis un peu perdu avec tout ces nouveaux outils, moi qui avait l'habitude de mes petits tests et configs fait "directement". M'enfin c'est une question d'adaptation.

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch-Using_Control_Groups.html

En fait le "problème" pourrait se poser un peu de la même manière pour de nombreuses choses, par exemple memlock de pam // cgroup mem. On ne devrait pas se focaliser sur systemd parcequ'il peut faire des choses que d'autres peuvent déjà faire, cette situation est très courante, non ?

ça fait chier les admins de devoir réapprendre un nouvel outil

C'est triste ton avis sur les admins.

troll, moment //mavie : quant je vois rhel6, je me dis que j'ai vraiment _très bien fait de pousser à passer à 5, plutôt que d'attendre 6 en tirant sur 4.

Frigidaire est un synonyme populaire de réfrigérateur ??? Et moi qui croyais qu'il s'agissait d'un adjectif, utilisé pour définir les jeunes hommes maladroits, issu de la racine latine frigidus !

"Antoine est un vrai frigidaire, il nous laisse toutes froides et moi m'a rendue frigide !"
"quel con cet Antoine"

haa les radiocom 2000
moment nostalgie analogique :-)

Il n'y a rien qui contredit le précédent commentaire, ni à rien à contredire.

pas du tout basé sur le même principe de fonctionnement pour mixer

c'est un bon résumé de ce qui me fait bizarre.

On parle de quoi là ?
Linux, le noyau de Linus ?
Une distribution ? debian ? Fedora ? Ubuntu ?

c'est lever un troll, mais sincèrement je pense qu'il parle de Fedora et de Redhat. Et de rien d'autres : les autres il s'en fiche, s'en balance, fait un noeud à sa capote avec...

Je me lancerai pas dans un discussion là dessus, il y a du pour et du contre. Mais je crois qu'il se moque (dans les deux sens du terme) des autres distro comme il se moque de bsd.

alors là c'est carrément du gros troll cet argument :

les pros se foutent de la puissance

Le particulier ne se fout pas de la puissance, ça c'est certain. Moi quant je vois qu'un service pour mixer 3 pov' flux de base, sans besoin spécifiques, bouffe de 2 à 5% de mon cpu, quant la totalité du système prends moins de ressources, y compris avec des zigouigouis 3D, je me pose de sacrées questions.

Et si la machine est un laptop, l'autonomie s'en ressent. Donc bon, il utilise là un argument qui sied très très mal à PA.

Pour les "pros" qui s'amusent avec des latences de 0,017ms (oui) sur 24 pistes, bien entendu ça va faire monter la conso cpu à 80 ~ 90% de 2 Xeon dual-core. Et effectivement ce sont des machines dédiées. sortir cet argument, vrai, ne résout rien concernant un fait simple : PA consomme plus tout seul que tout le système. Problème.

ha oui, très très loin : ajoutez un menu en dock qui se superpose.
l'utilité et l'ergonomie de ça ? ha, ça ne discute pas, on doit pouvoir lancer une appli depuis une 'vue en aigle' (pour reprendre une expression aux sources de ce concept). Bon si tu y tiens on peux ajouter daisy :-)

tu veux dire un truc comme ça ?
non, c'est pas possible, effectivement. Enfin, pas sans ouvrir une boite de configuration, puis choisir parmi 20 possibilités celle que l'on préfère, puis validez. pffu que c'est dur, faut savoir lire !

ouhaip.
Mais ça ne change fondamentalement l'admin des services, en fait. Remplace Sxx par before et after Ajoute les notions de dépendances et de conflits et tu obtiens la gestion du service. Ensuite, si ton service a des besoins particuliers en terme d'option : par exemple fourni par le logiciel dont s'occupe le service, alors tu enrichi la directive ExecStart=. S'il s'agit d'options en dehors dudit logiciel, par exemple, tu pourra utiliser la directe ExecStartPre=.

D'un point de vue admin l'avantage est d'avoir des déclaratifs dont la structure est très claire, en exagérant on peut dire similaire à un fichier de conf typique de freedesktop.

C'est donc plus simple de créer un service, mais cela enlève le plaisir du script aux petits onions ce qui est sommes toutes assez subjectif. Par contre l'inconvénient (que j'y vois, pour le moment) est l'éclatement de la structure du gestionnaire de services, ça c'est délicat à prendre en main, faut se faire la main dessus quelques temps, nous ne sommes plus du tout dans un /etc/init.d/ bien propret sur lui (et /etc/systemd/ peut ne pas suffire) Peut être qu'à l'avenir systemd gagnera en compactage (en cohérence ?), pour le moment c'est parfois difficile de se retrouver dans les .target, les .services, et à divers endroit de la hiérarchie du FS... On peut se contenter de /etc/systemd/ mais pas toujours.

j're-sort ce lien :
http://patrakov.blogspot.com/2011/01/writing-systemd-service-files.html
qui résume assez bien l'état de l'art, il me semble.

Systemd uses a different syntax from bash, so please resist the temptation to reuse the same configuration file for the traditional initscript and the service file. Resist even though some service files in the Gentoo systemd overlay do use the same configuration files as the corresponding traditional initscripts -- they are just buggy.

Et l'inconvénient, que tu soulignes (et qui, il me semble est bien réel) c'est que systemd lui même à un problème, tout va devenir très délicat, oui. M'enfin des logiciels rock-solid, systemd ne sera pas le premier ;)

mouhai, cette phrase aussi, elle tue son homme :

Avec systemd cela n'est plus possible et les processus ne peuvent plus s'échapper ainsi.

Il s'approprie un peu ce que font les Cgroups, là. C'est parceque les Cgroups le rendent possible que systemd peut s'occuper de politique. Ce n'est pas systemd qui permet cela, ce sont les Cgroups (et seuls, avec un bon admin).

C'est d'ailleurs un autre point commun à tout les logiciels qui a développés jusqu'à présent : avahi, pulseaudio et systemd sont des logiciels qui s'occupent de politique, sur d'autres briques, afin que tout fonctionne correctement, ça me semble remarquable.

Bon, sinon, franchement peu importe qu'il ne soit pas modeste ou qu'il ai les chevilles qui enflent : c'est ce qu'il est. Et l'essentiel c'est ce qu'il fait. Chapeau pour systemd, c'est du pur régal (même si l'intégration pourrait être meilleure, par exemple lorsque le boot process bloque sur un service, que le fallback ne soit pas lancé automatiquement, pour le moment, car systemd le permet déjà)

Avant de me délecter du reste de l'interview, je regrette l'absence de la question suivante :

• Pourquoi avoir choisi de créer un élément nouveau et supplémentaire, plutôt que contribuer à une partie de Alsa ?

Ils auraient peut être réagis comme "non ? t'es le patrickg de dlfp ??" arg, signe moi le pdf de la dernière dépêche kernel stp ! et l'interview avec Linus !" Et PAF réunion foutue, tout le monde discute dlfp,noyau.
Strop dur parfois :-)

spa grave : toshoper l'écran pour faire disparaître la faute.
bon, spa pratique pour le scroll.

ça va être vachement trop bien lol :
téléphone sous windows -> visio skype -> intégration facebook. D'ailleurs on dit déjà "les téléphones MSN" kikoo ! Bienvenu sur le skyblog mondial !

oula, il est vraiment temps de dégager de là ...

Microsoft c'est l'ami de l'Europe.
Mais si ...... puisqu'ils le disent !

Peut être qu'un jour le marché, le bon sens ou une autorité de régulation imposera l'interopérabilité!

Le marché est de préserver "ses clients" chez soi, jusqu'à présent. Mais cela atteint ses limites dans la mesure où si un déjà gros veut percer, il se doit de proposer des outils de "migration", on dira d'importation. Par exemple google+ permet de connecter son compte facebook et twitter (et d'autres). Il y a donc un paradoxe entre le fait de conserver les données, et le fait d'importer des données. C'est un peu éternel : ils cherchent à conserver les données, et cherchent à permettre facilement la migration, donc d'un côté x ne facilite pas la tache de migration, mais y arrive quant même à se connecter à x pour que michu puisse rapatrier ses données :p

Au final, peut être que le mieux pour tous sera la décentralisation :
cela ressemble plus au vrai réseau internet.
l'important ce sont les données, pour ces sociétés comme pour nous, et la décentralisation ne va pas forcément contre ça pour ces sociétés.
le coût de l'hébergement est lui aussi décentralisé.

Il y a certainement encore une place pour une société proposant l'ensemble des services que propose google+, facebook, twitter, elgg (et lorea), dans un logiciel chez soi, fonctionnant en p2p chez tous. Ce logiciel pourrait tout à fait être promulgué par un F.A.I., car économiquement cela intéresse cette fonction du réseau, il reprend la main sur du contenu ;-)

//circonvolution, hop, sieste...

D'accord.
Mais en dehors d'une solution totalement chiffrée de bout en bout (hébergement & sauvegarde, accès et partage, discussions) il y aura toujours une exploitation commerciale des données. Le référencement par un moteur de recherche commercial est une exploitation commerciale, et le seul moyen d'être totalement hors commerce est d'être totalement invisible, dans son usage et les échanges avec les contacts de ses groupes, eux aussi totalement hermétiques au web.

A partir du moment où il y a exploitation commerciale, pourquoi ne pas les laisser payer le coût du service et de l'hébergement ? Qu'apporterait réellement le fait de payer ici ? J'ai peur que ça ne soit aas grand chose à part le fait de payer :p