Renault a écrit 7161 commentaires

Si la boîte a des actifs (software, base de client, brevet, …), oui cela peut être intéressant de mettre la boîte en faillite car dans ce cas c'est l'investisseur qui récupère sa mise en premier.

Oulà non.
En France du moins, les premiers à récupérer les mises ce sont les salariés (si des salaires et autres indemnités n'ont pas pu être payés évidemment). Après normalement ce sont les clients et fournisseurs (je ne sais pas s'il y a un ordre sur le sujet et une séparation particuliers / entreprises aussi). Les derniers à récupérer les mises normalement sont les banques, les actionnaires et l'État (là encore, j'ignore l'ordre exact).

Bref, à moins d'avoir un portefeuille d'actifs important, la faillite ne rapporte pas grand chose à ses investisseurs. En général rien du tout même. La meilleure solution à ce niveau là est de réussir à vendre la structure pour eux que la faillite.

Merci pour votre réponse, après je suis difficile mais je cherche une entreprise dont la philosophie est proche du logiciel libre.

C'est plutôt flou, qu'est-ce qu'une entreprise proche de cette philosophie selon toi ?
Car des entreprises comme Intel, Samsung ou Google, qui contribuent énormément au noyau Linux font selon moi partie des bons élèves typiquement.

N'oublie pas que tu postules pour un stage, et qu'à priori tu vises des boîtes plutôt petites qui ne courent pas les rues. Il faut faire un choix, ce genre de boîtes prennent rarement des stagiaires (bien que cela arrive). Je pense qu'il faudra que tu te montres moins difficile au début pour ensuite trouver ce qui te correspond, quand tu auras plus d'expérience et une mobilité géographique.

Je suis passé par là, je parle en connaissance de causes. Je pense que de se montrer trop difficile pour un stage n'est pas forcément payant (il faut surtout trouver un sujet qui t'intéresse pour te former).

Je doute que Thales et Dassault aient le monopole du Linux embarqué. ;-)
Tu peux regarder dans l'aéronautique comme Airbus ou Zodiac, dans l'électronique grand public comme Samsung, Intel, Broadcom, Technicolor et d'autres, les constructeurs automobiles ou encore les télécoms avec Orange, SFR ou autres, les réseaux avec Cisco, Linksys, Alcatel ou Nokia, etc.

Des secteurs qui ont besoin de Linux embarqué tu en as beaucoup, et en Île de France tu as quand même pas mal de R&D même si les entreprises que j'ai cité ne sont pas forcément sur place ou pour réaliser ce genre d'activité.

Tu as aussi je crois Smile qui est une SSII sur des LL qui a de mémoire une antenne en Île de France. Tu peux essayer qui sait.

Elle est où ta pile audio parfaite pour les systèmes d'exploitation ?
Ils attendent ton patch avec impatience !

Je ne dis pas que c'est la méthode que j'aurais utilisé. Mais je ne la trouve pas si violente que cela. Il a dit qu'il était déçu, ce n'est pas ce que j'appelle une humiliation personnellement.

Si une telle chose a pu arriver, c'est à cause d'un problème d'organisation, puisque le système est censé être fait pour que ça n'arrive pas. Peut-être qu'Andrew a fait comme Linus, qu'il a laissé passé un truc dans l'urgence sans le voir.

Il faut comprendre que Linus ne vérifie presque pas le travail validé par ses lieutenants directs dont fait parti Andrew. Car Linus n'est pas omniscient, il n'est pas expert en tout dans le noyau et intervient rarement aux endroits qu'il connaît peu. C'est le boulot d'Andrew de vérifier / tester le commit final qui ira dans le noyau pour sa partie.

Ce serait une erreur dans le VFS ou x86, Linus serait sans doute à blâmer car ce sont des endroits qu'il gère et adore. Pas ici.

Après comme je dis, je peux comprendre qu'on aime pas cette ambiance, et l'avantage du Libre c'est qu'on peut justement se débarrasser d'un mauvais gestionnaire de projets. Après il faut convaincre les autres contributeurs que Linus n'est pas adapté.

Il faut quand même ne pas oublier que Andrew a de lourdes responsabilités et qu'il les a car Linus a une confiance énorme en lui. Une erreur pareille qui passe entre les mailles du filet est très rare dans le noyau, si tard dans le cycle du développement du moins. Je ne trouve pas la phrase si insultante, elle sous-entend clairement qu'Andrew fait d'habitude du très bon travail mais que sur le coup il a merdé et qu'il est déçu. C'est tout. Je ne trouve pas cela si humiliant (il ne l'a pas insulté par rapport à ses habitudes).

