bubar🦥 a écrit 6992 commentaires

La facilité d'utilisation est un point important me semble t il. On peux :
retrouver des gens perdus de vues (mieux qu'ailleurs)
échanger des discussions avec ses connaissances
échanger des avis, des idées, des commentaires
rigoler en créeant des groupes facebook (c'est le plus sympa et beaucoup utilisé par les djeuns, faut voir le sport de trouver des noms de groupes qui vont faire rire)
placer tout ça sur le réseau (quelque que soit la machine...)
Une "utilisabilité" simplifiée
Une utilisation des autres services (photos, vidéos), indipensable : pas ré-inventer la roue mais permettre aux inscrits d'utiliser et de partager facilement aussi cela

Bref absolument rien de neuf.
Mais un marketting à toute épreuve (au départ lancé et réservé il me semble pour les membres d'une grande école, ça faisait classe d'y être sans être sorti de cette école...) Reste à laisser prendre par effet boule de neige.

Pour Diaspora on aura peut être des possibilités comme pouvoir discuter sur des tickets de bugzilla dont l'usage serait aggloméré, comme picasa l'est sur facebook. Une autre sorte d'élite. Va savoir ?

Ca te va comme réponse ?

Il semble qu'il s'agisse d'un problème concernant le manque d'assurance vis à vis non pas de systemd seul, mais du processus de mise à niveau (preupgrade et/ou upgrade) et de systemd.

Le lien au dessus mène droit vers la discussion, mais au stade où ça s'énerve après la décision. Ouf c'est rassurant de voir qu'il s'agit encore d'êtres humains :) Mais avant cela si on cherche les raisons techniques : Cela dit simplement, sans froisser, que systemd a besoin d'être encore un peu lustré. Et que son intégration est repoussé. C'est tout. En cherchant un peu plus, il me semble qu'il s'agisse donc "juste" du fait que systemd n'a pas été assez testé, ou n'est pas prêt, à pouvoir être utiliser dans le cadre d'une montée de version 13 stable -> 14 stable, et que le risque potentiel de voir des systèmes cassés lors de cette montée de version n'est pas négligeable, et n'a pas été négligé.

trac : "After a long meeting today, FESCo decided to defer systemd to the f15 release to give it time to become rock solid. We will still need the docs and such, please keep working on them for f15. Notting will look at changes needed for f14, and I hope systemd development will continue in rawhide at a rapid pace."

Donc bon, il semble s'agir simplement de prudence. Que la documentation soit mise à jour tout juste avant le tesday, ou encore que les guides pour adapter les paquets soient (considéré) encore pauvres (semble t il) ne semblent pas être les raisons. Plutot juste de la prudence. ( "Its nice to be first but no at the expense of our user base") La flamewar qui s'en suit prouve bien qu'il s'agit du bon côté de La Force. Non ?

Me, i wait and see :)

...que ça devrait te botter
http://www.thehackademy.net/index.php?section_id=83

;)

Il faut proposer une section BSA à Wikileaks, c'est clair ! Histoire de balancer tout ces gros connards qui se gavent en utilisant la moitié de leur parc logiciel en pirates... et ensuite font la leçon des morales aux devs "tu vois la clause d'attribution de c, là, c'est rien, signe"

Ca me ferait vraiment marrer que les Microsoft et autre partenaires avec leur langue si bien pendues soient obligés d'être aussi offensive envers le piratage que l'industrie du disque et du cinéma le sont... Bien marré... Je garde une bouteille spécialement pour ce jour là ...

"au fait la triplette, là, tu peux la contourner ? t'es root dessus, non ? tu peux me filer la licence pour x ?"

Tu crois que Oracle va reprendre ce projet ?
(ultraviolet c'était un projet de gestion des drm opensource de sun, non ?)

TorchWood
En v'là une série que j'aime. Bien déjanté (surtout après les premiers épisodes, où ça commence sévère...). Humour Anglais. Vraiment terrible. Les ados, en Angleterre, ils sont plutôt chanceux avec ça :) Moi ça continue de me faire marrer, alors j'imagine quant on a 12~14 et qu'on découvre TorchWood....

