bubar🦥 a écrit 6943 commentaires

Fait, merci.

Non car je n'ai pas cherché plus loin que le descriptif de Kaspersky (et des sites cités), qui semble relativement honnête en comparaison du fatra de fud des sites "d'informations".

À noter que 45 élus ont signés le pacte du Logiciel Libre, ce sujet n'est pas cantonné chez "nouvelle donne". Et ce n'est qu'un début, nous pouvons en suivre ici l'évolution

Et puis le cumul des mandats est un sacré sac de noeuds. Par exemple à titre personnel je suis fondamentalement contre ce cumul, à tout les niveaux, et pencherai même pour une interdiction de cumul des rémunérations et émoluments afin de forcer à faire bouger les derniers récalcitrants …

Cependant, d'un autre point de vue, le cumul des mandats peut être aussi l'accélérateur calme d'une refonte des dits mandats. Le fait de cumuler des fonctions est finalement l'exemple parfait -absolument parfait- de cet état de faits : trop d'élus, trop de postes aux fonctions redondantes, aux responsabilités et périmètres devenus flous et se chevauchant. Le fait de pouvoir cumuler est bien l'ultime preuve que certaines fonctions sont remplies par ailleurs (ou bien sont inutiles ? hum, cela serait un peu trollesque ça).

Bref, les deux se défendent. Par contre, le non-cumul des rémunérations semble être le meilleur outil, dans les deux cas.

Hop. ;-)

Ce n'est pas parcequ'il serait bien conçu qu'il fait re-sortir les problèmes de drivers. NON. C'est parcequ'il a été adopté.

Bonsoir,
Et Kaspersky détaille le mode d'infection sur linux : un xpi au travers d'un firefox (qui serait lancé en root, en ayant désactivé l'option par défaut "avertir qu'un site souhaite installer une extension".

Perso j'ai cliquer partout sur les dit-sites, j'ai insisté à fond, pas moyen de choper quoi que ce soit.

Encore du FUD à destination des gens qui ne lisent pas les docs, mais qui ont le pouvoir de faire dépenser des milliers d'euros en antivirus pour linux, sans même avoir exigés de leur sysadmin la connaissance basique de pam.

On pourra noter que l'alliance Genivi vient de finaliser la version 5.0 de sa matrice de conformité. Et que celle ci éjecte gtk pour faire la part belle à Qt.

Référence :
- MentorGraphics

« the release is principally concerned with expanding support for windowing and graphics technologies. These include the X11 and newer Wayland windowing environments, as well as the Qt. 5.0 framework, and unstated “new GPUs" »

Encore mes remerciements à tous ceux qui sont impliqués dans ces projets !!! ;-) (bn, ok la paraphrase saynul, mais le coeur y est)

Juste une autre remarque : ils peuvent se référencer sur http://linuxpreinstalle.com/

Il manque également les références exactes des modèles. Là, même en téléchargeant le .doc (pourquoi pas pdf ?) on ne les trouve pas … le descriptif est complet mais aucne référence du modèle constructeur qui permettrait de faire une recherche sur le net, rapide. En l'état c'est de l'obfuscation.

Je ne trouve pas déconnant du tout de payer plus cher un matériel chez un petit revendeur, qui plus est s'il propose du pré-installé gnu/linux. Mais l'absence de référence m'arrête net. Ceci dit, depuis que l'informatique grand public s'est transformée en vente d'ordinateur portable, couplé à l'arrivée de la grande distribution sur le marché, qui peut croire encore qu'il peut vivre de vente de matériel en dehors de ces circuits ?

Qu'est ce qui va me faire acheter dans une telle boutique alors que pour 650€ j'ai un I7 4GO ram en 17pouces, avec un dd de 750Go et un ssd (ajouté) de 128Go au supermarché du coin ? Alors, quoi ? Que je sache qu'ils sont actifs d'une manière ou d'une autre m'inciterais à regarder sous un autre angle leurs offres.

Je viens d'essayer rapidos ITOP, et c'est vraiment très bien. QQ critiques : polices de caractères trop grosses, rendant l'interface inutilement large (syndrome gnome ?:p). Des progrès en ergonomie (il faut cliquer sur "modifier" le petit bouton en haut à droite, une fois un changement crée, pour pouvoir ajouter des taches. Car sinon le comportement par défaut lorsqu'on clique sur "taches" du nouveau changement puis sur "créer"… créeait en fait un nouveau ticket dissocié au changement. Pareil une fois une nouvelle tache crée : il faut créer un ticket associé dans le même temps). Cette ergonomie perfectible alourdie énormément le workflow, le circuit de . Il ne s'agit pas là que de "nouvelles habitudes à prendre". (Et ça, c'est très très difficile à remonter via le ticketing habituel d'un bugzilla)

