xcomcmdr a écrit 3537 commentaires

L'article oublie complètement la distorsion des filtres passe-bas.

Tu as lu l'article ?

So the math is ideal, but what of real world complications? The most notorious is the band-limiting requirement. Signals with content over the Nyquist frequency must be lowpassed before sampling to avoid aliasing distortion; this analog lowpass is the infamous antialiasing filter. Antialiasing can't be ideal in practice, but modern techniques bring it very close. …and with that we come to oversampling.

Et lire la suite (flemme de citer) : Oversampling…

Le 192khz permet d'un filtre simple, avec zéro distorsion à 20khz, ni changement de phase.
Son intermodulation à 33khz, passe à -80dB ! C'est limite audible, de l'ordre de grandeur des erreurs du son 16 bits.

Ben non, le 24bits/192Khz reste inutile pour juste écouter :

That's only half the story. Because digital filters have few of the practical limitations of an analog filter, we can complete the anti-aliasing process with greater efficiency and precision digitally. The very high rate raw digital signal passes through a digital anti-aliasing filter, which has no trouble fitting a transition band into a tight space. After this further digital anti-aliasing, the extra padding samples are simply thrown away. Oversampled playback approximately works in reverse.
This means we can use low rate 44.1kHz or 48kHz audio with all the fidelity benefits of 192kHz or higher sampling (smooth frequency response, low aliasing) and none of the drawbacks (ultrasonics that cause intermodulation distortion, wasted space). Nearly all of today's analog-to-digital converters (ADCs) and digital-to-analog converters (DACs) oversample at very high rates. Few people realize this is happening because it's completely automatic and hidden.
ADCs and DACs didn't always transparently oversample. Thirty years ago, some recording consoles recorded at high sampling rates using only analog filters, and production and mastering simply used that high rate signal. The digital anti-aliasing and decimation steps (resampling to a lower rate for CDs or DAT) happened in the final stages of mastering. This may well be one of the early reasons 96kHz and 192kHz became associated with professional music production

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

écroulé de rire

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Euh, il est aussi celui qui a refusé de collaborer avec Debian et les autres distros dérivées,

Je croyais que c'était un refus du projet Debian de transformer Debian en Ubuntu qui l'a conduit à crée Canonical et à lancer le projet Ubuntu ?
Et puis franchement vu le nombre de distros pour une raison x ou y plus que discutable, une de plus ou de moins ça change rien.

celui qui a créé inutilement de la division autour du bureau libre malgré un effort portant sur une décennie pour rassembler les forces (Upstart, Mir, Unity etc.).

LOL, non.

Concernant Upstart :
Même sans prendre en compte Upstart, les systèmes d'init étaient déjà bien différents et non-standardisés (sysvinit, openrc, systemd, le BSD-style init de Slackware et sa couche de compatibilité SysV qui existe depuis la version 7, …), et ça ne semblait pas s'arranger depuis 10 ans, au contraire. Les scripts d'init étaient en général incompatibles d'une distro à une autre (et ils le sont toujours).

Même si upstart a été adopté pendant un temps par Fedora et quelques autres tels que RHEL, la véritable unification à ce niveau provient de systemd. Et systemd lui-même est très récent. L'adoption de systemd par un nombre de distributions clés (sauf quelques unes tels que Slackware, Debian, Gentoo, et Ubuntu) et encore plus récente, et provient uniquement du fait que systemd apporte de nombreux avantages pour les mainteneurs (en gros : maintenance réduite).

Concernant Unity :
Depuis qu'Ubuntu existe, on a eu droit à :
KDE 3 qui devient KDE 4 (ce qui a donné lieu au fork Trinity)
Gnome 2 qui est devenu Gnome 3 (ce qui a créé le fork MATE)
Et ensuite il y a eu Unity tel qu'on le connaît aujourd'hui.
Entre temps, razor-qt et d'autres environnements sont aussi apparus.

Bref, si parmi tout cela, seul Unity gêne, c'est pas logique.