Je croyais qu'en France il avait virer ça sur de pov' chaines du cable, diffusé à pas d'heure, histoire d'éviter que l'ado moyen français entendu parler de torchwood.. ? C'est encore diffusé quelque part en France cette série ???

J'avais pas osé :)

(une fois les bugs triés entre bugs d'experts [suivant la sécurité, les correctifs du projet, etc] et bug de users [presse papier dans firefox par exemple] bien sûr. )

On peux prendre le problème par l'autre boût, aussi.
Y a très certainement des statistiques sur le nombre (voir mieux, un tri qa?) de rapports de bugs, afin de comparer entre : stable, testing et instable.
Y a que moi que ça choque autant de rapport de bugs sur la version stable ?

Et si on fait un tri plus fin, si c'est possible (?), je prends le parie que les rapports de bugs sur la version stable concernent en majorité... ce type de softs.

Je grossi le trait exprès oeuf2course.

Comme ajout, je le répête, je ne sais ce qu'il faut, ce qui est bon ou pas. Peut être simplement ajouter un compte adm par défaut, intermédaire, qui ai droit sur un rep particulier ? Simplement un howto ? La seule chose dont je sois sûr c'est que la situation bloque : Les utilisateurs veulent firefox / openoffice / vlc en version beta, parfois, souvent. Le bon côté c'est qu'ils font les remontées directement aux projets, ça tombe bien, des projets le demande. Et actuellement comme solution on a un "demerdez toi" ou un "utilise tout un système instable". C'est pas super, ni pour les projets, ni pour les utilisateurs. On va pas nous demander de devenir expert en c/lisp/c++/whatever, et exiger tout un système instable, pour rapporter que y a un bug de la gestion du presse-papier dans firefox, quant même ?

>où s'arreter ?
Là où la distro le décide.

Ca semble impossible... et pourtant.
Je le fais, tu le fais, et ça m'étonnerai que quiconque plus proche du code s'enquiquine à utiliser les packages de sa distribution pour le code sur lequel il participe.

Impossible ? hum ... bizarre.

Peux essayer de résumer cela par quelque chose de simple comme ceci :

--

Il y a un danger, réel : si Ubuntu est réellement massivement adoptée, alors elle devra massivement contribué. Ce n'est pas un problématique ni de licence ni de morale mais de stratégie de développement d'une entreprise. Pour le moment, le danger est là, mais Canonical avance à petit pas tout à fait cohérents. Donc ne pas anticiper le futur de Ubuntu parcequ'on en voit les inconvénients.

Son insistance sur le fait qu'Ubuntu permet à mr michu d'avoir gnu/linux facilement : c'est du troll de compétition d'un point de vue objectif, mais après tout c'est bien le rôle d'un patron/commercial de boite, non ? Il serait un peu décevant de lire que ubuntu c'est moins bien par le patron de ubuntu.

--

addon :
Peut être, par contre, que le danger qu'il n'a peut être pas encore vu venir c'est la gratuité de Ubuntu. Vampirisation de clients d'autres, affaiblissement éventuel des développements lorsque ceux ci sont fait par d'autres... Enfin, si je veux une distribution de calibre professionnel, et gratuite, ben que m'apporte ubuntu sur Debian ? trois trucs proprios ? kénena-afoutr ?
Bref certainement un délicat équilibre à trouver entre guerre commerciale et assurance de pérénité des développements.

Passer du status d'éditeur, intégrateur, de distribution, au status de centre majeur de développement ne se fait en deux ans. Et je ne crois pas que la politique actuelle de ubuntu à ce sujet aide vraiment canonical à se développer ...

En plus Debian est vraiment plus sexy :)

Ubuntu c'est une offre d'appel :) T'installes c'est beau ça marche bien. Puis ça te plait et tu veux la version au dessus :) Z'auraient peut être mieux de faire une branche 'corpo' à Debian dès le départ. M'enfin j'dit ça, j'dit rien...en plus c'est même pas vendredi.

Arretez d'utiliser un mauvais navigateur ?

