Il faut bien distinguer l'ancien Mac OS et son remplaçant : Mac OS X.
MacOS est l'OS des années 80/90 qui se nommait au départ System[1,7] et qui a tourné sur 68k et PowerPC.
MacOS*X* est une évolution de l'OS OpenStep de NeXT avec le look'n feel d'Apple. Le marketing l'a nommé successivement Rapsody (1998), MacOSX (2001) puis OSX et aujourd'hui MacOS. Il a débuté sur les machines PowerPC puis Intel et bientôt ARM.
Les premiers MacOSX proposaient Classic qui exécutait un environnement capable d'exécuter les anciennes applications compilés pour MacOS9.
Si on se place du coté d'une application que l'on voudrait installer sur un OS, sa compatibilité avec l'environnement cible n'est elle pas lié à l'ensemble de librairies qui lui permettent de s'executer ?
L'écosysteme ne peut il pas etre défini par cette compatibilité ?
Les combinaisonts sont infinies mais on peut distinguer approximativement (et sans prétention) les "ecosystemes" suivants :
- linux desktop : Gnome/KDE/… + X11/ + libc + linux
- linux Android : IHM proprio + java + Linux
- linux Console : shell + gnu + libc + linux
- OSX : IHM Mac + libs apple + BSD
- IOS : IHM iphone + libs apple + BDS
- Windows : exporer + libs microsoft + noyau NT
- etc.
La qualité d'un codec vidéo ne se résume pas qu'aux seuls criteres du taux de compression et de la qualité d'image.
Il est possible de compresser toujours plus à qualité d'image constante… mais le plus souvent aux prix d'une consomation CPU/RAM/IO/energie en hausse et le risque de perdre en fluidité d'encodage/décodage et en autonomie.
La contrainte de l'encodage/décodage en temps réel par les appareils du marché est primordiale : Téléphones, tablettes, box TV, PC, camescope numeriques, RaspberryPI et ses cousins, etc… En ce sens, la diffusion d'un codec correspond à l'ère du temps.
Le H265 n'a rien de miraculeux. Il demande aux équipements une puissance qu'ils offrent à peine aujourd'hui !
Demain, la puissance moyenne des equipements aura augmenté, et de nouveaux codecs, inenvisageable aujourd'hui, pourront être proposés.
Autre facteur clé de succes, les puces embarquées spécialisées dans la compression/decompression de certain codec laisse peu de chance aux codecs concurents.
Ca fait quelques années que je suis à l'affut d'outils libres sous Linux qui me permettraient de me passer du module de développement de Lightroom.
S'il y a hétérogénéité sur les format Raw de chaque constructeur, il y a pire encore : LES PROFILS COLORIMETRIQUES DES CAPTEURS. Chaque boitier à son propre rendu des couleurs.
J'ai 2 appareils photos Canon EOS-350D et EOS-600D. Un traitement dcraw par défaut produit toujours des images avec des tons jaunes/rouges tirant sur l'orangé (c'est moche). On est loin des rendus "jpeg embarqué", des rendu du logiciel constructeurs, ou du rendu LightRoom. La faute revient à l'absence de profil de conversion de couleur adapté à mes appareils. On trouve parfois sur le net des profils en téléchargement, mais aucun ne m'a jamais convaincu. Il est aussi possible dans le cas de Canon d'emprunter ceux du logiciel constructeur (DPP), mais ces profils ne suffisent pas à s'approcher du rendu recherché.
Le logiciel libre Darktable à la particularité d'embarquer une courbe de transformation de couleur pour certains appareils de manière à s'approcher le plus possible du rendu constructeur. Ca marche très bien dans mon cas.
De la même façon qu'il existe une banque de profils géométriques pour les déformations optiques, il serait merveilleux de disposer une base libre de profils colorimétriques (ICC) pour tous nos appareils.
Maven est bien un outil de build logiciel en Java, mais il n'est pas vraiment équivalent à Make.
Alors que Make ou Ant (équivalent de make en Java) se base sur un script qui décrit, en détail, chaque étapes du process, Maven se base sur une modélisation haut niveau du projet. Ainsi, il est inutile de décrire toujours le même process de build. Maven, par le biais de ses plugins sait faire par défaut. Les cas particulier demanderont de configurer les plugins voulu.
Néanmoins, il n'y a pas de miracle, les processus de builds les plus tordus passent mal sur une approche Maven. Il faut pour cela, développer des plugins spécifiques, ou remettre en cause le process.
[^] # Re: Mes quelques ajouts
Posté par arnaud.c . En réponse au journal Vulgarisation scientifique en vidéo et en français. Évalué à 3.
J'ai récemment découvert Mathémusique qui, comme son nom l'indique, montre les liens entre les mathématiques et la musique : https://www.youtube.com/c/Math%C3%A9musique
[^] # Re: MacOS
Posté par arnaud.c . En réponse au journal RiscOS et les systèmes inventifs des années 80. Évalué à 3.
Il faut bien distinguer l'ancien Mac OS et son remplaçant : Mac OS X.
MacOS est l'OS des années 80/90 qui se nommait au départ System[1,7] et qui a tourné sur 68k et PowerPC.
MacOS*X* est une évolution de l'OS OpenStep de NeXT avec le look'n feel d'Apple. Le marketing l'a nommé successivement Rapsody (1998), MacOSX (2001) puis OSX et aujourd'hui MacOS. Il a débuté sur les machines PowerPC puis Intel et bientôt ARM.
Les premiers MacOSX proposaient Classic qui exécutait un environnement capable d'exécuter les anciennes applications compilés pour MacOS9.
[^] # Re: Flux audio
Posté par arnaud.c . En réponse au journal France Inter fait des podcasts. Évalué à 1.
youtube-dl ferait il l'affaire ?
A priori, France-Inter fait parti des sites supportés.
[^] # Re: Blagues Carambar
Posté par arnaud.c . En réponse au journal Lord Casque Noir est bronsonisé. Évalué à 1.
Pour les nostalgiques, y a beaucoup de vieux magazines scannés sur
http://www.abandonware-magazines.org/
A+
[^] # Re: Fake
Posté par arnaud.c . En réponse au journal Baleine d'avril sur Nextinpact. Évalué à 3.
C'est assez !
# Un ecosysteme = environnement compatible ?
Posté par arnaud.c . En réponse au journal Où est le "vrai Linux"?. Évalué à 2.
Si on se place du coté d'une application que l'on voudrait installer sur un OS, sa compatibilité avec l'environnement cible n'est elle pas lié à l'ensemble de librairies qui lui permettent de s'executer ?
L'écosysteme ne peut il pas etre défini par cette compatibilité ?
Les combinaisonts sont infinies mais on peut distinguer approximativement (et sans prétention) les "ecosystemes" suivants :
- linux desktop : Gnome/KDE/… + X11/ + libc + linux
- linux Android : IHM proprio + java + Linux
- linux Console : shell + gnu + libc + linux
- OSX : IHM Mac + libs apple + BSD
- IOS : IHM iphone + libs apple + BDS
- Windows : exporer + libs microsoft + noyau NT
- etc.
# petite nuance
Posté par arnaud.c . En réponse au journal Magic Lantern : un projet open-source (trop?) discret. Évalué à 9.
ML ne remplace pas le firmware des appareils Canon. Il se greffe juste par dessus.
Seul le boot loader est modifié pour charger les extensions MagicLantern sur la carte SD en complement du firmware d'origine.
[^] # Re: Pour le succès
Posté par arnaud.c . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 7. Dernière modification le 03 juillet 2013 à 20:16.
La qualité d'un codec vidéo ne se résume pas qu'aux seuls criteres du taux de compression et de la qualité d'image.
Il est possible de compresser toujours plus à qualité d'image constante… mais le plus souvent aux prix d'une consomation CPU/RAM/IO/energie en hausse et le risque de perdre en fluidité d'encodage/décodage et en autonomie.
La contrainte de l'encodage/décodage en temps réel par les appareils du marché est primordiale : Téléphones, tablettes, box TV, PC, camescope numeriques, RaspberryPI et ses cousins, etc… En ce sens, la diffusion d'un codec correspond à l'ère du temps.
Le H265 n'a rien de miraculeux. Il demande aux équipements une puissance qu'ils offrent à peine aujourd'hui !
Demain, la puissance moyenne des equipements aura augmenté, et de nouveaux codecs, inenvisageable aujourd'hui, pourront être proposés.
Autre facteur clé de succes, les puces embarquées spécialisées dans la compression/decompression de certain codec laisse peu de chance aux codecs concurents.
# Quid de la gestion des couleurs ?
Posté par arnaud.c . En réponse au journal Logiciels de développement des fichiers RAW sous Linux. Évalué à 2.
Ca fait quelques années que je suis à l'affut d'outils libres sous Linux qui me permettraient de me passer du module de développement de Lightroom.
S'il y a hétérogénéité sur les format Raw de chaque constructeur, il y a pire encore : LES PROFILS COLORIMETRIQUES DES CAPTEURS. Chaque boitier à son propre rendu des couleurs.
J'ai 2 appareils photos Canon EOS-350D et EOS-600D. Un traitement dcraw par défaut produit toujours des images avec des tons jaunes/rouges tirant sur l'orangé (c'est moche). On est loin des rendus "jpeg embarqué", des rendu du logiciel constructeurs, ou du rendu LightRoom. La faute revient à l'absence de profil de conversion de couleur adapté à mes appareils. On trouve parfois sur le net des profils en téléchargement, mais aucun ne m'a jamais convaincu. Il est aussi possible dans le cas de Canon d'emprunter ceux du logiciel constructeur (DPP), mais ces profils ne suffisent pas à s'approcher du rendu recherché.
Le logiciel libre Darktable à la particularité d'embarquer une courbe de transformation de couleur pour certains appareils de manière à s'approcher le plus possible du rendu constructeur. Ca marche très bien dans mon cas.
De la même façon qu'il existe une banque de profils géométriques pour les déformations optiques, il serait merveilleux de disposer une base libre de profils colorimétriques (ICC) pour tous nos appareils.
# Nuance...
Posté par arnaud.c . En réponse à la dépêche Soirée Maven 3 à Grenoble. Évalué à 3.
Alors que Make ou Ant (équivalent de make en Java) se base sur un script qui décrit, en détail, chaque étapes du process, Maven se base sur une modélisation haut niveau du projet. Ainsi, il est inutile de décrire toujours le même process de build. Maven, par le biais de ses plugins sait faire par défaut. Les cas particulier demanderont de configurer les plugins voulu.
Néanmoins, il n'y a pas de miracle, les processus de builds les plus tordus passent mal sur une approche Maven. Il faut pour cela, développer des plugins spécifiques, ou remettre en cause le process.