Concernant Mir:
On verra si Mir est bon ou pas. En tout cas depuis qu'il existe le projet Wayland s'est bien réveillé, et les deux équipes derrière chaque projet semblent échanger régulièrement. Le libre est en marche, et la concurrence est une opportunité de s'améliorer pour les deux projets, pas un fardeau.

De mon point de vue, la crédibilité de Shuttleworth au niveau du libre est assez basse,

Mais la contribution de Canonical au libre en général reste énorme, pas uniquement du point de vue des lignes de code (launchpad, participations aux standards FDO tels que NotifyOSD, de très bons projets tels que LightDM, bzr, ayatana, contributions énormes aux LXC, démocratisation de GNU/Linux bien plus importante qu'avant, Steam sous GNU/Linux et amélioration des pilotes graphiques grâce aux retours de Valve, …).

c'est avant tout un entrepreneur qui a du nez (mobile, cloud, etc.) mais à qui il manque de la constance dans ses décisions et qui commence à s'impatienter de ses échecs (la dernière sortie en est une preuve flamboyante)
[…]
il est en train de tuer la communauté Ubuntu avec ses caprices d'enfant gâté
[…]

Ça, c'est clair.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Toujours sauvegarder toutes ses données sur un support externe avant d'installer un système d'exploitation, ça évite les sueurs froides.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

(pourquoi devrait-il attendre quand son ordinateur lui conseil de mettre à jour ?)

Jamais une LTS ne propose une mise à niveau vers une version intermédiaire.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Personnellement je trouve que passer de LTS en LTS est risqué parce que ce sont des mises à jours bien plus lourdes, je préfère largement faire une mise à jour tous les 6 mois avec au moins un mois de décalage pour ne pas avoir les problèmes des early adopters.

Non, en général passer de LTS en LTS se passe bien mieux, parce que les LTS sont bien plus fiables. La mise à niveau n'est pas plus lourde (c'est à peu près le même nombre de paquets qui sont mis à jours/supprimé/ajouté, et l'opération n'est pas plus longue). Et surtout, si tu attends la fin du support de ta LTS avant de migrer, tu auras une migration d'autant moins foireuse (exemple : un passage entre la 10.04.4 et la 12.04.2).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Stupide ?

Ça se discute. Avant Firefox 23, j'utilisais omnibar depuis des années.

La raison principale était un gain de place, avoir une zone de texte bien plus grande/confortable (oui j'aurais pu mettre la barre de recherche au niveau des menus mais je n'utilise pas la barre de menus et ça m'aurait fait perdre de la hauteur), et comme la barre d'url permettait déjà de saisir des recherches, je n'utilisais plus la barre de recherche (les zones de texte doublon dans une UI, c'est nul).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Il le fait.

Voilà ce que j'ai appliqué de mon côté sur ma Archlinux :
autologin dans lxdm (session xfce)
~/.config/autostart/autoscript.desktop lance ~/.autostart.sh

Contenu de autostart.sh :

#! /usr/bin/env sh
while [ ! $(pidof xfwm4) ]; do
sleep 1
done
wmctrl -s 1
thunderbird &
wmctrl -s 0
start-pulseaudio-x11 &
sleep 2
gnome-screensaver &
sleep 2
gnome-screensaver-command -l &
xfce4-volumed-pulse &
exec /home/max/bin/timidity-titanic.sh &
pnmixer &
pidgin &
firefox &
xfce4-terminal &

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ouai j'y avait pensé a cette solution de locker dès l'ouverture mais dans l'idéal j'aurai préféré l'ouvrir déjà locké.

Hibernation avec verrouillage avant la mise en hibernation ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Belle mentalité.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

J'espère que le fork va prendre ses responsabilités et renommer son bousin.

J'espère surtout que ce bousin va bouser de Debian.

----> []

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

En premier sur http://www.ubuntu.com/download/desktop j'ai la 12.04.

