Pierre Carrier a écrit 199 commentaires

Camping existe en anglais, parking moins directement dans parking space / parking lot.

et on ne peut pas vraiment imaginer éditer des S-expressions à la main.

Quoi ??

C'est pas bientôt fini ces anneries ? La license spécifiait version 2 ou version ultérieure (à votre choix).

Il a choisi de commencer à distribuer avec une version ultérieure, c'est son droit.

Tu as le droit d'utiliser le code publié en GPL2+ depuis du code GPL2, GPL2+, GPL3, GPL3+, etc. ; tu n'as pas le droit d'utiliser le code publié en GPL3+ depuis du code GPL2.

La seule référence est un lien cassé, et la page sur l'électrosensibilité "dénonce" l'échec de la plupart des études en double-aveugle. Tant qu'on ne me sort pas une méta-analyse crédible démontrant l'existence du phénomène, j'assume que c'est bidon. Et non, les anecdotes et témoignages ne sont pas une substitution valable.

Ou tu commandes en ligne.

Compatibilité binaire avec BeOS.

Je n'ai jamais dit que Spotify n'avait pas de restrictions. Juste que ni Steam ni Spotify ne devraient être décrits comme "une solution de DRM".

À titre personnel, j'aimerai savoir si tu as une bonne raison d'associer la législation allemande et la possibilité de créer des comptes sans passer par un identifiant Facebook ?

Avertissement : je travaille à Spotify, que tu qualifierais probablement aussi de "solution propriétaire de DRM"

"solution propriétaire de DRM nouvellement arrivée sur système GNU/Linux" est du foutage de gueule pur et simple. Steam est une plateforme de vente, distribution (y compris mises à jour), stockage décentralisé des données, discussion & organisation de parties, etc.

Un paquet de jeux sur Steam n'utilisent pas de DRM, ou pas la solution intégrée dans Steam, et tu peux les redistribuer sans Steam.

Tu penses franchement que le gros de l'effort de développement se focalise sur les DRMs, ou ça t'amuse juste de salir le travail de dizaines de développeurs, designers, graphistes, etc. ?

Non. Valve l'a très bien expliqué : ils veulent se focaliser sur une plate-forme pour les premières itérations.

Il y a un paquet de problèmes à résoudre. Certains ont été discutés à UDS, et (mon analyse:) Valve est bien content d'avoir une communauté précise avec laquelle discuter, et une entité commerciale qui peut pousser les changements nécessaires dans "leur" produit (Canonical).

Pour donner un exemple, quand les utilisateurs changent le focus d'un jeu plein écran, le multi-écran et la résolution du bureau doivent être restaurés, jusqu'à ce que le jeu reprenne la main. Quand un jeu crash, multi-écran et résolution doivent être restaurés. Ces problèmes doivent être résolus quelque part dans la pile graphique, et les discussions tournaient autour de gnome-settings-daemon, Unity, le noyau, etc. pour établir la meilleure stratégie ; les dévs Unity repartent avec des objectifs à remplir pour Unity, mais heureusement avec l'intention d'offrir une standardisation (vraisemblablement des WM hints).

Beaucoup de développeurs tendent à compiler statiquement la plupart de leurs dépendances, mais il reste des composants système (SDL, OpenGL, OpenAL, libstdc++, etc.) qui doivent offrir une compatibilité binaire ascendante pour de longues périodes ; encore une fois, Valve peut discuter avec les mainteneurs de "la principale distribution" pour leur cible pour trouver une solution viable. Ça ne veut pas dire que les autres distributions ne pourront faire un effort similaire.

De manière générale, j'ai trouvé leur approche très saine (ignorant le débat autour des DRMs, qu'ils n'imposent d'ailleurs pas aux jeux, ils offrent une option). Il est évident qu'ils se focalisent sur l'expérience utilisateur, qu'au moins une partie de l'entreprise cherche réellement à fournir une solution solide sous Linux plutôt qu'à jouer un tour de force anti-Microsoft, et qu'ils sont bien partis pour réussir.

J'aime mes jeux, dont plein de propriétaires. Je ne m'attends pas à ce que les studios et éditeurs changent de modèles commerciaux ou techniques de sitôt, mais je serai extrêmement satisfait si l'offre sous Linux devient comparable à celle sous Windows, que je n'abandonnais plus l'idée de faire une petite partie par peine de redémarrer, et que moins d'utilisateurs potentiels de distributions Linux rejetaient l'idée à cause du dernier FPS.

Pour linux-lts, tu le mets dans HoldPkg dans /etc/pacman.conf et tu suis les sorties pour savoir quand des problèmes qui t'affectent vraiment (genre sécurité) requièrent une mise à jour et un redémarrage.

Personnellement cette approche me plaît bien, surtout que je fais grosso modo la même chose avec les autres distributions.

T'as peut-être envie d'automatiser ça du coup, non ?

Surtout que ce n'est pas particulièrement difficile…

Ça ne répondra vraissemblablement pas à tes besoins, mais voilà ma solution : https://github.com/pcarrier/vagrant-images/blob/archlinux/build.sh

Elle me permet de placer ma config dans overlay/, donc pas de grosse différence qu'il y ait un fichier avec plusieurs sections ou plusieurs fichiers…

ls -1 | awk -F_ '{print $(NF-1) " " $0}' | sort | cut -d' ' -f2-

Edit: explication

• ls -1 : un fichier par ligne

• awk :
  ** Découpage :
  *** -F_ : le séparateur de champs est _
  *** NF-1 : numéro de l'avant-dernier champ
  *** $(NF-1) : contenu de l'avant-dernier champ
  *** $0 : contenu complet de l'enregistrement (ligne)
  ** En sortie, on a la date suivie d'un espace puis le nom de fichier