Konqueror a toujours sû faire cela, placer l'écrit dans un tampon. Un retour arrière et hop tu retrouves ta prose sans être obligé de chercher dans les méandres des fichiers temporaires.

Firefox le fait aussi depuis pas mal de versions je crois.

Bien sûr cela m'est arrivé également, et de nombreuses fois :p Depuis, pas mesure de sécurité je fais simplement un ctrl+a avant de cliquer sur "poster", juste au cas où...

Bonus : Quant fifi beta 245 merde, l'utilisateur pourra pas dire "debian merde" : il saura bien que c'est son fif beta 245, là. Ca ne vient pas de la distro.

Merci aussi à tous de vos réponses.

Je tenterai de mettre tout ça au clair pour moi, dans un nourjal prochain, avec ces nouvelles lumières.

Là où je veux en venir, en essayant de résumé une idée non-finie :

Le système ne devrait pas contraindre l'utilisateur. (ne pas être obliger d'avoir tout son système en instable juste parcequ'il souhaite utiliser une version beta d'un soft mineur pour le système mais majeur pour lui)
Le système devrait savoir se protéger. (ne pas laisser un rpm de chrome faire ce qu'il veut en %pre %post et autre... seul le binaire et un menu sont intéressants...)
L'utilisateur devrait pouvoir installer firefox 4 beta sur son système stable, de manière simple (ne pas se contenter de coller le binaire, et ses libs, dans son ~/bin : c'est sale)
La distribution ne devrait pas avoir 'la responsabilité' de l'usage de ce binaire (pas de rapports de bugs à la distro valide pour ça, renvoyant ainsi la balle au projet quant il refuse des rapports parceque le binaire vient pas de chez eux.)

L'utilisateur il est tout jouasse : il a un système stable avec son fifi beta 245, même si ce fifi consomme plus de ram et est moins propre que celui livré de base.
L'adminisatreur, il est rassuré : le système n'est pas impacté. Si bronx il y a ça sera chez l'utilisateur, dans son home, sous sa responsabilité.
Le projet, il est content : il a des remontées directes de ses utilisateurs pour ses versions beta.
J'imagine la distribution rassurée : finie les requêtes incessantes "bouh firefox openoffice vlc sont antédiluvients", fini les rapports merdiques du gars ne disant pas que son truc il a installé depuis un dépôt obscur.

Les backports sont une réponse à cela, mais est ce bien le plus propre pour le système ? Si j'installe des backports, je reprends l'exemple de firefox, je vais me retrouver quant même avec certaines bibliothèques importantes (pour gnome) qui seront backportées également. Elles ne seront pas isolées sur le système, mais en seront partie intégrante. Bien que depuis quelques temps, xul-runner est il me semble en version spécifique pour firefox, non ? justement pour éviter cela, on a déjà un doublon ...
Ce n'est pas "pour ou contre" je me demande juste si les backports ce n'est pas une réponse qui finalement ne convient pas à FireFox et OpenOffice ? Alors qu'elle est gage de qualité pour d'autres logiciels 'endusers' ?

(ce n'est qu'une question)

Tout à fait, c'est cela aussi que je ne comprends pas.

Le système a tout ce qu'il faut, intrinsèquement, pour permettre cet accueil (/opt, mais aussi /usr/games et le compte associé, hein). Le système propose des outils franchement géniaux aussi pour ce type de cas (de la configuration par défaut des autotools, qui font attention par défaut au système, jusqu'aux possibilités de restrictions diverses). Les projets se décarcassent souvent pour finir un .spec dans leurs sources, voir même parfois passent des heures à construire plein de paquets, ou propose des binaires statiques [pas mal pour les versions beta]

Le seul point bloquant, c'est le packaging, ou plutot cette politique forcenée de packaging. N'est il pas possible de se dire simplement que le système ne devrait pas être en danger si l'utilisateur choisi firefox 4 beta ? Ne peux t on donc faire aucune concession sur la propreté théorique du système afin d'éviter des conneries pires, et de permettre (bis) aux utilisateurs d'avoir firefox 4 beta et de faire leur remontées avec l'outil prévu par la MoFo ?