On retombe peu ou prou sur le problème de la gestion de projet par un Ayatollah. Ça a montré son efficacité, mais c'est pas facile tous les jours pour les autres.

Tout le monde connaît les règles du jeu avec Linus, ce n'est pas nouveau et Andrew en particulier les connaît très très bien.
Notons que Linus l'a toujours dit, l'avantage du LL, c'est que si Linus devient fou, incompétent ou que plus personnes ne lui fait confiance, on peut prendre les sources et aller faire son projet ailleurs avec les autres pour écarter Linus.

Si personne ne le fait vraiment, c'est que malgré tout le système semble fonctionner suffisamment bien. Même Google, qui a pourtant de gros moyens humains et financiers limite au maximum l'écart avec la branche officielle pour Android.

Non.
Je pense que le but de la manœuvre est d'opposer la sauvegarde de l'information par une charge électrique dans un composant solide par rapport à une sauvegarde magnétique qui est dans un champs immatériel.

• le choix de partitionnement du disque n'est pas si intuitif, non vraiment pas, pourtant il y a un effort sur le graphique, mais je ne le trouve pas terrible, en même temps, je suis plus mode texte qu'interface graphique, en général c'est peut être ça au fond, c'est moi le soucis ;

Une autre interface sera disponible dans Anaconda à partir de Fedora 26 : blivet-gui (que tu peux installer sur ta Fedora actuelle si tu veux un visuel) qui sera plus proche de GParted et consort en terme d'organisation.

L'interface actuelle ne sera pas supprimée pour autant, le but est de satisfaire différents besoins des utilisateurs. Ces interfaces n'auront donc pas le même public et blivet est plus proche des outils traditionnels par son approche.

J'installe des paquets en graphique, bof, j'y comprend rien, je passe en ligne de commande, la ça roule tout seul, screen, emacs, vim, gcc-c++, make, sdl, git tout roule tout seul.

Si tu as utilisé GNOME Logiciels, il n'est pas adapté pour installer des environnements de développement. Il ne propose que des applications finies et qui possèdent un fichier .appdata dans son paquet voire code pour la description et d'autres infos. Donc en effet tout ce qui est CLI ou bibliothèque, cela n'est pas visible. Il faut se tourner vers la CLI ou un autre utilitaire tel que Yumex.

Donc au final, je la trouve bien cette fedora 25, et je suis satisfait d'y avoir passé quelques heures, au revoir fluxbox, on se retrouvera dans quelques mois/année et bienvenu gnome-shell.

Cool. :)

10 ans aujourd'hui c'est très long.

Dans certains secteurs d'activité oui, dans d'autres pas du tout.
Tu sembles oublier que souvent, lors du dépôt de brevet il est rare que le dépositaire soit capable de mettre son brevet directement en application. Car il faut probablement du financement, du matériel et du savoir faire pour mettre cela en œuvre. Il faut aussi du temps pour peaufiner le produit, pour peaufiner les processus ou réaliser des certifications. Et 10 ans ça peut être nécessaire pour cela.

On a un vrai problème avec la PI en générale, il est absurde de protéger un même type d’œuvre selon des durée variable, et encore plus sur des durée qui dépasse le siècle.

Je ne vois pas le rapport.
La durée de vie de la PI d'une chanson par exemple est relativement simple dans pas mal de pays, la France a une liste de clauses impressionnante pour allonger la durée de base mais cela n'est pas le principal problème. Le principal problème réside plus dans la durée finale de protection.

Oui et selon les juridictions tu n'auras pas les même chance. Aux US par exemples les procès en violation de brevets se font toujours dans les mêmes états…

Et en Chine bonne chance pour faire valoir tes droits par rapport à une entreprise locale.
C'est évident que les brevets reposent sur la justice pour fonctionner et que la qualité du système judiciaire est important. Mais cela n'est pas spécifique aux brevets, c'est valable pour l'ensemble du droit.

Tu me comprends mal: j'ai déjà moi-même lu et déposé des brevets sans aucune intention de ma boite de jamais les implémenter justement pour bloquer les implémentations alternatives qu'on estimait compétitives.

En France, un brevet qui en 10 ans n'a pas été mis en œuvre devient caduque, avant les 25 ans habituels afin d'éviter ce phénomène.

Si tu es une grosse boite qui attaque une petite boite, la stratégie c'est que la petite boite aura jeté l'éponge ou mis la clé sous la porte avant que la décision soit rendue.

Cela concerne potentiellement n'importe quelle décision juridique ou de propriété intellectuelle. Ce n'est pas nouveau et pas lié spécifiquement aux brevets.