• sort : on trie les lignes dans l'ordre alphanumérique :)

• cut -d' ' -f2- :
  ** -d' ' : Le délimiteur de champs est l'espace
  ** -f2- : Garder tous les champs à partir du second

Tant qu'on y est, pourquoi tu ne fais pas tourner le JavaScript sous Firefox 1.0 dans un système émulé avec jslinux côté iPhone 5, face à Chrome mobile pour le Samsung Galaxy S III ?

Oui, je m'arrête déjà à sqrt(n). Le reste des optimisations complique pas mal le code.

Bon, l'implémentation native prend en fait toujours moins de 2 millisecondes maintenant que je ne fais plus le boulet (code corrigé et compilation avec -O3 ; lien mis à jour).

Vu que tu sembles axé JVM, j'ai fait une version en Java pour comparer l'effort.

L'avantage est qu'elle gère des nombres considérablement plus grands (utilisation d'un BitSet et de BigInteger). Après, évidemment, on perd en perf…

% java -cp target/classes PrimeSum 2000000 
max:2000000, count:148933, sum:142913828922, time:0.043000

% java -cp target/classes PrimeSum 100000000
max:100000000, count:5761455, sum:279209790387276, time:1.965000

Je suppose qu'on a trouvé mieux que le crible d'Ératosthène en 22 siècles, mais c'était un exercise rigolo.

Toutes les JVM dont j'ai jamais entendu parler (et j'aime le sujet) utilisent des threads sous Linux depuis de nombreuses années.

Les threads seront moins coûteux. Sur un système Linux threads et processus sont tous deux des tâches, mais les threads ont beaucoup plus en commun (notamment l'espace d'addressage).

Pour ton exercise, ni threads ni processus ! Une implémentation naïve, sans aucun parrallélisme prend 3 ms sur mon ordinateur portable.

Oui, c'est un bug connu.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677096

Comportement classique pour dstat ou ifstat avec un noyau 2.6.32, c'est les statistiques qui ne sont pas mises à jour toutes les secondes par ton noyau. Utilise tcpdump et tu verras que les paquets passent en continu.

Le PPA Ubuntu n'est vraiment pas à jour (vieille version de kiwix, pas de paquets pour oneiric ou precise).

Vous avez besoin d'un coup de main ?

Les bandes annonce, c'est de la publicité aussi.

Non. Le kernel de mon ordinateur portable était à jour et MySQL a bien pris 100% de CPU.

Mon employeur a anticipé, coupé tous les ntpd et retiré la leap second a l'aide d'un petit binaire.

Quelques services n'ont pas reçu cette correction par erreur (oubli d'un réseau pas publiquement addressable) et ont systématiquement eu des problèmes (JVM principalement). Mais le gros de la production a parfaitement survécu.

Google de leur côté trichent avec UTC-SLS ( http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/ ), et ils ont bien raison :)

Gros coup de stress peu après minuit GMT, surtout quand on surveillait Twitter et découvrait qu'un tas de gros services étaient tombés (dont yelp.com, Facebook XMPP, etc.).

O'Reilly est fantastique pour cette raison : si tu possèdes une version papier, la mise à jour E-book est à 5 dollars US.

Il faut pour cela disposer de l'ISBN du livre. Les ISBNs sont publics et disponibles sur le site Web, donc ils comptent sur ton honnêteté, vraiment l'inverse des DRMs.

Il faut s'enregistrer, mais en contre-partie ils te tiennent informés des mises à jour sur les versions électroniques, et tu peux les re-télécharger à tout moment, dans n'importe quel format supporté.

Aucune différence entre le contenu électronique et le contenu papier, du moins j'espère.

Les coûts de développement (pour un livre, "mise en page") spécifiques au format électronique sont inférieurs à ceux spécifiques au format papier, largement si la chaîne de conception est correcte, bas dans l'absolu. Ramenés à un coût par exemplaire vendu, peuvent être supérieurs, mais encore une fois vraiment bas.

Les coûts par exemplaire sont ridiculement bas par rapport au format papier.

L'impression, le stockage, la distribution, la mise en rayon, les invendus (généralement pris en charge par l'éditeur, pas le distributeur ou revendeur !), etc. coûtent très cher, particulièrement sur ce genre de petits tirages (peu d'économies d'échelle : pour résumer et avec les chiffres que j'ai en tête, en impression tu payes le premier bouquin livré à l'éditeur ~20 fois plus cher que le 100ième, ~50 fois plus cher que le 1000ième, cela pour un même éditeur ; les grands éditeurs payent évidemment moins chers quand ils sont bons clients).

En gros, tu payes effectivement quelques euros pour le bouquin technique moyen (cartonné, tirage de qualité, relativement gros formats et longs).

Par contraste, les ouvrages au format de poche sont peu chers pour les raisons suivantes (liste vraissemblablement non-exhaustive) :
- Gros tirages directement puisque le livre a déjà "marché",
- Vu que le livre à déjà marché, et qu'une réédition est improbable, probablement pas ou peu d'invendus,
- Format, qualité d'impression, matériaux à coûts réduits,
- Il me semble que la part (portion) pour l'auteur est inférieure, mais ma mémoire pourrait me tromper.

J'aurai presque envie de supposer que les éditeurs font payer cher le coût d'opportunité : la perte de marché due au "piratage" du livre électronique (du moins celle qui n'aurait pas eu lieu avec des copies "scanner") est payée par les bénéficiaires.

sethostname est standard, mais pas persistant (perdu au redémarrage).

clock_settime ne couvre pas le fuseau horaire.

setenv n'affecte que les processus descendants, certainement pas l'ensemble de la session ou des prochaines, donc à nouveau pas persistant.