SUPER!

L'interception de matériel acheté sur Amazon a touché Andrea Shepard, une core dev. de TOR. Ainsi, son nouveau portable est passé par la case "Virginie" avant de lui être livré chez elle à Seatle. Probablement pour l'installation d'un malware par des gens du programme TAO.

Sitipabô ?
D'où l'importance de pouvoir disposer de portable tel que le samsung arm chromebook, qui, s'il est loin d'être une foudre de guerre, permet de tout flasher, y compris l'EC …

On peut s'étonner du manque de subtilité de faire apparaitre le cheminement complet… Andrea s'en étonne aussi : https://twitter.com/puellavulnerata/status/426597381727989760/photo/1

Oui, c'est pourquoi les auteurs utilisent Inception sur Thunderbold / DisplayPort, mais lorsque l'usager est loggué. Afin de dumper la ram, puis d'en extraire le mot de passe de FileVault2 (c'est étrange qu'il n'y pas une option du style auth-nocache pour filevault et bitlocker) Bon, la vidéo a été supprimée de Youtube mais il reste l'article qui a deux ans.

moi ça m'espante
et je vais de ce pas acheter un adaptateur pour mon Acer …

Depuis que Apple a inventé cette merveille, donc ~1994
\o/

Cette bibliothèque n'est pas en cause, elle n'est mentionnée que pour ceux souhaitant lire plus, son site étant particulièrement fourni en informations lisibles par tous. C'est la gestion du DMA par l'IEE1394 qui est en cause, donc directement la norme…

Sous les Linux anciens, utilisant encore ohci1394, il suffit de passer une option au chargement du module : phys_dma=0 afin de désactiver cela. Sur les Linux plus récents, c'est la nouvelle pile "juju" qui s'occupe de l'IEE1394, et ses différents modules n'ont visiblement pas repris cette option [ need info ] Il y en a même deux qui sont spécifiquement dédiés au debug (au lieu d'avoir seulement une option debug), sur le noyau Fedora ces deux modules ne sont pas compilés. Mais blacklister firewire_core semble être de toutes façons la solution la plus simple. Plus d'intrusion possible par ces voies là, paf la faille.

Non ?

Comment dire autrement que «ton noiré magnifique, intelligente utilisation de l'espace jusqu'alors inutilisé du gestionnaire de fenêtres pour le gestionnaires de fichiers, mais qu'est ce que ça fait du bien de revenir à un desktop léger, véloce, efficient" … byebye gnome3 : 3 ça doit vouloir dire 3 jours….

s/Facebook/Amazon
:p

Oui, d'où l'ajout d'une capture d'écran de plus dans le journal (les 3 premières venant d'un site de news sur Gnome, la dernière c'est mon bureau [j'ai pas fait gaffe à l'édition du journal, mais l'ai laissé car c'est plutôt drole au final] : on y voit ce fameux nouveau menu qui est vraiment beau)

échec signifie "le roi est mort", plus généralement "in-succès".
L'échec ne se réfère donc pas seulement à un manqué mais aussi à une étape. Or, où est l'étape qui permettrai de définir "l'échec" des distributions ?

D'abord, la majorité des distributions n'a pas vocation à être maintenue sur le long terme. Elles ne s'en sont pas fait un objectif, il n'y a pas d'étape là. (encore plus avec celles en rolling-release).

Ensuite, ne prenons que les distributions qui visent, ou ont visées, le "grand public" : leur planning est clair, et la maintenance de chaque version annoncée. Elles s'y tiennent.

Enfin, il y a les distributions qui visent le "plus de 10 ans", et Redhat par exemple a un support sur 13 années.

Ce qui permet de faire la transition sur le type de support. Car dans ton journal tu inclus l'un dans l'autre : la maintenance et la disponibilité de nouveaux pilotes et logiciels. Or ce sont deux choses distinctes. Redhat, par exemple, réalise des backports de drivers pendant une certaine période du support global, se dernier se finissant uniquement avec des mises à jours de sécurité.

Donc :

• Le logiciel libre évolue vite, très vite.
• Un système gnu/linux offre plus par défaut que les systèmes propriétaires, il a donc plus de maintenance à faire.
• Et auquel vient se greffer un très grand nombre de logiciels, à l'intégration plus ou moins réussie, et à la vie plus ou moins éphémère. Comme pour les systèmes proprios.

En conclusion je dirais que la seule chose qui compte c'est un process de mise à jour / mise à niveau qui soit irréprochable. Passer d'une version N à N+1 doit se faire aussi facilement que des mises à jour de N.

C'est Gnome-shell qui doit gérer ça, et je ne vois pas de paramètres permettant de faire cela …

Rigolo même un lundi :-)