Pil Poil !!!!

Seule la réponse "non" est inadaptée car elle ne concerne que le cas où un soft beta viendrai foutre le bronx dans mon système. Plus un. Mais inadaptée car elle n'entre pas en contradiction avec cette légitime volonté d'un utilisateur de vouloir firefox beta 4 sur son système stable, mais sans installer un paquet venu de n'importe où, sans foutre le bronx dans son système.

Tu viens d'illustrer à merveille l'enfermement de l'utilisateur.
S'il ne sait pas compiler correctement Firefox, alors qu'il creuve ou change de distro. C'est dommage, visiblement l'utilisateur lui il veux à la fois avoir un système stable, en suivant la doc, en écoutant, bref... et à la fois, pour quelques softs pouvoir les avoir en version beta sans remettre en cause le premier point.

J'ai volontairement laisser de côté l'aspect technique (n'ayant pas la prétention de dire "c'est ça qu'il faut faire", perso je compile et je chroot, tu vois c'est pas la panacée non plus) pour ne m'interessé qu'à l'aspect théorique. L'utilisateur il écoute Debian, il comprends pourquoi Chromium se sera pas intégrer par exemple. Actuellement, la seule solution facile qui lui possible c'est ... de foutre le bronx dans son système :( :( :(
Or il comprends que saymal, et aimerai bien avoir à la fois, comme tu le fais, un système stable et un firefox beta dans un coin. Pour le projet c'est bien aussi : un même binaire chez tout le monde, des remontées directes. Sans heurter les politiques des distros.

Une petite concession permettant :
1. éviter de foutre le bronx sur un système stable
2. au projet un rapport direct avec leurs utilisateurs quant il le demande
3. à l'utilisateur de pouvoir avoir firefox 4 beta

C'est il me semble une bien petite concession au regard de ce que cela apporte.
Techniquement, doit on se contenter d'un howto ? En sachant que peu le suivront et finiront par mettre le bronx sur leur système ? Ou est ce possible d'avoir une solution correcte pour tous ?

En tout cas, maintenant nous en sommes sûr : les méchants utilisent bash et ne connaissent pas les limits

/tout les jours aussi, je lave mon cerveau avec la télévision

C'était plus une question sur la pertinence d'appliquer des recettes de serveur et de système d'entrerprise pour un système orienté grand public. (je comprends que le sysadmin devienne un peu dictateur avec ses usagers, je le comprends moins lorsque le sysadmin et l'usager sont une seule personne : utilisateur unique ou familial d'une machine personnelle, et que c'est la distro qui endosse ce rôle)
Dans ce petit cadre d'utilisation personnelle et familale, n'y a t il possibilité de laisser l'usager pouvoir suivre facilement directement les projets eux-mêmes, pour quelques grands softs "vitrines" ? Est ce qu'une politique de packaging unique ne devient pas contradictoire, au final, parfois, avec le but de l'utilisation personnelle facilité ? Qu'est ce que le système, la distro, craint il vraiment, de voir ses utilisateurs pouvoir facilement utiliser firefox 4 beta, sans déstabilisé tout leur système, ni encombrer son bugzilla avec un problème uniquement à firefox 4 beta ? Est ce que le système de packaging n'atteinds pas là ses limites ?

Ouhaip, c'est complètement déplacé de questionner sur ça sur un post de Debian. Désolé.
En plus, effectivement, j'ai oublié plein de points d'interrogations partout.

http://www.thinq.co.uk/2010/7/1/tv-business-kisses-hdmi-good(...)
(l'article sur lequel pointe celui de /.)

je suis bien incapable de t'en dire plus ! j'ai vu passer la news, comme beaucoup d'autres je pense, sur /. il me semble, il y a une quinzaine de jours.
et hop, le lien est fait, c'est tout :)

C'est drole que ce soi-disant "cassage" ai lieu pile au moment où certains constructeurs commencent à parler sérieusement de déjà remplacer hdmi. Avec ça comme argument, nul doute qu'ils vont pouvoir convaincre leurs partenaires.

Y a des disclosers comme ça, vachement bien opportuns.