C'est ubuntu-fr, un site non-officiel, qui propose la 13.10 par défaut.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Loupé. Une LTS, par défaut, ne propose pas de mise à niveau vers une version intermédiaire.
Pour les utilisateurs de la 12.04, la mise à niveau ne sera proposée que lorsque la nouvelle LTS sera là (la 14.04).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Je sais pas vraiment ce que signifie "l'inverse n'est pas vrai" (j'entends par là: "ça veut rien dire" car si A fait différent de B, alors B est différent de A)

Je ne parlais pas de différence, mais de compatibilité au niveau des arguments en ligne de commande, voire de l'API (pouvoir remplacer ffmpeg par libav et inversement sans que ton script/programme se retrouve cassé. Ce qui compte quand on remplace ffmpeg par libav dans une distrib')

Morceaux choisis :

ffprobe outputs: last year, Stefano and I worked on a way of improving ffprobe by making it output something else than the weird INI/XML by default. So we developed a simple writer system and provided a JSON output. At the same time, the feature was proposed as a hack on libav (they just hardcoded crappy printf calls all over the code). Of course, I suggested to just pick the commits in FFmpeg, but I was likely ignored (the hack patch as well). We then worked on adding XML, CSV, flat and various other outputs, most of them customizable through options. People started to use them, and obviously requested to the Libav folks the feature. The sane choice would have been to just pick what was already done. Instead, they decided to rewrite this from scratch, with the argument: "I don't like it". And by the way, they broke the default output "because it's evil and it sucks", and so breaking users scripts (without any version bump or anything).** They also didn't even care to keep the same option names with FFmpeg so users could switch between tools easily (FFmpeg added the -of alias for compatibility).**
[…]
Note: FFmpeg is providing ff* tools, fully compatible with the av* tools from Libav (avconv, avplay, …), with additional features, bug fixes, but also backward compatibility for some options Libav decided to remove.
[…]
libswresample and libavresample: end of 2011, Michael wrote an audio library to do any sample rate, formats, layout, packing conversions he dubbed libswresample. Later on a few people contributed to it, for example to document or expose the API properly to the user. It was then integrated to the whole project (tools, filters), and greatly improved the audio support in FFmpeg. As usual, Libav completely ignored this for one year, and then decided to pay a developer (with the money of the FFmtech foundation) to rewrite completely a library for the exact same purpose. They tried to justify this. This obviously pissed off the users. Since FFmpeg has a much better policy toward satisfying the users, we also provide the libavresample API.

Bref, ffmpeg s'occupe d'être rétro-compatible (garde les anciens codecs, par exemple), et d'être compatible avec libav.
Du côté de libav, on a le syndrome du NIH et pas grand chose d'autre.

Et lorsque j'essaie de compiler certains software qui utilisent libav, j'ai régulièrement des problèmes, selon que les dévs utilisent plutôt une version, et moi une autre.

Eh oui:

The main problem is that external projects who want to support both FFmpeg and Libav are just fucked, and this only because Libav doesn't care a second about their users.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et sinon, y'a la 12.04 qui est maintenu jusqu'en avril 2017 et qui est fiable.

Le geek, c'est celui qui fait la migration. Pas le grand public.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

La sécurité ne se limite pas au chiffrement… C'est aussi s'assurer que personne n'a accès à plus de données qu'il n'en a besoin.

Ben justement foutre ça en clair j'aurais pas trouvé ça mieux…
En même temps c'est plus ou moins troué vu que pour afficher les images des articles c'est des requêtes directes à Amazon (ça a peut-être changé depuis la 12.10).

Anonyme pour qui ? Canonical ? Pourquoi est-ce cela devrais transiter par Canonical ? Amazon, lui a une réelle nécessité à savoir qui je suis pour pouvoir m'envoyer mes bouquins et mes disques.

C'est juste une recherche, pas un formulaire d'achat non plus, hein. Je doute que tu puisse faire des commandes dans le Dash.