ps : tu postes à -5 ou bien tu es moinssé aux moindres faits et gestes ?? (-75 de karma ne fait pas poster à -5, si ??)

j'ai vu presque personne dire "je suis sysadmin, je surkiffe trop upstart
j'ai le sentiment que personne parmi les sysadmins que je connais ne cherche à tirer parti des fonctions
alors que la communauté Ubuntu est censé être une des plus grande niveau utilisateur.

Cela rejoint le titre du journal auquel celui ci fait référence. Il y a quelque chose entre ces deux mondes. Ou pas, dans cet exemple.

un frein pour la distribution

Ce n'est pas contradictoire. Il semble important pour (notre regard sur) systemd que Debian l'adopte. Sans cela, il continuera de vivre sans problème, et d'être présent dans de nombreuses distributions ou sous-distributions, mais disons que le regard porté sur systemd ne sera pas le même… Que Debian adopte systemd semble être un gage d'assurance pour tous. Ce n'est pas contradictoire et ça semble important.

mais le cas chez Ubuntu

Ubuntu s'est isolée toute seule avec le sujet mir, ça serait dommage qu'elle entraine Debian avec elle sur l'init.

Je ne tiendrais pas la discussion technique que tu souhaites, mais plus simplement y apporter un point de vue de sysadmin qui suit l'actualité (et peut être relancer ce thread) Et ça me fait bien marrer de voir kdbus aujourd'hui porté dans la branche principale après les commentaires rageux d'il y a quelques années «mais ils sont fous / c'est dégueulasse / on en a pas besoin» lorsque ghk a mis cette demande (venant de l'automotive) dans sa branche. Il y a un petit goût de déjà vu … :) Concernant systemd, c'est déconcertant la facilité avec laquelle il est maintenant possible de réaliser des choses un peu complexes auparavant, execreload, limitnofile, environnment, conditionpath, stopwhenunneeded, … (et je ne parlerai pas des TTY*, que je n'ai pas pigés et qui me posent qq soucis). C'est un plaisir, un régal, que de pouvoir faire aussi facilement des confs comme ça, je n'avais pas connu plus simple.

Mon tit point de vue de tit sysadmin c'est que systemd gagne haut la main, en explosant tout le reste. Je veux bien "argumenter" là dessus, à défaut d'avoir une discussion de développeur. Nous avons là un système d'init plus simple à utiliser (pour un sysadmin mais aussi -surtout- un intégrateur) tout en permettant plus de possibilités.

A mon humble avis cette discussion est close depuis 2 ans, en fait.
Et toujours à mon bien humble avis, si Debian adopte systemd, ça sera le moment où systemd entrera en production, la communauté peut le prendre en charge non une seule entité. si Debian n'adopte pas systemd par contre, donc n'y fourre plus son nez dedans, là ça sera un frein sévère à systemd (à mes yeux)

(Maintenant on peut troller sur le format binaire (et le niveau de verbosité, et la compacité des informations sur un seul endroit) du journal, qui est horreur : les logs sont faites pour être utilisées, journal visiblement beaucoup moins…lol)

Choisir systemd+openrc me paraît être le choix le plus raisonnable

Maintenir deux systèmes d'init ne (me) parait pas raisonnable. Doubler le travail (même si openrc demande bien moins d'efforts) ne semble pas raisonnable.

D'autant que cela déporte la question sur «quel init par défaut», qui se déportera sur «quelle arch», et qui quasi-inévitablement aura en résultat «bien, 4 ans après, le systeme d'init par défaut est utilisé sur 99% des plateformes intel et arm via l'usage de 90% de linux, le reste étant dû au port de kfreebsd puis au quelques choix rares et volontaires d'autres choses que l'init par défaut sur intel/arm/linux». Hum, c'est une projection (d'autres argueront que d'ici là, la glib ne sera plus utilisable/portable sur le noyau freebsd parceque …) certes. Mais même si les résultats étaient différents, à la base cela demande double travail.

Mes deux cents.

Non je ne connaissais pas, ça a l'air pas mal!