ça donne une erreur lors de l'installation de Firefox, alors que tout devrait bien se passer
Le but des packages, c'est d'avoir un système homogène, en évitant que chaque logiciel réinvente son propre système de packaging
ça veut dire que si tu récupères une copie complète du miroir officiel de ta distrib, elle n'est finalement pas si complète que ça (tu n'as pas Firefox au complet)
dans ce cas, si c'est valable pour Firefox, pourquoi chaque logiciel ne pourrait pas récupérer des composants de cette façon ? et on se retrouve avec une distrib totalement inutilisable sans internet \o/
Pour moi, ce sont des maths à la base. Prends deux droites orthogonales, qui se coupent donc à angle droit.
Si tu te déplaces sur la droite verticale, tu ne bouges absolument pas horizontalement (par définition). Idem si tu te déplaces sur la droite horizontale. On peut donc dire que ces deux droite sont indépendantes l'une de l'autre.
Maintenant, imagine que la droite verticale est inclinée. Si tu te déplaces le long de la droite inclinée, tu vas également bouger vis-à-vis de la droite horizontale. Quelque part, ces deux droites sont donc « liées » (même si mathématiquement ce n'est pas le bon terme, « lié » a un sens précis en maths).
L'image, c'est que chaque droite correspond à un problème : travailler sur un problème (te déplacer sur la droite) n'a aucune influence sur le second problème quand les deux problème sont orthogonaux.
Ce que dit ta page, c'est qu'il y a eu un nouveau format XML (Office Open XML) avec Office 2007. Mais il y en avait déjà un, qui est apparu avec Office 2003 (et qui n'avait pas l'air terrible, au passage).
Si c'est une entreprise bien déterminée qui produit le logiciel (on se moque de la licence, qu'elle soit libre ou non), celui qui a écrit le code fautif a de fortes chances d'être identifié. Et tu as deux possibilités :
* soit l'entreprise l'a explicitement demandé, et c'est dangereux pour l'entreprise (perte de confiance des clients, voire un procès de leur part),
* soit le codeur l'a fait sans l'accord de son entreprise, et il risque de perdre son job, voire une amende ou de la prison.
D'ailleurs, ce cas correspond bien davantage à ton scénario de pharmacien : tu lui fais confiance parce qu'il est clairement identifiable et que s'il ne fait pas bien son boulot, il risque beaucoup.
Alors que dans le libre, tu peux considérer que tu ne risques absolument rien. Tu as peut-être moins de chances que ça passe, mais si ça casse, ce n'est pas trop grave, tu tenteras avec un autre projet.
Accessoirement une faille de sécurité peut très bien être considérée comme un bug (cf. la faiblesse de SSH dans Debian : qui te garantit que ce n'était pas volontaire ?).
Je ne connais pas trop les UEFI sur les cartes-mères actuelles, mais il me semble qu'ils sont bien plus évolués que les EFI des Mac (qui commencent à être un peu dépassés à ce que j'ai pu lire, notamment le bootloader intégré).
Techniquement, c'est faisable, mais je n'ai aucune idée si c'est intégré par les fabricants des CM (et ça doit dépendre d'une CM à l'autre).
Je trouve que les Mac restent les machines les plus faciles à installer : tu peux connecter l'installeur (DVD ou clef USB) et le sélectionner depuis l'OS actuel, ou appuyer sur ALT dès le boot. Tu peux aussi mettre un DVD d'installation sur une autre machine, tu redémarres la tienne et elle va le détecter automatiquement. Sinon, tu peux également booter ou installer via du HTTP. Dernier choix, tu peux démarrer ta machine pour qu'elle soit considérée comme un disque externe si tu veux transférer tes données.
J'ai eu en main pas mal de PC où il faut appuyer sur F1/F12/Del/Enter au bon moment (sinon tu entres dans la conf' RAID ou tu bootes sur la carte réseau)… mais il faut d'abord avoir configuré le BIOS pour accepter le boot sur USB/CD. Quand tu as une machine particulièrement lente à démarrer (à cause du matériel), c'est franchement pénible.
Ensuite, quand tu as plusieurs disques durs et que tu as déjà eu un GRUB installé, tu ne sais pas lequel doit être mis en premier, ni sur lequel tu dois installer le nouveau GRUB. Et là, tu peux être parti pour 4 ou 5 redémarrages pour trouver à l'aveuglette le bon disque… (bah oui, dans le BIOS tu as le numéro de série alors que tu installes le GRUB sur /dev/SDX).
Correction : pour développer avec Xcode et le framework Cocoa (qui n'existent que sur OS X), il faut OS X.
Si tu veux, tu peux très bien développer pour Mac sans avoir de Mac avec d'autres techno (je le fais sans souci avec du Python + Qt, par exemple).
C'est toujours moins pratique, au même titre que c'est moins pratique de développer pour Linux sans avoir de Linux, ou de développer pour Windows sans avoir de Windows. Mais ça reste possible.
Que doivent payer les développeurs ? À ma connaissance, développer des applis sur Mac OS X est totalement gratuit (en revanche, la publication — facultative — sur l'AppStore doit être payante).
En tant qu'utilisateur de Mac, j'attends qu'une appli correctement intégrée utilise les possibilités de l'OS, qui vont bien au-delà d'un simple aspect graphique. En vrac, quelques exemples :
graphiquement, les textes ne sont pas correctement alignés, tu n'as pas les mêmes boutons, les mêmes possibilités de widgets (pour avoir un champ de recherche, par exemple)
pas de connexion simple au champ texte Cocoa (qui vient avec son correcteur grammatical/orthographique global, ses raccourcis, …)
pas de possibilité de changer les raccourcis clavier de tous les éléments du menu,
quand tu places une icône dans la barre de menu, elle est traitée différemment (tu passes de l'une à l'autre avec les flèches… mais en sautant les icônes Qt)
pas facile d'utiliser le gestionnaire de mot de passe/de certificat du système,
pas facile d'utiliser le gestionnaire de médias (photos/musique/documents/…)
Et il y a sûrement plein d'autres trucs de ce genre. Après, tout peut être corrigé, évidemment, mais il faut le refaire à la main, et s'il faut tout refaire à la main, autant partir directement sur Cocoa.
Personnellement, j'ai surtout vu de plus en plus de Mac (avec pas mal de migrations de Linux vers OS X).
Après, c'est difficile de généraliser sans avoir de chiffres plus globaux.
Pas besoin de ça, il y a des clefs USB qui permettent de simplement copier des .iso dans le bon dossier, et d'avoir un menu de boot qui détecte automatiquement tous les .iso présents.
Tu proposes tout de même de faire payer quelque chose de gratuit pour donner de l'argent à des gens qui n'en demandent pas (s'ils choisissent explicitement de le distribuer gratuitement, c'est parce qu'ils ne tiennent pas spécialement à être payés… ou alors quelque chose m'échappe).
Je trouve ça quand même dur à justifier.
Ah si, j'avais oublié : c'est indolore. Trouves-tu sincèrement qu'on n'a pas assez d'impôts et de taxes en tout genre ?
Figure-toi qu'avec Jenkins ou TeamCity, tu peux tout à fait lancer n'importe quel script en ligne de commande.
Travis-CI te permet de prendre un fichier de conf' simple et de lancer les scripts bien plus facilement, avec des configurations toutes faites pour les principaux langages.
Voilà un exemple pour du Python :
language: python
python:
- "2.6"
- "2.7"
- "3.2"
- "3.3"
- "3.4"
# command to install dependencies
install: "pip install -r requirements.txt"
# command to run tests
script: nosetests
Ça lance les scripts dans 5 versions différentes de Python, ça installe les dépendances et ça lance le test.
Oui, on pourrait faire un script, mais ça prendrait plus de temps (surtout à débugguer, parce que ton script va planter lors du pip install à cause de variables d'environnement mal mises, par exemple).
Je trouve Gitlab vraiment bien fichu, mais en revanche Gitlab-CI est assez limité, je trouve. On peut lancer un script, et c'est à peu près tout. On est assez loin de Travis-CI en terme de simplicité (ou alors ça aa bien changé depuis la dernière fois que j'ai regardé).
Ton livre parle d'algo de chiffrement (et un chiffrement faible est cassé avec des méthodes totalement différentes de la recherche de failles classiques). Le journal parle de l'intégralité du code (et oui, les failles peuvent se trouver partout), et de codes extrêmement spécialisés (industrie de défense).
En pratique, on constate que
* un code open-source utilisé par beaucoup de monde peut contenir des failles graves et très vieilles (heartbleed, shellshock, debian+ssh, …), donc soit il n'y a pas de relecture, soit elle est inutile,
* les failles sont dans leur très grande majorité trouvées sans utiliser le code source.
Maintenant, prenons un code utilisé dans une centrale nucléaire ou un avion de combat.
Qui ira relire bénévolement des milliers de lignes de code qu'il ne pourra pas réutiliser, à part les services de renseignement étrangers ?
Pourquoi cette relecture serait-elle magiquement plus efficacement que sur les codes classiques ?
Réponse donnée par Scoubidou : des gens qu'on paierait pour relire le code… bon, bah pour ça, il n'y a pas besoin de donner le code aux services étrangers, et de toute façon c'est probablement déjà fait (ça s'appelle des audits et c'est très classique).
Dans beaucoup de cas, dévoiler le code revient à dévoiler nos capacités, sans même parler des failles potentielles que les services étrangers garderaient pour eux…
Je vois bien ce qu'on peut y perdre, mais je ne vois pas trop ce qu'on y gagne.
[^] # Re: Sous Linux aussi
Posté par flan (site web personnel) . En réponse au journal H264 par Cisco dans Firefox (suite). Évalué à 8.
[^] # Re: Sous Linux aussi
Posté par flan (site web personnel) . En réponse au journal H264 par Cisco dans Firefox (suite). Évalué à 7. Dernière modification le 27 février 2015 à 08:12.
on peut très bien avoir des sites web sur un réseau local… (qui lui est déconnecté d'Internet).
[^] # Re: Sous Linux aussi
Posté par flan (site web personnel) . En réponse au journal H264 par Cisco dans Firefox (suite). Évalué à 3. Dernière modification le 26 février 2015 à 22:09.
Heureusement ! Tout le monde n'est pas connecté à internet…
Si je me souviens bien, ce n'est pas le cas d'ubuntu, qui télécharge le binaire à l'installation.
[^] # Re: Orthogonalité ?
Posté par flan (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 8.
Pour moi, ce sont des maths à la base. Prends deux droites orthogonales, qui se coupent donc à angle droit.
Si tu te déplaces sur la droite verticale, tu ne bouges absolument pas horizontalement (par définition). Idem si tu te déplaces sur la droite horizontale. On peut donc dire que ces deux droite sont indépendantes l'une de l'autre.
Maintenant, imagine que la droite verticale est inclinée. Si tu te déplaces le long de la droite inclinée, tu vas également bouger vis-à-vis de la droite horizontale. Quelque part, ces deux droites sont donc « liées » (même si mathématiquement ce n'est pas le bon terme, « lié » a un sens précis en maths).
L'image, c'est que chaque droite correspond à un problème : travailler sur un problème (te déplacer sur la droite) n'a aucune influence sur le second problème quand les deux problème sont orthogonaux.
[^] # Re: L’avis de Microsoft : ODF has clearly won
Posté par flan (site web personnel) . En réponse au journal ODF a t-il définitivement perdu la guerre face à OOXML ?. Évalué à 2. Dernière modification le 25 février 2015 à 22:58.
Et pourtant : http://en.wikipedia.org/wiki/Microsoft_Office_XML_formats
Ce que dit ta page, c'est qu'il y a eu un nouveau format XML (Office Open XML) avec Office 2007. Mais il y en avait déjà un, qui est apparu avec Office 2003 (et qui n'avait pas l'air terrible, au passage).
[^] # Re: L’avis de Microsoft : ODF has clearly won
Posté par flan (site web personnel) . En réponse au journal ODF a t-il définitivement perdu la guerre face à OOXML ?. Évalué à 1.
À ma connaissance, MS a abandonné le format binaire en faveur d'un format XML pour Office avec Office 2003, donc bien avant ODF.
[^] # Re: spelld
Posté par flan (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Il y a également un « À contrario », qui s'écrit « A contrario ».
[^] # Re: Trivial avec du proprio, mais pas impossible avec du libre
Posté par flan (site web personnel) . En réponse au journal Superfish ou: j'ai rien compris au logiciel propriétaire. Évalué à 3. Dernière modification le 21 février 2015 à 15:28.
Tu ne présentes qu'une partie des arguments…
Si c'est une entreprise bien déterminée qui produit le logiciel (on se moque de la licence, qu'elle soit libre ou non), celui qui a écrit le code fautif a de fortes chances d'être identifié. Et tu as deux possibilités :
* soit l'entreprise l'a explicitement demandé, et c'est dangereux pour l'entreprise (perte de confiance des clients, voire un procès de leur part),
* soit le codeur l'a fait sans l'accord de son entreprise, et il risque de perdre son job, voire une amende ou de la prison.
D'ailleurs, ce cas correspond bien davantage à ton scénario de pharmacien : tu lui fais confiance parce qu'il est clairement identifiable et que s'il ne fait pas bien son boulot, il risque beaucoup.
Alors que dans le libre, tu peux considérer que tu ne risques absolument rien. Tu as peut-être moins de chances que ça passe, mais si ça casse, ce n'est pas trop grave, tu tenteras avec un autre projet.
Accessoirement une faille de sécurité peut très bien être considérée comme un bug (cf. la faiblesse de SSH dans Debian : qui te garantit que ce n'était pas volontaire ?).
[^] # Re: La seule question qui s'impose
Posté par flan (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 3.
Je ne connais pas trop les UEFI sur les cartes-mères actuelles, mais il me semble qu'ils sont bien plus évolués que les EFI des Mac (qui commencent à être un peu dépassés à ce que j'ai pu lire, notamment le bootloader intégré).
Techniquement, c'est faisable, mais je n'ai aucune idée si c'est intégré par les fabricants des CM (et ça doit dépendre d'une CM à l'autre).
[^] # Re: La seule question qui s'impose
Posté par flan (site web personnel) . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 4.
Je trouve que les Mac restent les machines les plus faciles à installer : tu peux connecter l'installeur (DVD ou clef USB) et le sélectionner depuis l'OS actuel, ou appuyer sur ALT dès le boot. Tu peux aussi mettre un DVD d'installation sur une autre machine, tu redémarres la tienne et elle va le détecter automatiquement. Sinon, tu peux également booter ou installer via du HTTP. Dernier choix, tu peux démarrer ta machine pour qu'elle soit considérée comme un disque externe si tu veux transférer tes données.
J'ai eu en main pas mal de PC où il faut appuyer sur F1/F12/Del/Enter au bon moment (sinon tu entres dans la conf' RAID ou tu bootes sur la carte réseau)… mais il faut d'abord avoir configuré le BIOS pour accepter le boot sur USB/CD. Quand tu as une machine particulièrement lente à démarrer (à cause du matériel), c'est franchement pénible.
Ensuite, quand tu as plusieurs disques durs et que tu as déjà eu un GRUB installé, tu ne sais pas lequel doit être mis en premier, ni sur lequel tu dois installer le nouveau GRUB. Et là, tu peux être parti pour 4 ou 5 redémarrages pour trouver à l'aveuglette le bon disque… (bah oui, dans le BIOS tu as le numéro de série alors que tu installes le GRUB sur /dev/SDX).
[^] # Re: Qt
Posté par flan (site web personnel) . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 2.
Correction : pour développer avec Xcode et le framework Cocoa (qui n'existent que sur OS X), il faut OS X.
Si tu veux, tu peux très bien développer pour Mac sans avoir de Mac avec d'autres techno (je le fais sans souci avec du Python + Qt, par exemple).
C'est toujours moins pratique, au même titre que c'est moins pratique de développer pour Linux sans avoir de Linux, ou de développer pour Windows sans avoir de Windows. Mais ça reste possible.
[^] # Re: Qt
Posté par flan (site web personnel) . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à -1.
Que doivent payer les développeurs ? À ma connaissance, développer des applis sur Mac OS X est totalement gratuit (en revanche, la publication — facultative — sur l'AppStore doit être payante).
[^] # Re: Pas libre
Posté par flan (site web personnel) . En réponse à la dépêche Le projet Libre OS USB a besoin de vous. Évalué à 3.
Si, bien sûr que si, la musique achetée sur iTunes n'a aucun DRM.
[^] # Re: Qt
Posté par flan (site web personnel) . En réponse à la dépêche LibreOffice 4.4 : sous le capot. Évalué à 6.
En tant qu'utilisateur de Mac, j'attends qu'une appli correctement intégrée utilise les possibilités de l'OS, qui vont bien au-delà d'un simple aspect graphique. En vrac, quelques exemples :
Et il y a sûrement plein d'autres trucs de ce genre. Après, tout peut être corrigé, évidemment, mais il faut le refaire à la main, et s'il faut tout refaire à la main, autant partir directement sur Cocoa.
[^] # Re: Drôle de phrase
Posté par flan (site web personnel) . En réponse au journal "Gummiboot UEFI Boot Loader" sera ajouté à Systemd. Évalué à 2.
Personnellement, j'ai surtout vu de plus en plus de Mac (avec pas mal de migrations de Linux vers OS X).
Après, c'est difficile de généraliser sans avoir de chiffres plus globaux.
[^] # Re: python3 uniquement ?
Posté par flan (site web personnel) . En réponse au journal Nouveautés de pyAggr3g470r. Évalué à 2.
Si je ne m'abuse, tu auras toujours un problème avec Python 3.3, vu que le « yield from X » est une nouveauté de Python 3.4.
# Quelques questions
Posté par flan (site web personnel) . En réponse à la dépêche Backup Checker 1.0, le vérificateur automatisé de sauvegarde. Évalué à 8.
J'ai un peu regardé la doc (l'idée me paraît intéressante), et j'ai quelques remarques :
[^] # Re: Une source à ouvrir
Posté par flan (site web personnel) . En réponse à la dépêche GnuPG utilisé, GnuPG oublié, mais GnuPG financé. Évalué à 8.
http://www.easy2boot.com
Le site web fleure bon les années 90, mais ça marche super bien :)
[^] # Re: Une source à ouvrir
Posté par flan (site web personnel) . En réponse à la dépêche GnuPG utilisé, GnuPG oublié, mais GnuPG financé. Évalué à 6.
Pas besoin de ça, il y a des clefs USB qui permettent de simplement copier des .iso dans le bon dossier, et d'avoir un menu de boot qui détecte automatiquement tous les .iso présents.
[^] # Re: Une source à ouvrir
Posté par flan (site web personnel) . En réponse à la dépêche GnuPG utilisé, GnuPG oublié, mais GnuPG financé. Évalué à 4. Dernière modification le 08 février 2015 à 10:12.
Tu proposes tout de même de faire payer quelque chose de gratuit pour donner de l'argent à des gens qui n'en demandent pas (s'ils choisissent explicitement de le distribuer gratuitement, c'est parce qu'ils ne tiennent pas spécialement à être payés… ou alors quelque chose m'échappe).
Je trouve ça quand même dur à justifier.
Ah si, j'avais oublié : c'est indolore. Trouves-tu sincèrement qu'on n'a pas assez d'impôts et de taxes en tout genre ?
[^] # Re: Une source à ouvrir
Posté par flan (site web personnel) . En réponse à la dépêche GnuPG utilisé, GnuPG oublié, mais GnuPG financé. Évalué à 6.
pourquoi donc ? je préférerais largement diminuer de moitié ces taxes…
[^] # Re: gitlab-ci
Posté par flan (site web personnel) . En réponse au journal Un bond en avant pour Gitlab.com. Évalué à 2.
Figure-toi qu'avec Jenkins ou TeamCity, tu peux tout à fait lancer n'importe quel script en ligne de commande.
Travis-CI te permet de prendre un fichier de conf' simple et de lancer les scripts bien plus facilement, avec des configurations toutes faites pour les principaux langages.
Voilà un exemple pour du Python :
language: python
python:
- "2.6"
- "2.7"
- "3.2"
- "3.3"
- "3.4"
# command to install dependencies
install: "pip install -r requirements.txt"
# command to run tests
script: nosetests
Ça lance les scripts dans 5 versions différentes de Python, ça installe les dépendances et ça lance le test.
Oui, on pourrait faire un script, mais ça prendrait plus de temps (surtout à débugguer, parce que ton script va planter lors du pip install à cause de variables d'environnement mal mises, par exemple).
# gitlab-ci
Posté par flan (site web personnel) . En réponse au journal Un bond en avant pour Gitlab.com. Évalué à 3.
Je trouve Gitlab vraiment bien fichu, mais en revanche Gitlab-CI est assez limité, je trouve. On peut lancer un script, et c'est à peu près tout. On est assez loin de Travis-CI en terme de simplicité (ou alors ça aa bien changé depuis la dernière fois que j'ai regardé).
[^] # Re: c'est pas faux!
Posté par flan (site web personnel) . En réponse au journal A cause d'Ubuntu et de ses nombreux défauts, un moteur de jeux abandonne Linux !. Évalué à 2.
Mais heureusement, tu as Scala ! Comme ça, tu dois vérifier que tu as les paquets pour la bonne version de Scala ET pour la bonne version de Java ! :)
[^] # Re: je suis effaré
Posté par flan (site web personnel) . En réponse au journal Les lois françaises favorisent-elles l’insécurité informatique ?. Évalué à 1.
Ton livre parle d'algo de chiffrement (et un chiffrement faible est cassé avec des méthodes totalement différentes de la recherche de failles classiques). Le journal parle de l'intégralité du code (et oui, les failles peuvent se trouver partout), et de codes extrêmement spécialisés (industrie de défense).
En pratique, on constate que
* un code open-source utilisé par beaucoup de monde peut contenir des failles graves et très vieilles (heartbleed, shellshock, debian+ssh, …), donc soit il n'y a pas de relecture, soit elle est inutile,
* les failles sont dans leur très grande majorité trouvées sans utiliser le code source.
Maintenant, prenons un code utilisé dans une centrale nucléaire ou un avion de combat.
Qui ira relire bénévolement des milliers de lignes de code qu'il ne pourra pas réutiliser, à part les services de renseignement étrangers ?
Pourquoi cette relecture serait-elle magiquement plus efficacement que sur les codes classiques ?
Réponse donnée par Scoubidou : des gens qu'on paierait pour relire le code… bon, bah pour ça, il n'y a pas besoin de donner le code aux services étrangers, et de toute façon c'est probablement déjà fait (ça s'appelle des audits et c'est très classique).
Dans beaucoup de cas, dévoiler le code revient à dévoiler nos capacités, sans même parler des failles potentielles que les services étrangers garderaient pour eux…
Je vois bien ce qu'on peut y perdre, mais je ne vois pas trop ce qu'on y gagne.