Il faut des années de procédure pour faire invalider un brevet, et la notion d'évidence pour un expert est l'angle d'attaque qui a le moins de chance de passer.

Toujours est-il que c'est possible. Comme beaucoup de choses, cela n'est pas pour autant simple, automatique ou rapide à obtenir. Ce n'est pas le sens de mon propos…

-un moyen d'empêcher les concurrents de faire comme toi

Bah oui, par définition, je ne le nie pas.

-un moyen d'empêcher quiconque d'implémenter des solutions alternatives à la tienne

Non.
Un brevet protège justement une implémentation de la fonctionnalité, mais pas la fonctionnalité elle-même (du moins à l'international, certains pays peuvent être moins regardant notamment pour les brevets logiciels).

Tu peux donc faire un lave-linge révolutionnaire en utilisant d'autres techniques que celles brevetées actuellement par exemple.

-une arme atomique contre tout le monde via le volume (si je déclare que tu violes 500 brevets à moi, on est parti pour des années de procédures à grands frais… même si on sait tous les 2 que mes accusations sont bidons!!)

Si les accusations sont bidons, la plaignante va perdre et payer les frais de procédure. Je ne vois pas ce que tu veux dire.
Et ce n'est pas spécifique aux brevets, des procès intentés sans fondement juridiques cela n'est pas lié aux brevets.

Et si je veux, 23ans après le brevet original, je dépose une toute petite amélioration devenue évidente avec les progrès techo… Et on recommence!

Un brevet pour être valable ne doit pas être évident pour quelqu'un qui est à jour dans l'état de l'art justement.
Bien entendu, les Offices du brevets nationaux ne font pas toujours les vérifications nécessaires. Mais dans ce cas il suffit de mettre cet organisme dans la boucle judiciaire pour faire invalider les brevets et sanctionner l'organisme pour mauvaises pratiques.

Je pense qu'avec une comparaison et une explication cela serait plus claire.
Un brevet donne un droit exclusif sur la commercialisation du produit (le côté exclusif pouvant être remis en cause suivant le brevet et le pays, genre dans les télécoms cela est plutôt courant pour ne pas verrouiller le marché).

De fait, le droit de production des graines appartient bien à Mosanto, à cause des dits brevets que la graine contient.

C'est un peu comme si une imprimante 3D brevetée souhaitait s'imprimer elle même à la demande de son utilisateur (différent du constructeur). Cela serait une contrefaçon, car l'imprimante étant brevetée, l'utilisateur n'a pas le droit d'en faire une réplique même si matériellement cet outil en offre la possibilité intrinsèque.

C'est le (petit) avantage des brevets.

Ce n'est clairement pas un petit avantage, c'est au contraire le point clé des brevets.
Il faut voir le brevet comme suit :

• L'État s'engage sur une période donnée (maximum 25 ans) à accorder un monopole exclusif sur une invention à son dépositaire ;¹
• Le dépositaire du brevet doit en contre partie donner toutes les instructions nécessaires à la mise en œuvre dudit brevet pour que quand cela tombe dans le domaine public, la technologie soit exploitable par tous.

Le brevet est donc une arme contre les entreprises ou inventeurs qui gardent des secrets indéfiniment et qui finissent même par disparaître.
C'est donc un système gagnant-gagnant. Et je ne suis pas convaincu que la partie domaine public soit négligeable, au contraire.

Sauf que 25 ans est la date limite maximale de la validité d'un brevet. Ensuite, c'est du domaine public.

Je veux pas faire le rabat-joie, mais quand gnome-shell plante sous Wayland, toutes les applications plantent avec (si un contenu n'était pas sauvegardé, les données sont perdues)

Ce n'est pas forcément spécifique à Wayland.
Le fait que Gnome-Shell souhaite corriger cette régression montre que cela semble possible, il faut juste changer l'architecture de mutter vis à vis de Wayland.

Ne confonds pas Wayland avec son implémentation dans Gnome-Shell.

Quelques raisons qui ne me laissent pas en confiance sous Wayland : une grosse partie du code de gnome-shell est écrit en JavaScript. C'est une architecture monolithique (beaucoup moins modulaire que Xfce, par exemple). Et il y a un an ou deux d'ici, j'avais assez souvent des crash de gnome-shell (sous X11), et je pense qu'on pouvait voir sur le Retrace Server que ça arrivait à pas mal de monde.

Il n'y a aucun rapport entre Wayland et le JavaScript. Tu confonds encore l'implémentation de Wayland dans Gnome-Shell et Wayland lui même.
Sans compter que je ne vois pas le rapport entre JavaScript et la qualité d'un projet (de beaux projets robustes peuvent être faits en JS et de la merde en boîte avec n'importe quel autre langage au monde).

Tu veux qu'on reparle de tous les défauts de X11 aussi pour te convaincre que Wayland même si pour le moment n'offre pas tout, reste un choix pertinent aujourd'hui ?

Je ne parle pas tous les jours, mais une à plusieurs fois par semaine ce qui est plus rare pour un trésorier (et plus compliqué à gérer, avec potentiellement plus d'activités).

Non, on a un numéro de compte.

Pour ces gens là, il y a la mise à niveau par GNOME Logiciels, et comme dit plus haut, il suffit d'un clic. ;-)
En plus c'est suggéré par une pop-up quand c'est disponible, pas besoin de savoir qu'une version est sortie pour la mettre à niveau.

Ça doit être pour ça que Netflix fait sa propre production, c'est disponible sur Netflix avant de l'être en téléchargement illégal.

Netflix est américain et les USA n'ont pas la chronologie des médias telle que pratiquée en France.
Netflix fait sa propre production essentiellement pour se diversifier, à l'heure où certaines entreprises de productions rechignent à alimenter Netflix de peur de lui donner trop de pouvoirs économiques.

Pour le reste, ben soit t'achêtes le DVD à prix d'or bourré de pubs et de bandes-annonce, soit t'attends 3 ans pour le voir en VOD.

La VOD à l'unité en France est disponible dans l'année de sortie du film au cinéma ce qui est raisonnable. C'est en effet plus long pour la VOD à la demande telle que Netflix.
Mais la VOD à l'unité, ce n'est pas si inabordable que cela. Sans commune mesure par rapport aux DVD.

Oui, bien sûr, mais tu noteras quand même qu'il faut que celui qui envoie l'argent renseigne correctement ce champ. Après je pense que c'est une question d'habitude aussi (la France représente environ 2/3 des chèques émis en UE)…

Note qu'il y a une différence entre une association et ton compte bancaire.
Dans une association, surtout petite, le trésorier ne va pas vérifier tous les jours l'état du compte en banque. Très souvent même, il va se reposer sur les bilans mensuels de la banque.

Ce qu'il fait que l'association peut rarement agir à temps si jamais il y a eu utilisation frauduleuse de l'IBAN de l'association. Alors que pour le particulier, qui normalement vérifie ses comptes à une fréquence plus élevée, cela est moins problématique.

Pourquoi avoir forcément besoin d'écrire dans la flash ? Le XIP n'est plus utilisé que je sache (trop lent).

Euh, non.
C'est encore utilisé, pas plus tard qu'il y a 1 an ou deux j'ai du le mettre en place dans un projet utilisant Linux.
Le XIP a l'avantage d'être très simple en fonctionnement. Malgré ses performances réduites, cela fait sens suivant les besoins, composants choisis et temps de développement nécessaire.

Quand tu vois les dégâts causés par les maladies et la quantité de malades qu'ils ont eu sans vaccins, est-ce que les dégâts provoqués par le vaccin sur quelques individus ne sont pas le prix à payer pour sauver toutes ces personnes ?

Ton ami aurait peut être contracté la maladie si le vaccin n'hésitait pas. Voire une bonne partie de son entourage…

C'est une question d'éthique, mais la balance bénéfice/risque reste clairement en faveur du vaccin. Si par contre nous pouvons développer un système fiable pour ne pas vacciner ceux qui ne supporteraient pas le vaccin, cela serait à mettre en œuvre oui. Mais pour le moment cela n'existe pas.

Puis c'est en rapportant des bogues qu'on les corrige et évite à l'avenir aussi.
J'espère qu'il a bien rempli / crée des tickets à cette fin avant de se plaindre.

hum… De ce que je connais de Jenkins (c'est très vague), il permet de lancer des tests après un merge/commit, et donc trop tard (on fait de la correction à postériori, mieux que rien mais pas le mieux, je l'imagine pour des tests trop longs pour le CI, c'est parfois chiant d'attendre 24 heures que le CI accepte un PR). Comment bloques-tu le PR dans le gestionnaire de version tant que les tests ne sont pas fait avec Jenkins?

Pas du tout. Enfin, c'était peut être vraie à ton époque.
Dans ma boîte, on couple Gerrit (pour le code review) et Jenkins. Les commits sont en attentes dans Gerrit pour être validés par un humain, et automatiquement Jenkins vérifie de son côté que cela compile et les tests soient corrects.

Quand l'humain et Jenkins ont validé de leur côté, le commit peut être mergé.

Bref, on peut valider à priori avec Jenkins, au moins avec Gerrit. Comme Gerrit repose sur git, cela devrait être possible de faire avec git directement aussi.