Ça transite par Canonical pour éviter de donner les IP à Amazon, et parce que les serveurs Canonical ne retournent pas bêtement le résultat de la requête sur Amazon, mais essaie de retourner des résultats intelligents (d'ailleurs ça ne concerne pas que la lens "shopping" mais aussi celle de la logithèque et autres services).

On peut toujours dire aux gosses à venir à l'école en culotte courte blindée, il n'empêche que tirer sur des écoles, c'est mal.

Je rajouterais que le code reste libre et sous licence GPLv3. :p
Maintenant ce qui serait pas mal c'est que ce soit signalé à l'installation. L'utilisateur de base n'est pas forcément au courant, même s'il y a un écran d'informations accessible directement depuis le Dash.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est le but du Dash depuis le début, même quand il ne faisait que chercher en local puis en proposant des logiciels provenant de la logithèque : trouver instantanément ce que veux l'utilisateur, à l'aide d'une recherche globale et de "lens".

Bon après ça reste chiffré (sûrement juste entre le client et les serveurs Canonical), et ça passe par les serveurs de Canonical histoire que ce soit anonyme (plus ou moins).

Et puis on peut toujours le désactiver en trois clics sans devoir rajouter un truc tel que Unity Tweak (voir virer le paquet correspondant), et on peut toujours faire une recherche uniquement locale.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

TON SPAM, ON S'EN TAMPONNE LE COQUILLARD AVEC UNE CUILLÈRE TAILLE BRONTOSAURE PLACÉE DERRIÈRE L'OREILLE TOUT EN FAISANT DU YOGA À 4 HEURES DU MATIN AVEC UNE PLUME ENTRE LES FESSES TOUT EN ÉCOUTANT RADIO MÉTAL, BORDEL !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

ffmpeg est 100% compatible libav.
L'inverse n'est pas vrai.

Et libav est aussi utilisé par Ubuntu (vu que ça provient des paquets Debian).

Au moins sous Arch on a ffmpeg, le seul, le vrai. ;-)

edit : un lien en plus par rapport à la situation :
http://aballier.wordpress.com/2013/01/18/ffmpeg-vs-libav-a-distribution-maintainer-point-of-view-almost-two-years-after-the-split/

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

ON S'EN FOUT !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Quand on utilise une appli Qt sur Windows on a vraiment l'impression d'utiliser une native.

Euh, non. C'est joli, c'est bien intégré, c'est à mille lieux plus agréable qu'une application GTK sous Windows, mais on reconnaît tout de suite sous Windows une application QT. Tout comme on reconnaît de suite une application Windows Forms, ou WPF.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Les forums ont aussi pléthore de sujets techniques bien plus utiles que ça.
Et la doc est en général de bonne qualité, à jour, et fournie.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Le PAE est propre aux CPUs 32 bits, et est pris en charge par linux 32 bits. Cela n'existe pas pour les CPU 64 bits, donc ça ne concerne en rien les linux 64 bits.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ben pourtant :

Portability to OSes:

systemd is not portable to non-Linux systems. It makes use of a large number of Linux-specific interfaces, including many that are used by its very core. We do not consider it feasible to port systemd to other Unixes (let alone non-Unix operating systems) and will not accept patches for systemd implementing any such portability (but hey, it's git, so it's as easy as it can get to maintain your own fork…). APIs that are supposed to be used as drop-in .c files are exempted from this: it is important to us that these compile nicely on non-Linux and even non-Unix platforms, even if they might just become NOPs.

Mais bon soit. Que systemd soit dépendant fortement ou non des API Linux, un binding aurait été possible.
Mais le choix aurait été tout autant critiqué, voir plus :
-> C++ (ça aurait invoqué le refrain classique comme quoi le C++ est "trop compliqué")
-> Ruby/Java/Python ("une VM pour l'init, what ?!")
-> D ("quoi, un langage pas connu ?!")
-> …

Le choix du C, en plus d'être classique, évite de maintenir un binding, d'avoir un langage connu (par les auteurs de systemd et par les développeurs *nix en général), portable, rapide, avec des compilateurs matures (gcc, clang).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Il y a des bindings avec l'API unix dans quasiment tout les langages que je connaisse. Tu n'as vraiment pas besoin de C pour effectuer des syscalls.

systemd n'utilise pas l'API Unix, mais l'API Linux, notamment les cgroups.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)