En France, une association "à but non lucratif" (loi 1901) ne peut pas reverser ses bénéfices à ses adhérents ou à ses dirigeants. C'est une protection pour ne pas que les adhérents partent avec la caisse, c'est tout.
ça n'empêche pas d'avoir une activité commerciale. L'association est exonérée d'impôts commerciaux jusqu'à 61145€ de produits d'activités "lucratives", autant dire pas grand chose, et seulement si c'est une activité secondaire et que le but principal est non lucratif. Dans le cas contraire, elle paie des impôts comme n'importe quelle entreprise. Ce n'est pas interdit de le faire, c'est juste qu'on paie des impôts comme tout le monde.
Voilà, ça me semble plutôt clair comme statut. ça peut être approprié dans certains cas bien spécifiques, mais en général, je dirais qu'il vaut mieux créer une entreprise normale…
C'est probablement différent dans d'autres pays. Quelqu'un a-t-il des infos sur les 501(c)3 aux États-Unis, par exemple?
Moi je trouve que 4Gio de RAM, c'est quand même plus simple que 4.294Go. On peut arrondir à 4Go mais ça fait quand même une erreur de 5%.
Pour les processeurs, ce n'est pas forcément important dans l'utilisation quotidienne, mais pour les gens qui conçoivent le matériel, ça change tout et il y a besoin de connaître les fréquences exactes. On peut rien y faire, quelque part, l'informatique c'est de la technologie et y'a besoin d'être un minimum précis.
Cela dit, ça n'est pas forcément une raison pour utiliser des Mio partout dans les interfaces graphiques et embrouiller les utilisateurs.
Je peux penser à des monnaies avec des pièces de 1/4, 1/2, éventuellement 1/5, 1/10. Mais y-en-a-t'il avec des pièces de 1/3? Sinon c'est pas de la base 60!
Pour rappel, la base 60 (3*4*5) permet d'avoir des quarts, moitiés, cinquièmes et tiers qui sont des "décimaux". Contrairement à la base 10 ou on se retrouve avec du 0.333333…. pour les tiers.
Cette unité bizarre est née d'une optimisation. Pour convertir une taille d'octets en Kilo-octets, quelqu'un, quelque part, s'est dit que ça serait beaucoup plus simple de diviser par 210, que de diviser par 1000. D'une part, la division est plus facile à faire pour un processeur, et d'autre part, les secteurs sur un support de stockage ont toujours une taille en puissance de 2 pour simplifier l'adressage. Il suffit donc de compter le nombre de secteurs et de convertir dans un multiple de "à peu près 1000 octets".
Détail amusant: une disquette de "1.44Mo" contient en fait: 2 faces x 80 pistes x 18 secteurs x 512 octets = 1440 x 1024 octets. Cela fait 1440Kio, soit 1.40625Mio ou 1.47456Mo.
Le baud s'abrège Bd, et représente quelque chose de plus bas niveeau: le nombre de "symboles" par seconde (le "par seconde" est déjà inclus, donc les "bauds par seconde" ça servirait à… mesurer la variation de vitesse de la connexion?). Dans un symbole, il peut y avoir plusieurs bits.
En gros, en informatique on n'utilise plus les baud depuis bien longtemps. Par exemple, un modem dit "56K" transmet à 56 Kilo-bits par seconde, mais seulement 8000 bauds. En effet, chaque symbole comprend 7 bits.
Conclusion, il vaut mieux laisser le baud aux télégraphistes et aux gens qui travaillent dans les télécommunications. En informatique il ne sert pas à grand chose et on a déjà assez de confusion comme ça!
Je ne pense pas que tu puisses changer la taille donnée par le firmware de la carte. ça, c'est interne au firmware et normalement pas modifiable.
Le mieux que tu puisses obtenir, c'est de créer une partition de 8Go ou un peu moins, et de faire attention de ne jamais utiliser le reste de l'espace "disponible".
Pour vim, j'ai installé youcompleteme, qui communique avec un serveur faisant tourner clang sur les buffers ouverts. On a la complétion, les prototypes des fonctions, et plein d'autres trucs que je découvre petit à petit.
Seul inconvénient: cela mange quelques Go de RAM quand on a des projets un peu complexes, car l'AST (la représentation interne de clang) de chaque fichier est stockée en RAM (cela comprend le fichier + tous les includes).
Presto (le moteur d'Opera) est toujours développé. Il fait toujours fonctionner Opera Mini sur les téléphones. Simplement il n'est plus utilisé pour leur navigateur "desktop", qui n'est pas celui sur lequel ils font des bénéfices, de toutes façons.
Le modèle d'Opera est qu'ils gagnent des sous avec le moteur Presto qu'ils utilisent pour l'embarquer dans plein de trucs (plusieurs consoles de chez Nintendo par exemple). Le navigateur desktop c'est juste une vitrine pour faire savoir qu'ils existent et que les gens reconnaissent leur marque.
Je m'interroge un peu plus sur des gens comme Vivaldi Technologies, qui développent un navigateur basé sur Blink et le distribuent gratuitement. Je me demande comment ils comptent faire pour continuer à payer leurs 35 employés?
m4, un langage de macros pour remplacer des choses dans un fichier texte. Peut être utilisé pour pré-traiter du code source, quand le préprocesseur C montre ses limites, mais aussi pour plein d'autres choses.
gperf, un outil pour générer une table de hachage sans collisions à partir de chaînes de caractères.
Et pour aller avec CMake, il me paraît intéressant de mentionner CTest (un moteur pour faire des tests unitaires) et CPack (pour générer facilement des pauqets deb, rpm, et même des installeurs pour Windows). Tous les deux sont utilisables avec ou sans CMake, mais sont assez bien intégrés dans ce dernier.
La fonction annuler/refaire d'un éditeur de texte est-elle utile pour produire du code? Je me sers beaucoup de git comme une extension (ou généralisation) de cette fonctionnalité (persistance sur le disque, gestion de plusieurs fichiers, etc).
Pour moi c'est un outil indispensable pour produire du code.
J'ai du mal à croire qu'il y aie des gens (même riches ou richissimes) qui gardent tout leur argent sous leur matelas. Du coup, dès que c'est dans une banque sur un compte d'épargne, ce n'est pas sorti de l'économie.
Cela dit il repose aussi sur d'autres trucs plus récents (DHCP, …) et les RFC ont été plusieurs fois mises à jour depuis.
(et puis, on pouvait déjà booter sur le réseau à l'époque du Xerox Alto en 1973. Par contre ça n'était probablement pas tout à fait le même protocole).
Le déclin du LL sur le navigateur ça n'a pas l'air d'être trop le cas pour le moment. Que je sache, Chrome (qui est de loin le navigateur le plus utilisé maintenant) est un logiciel libre. Et ne vient pas me dire que "oui mais c'est Google, c'est pas pareil" (le bon et le mauvais chasseur?).
Il y a des gens qui se trompent de combat. Pour les navigateurs, le combat sur le LL est déjà gagné, et c'est bien. Mais on a un peu oublié le combat sur le respect de la vie privée des utilisateurs et de leurs données, qui finalement, ne vient pas forcément automatiquement avec le logiciel libre. Moi, c'est plus là-dessus que j'attends Mozilla, maintenant.
Early production runs are likely to be done in batches of ~25 wafers. This would yield around 100-200K good chips per batch. We expect to produce packaged chips for less than $10 each.
Donc, une première production de 100 à 200 000 unités à 10$ pièce? On est effectivement pas vraiment dans un volume "faible".
git repose exactement sur la même "supposition". Selon leurs propres mots: il y a plus de chance que les développeurs du projet soient tués par des loups une nuit, dans des évènements indépendants, que de tomber par hasard sur une collision SHA-1.
La supposition que les collisions sont suffisament rares pour ignorer le problème permet à git (et je suppose aussi à SVN) d'être rapide. Dans le cas de git, il me semble qu'ils vérifient qu'il n'y a pas de collision, et donc lors d'un commit, tu auras un message d'erreur avant de casser ton dépôt. C'est déjà ça…
vim peut convertir le contenu d'un fichier en code HTML préservant la coloration syntaxique. C'est la commande :TOhtml. Ensuite tu peux ouvrir le résultat comme un fichier HTML (dans un navigateur web ou directement dans LO?) et copier le résultat dans ton document.
Je rajoute un lien vers le projet LowRISC, qui est un des projets pour fondre des puces utilisant le jeu d'instructions RISC-V (64 bit): http://www.lowrisc.org/faq/
Leur but est d'avoir un system on chip pour environ 10$ pièce, gravé en 22nm, et qui tournerait à 1 ou 1.5GHz, pour y faire fonctionner un système Linux.
Ils prévoient de lancer une campagne de financement cette année pour pouvoir investir dans la réalisation des circuits. En attendant, cela s'expérimente sur des FPGA, ce qui leur permet déjà de travailler aux compilateurs, portage de Linux vers leur système, etc.
En Europe, il n'y a que GSM et UMTS. Aux USA, tu as des opérateurs en CDMA, par exemple. Et ça c'est pour les trucs déjà déployés et mis en production. A chaque nouvelle génération de standard (3G, 4G, …), plusieurs projets sont mis en concurrence.
Je ne crois pas que l'implémentation matérielle des puces Atheros soit ouverte?
En ce qui concerne les specs pour l'UMTS, cela m'a l'air d'être disponible par ici: http://www.3gpp.org/specifications (un lien vers un serveur FTP avec tous les documents, un peu en vrac il est vrai).
Par contre, il y a, d'une part des brevets, et d'autre part, une partie confidentielle qui concerne le chiffrement des données: http://www.3gpp.org/specifications/60-confidentiality-algorithms . ça semble normal qu'ils ne veulent pas filer leurs clés de chiffrement à n'importe qui :o)
OpenCores est une bibliothèque de composants matériels libres. On y trouve la description en langage VHDL (le code source, quoi) de ces composants, que l'on peut assembler pour fabriquer un appareil électronique.
Ce n'est qu'une partie du travail, ensuite il faut synthétiser tout ça et le mettre dans du matériel. Dans un premier temps, on simule logiciellement (en général, pas assez performant pour faire du temps réel). Dans un deuxième temps, on peut mettre ça sur un (ou plusieurs) FPGA (une puce électronique reconfigurable qui permet d'avoir des performances "correctes" pour faire des essais en temps réel - là ça consomme beaucoup). Enfin, on peut faire fondre un ASIC, c'est à dire une "vraie" puce figée avec le design final. Là, on peut avoir les performances d'un ARM ou d'un Atom, mais ça coûte des millions d'euros à produire (en grande quantité) et il faut être vraiment sûr de pas avoir laissé traîner des bugs dans le matériel.
En ce qui concerne OpenRISC, c'est un projet pour concevoir un cœur de processeur libre et sans licence. Il n'y a pas de raison qu'il soit moins bon qu'un autre (ARM ou Atom), mais il faut voir à l'usage, et cela peut dépendre des implémentations. De la même façon que le jeu d'instruction x86 est implémenté de différentes façons par Intel ou AMD, ou même dans différents produits chez le même fabricant; OpenRISC aura aussi plusieurs implémentations, tournées soit vers les performances brutes, soit plus vers l'économie d'énergie.
[^] # Re: [HS] Attaques personnelles
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Signet : l'étendue de l'application de la clause NC des licence CC (aux USA). Évalué à 4.
Bon répondons sur les idées alors:
En France, une association "à but non lucratif" (loi 1901) ne peut pas reverser ses bénéfices à ses adhérents ou à ses dirigeants. C'est une protection pour ne pas que les adhérents partent avec la caisse, c'est tout.
ça n'empêche pas d'avoir une activité commerciale. L'association est exonérée d'impôts commerciaux jusqu'à 61145€ de produits d'activités "lucratives", autant dire pas grand chose, et seulement si c'est une activité secondaire et que le but principal est non lucratif. Dans le cas contraire, elle paie des impôts comme n'importe quelle entreprise. Ce n'est pas interdit de le faire, c'est juste qu'on paie des impôts comme tout le monde.
Source: http://www.assistant-juridique.fr/but_non_lucratif_association.jsp
Voilà, ça me semble plutôt clair comme statut. ça peut être approprié dans certains cas bien spécifiques, mais en général, je dirais qu'il vaut mieux créer une entreprise normale…
C'est probablement différent dans d'autres pays. Quelqu'un a-t-il des infos sur les 501(c)3 aux États-Unis, par exemple?
[^] # Re: la réponse est 42!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Mio/MiB je ne comprends pas.. Évalué à 2.
Moi je trouve que 4Gio de RAM, c'est quand même plus simple que 4.294Go. On peut arrondir à 4Go mais ça fait quand même une erreur de 5%.
Pour les processeurs, ce n'est pas forcément important dans l'utilisation quotidienne, mais pour les gens qui conçoivent le matériel, ça change tout et il y a besoin de connaître les fréquences exactes. On peut rien y faire, quelque part, l'informatique c'est de la technologie et y'a besoin d'être un minimum précis.
Cela dit, ça n'est pas forcément une raison pour utiliser des Mio partout dans les interfaces graphiques et embrouiller les utilisateurs.
[^] # Re: la réponse est 42!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Mio/MiB je ne comprends pas.. Évalué à 2.
Oui c'est un exemple de monnaie "moderne".
Je peux penser à des monnaies avec des pièces de 1/4, 1/2, éventuellement 1/5, 1/10. Mais y-en-a-t'il avec des pièces de 1/3? Sinon c'est pas de la base 60!
Pour rappel, la base 60 (3*4*5) permet d'avoir des quarts, moitiés, cinquièmes et tiers qui sont des "décimaux". Contrairement à la base 10 ou on se retrouve avec du 0.333333…. pour les tiers.
[^] # Re: la réponse est 42!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Mio/MiB je ne comprends pas.. Évalué à 2.
Cette unité bizarre est née d'une optimisation. Pour convertir une taille d'octets en Kilo-octets, quelqu'un, quelque part, s'est dit que ça serait beaucoup plus simple de diviser par 210, que de diviser par 1000. D'une part, la division est plus facile à faire pour un processeur, et d'autre part, les secteurs sur un support de stockage ont toujours une taille en puissance de 2 pour simplifier l'adressage. Il suffit donc de compter le nombre de secteurs et de convertir dans un multiple de "à peu près 1000 octets".
Détail amusant: une disquette de "1.44Mo" contient en fait: 2 faces x 80 pistes x 18 secteurs x 512 octets = 1440 x 1024 octets. Cela fait 1440Kio, soit 1.40625Mio ou 1.47456Mo.
[^] # Re: la meme chose
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Mio/MiB je ne comprends pas.. Évalué à 4.
Oula, des "bauds par seconde" maintenant!
Mbps ce sont des Mega-bits par seconde.
Le baud s'abrège Bd, et représente quelque chose de plus bas niveeau: le nombre de "symboles" par seconde (le "par seconde" est déjà inclus, donc les "bauds par seconde" ça servirait à… mesurer la variation de vitesse de la connexion?). Dans un symbole, il peut y avoir plusieurs bits.
En gros, en informatique on n'utilise plus les baud depuis bien longtemps. Par exemple, un modem dit "56K" transmet à 56 Kilo-bits par seconde, mais seulement 8000 bauds. En effet, chaque symbole comprend 7 bits.
Conclusion, il vaut mieux laisser le baud aux télégraphistes et aux gens qui travaillent dans les télécommunications. En informatique il ne sert pas à grand chose et on a déjà assez de confusion comme ça!
[^] # Re: MBR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message fausse capacité carte memoire USB disque dur .. Évalué à 3.
Je ne pense pas que tu puisses changer la taille donnée par le firmware de la carte. ça, c'est interne au firmware et normalement pas modifiable.
Le mieux que tu puisses obtenir, c'est de créer une partition de 8Go ou un peu moins, et de faire attention de ne jamais utiliser le reste de l'espace "disponible".
[^] # Re: ctags
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 5.
Pour vim, j'ai installé youcompleteme, qui communique avec un serveur faisant tourner clang sur les buffers ouverts. On a la complétion, les prototypes des fonctions, et plein d'autres trucs que je découvre petit à petit.
Seul inconvénient: cela mange quelques Go de RAM quand on a des projets un peu complexes, car l'AST (la représentation interne de clang) de chaque fichier est stockée en RAM (cela comprend le fichier + tous les includes).
[^] # Re: Un problème structurel
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mozilla nous dit que le closed-source est plus bankable. Évalué à 2.
Presto (le moteur d'Opera) est toujours développé. Il fait toujours fonctionner Opera Mini sur les téléphones. Simplement il n'est plus utilisé pour leur navigateur "desktop", qui n'est pas celui sur lequel ils font des bénéfices, de toutes façons.
Le modèle d'Opera est qu'ils gagnent des sous avec le moteur Presto qu'ils utilisent pour l'embarquer dans plein de trucs (plusieurs consoles de chez Nintendo par exemple). Le navigateur desktop c'est juste une vitrine pour faire savoir qu'ils existent et que les gens reconnaissent leur marque.
Je m'interroge un peu plus sur des gens comme Vivaldi Technologies, qui développent un navigateur basé sur Blink et le distribuent gratuitement. Je me demande comment ils comptent faire pour continuer à payer leurs 35 employés?
[^] # Re: Autour du projet
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 4.
Et le très complet ProjeQtOr, mais là, on est plus vraiment dans les outils pour les développeurs…
# D'autres outils
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 6.
Moins connus mais pas forcément moins utiles:
Et pour aller avec CMake, il me paraît intéressant de mentionner CTest (un moteur pour faire des tests unitaires) et CPack (pour générer facilement des pauqets deb, rpm, et même des installeurs pour Windows). Tous les deux sont utilisables avec ou sans CMake, mais sont assez bien intégrés dans ce dernier.
[^] # Re: git / svn?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 10.
La fonction annuler/refaire d'un éditeur de texte est-elle utile pour produire du code? Je me sers beaucoup de git comme une extension (ou généralisation) de cette fonctionnalité (persistance sur le disque, gestion de plusieurs fichiers, etc).
Pour moi c'est un outil indispensable pour produire du code.
[^] # Re: Compilateurs
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Outils utiles pour développeur. Évalué à 4.
Il y en a plein d'autres qui sont libres, par exemple:
* Open Watcom
* SDCC (pour l'embarqué, PIC, z80, …)
[^] # Re: Ceci expliquerait-il cela ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mais qui a bien pu casser Amazon ? . Évalué à 10.
[^] # Re: Cotisations != employé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un four à pain c'est considéré comme un employé ?. Évalué à 2.
J'ai du mal à croire qu'il y aie des gens (même riches ou richissimes) qui gardent tout leur argent sous leur matelas. Du coup, dès que c'est dans une banque sur un compte d'épargne, ce n'est pas sorti de l'économie.
[^] # Re: vim
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Copier/coller avec coloration syntaxique dans LO Impress. Évalué à 2.
Je ne sais plus comment je l'ai découvert, probablement en listant
:help syntaxdans vim?Pour emacs, tu peux utiliser ça pour libérer quelques doigts. Mais ça ne donne pas de bon points à emacs pour autant: ça marche aussi avec vim!
[^] # Re: Netboot
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Libérer un Mac/Intel. Évalué à 3. Dernière modification le 02 mars 2017 à 13:05.
PxE repose assez largement sur TFTP, dont la RFC date de 1981. PxE lui même est documenté dans une RFC datant de 1984. Source: https://fr.wikipedia.org/wiki/Preboot_Execution_Environment
Cela dit il repose aussi sur d'autres trucs plus récents (DHCP, …) et les RFC ont été plusieurs fois mises à jour depuis.
(et puis, on pouvait déjà booter sur le réseau à l'époque du Xerox Alto en 1973. Par contre ça n'était probablement pas tout à fait le même protocole).
[^] # Re: et si ça n'a rien à voir avec les licences ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mozilla nous dit que le closed-source est plus bankable. Évalué à -4.
Le déclin du LL sur le navigateur ça n'a pas l'air d'être trop le cas pour le moment. Que je sache, Chrome (qui est de loin le navigateur le plus utilisé maintenant) est un logiciel libre. Et ne vient pas me dire que "oui mais c'est Google, c'est pas pareil" (le bon et le mauvais chasseur?).
Il y a des gens qui se trompent de combat. Pour les navigateurs, le combat sur le LL est déjà gagné, et c'est bien. Mais on a un peu oublié le combat sur le respect de la vie privée des utilisateurs et de leurs données, qui finalement, ne vient pas forcément automatiquement avec le logiciel libre. Moi, c'est plus là-dessus que j'attends Mozilla, maintenant.
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2.
Oups, j'ai confondu les chiffres…
Pour la production il y a ceci dans la FAQ:
Donc, une première production de 100 à 200 000 unités à 10$ pièce? On est effectivement pas vraiment dans un volume "faible".
[^] # Re: Et paf le Subversion
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et paf, le SHA-1 !. Évalué à 7.
git repose exactement sur la même "supposition". Selon leurs propres mots: il y a plus de chance que les développeurs du projet soient tués par des loups une nuit, dans des évènements indépendants, que de tomber par hasard sur une collision SHA-1.
La supposition que les collisions sont suffisament rares pour ignorer le problème permet à git (et je suppose aussi à SVN) d'être rapide. Dans le cas de git, il me semble qu'ils vérifient qu'il n'y a pas de collision, et donc lors d'un commit, tu auras un message d'erreur avant de casser ton dépôt. C'est déjà ça…
[^] # Re: et si ça n'a rien à voir avec les licences ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mozilla nous dit que le closed-source est plus bankable. Évalué à 6.
Peut être que tout le monde commence à comprendre que tu avais raison depuis le début, hein?
# vim
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Copier/coller avec coloration syntaxique dans LO Impress. Évalué à 4.
vim peut convertir le contenu d'un fichier en code HTML préservant la coloration syntaxique. C'est la commande :TOhtml. Ensuite tu peux ouvrir le résultat comme un fichier HTML (dans un navigateur web ou directement dans LO?) et copier le résultat dans ton document.
Dans le même esprit il y a Pyygmentize en python: http://pygments.org/docs/cmdline/
[^] # Re: Système de fichiers
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Les tutoriaux du mois de février 2017. Évalué à 2.
Sous Haiku, j'utilise BFS, bien sûr.
Pour les autres systèmes, XFS ou JFS, selon l'humeur du moment. Je n'ai toujours pas réussi à les départager.
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2.
Je rajoute un lien vers le projet LowRISC, qui est un des projets pour fondre des puces utilisant le jeu d'instructions RISC-V (64 bit): http://www.lowrisc.org/faq/
Leur but est d'avoir un system on chip pour environ 10$ pièce, gravé en 22nm, et qui tournerait à 1 ou 1.5GHz, pour y faire fonctionner un système Linux.
Ils prévoient de lancer une campagne de financement cette année pour pouvoir investir dans la réalisation des circuits. En attendant, cela s'expérimente sur des FPGA, ce qui leur permet déjà de travailler aux compilateurs, portage de Linux vers leur système, etc.
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 2.
En Europe, il n'y a que GSM et UMTS. Aux USA, tu as des opérateurs en CDMA, par exemple. Et ça c'est pour les trucs déjà déployés et mis en production. A chaque nouvelle génération de standard (3G, 4G, …), plusieurs projets sont mis en concurrence.
Je ne crois pas que l'implémentation matérielle des puces Atheros soit ouverte?
En ce qui concerne les specs pour l'UMTS, cela m'a l'air d'être disponible par ici: http://www.3gpp.org/specifications (un lien vers un serveur FTP avec tous les documents, un peu en vrac il est vrai).
Par contre, il y a, d'une part des brevets, et d'autre part, une partie confidentielle qui concerne le chiffrement des données: http://www.3gpp.org/specifications/60-confidentiality-algorithms . ça semble normal qu'ils ne veulent pas filer leurs clés de chiffrement à n'importe qui :o)
[^] # Re: C'est ... compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal 3310. Évalué à 3.
OpenCores est une bibliothèque de composants matériels libres. On y trouve la description en langage VHDL (le code source, quoi) de ces composants, que l'on peut assembler pour fabriquer un appareil électronique.
Ce n'est qu'une partie du travail, ensuite il faut synthétiser tout ça et le mettre dans du matériel. Dans un premier temps, on simule logiciellement (en général, pas assez performant pour faire du temps réel). Dans un deuxième temps, on peut mettre ça sur un (ou plusieurs) FPGA (une puce électronique reconfigurable qui permet d'avoir des performances "correctes" pour faire des essais en temps réel - là ça consomme beaucoup). Enfin, on peut faire fondre un ASIC, c'est à dire une "vraie" puce figée avec le design final. Là, on peut avoir les performances d'un ARM ou d'un Atom, mais ça coûte des millions d'euros à produire (en grande quantité) et il faut être vraiment sûr de pas avoir laissé traîner des bugs dans le matériel.
En ce qui concerne OpenRISC, c'est un projet pour concevoir un cœur de processeur libre et sans licence. Il n'y a pas de raison qu'il soit moins bon qu'un autre (ARM ou Atom), mais il faut voir à l'usage, et cela peut dépendre des implémentations. De la même façon que le jeu d'instruction x86 est implémenté de différentes façons par Intel ou AMD, ou même dans différents produits chez le même fabricant; OpenRISC aura aussi plusieurs implémentations, tournées soit vers les performances brutes, soit plus vers l'économie d'énergie.