La multiplication par 10 des ressources sur un projet ne multiplie pas la vitesse de developpement par 10. Reciproquement, ca division par 10, meme si a court terme va desorganiser le projet, ne peut que tendre vers une moindre bureaucratie et une plus grande efficacite. Cela veut aussi dire qu'il va y avoir logiquement une volonte d'avoir un code plus maintenable dans le temps donc plus lege. Par contre, il y aura probablement moins de support des vieilles version et un focus sur uniquement la prochaine version. Tout depend des ressources restantes et de leur competences.
Pour information, n'oubliez pas que GTK, c'est globalement une personne et les EFL une vingtaine. Donc meme si ils perdent tous les contributeurs Nokia (ce qui est peu probable, car un certain nombre trouvera du boulot ailleur dans le meme domaine), ils auront toujours plus de contribution que leurs principaux concurrent libre.
Qt a un enorme momentum et ce n'est pas les decisions de Nokia qui le tueront. Sur le long terme, ils dependront nettement plus de la communaute et d'une bonne gestion ouverte… Mais ca, ce n'est deja plus Nokia qui decide.
La premiere raison est une question de coup, pourquoi est-ce que tu acheterais un telephone, un desktop/laptop, une console et une set top box, quand au final ceux dont tu as besoin c'est juste un processeur, des ecrans et peripheriques d'entree adaptes. Si en plus tu rajoutes a ca que ton telephones est subventionne… Pourquoi depenser plus si il est capable de se connecter a n'importe quel ecran et clavier/souris ? Je prend le parie que les gens laisseront definitivement tomber massivement le desktop pc dans ce cas la. La question est a quel echeance est-ce que le hardware sera capable d'etre competitif ? Deja aujourd'hui un Galaxy S3 est plus performant qu'un netbook et a une connectique hdmi/usb/bluetooth. Il manque que le software…
Il n'y a pas de negligence de l'environnement de travail, la strategie de microsoft dans ce domaine quand elle est regarde avec cet angle de vue, prend tout son sens. Il vise les entreprises qui fournissent des laptop pour l'instant a leur employe. Demain, si ils sont capable de fournir un OS qui s'integre aussi bien en mode desktop (telephone connecter a un dock desktop) que en telephone dans le reseau d'entreprise, ils peuvent potentiellement reprendre pied dans le domaine des smartphones.
Ce qui est important de comprendre ce n'est pas parce que ton interface a un look mobile sur un touch screen qu'elle doit necessairement avoir un look mobile sur un desktop. C'est la ou la difference d'implementation va se faire. La meme application mail peut avoir deux look completement differents et adapte a l'ecran (AMOLED vs LED LCD), a la distance de visualisation et au dpi, a la precision du pointeur (souris ou doigt), le tout sans changer le code. Le plus important est que le code reste identique de maniere a pouvoir plus facilement acceder aux memes informations.
Pour bien comprendre l'idee prenont l'exemple de LibreOffice Impress. Le telephone est plugge dans son dock. Il s'affiche donc sur ton ecran de PC tout comme aujourd'hui. Tu peux editer le contenu normalement, il n'y a aucune difference. Maintenant, tu l'enleves du dock. La, il se retrouve contraint sur un petit ecran de telephone, donc il passe en mode lecture seule. Il te permet d'aller d'une page a une autre, mais plus d'editer, toute l'interface est dedie a la lecture. Puis tu le connectes a un video projecteur, le telephone le detect, transforme l'ecran de telephone en telecommande et demarre la presentation. D'un bout a l'autre, c'est la meme application, le meme code, juste les informations affiches a l'ecran et la maniere d'interagir change.
Ceci est juste un exemple. Tu peux decliner les scenarios avec un client mail, un lecteur multimedia, un navigateur web, un client IM, un jeu …
Le probleme que tu pointes vient principalement du fait que le projet GNOME n'a pas d'equivalent a ce que Edje ou QML permettent. C'est a dire une separation clair entre layout/theme et code. Cela rend la tache de designer une application multi mode tres difficile et donne le resultat qu'on connait aujourd'hui. Mais ca, c'est un probleme d'implementation pas de concept.
Ce concept pose par contre de tres gros challenge en terme de securite, de vie prive et surtout de survie du logiciel libre ! Si demain le marche du desktop/laptop se reduit comme peau de chagrin et qu'il faut acheter une machine specifique pour pouvoir faire du logiciel libre, car il n'existe pas de telephone libre, alors ca sera problematique…
Enlightenment se porte tres bien en haut dpi. On est parfaitement capable de faire la difference entre les elements lisibles par l'utilisateur qui necessitent d'etre agrandit et les elements de decors qui ne doivent pas l'etre. D'ailleur lors de la premiere utilisation, tu as une boite de dialogue qui te demande de choisir le scale ratio qui te convient le mieux via une petite preview de ce que donnera l'interface avec ce ratio. Cela permet de choisir le aspect en fonction du dpi et de la distance lorsqu'on n'a pas les characteristiques du constructeur. Donc nop, Linux n'est pas a la traine dans le domaine !
Serieusement, ce n'est pas parce que GNOME et Unity ont merde leur convergence que c'est forcement mal d'avoir un tel objectif. Surtout que les telephones mobiles tant a manger de plus en plus de processeur dans la maison. Et il y a de bonne raison pour ca. En moyenne on en change tous les deux ans, la plus part des equiments electroniques et electrique de la maison, c'est plutot dix ans ou plus (TV, console, mais aussi frigo, machine a laver, voiture). Certains equipements ont une duree de vie encore plus longs, compteurs electriques, gaz, eaux, … Quelques uns ont une vie que legerement plus courte environ 5 ans, imprimantes, scanner, …
De plus deja aujourd'hui les smartphone sont capable de se connecter a des peripheriques bluetooth, a un hub USB et a un ecran en HDMI. Demain ce sera en Wireless Display. Un Samsung Galaxy S3 a plus de pattate niveau CPU/GPU qu'un ordinateur milieu de gamme d'il y a 4 ans. Et ils suivent la loi de moore.
Pour quel raison est-ce que j'aurais besoin de me trimbaler avec mon laptop alors que j'ai deja un processeur suffisament puissant dans ma poche ? Pourquoi je ne peux pas directement l'utiliser en le connectant a un ecran de PC ? Ou a un video projecteur ? Ou a une TV ?
La reponse est simple, c'est qu'aucun constructeur n'est encore venu sur le marche avec une technologie qui adapte le rendu de l'interface a la resolution, au dpi, a la distance de visionage et a la precision du peripherique d'entree. Mais pour le coup, le logiciel libre est en avance de ce cote la.
Le projet Enlightenment integre ces technologies, et c'est le but depuis des annees, directement dans le coeur de son infrastructure. Il est possible d'avoir une interface qui s'adapte completement aux peripheriques d'entree et de sortie utilise. D'avoir une application mail qui passe automatiquement de l'ecran de telephone au PC en s'adaptant automatiquement pour passer d'un simple mode liste au mode plus classique des mailers PC. Ce concepte est pour l'instant experimente dans Enna uniquement, mais l'infrastructure et les fonctionnalites sont la.
Il est important a mon sens de se rendre compte que le telephone mobile a aujourd'hui suffisament de puissance pour remplacer n'importe quel netbook et etre competitif avec les laptops bas de gamme. Il est important que le logiciel libre s'en rende compte et ne loupe pas cette etape. Car si demain nos ordinateurs deviennent aussi ferme que iOS et Android, nous aurons l'air malin avec nos logiciels libres.
Il nous faut aujourd'hui des solutions libre, plus efficace, plus legere, plus performante que ce que peut faire iOS, Android ou Windows. Car quand les usages seront vraiment possible et que l'on pourra faire le switch, probablement en 2015, soit on est pret, soit ce sera fini. Donc je trouve que c'est une tres bonne nouvelle que GNOME, tout comme KDE et le projet Enlightenment se prepare a ne pas louper se tournant. Apres les choix techniques et l'implementation sont une autre discussion, mais c'est deja une bonne chose en soit que personne ne loupe cette etape.
Le probleme n'est pas la technologie. C'est certain qu'on a les competences en Europe pour faire un telephone et j'espere que Jolla reussira a le montrer. Non, le veritable probleme, c'est que l'industrie europeenne est sclerose. Bloque dans un monde du passe. Le management se bat plus pour prendre la place du chef que pour ecraser la concurrence. Il n'y a pas de prise de risque. Pas de comprehension qu'on vit dans un monde qui change. Les grandes societes europeennes sont dans leur tres grande majorite tue par un management individualiste, sans envergure et imbut d'eux meme.
Le cas de Nokia en est un tres bon exemple. Ils ont rachete Trolltech en 2008, et ils ont mis plus de 3 ans pour realiser leur premier telephone. La raison, c'est quand interne, le management de Symbian ne voulait pas perdre de pouvoir, donc a accapere des ressource Qt inutilement. Meme chose avec une partie de l'equipe de Maemo. Au fina, ils ont passe plus de temps a se foutre sur la tronche qu'a faire un produit pour rivaliser avec la concurrence. Forcement a un moment donne, les actionnaires ont pris un arbitre charge de faire le menage. Arbitre qui ne peut pas avoir confiance dans les informations de ses troupes et qui est oblige d'aller chercher ailleur pour avoir une solution. Il aurait pu aller chercher chez Google, mais ca, c'est un autre debat.
Ce scenario pour l'avoir discute avec des amis qui travaillent dans d'autre branche de l'industrie (automobile, train, electrique, telecom), se repete inlassablement. Notre probleme, c'est les ecoles et la mantalite des manageurs de l'industrie europeenne. Ca ne changera pas. La seule bonne nouvelle, c'est que les entreprises asiatiques souffrent du meme probleme, voir pire, car il y a culturellement un pouvoir lie a l'age que nous avons moins en europe. Donc quand le coup du travail aura suffisament augmente, l'asie sera aussi ininterressante que l'europe. Je ne connais pas assez le reste du monde pour me prononcer.
Le probleme, c'est l'incapacite a prendre des risques, assumer des choix techniques en opposition avec les buzzword du moment et ca ca implique des managers courageux… C'est devenu un probleme culturel avant d'etre un probleme industriel. Je comprend de mieux en mieux pourquoi Steve Jobs a reussi a faire de Apple une societe aussi differente.
En meme temps l'utilite de ces packages est tres limite, car la premiere chose dont tu as besoin si tu veux faire une session de debuggage correct, c'est d'etre sur la derniere version du trunk du projet (ou de la branch stable). Recuperer les symboles de debuggage sur un truc ancestral, je vois pas l'interet.
Ce qui serait plus utile, c'est d'avoir une version de developpement et une version de production pour les bibliotheques. La version de developpement activant tous les checks evitant les plantages et donnant des informations precisent aux developpeurs. La version de production prenant tous les raccourcis et pouvant amener des jolis SEGV plutot qu'un morne message d'erreur.
Ca serait deja plus utile pour les developpeurs utilisant ces bibliotheques. A la rigueur pour faciliter le debogage la version de dev devrait inclure les symboles de debug. Mais bon, je ne connais aucune distrib qui fait ca…
Et ne me dit pas pour que le démarrage soit plus rapide … Archlinux n'a pas besoin de systemd pour être véloce au démarrage.
Tu as fait la comparaison ? J'ai un boute en 4s avec systemd au lieu de 40s avec l'init classique. Et oui, ca demarre le meme nombre de service et ca fait exactement la meme chose…
Bof, ce que faisaient eux même les utilisateurs est déporté aux bénévoles de la distribution.
Meme pas, c'est deporte sur les developpeurs upstream qui fournissent une unit pour leur projet. Ca evite que les distribs ou les utilisateurs ne fassent trop n'importe quoi. Ca permet de faire le boulot une fois pour absolument tout le monde. Les unit systemd etant nettement plus portable que les scripts d'init…
Franchement, j'ai du me palucher systemd sur une Fedora 17 pour tester la réalisation d'un paquet RPM et je reste assez dubitatif sur la chose : le compromis entre la complexité du bousin et le service qu'il est censé remplir vaut il vraiment le coup ?
Maintenant compare la complexite entre apprendre le shell script et le systeme de demarrage de ton systeme a la complexite d'un fichier unit qui sera terme fourni par la majorite des projets upstream. C'est sur faut changer ses habitudes et apprendre un truc nouveau pour ceux qui savaient deja de quoi on parlait.
ArchLinux fait pour moi parti de ces distribs qui sont ideals pour les developpeurs. Respect de l'upstream. Pas de patch aleatoire. Pas de paquet casse comme sur Ubuntu et Gentoo qui empeche la compilation. Pas de separation paquet de developpement/paquet princicipal. Possibilite de suivre directement le svn/git/… Excellente documentation.
Alors forcement, si c'est une distrib pour les developpeurs, c'est logique qu'elle suive ce que les developpeurs font et qu'elle aille vers ce qu'ils preferent.
Probablement un mode de veille avant le suspend complet. Certain processeur ARM sont capable de couper quasiment toutes leurs unites interne excepte les registres, le cache et la TLB. Cela permet de consommer beaucoup moins tout en maintenant le systeme parfaitement reactif et multitache. Il faut par contre que les applications et le systeme gere les choses correctement, car sinon c'est un bon moyen de se reveiller trop souvent et de tuer la batterie.
Mais, je doute fortement que E17 soit capable de tourner sur les mêmes machines que E16 …
Challenge interressant, mais l'architecture de E17 est nettement plus optimise que E16. La difficulte sera surtout de trouver le meme theme que E16 et de comparer a effets egaux. Et on tourne toujours sur des pentiums MMX, certains testent encore :-D
Ca viendra en son temps aussi. Il y a peu d'interet a refaire un nieme navigateur web ou un nieme client mail, si en plus de l'integration, il n'apporte pas quelque chose de neuf. On a des idees, des projets.
Terminology est la premiere application sur laquelle on va explorer ces nouvelles idees. Un nouveau concept pour les tabs, la notification, l'integration de fonctionnalite exterieur. Une fois que ces fonctions seront operationnelles, elles seront merge dans la bibliotheque de widget et on attaquera surement un navigateur web. Mais ca je ne le vois pas arriver avant l'annee prochaine vu la taille de notre equipe actuelle.
Pour un client mail, les idees ne manquent pas. Je recommande la lecture de l'ebook de Brett Victor qui contient de tres bonnes idees ainsi que ce lien : http://www.vanschneider.com/work/mail/. En lien supplementaire, je rajouterais aussi : http://notmuchmail.org/. D'un point de vue architecture, reecrire et gerer tous les protocoles mails est une tache, lourde, complexe et peu gratifiante, car deja fait et sans trop de plus valu a priori. Ce qui compte, c'est surtout d'etre capable de naviguer rapidement et efficacement dans ses maildirs, d'afficher tous ses mails, de pouvoir en ecrire et de donner du contexte a l'ensemble des information.
En fait, l'interface graphique a tout interet a devenir une suite de communication et pas uniquement un afficheur de mail. La, il y a beaucoup de chose que l'on peut faire qui peuvent etre nouveau. Donc l'idee actuel serait de se baser sur un daemon qui remplit gentillement un maildir en tache de fond et un front end qui ne fait que de l'affichage et de la manipulation de donnees. Cela simplifiera surement grandement l'ecriture d'un tel client. Il faut maintenant trouver un bon daemon pour nous remplir nos maildir… Mais pareil, cet effort ne commencera surement pas avant que E17 et Terminology ne soit release. En attendant, on reflechit, trouve des outils qui nous permettront quand on s'y attaquera d'avancer efficacement.
La tres grosse difference avec TermKit, c'est qu'on utilise l'infra existante et tous les binaires utilisant un terminal. A l'oppose, TermKit reecrit tout…
Le "Desktop Shell" se limite principalement a offrir un window manager tres configurable avec un bon file manager et un certain nombre de "sonde" sous forme de plugins. Pas de client mail, irc, im, web, office… Donc en gros pas d'appli, mais des gadgets pour savoir combien de mail en attente, les news, l'etat du reseau, …
Euh, comparer E16 et E17, ca n'a juste rien a voir. E17 aujourd'hui n'a pas une seule ligne en commun avec E16. Il est aussi plus performant que E16 (Mais ca ce n'etait pas tres difficile).
Pour le cote configurable, j'avoue ne pas comprendre ta remarque. C'est un des windows manager les plus configurable. On peut configurer la disposition des fenetres par bureau virtuel. L'un en tile, un autre classique. On peut attacher des bindings claviers ou souris a toutes les actions. Tous les modules peuvent etre active ou desactive a la demande de l'utilisateur et il est tres simple d'ecrire son propre module. De ce cote la, je pense qu'on n'a pas a rougir de la concurrence !
Pour ce qui est du theme par contre, c'est clair que celui par defaut est moche ! C'est pas comme si on pouvait en changer facilement, mais avoir un theme complet et joli ca prend du temps. Si il y a des designers motives pour nous aider, la porte est grande ouverte. La plus grande difficulte pour nous, c'est de faire les graphismes, modifier le theme est facile apres. Donc si quelqu'un veut proposer un nouveau theme par defaut, on attend vos idees. A vos GIMP et Inkscape :-)
Ensuite, E17 n'est pas GNOME ou KDE, c'est a comparer plutot avec kwin ou Compiz…
Je note un certain manque d'imagination. Tout d'abord les effets speciaux sur le curseur, ca permet de toujours le retrouver rapidement. Les videos et images, permettent certe de completement customiser son terminal, mais cela ouvre surtout la porte a une preview rapide de tous les fichiers sans application externe.
Il est tant de repenser les limites de son terminal…
Alors non, "Desktop Shell" n'a pas ete invente car on manquait de ressource. C'est la ligne directrice de E17 depuis le debut. Avoir un window manager, leger, souple, tres configurable. Les EFL ne sont qu'un effet de bord de cette objectif.
En fait, l'existence des EFLs, montre un gros disfonctionnement dans notre communaute. A chaque fois que quelqu'un veut faire une application, il commencait par faire la bibliotheque generique et reutilisable. L'application venait ensuite, peut etre… Resultat, on a un toolkit tres complet et efficace, mais peu d'application !
Le developpement de E17 a aussi ete complique par cette manie. A chaque fois qu'on ecrit un petit bout de code, on se rend compte qu'on pourrait le partager et qu'il serait utile a d'autre. Hop, une lib ! Resultat 10 ans pour faire un window manager… Ca finit par payer en terme de developpement de nouvelle fonctionnalite, de performance et de souplesse. Mais ce qui attire les developpeurs en general, c'est les applications. Ceux sont les entreprises qui sont attirees par les bibliotheques.
Raster regrette d'ailleur de ne pas avoir fait prendre au projet une orientation "Desktop" plus tot que "Desktop Shell". C'est aussi une des raisons de cette release de E17. Ce refocaliser sur les applications… Mais ce sera plus qu'un environement de bureau, car fonctionnant sur tous vos terminaux (telephone, tv, pc, …). Et ce sera le meme code sur chaque terminal, ce qui ouvre la porte a une plus grande cooperation entre les developpeurs des differents environnements… On verra bien ce que cela donnera !
Tout a fait d'accord avec l'analyse de Aaron. Il est preferable d'avoir le moins de process possible pour economiser des ressources. Et le code source xterm et urxvt est effectivement en mauvais etat du fait de son age.
Mais bon, ici on parle de deux chose, consommation memoire et performance. Tout d'abord pour les performances, le benchmark utilise est "time cat http://www.gutenberg.org/files/100/100.txt" (Le fichier etant en local sur la machine, et le temps retenu est le plus faible apres plusieurs lancement). Le resultat est sans appel, le temps d'execution est du plus grand au plus petit: Linux console > GNOME Terminal (et tous les utilisateurs de libvte) > Konsole > xterm > urxvt & Terminology.
Terminology : 2Mo dans le tas, 136K dans la stack
urxvt: 2.4Mo, 136K dans la stack
konsole: 3Mo dans le tas, 136K dans la stack (avec 4 tabs, on passe a 3.6Mo)
Conclusion pour l'instant, Aaron a raison, il y a plus de donnee partage dans konsole avec des tabs que dans urxvt. Donc assez rapidement, konsole prendra l'avantage sur urxvt. Il n'y a pas de tab pour l'instant dans Terminology, mais une partie des ressources peuvent etre mise en commun grace a CServe2 entre toutes les instances (Image et glyph de font). Cela genere une economie de 1.5Mo par instance, le cout d'un nouveau Terminology etant de 500K. On n'est plus tres loin de ce que fait Konsole avec ces tabs, mais sans tab on ne pourra pas faire beaucoup mieux.
Mais bon pour ces 500K, vous avez un terminal qui fonctionne en frame buffer, sous wayland et X (en soft ou avec acceleration OpenGL) sans aucune modification. La version frame buffer peut suivant les machines etre en 10 et 50 fois plus rapide que la console Linux par defaut. Il est presque fonctionnel sur touchscreen (manque le scroll back au touch).
Mais le fait d'avoir un toolkit complet ouvre des possibilites nouvelles. Pour le meme prix, vous avez le droit a la preview des images et des videos directement dans Terminology sans lancer d'application. Il suffit de cliquer sur un chemin, et si c'est une image, un pdf, une video, vous avez directement un player d'afficher. Il reste a maintenant patcher tous les outils classiques pour qu'il detecte Terminology et emettent un code d'echapement permettant d'avoir cette fonctionnalite de disponible partout. L'idee etant que dans mc, vous cliquez sur un fichier image et ca l'afficher instantanement. Pareil, une url dans mutt ou irssi vers une image, et ca vous l'affichera d'un simple click, pas besoin de lancer un browser pour.
Bon, et tout ca, ca a pris combien de temps ? Et bien Terminology a tout juste un mois ! Il a recu les contributions d'une dizaine de developpeur durant ce laps de temps. On a passez beaucoup de temps a ecrire les bibliotheques, mais aujourd'hui se framework se revele extremement productif ! Il est probable qu'on puisse finaliser Terminology (sans tab) pour la release de E17.
Il y a une difference majeur avec Kinect, c'est que tu te trouves a petite distance, juste au dessus du capteur. Un bon eclairage infrarouge et deux camera de bonne definition elimineront beaucoup de bruit deja. Ensuite pas la peine de reconstituer tous un corps, mais ici il n'est necessaire que de caler le nuage de point sur une main d'une forme generique. Ca permettra de differencier directement les doigts par la meme occasion. Je pense qu'en prenant suffisament de raccourci ca doit pouvoir passer pour cet usage.
Sauf que uniformiser les API est une bonne chance. La situation actuelle, c'est plein de patch plus ou moins bon par distrib difficilement maintenable plus un peu de biniouterie upstream pour gerer ce qu'il est possible de gerer. Resultat un systeme branlant et difficilement maintenable. Ce que fait systemd, mettre une API claire en dbus au milieu.
C'est comme la libc, on n'a pas tous la meme, mais l'API a globalement converge. Donc maintenant la seule vrai dependence, c'est dbus. Le reste c'est un choix de distrib. Et on s'en fiche de l'independance des briques tant qu'on a une API claire et qu'on peut faire les wrapper que l'on veut.
Il y a une difference entre le fait que le dev principal n'en ai rien a faire de BSD et soit un communicant specialise dans la polemique. Si ca ne l'amuse pas de demarrer un BSD pour essayer de faire tourner son soft dessus, bah, rien ne l'y force. C'est a ceux qui utilisent cet OS et qui veulent voir ces fonctionnalites de se bouger (En plus, c'est pas comme si c'etait une boite noire, il y a de la doc, du code et meme pour certains morceaux des specs).
Et en meme temps le projet en lui meme n'empeche personne de proposer des patchs pour le rendre portable. Donc c'est encore un raccourci, Lennart == systemd && Lennart != portabilite donc systemd != portabilite. C'est une insulte a tous les gens qui ont contribue a systemd deja. Ensuite c'est revele a quel point on ne comprend pas le logiciel libre et que on a le droit de se bouger pour regler le probleme.
Je ne vois pas en quoi. J'ai l'impression que tu fais un raccourci distribution == Linux. Alors que Linux n'est qu'un noyau utilise dans beaucoup de distribution. Mais les BSD sont tout autant des distributions et je n'y vois aucune difference. Donc peux-tu ettayer ton propos et me dire en quoi il est linuxo-centric ?
[^] # Re: Paris (SG) c'est cher aussi
Posté par cedric . En réponse au journal Il était une fois, un petit pas... Maintenant, c'est 6 grandes roues !. Évalué à 3.
L'interet des JO, ce n'est pas pour la science medical et l'optimisation des performances humaines ? Ah, on me signale que cela peut deraper …
[^] # Re: Petit rappel historique
Posté par cedric . En réponse au journal Quel avenir pour Qt ?. Évalué à 4.
La multiplication par 10 des ressources sur un projet ne multiplie pas la vitesse de developpement par 10. Reciproquement, ca division par 10, meme si a court terme va desorganiser le projet, ne peut que tendre vers une moindre bureaucratie et une plus grande efficacite. Cela veut aussi dire qu'il va y avoir logiquement une volonte d'avoir un code plus maintenable dans le temps donc plus lege. Par contre, il y aura probablement moins de support des vieilles version et un focus sur uniquement la prochaine version. Tout depend des ressources restantes et de leur competences.
Pour information, n'oubliez pas que GTK, c'est globalement une personne et les EFL une vingtaine. Donc meme si ils perdent tous les contributeurs Nokia (ce qui est peu probable, car un certain nombre trouvera du boulot ailleur dans le meme domaine), ils auront toujours plus de contribution que leurs principaux concurrent libre.
Qt a un enorme momentum et ce n'est pas les decisions de Nokia qui le tueront. Sur le long terme, ils dependront nettement plus de la communaute et d'une bonne gestion ouverte… Mais ca, ce n'est deja plus Nokia qui decide.
[^] # Re: Triste opinion de la convergence
Posté par cedric . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 5.
La premiere raison est une question de coup, pourquoi est-ce que tu acheterais un telephone, un desktop/laptop, une console et une set top box, quand au final ceux dont tu as besoin c'est juste un processeur, des ecrans et peripheriques d'entree adaptes. Si en plus tu rajoutes a ca que ton telephones est subventionne… Pourquoi depenser plus si il est capable de se connecter a n'importe quel ecran et clavier/souris ? Je prend le parie que les gens laisseront definitivement tomber massivement le desktop pc dans ce cas la. La question est a quel echeance est-ce que le hardware sera capable d'etre competitif ? Deja aujourd'hui un Galaxy S3 est plus performant qu'un netbook et a une connectique hdmi/usb/bluetooth. Il manque que le software…
Il n'y a pas de negligence de l'environnement de travail, la strategie de microsoft dans ce domaine quand elle est regarde avec cet angle de vue, prend tout son sens. Il vise les entreprises qui fournissent des laptop pour l'instant a leur employe. Demain, si ils sont capable de fournir un OS qui s'integre aussi bien en mode desktop (telephone connecter a un dock desktop) que en telephone dans le reseau d'entreprise, ils peuvent potentiellement reprendre pied dans le domaine des smartphones.
Ce qui est important de comprendre ce n'est pas parce que ton interface a un look mobile sur un touch screen qu'elle doit necessairement avoir un look mobile sur un desktop. C'est la ou la difference d'implementation va se faire. La meme application mail peut avoir deux look completement differents et adapte a l'ecran (AMOLED vs LED LCD), a la distance de visualisation et au dpi, a la precision du pointeur (souris ou doigt), le tout sans changer le code. Le plus important est que le code reste identique de maniere a pouvoir plus facilement acceder aux memes informations.
Pour bien comprendre l'idee prenont l'exemple de LibreOffice Impress. Le telephone est plugge dans son dock. Il s'affiche donc sur ton ecran de PC tout comme aujourd'hui. Tu peux editer le contenu normalement, il n'y a aucune difference. Maintenant, tu l'enleves du dock. La, il se retrouve contraint sur un petit ecran de telephone, donc il passe en mode lecture seule. Il te permet d'aller d'une page a une autre, mais plus d'editer, toute l'interface est dedie a la lecture. Puis tu le connectes a un video projecteur, le telephone le detect, transforme l'ecran de telephone en telecommande et demarre la presentation. D'un bout a l'autre, c'est la meme application, le meme code, juste les informations affiches a l'ecran et la maniere d'interagir change.
Ceci est juste un exemple. Tu peux decliner les scenarios avec un client mail, un lecteur multimedia, un navigateur web, un client IM, un jeu …
Le probleme que tu pointes vient principalement du fait que le projet GNOME n'a pas d'equivalent a ce que Edje ou QML permettent. C'est a dire une separation clair entre layout/theme et code. Cela rend la tache de designer une application multi mode tres difficile et donne le resultat qu'on connait aujourd'hui. Mais ca, c'est un probleme d'implementation pas de concept.
Ce concept pose par contre de tres gros challenge en terme de securite, de vie prive et surtout de survie du logiciel libre ! Si demain le marche du desktop/laptop se reduit comme peau de chagrin et qu'il faut acheter une machine specifique pour pouvoir faire du logiciel libre, car il n'existe pas de telephone libre, alors ca sera problematique…
[^] # Re: Triste opinion de la convergence
Posté par cedric . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 4.
Enlightenment se porte tres bien en haut dpi. On est parfaitement capable de faire la difference entre les elements lisibles par l'utilisateur qui necessitent d'etre agrandit et les elements de decors qui ne doivent pas l'etre. D'ailleur lors de la premiere utilisation, tu as une boite de dialogue qui te demande de choisir le scale ratio qui te convient le mieux via une petite preview de ce que donnera l'interface avec ce ratio. Cela permet de choisir le aspect en fonction du dpi et de la distance lorsqu'on n'a pas les characteristiques du constructeur. Donc nop, Linux n'est pas a la traine dans le domaine !
# Triste opinion de la convergence
Posté par cedric . En réponse au journal GNOME 4.0 et GNOME OS prévus pour 2014 : abandon du pc, (même si on en était pas loin avec Gnome3). Évalué à 10.
Serieusement, ce n'est pas parce que GNOME et Unity ont merde leur convergence que c'est forcement mal d'avoir un tel objectif. Surtout que les telephones mobiles tant a manger de plus en plus de processeur dans la maison. Et il y a de bonne raison pour ca. En moyenne on en change tous les deux ans, la plus part des equiments electroniques et electrique de la maison, c'est plutot dix ans ou plus (TV, console, mais aussi frigo, machine a laver, voiture). Certains equipements ont une duree de vie encore plus longs, compteurs electriques, gaz, eaux, … Quelques uns ont une vie que legerement plus courte environ 5 ans, imprimantes, scanner, …
De plus deja aujourd'hui les smartphone sont capable de se connecter a des peripheriques bluetooth, a un hub USB et a un ecran en HDMI. Demain ce sera en Wireless Display. Un Samsung Galaxy S3 a plus de pattate niveau CPU/GPU qu'un ordinateur milieu de gamme d'il y a 4 ans. Et ils suivent la loi de moore.
Pour quel raison est-ce que j'aurais besoin de me trimbaler avec mon laptop alors que j'ai deja un processeur suffisament puissant dans ma poche ? Pourquoi je ne peux pas directement l'utiliser en le connectant a un ecran de PC ? Ou a un video projecteur ? Ou a une TV ?
La reponse est simple, c'est qu'aucun constructeur n'est encore venu sur le marche avec une technologie qui adapte le rendu de l'interface a la resolution, au dpi, a la distance de visionage et a la precision du peripherique d'entree. Mais pour le coup, le logiciel libre est en avance de ce cote la.
Le projet Enlightenment integre ces technologies, et c'est le but depuis des annees, directement dans le coeur de son infrastructure. Il est possible d'avoir une interface qui s'adapte completement aux peripheriques d'entree et de sortie utilise. D'avoir une application mail qui passe automatiquement de l'ecran de telephone au PC en s'adaptant automatiquement pour passer d'un simple mode liste au mode plus classique des mailers PC. Ce concepte est pour l'instant experimente dans Enna uniquement, mais l'infrastructure et les fonctionnalites sont la.
Il est important a mon sens de se rendre compte que le telephone mobile a aujourd'hui suffisament de puissance pour remplacer n'importe quel netbook et etre competitif avec les laptops bas de gamme. Il est important que le logiciel libre s'en rende compte et ne loupe pas cette etape. Car si demain nos ordinateurs deviennent aussi ferme que iOS et Android, nous aurons l'air malin avec nos logiciels libres.
Il nous faut aujourd'hui des solutions libre, plus efficace, plus legere, plus performante que ce que peut faire iOS, Android ou Windows. Car quand les usages seront vraiment possible et que l'on pourra faire le switch, probablement en 2015, soit on est pret, soit ce sera fini. Donc je trouve que c'est une tres bonne nouvelle que GNOME, tout comme KDE et le projet Enlightenment se prepare a ne pas louper se tournant. Apres les choix techniques et l'implementation sont une autre discussion, mais c'est deja une bonne chose en soit que personne ne loupe cette etape.
[^] # Re: Vendeurs de téléphone
Posté par cedric . En réponse à la dépêche Hadopi, Acte II : Vers l’économie de la connaissance. Évalué à 10.
Le probleme n'est pas la technologie. C'est certain qu'on a les competences en Europe pour faire un telephone et j'espere que Jolla reussira a le montrer. Non, le veritable probleme, c'est que l'industrie europeenne est sclerose. Bloque dans un monde du passe. Le management se bat plus pour prendre la place du chef que pour ecraser la concurrence. Il n'y a pas de prise de risque. Pas de comprehension qu'on vit dans un monde qui change. Les grandes societes europeennes sont dans leur tres grande majorite tue par un management individualiste, sans envergure et imbut d'eux meme.
Le cas de Nokia en est un tres bon exemple. Ils ont rachete Trolltech en 2008, et ils ont mis plus de 3 ans pour realiser leur premier telephone. La raison, c'est quand interne, le management de Symbian ne voulait pas perdre de pouvoir, donc a accapere des ressource Qt inutilement. Meme chose avec une partie de l'equipe de Maemo. Au fina, ils ont passe plus de temps a se foutre sur la tronche qu'a faire un produit pour rivaliser avec la concurrence. Forcement a un moment donne, les actionnaires ont pris un arbitre charge de faire le menage. Arbitre qui ne peut pas avoir confiance dans les informations de ses troupes et qui est oblige d'aller chercher ailleur pour avoir une solution. Il aurait pu aller chercher chez Google, mais ca, c'est un autre debat.
Ce scenario pour l'avoir discute avec des amis qui travaillent dans d'autre branche de l'industrie (automobile, train, electrique, telecom), se repete inlassablement. Notre probleme, c'est les ecoles et la mantalite des manageurs de l'industrie europeenne. Ca ne changera pas. La seule bonne nouvelle, c'est que les entreprises asiatiques souffrent du meme probleme, voir pire, car il y a culturellement un pouvoir lie a l'age que nous avons moins en europe. Donc quand le coup du travail aura suffisament augmente, l'asie sera aussi ininterressante que l'europe. Je ne connais pas assez le reste du monde pour me prononcer.
Le probleme, c'est l'incapacite a prendre des risques, assumer des choix techniques en opposition avec les buzzword du moment et ca ca implique des managers courageux… C'est devenu un probleme culturel avant d'etre un probleme industriel. Je comprend de mieux en mieux pourquoi Steve Jobs a reussi a faire de Apple une societe aussi differente.
[^] # Re: Distrib pour developpeur
Posté par cedric . En réponse au journal Mon point de vue sur Archlinux. Évalué à 2.
En meme temps l'utilite de ces packages est tres limite, car la premiere chose dont tu as besoin si tu veux faire une session de debuggage correct, c'est d'etre sur la derniere version du trunk du projet (ou de la branch stable). Recuperer les symboles de debuggage sur un truc ancestral, je vois pas l'interet.
Ce qui serait plus utile, c'est d'avoir une version de developpement et une version de production pour les bibliotheques. La version de developpement activant tous les checks evitant les plantages et donnant des informations precisent aux developpeurs. La version de production prenant tous les raccourcis et pouvant amener des jolis SEGV plutot qu'un morne message d'erreur.
Ca serait deja plus utile pour les developpeurs utilisant ces bibliotheques. A la rigueur pour faciliter le debogage la version de dev devrait inclure les symboles de debug. Mais bon, je ne connais aucune distrib qui fait ca…
[^] # Re: Et pourquoi systemd ?
Posté par cedric . En réponse au journal Mon point de vue sur Archlinux. Évalué à 6.
Tu as fait la comparaison ? J'ai un boute en 4s avec systemd au lieu de 40s avec l'init classique. Et oui, ca demarre le meme nombre de service et ca fait exactement la meme chose…
Meme pas, c'est deporte sur les developpeurs upstream qui fournissent une unit pour leur projet. Ca evite que les distribs ou les utilisateurs ne fassent trop n'importe quoi. Ca permet de faire le boulot une fois pour absolument tout le monde. Les unit systemd etant nettement plus portable que les scripts d'init…
Maintenant compare la complexite entre apprendre le shell script et le systeme de demarrage de ton systeme a la complexite d'un fichier unit qui sera terme fourni par la majorite des projets upstream. C'est sur faut changer ses habitudes et apprendre un truc nouveau pour ceux qui savaient deja de quoi on parlait.
C'est juste une periode de transition.
# Distrib pour developpeur
Posté par cedric . En réponse au journal Mon point de vue sur Archlinux. Évalué à 7.
ArchLinux fait pour moi parti de ces distribs qui sont ideals pour les developpeurs. Respect de l'upstream. Pas de patch aleatoire. Pas de paquet casse comme sur Ubuntu et Gentoo qui empeche la compilation. Pas de separation paquet de developpement/paquet princicipal. Possibilite de suivre directement le svn/git/… Excellente documentation.
Alors forcement, si c'est une distrib pour les developpeurs, c'est logique qu'elle suive ce que les developpeurs font et qu'elle aille vers ce qu'ils preferent.
# Vieux barbus
Posté par cedric . En réponse au journal Arch et le tournant. Évalué à -5.
Oh, un troll de vieux barbu ! Et oui, c'etait mieux avant ! Evoluer, c'est le mal !
Je pense avoir bien resume l'attitude generale de ce journal…
[^] # Re: empeche ou permet
Posté par cedric . En réponse à la dépêche Sortie du noyau Linux 3.5. Évalué à 3.
Probablement un mode de veille avant le suspend complet. Certain processeur ARM sont capable de couper quasiment toutes leurs unites interne excepte les registres, le cache et la TLB. Cela permet de consommer beaucoup moins tout en maintenant le systeme parfaitement reactif et multitache. Il faut par contre que les applications et le systeme gere les choses correctement, car sinon c'est un bon moyen de se reveiller trop souvent et de tuer la batterie.
[^] # Re: Applications ?
Posté par cedric . En réponse à la dépêche Enlightenment 0.17 a un release manager. Évalué à 4.
Challenge interressant, mais l'architecture de E17 est nettement plus optimise que E16. La difficulte sera surtout de trouver le meme theme que E16 et de comparer a effets egaux. Et on tourne toujours sur des pentiums MMX, certains testent encore :-D
[^] # Re: Applications ?
Posté par cedric . En réponse à la dépêche Enlightenment 0.17 a un release manager. Évalué à 7.
Ca viendra en son temps aussi. Il y a peu d'interet a refaire un nieme navigateur web ou un nieme client mail, si en plus de l'integration, il n'apporte pas quelque chose de neuf. On a des idees, des projets.
Terminology est la premiere application sur laquelle on va explorer ces nouvelles idees. Un nouveau concept pour les tabs, la notification, l'integration de fonctionnalite exterieur. Une fois que ces fonctions seront operationnelles, elles seront merge dans la bibliotheque de widget et on attaquera surement un navigateur web. Mais ca je ne le vois pas arriver avant l'annee prochaine vu la taille de notre equipe actuelle.
Pour un client mail, les idees ne manquent pas. Je recommande la lecture de l'ebook de Brett Victor qui contient de tres bonnes idees ainsi que ce lien : http://www.vanschneider.com/work/mail/. En lien supplementaire, je rajouterais aussi : http://notmuchmail.org/. D'un point de vue architecture, reecrire et gerer tous les protocoles mails est une tache, lourde, complexe et peu gratifiante, car deja fait et sans trop de plus valu a priori. Ce qui compte, c'est surtout d'etre capable de naviguer rapidement et efficacement dans ses maildirs, d'afficher tous ses mails, de pouvoir en ecrire et de donner du contexte a l'ensemble des information.
En fait, l'interface graphique a tout interet a devenir une suite de communication et pas uniquement un afficheur de mail. La, il y a beaucoup de chose que l'on peut faire qui peuvent etre nouveau. Donc l'idee actuel serait de se baser sur un daemon qui remplit gentillement un maildir en tache de fond et un front end qui ne fait que de l'affichage et de la manipulation de donnees. Cela simplifiera surement grandement l'ecriture d'un tel client. Il faut maintenant trouver un bon daemon pour nous remplir nos maildir… Mais pareil, cet effort ne commencera surement pas avant que E17 et Terminology ne soit release. En attendant, on reflechit, trouve des outils qui nous permettront quand on s'y attaquera d'avancer efficacement.
[^] # Re: Applications
Posté par cedric . En réponse à la dépêche Enlightenment 0.17 a un release manager. Évalué à 1.
La tres grosse difference avec TermKit, c'est qu'on utilise l'infra existante et tous les binaires utilisant un terminal. A l'oppose, TermKit reecrit tout…
[^] # Re: Applications ?
Posté par cedric . En réponse à la dépêche Enlightenment 0.17 a un release manager. Évalué à 4.
Le "Desktop Shell" se limite principalement a offrir un window manager tres configurable avec un bon file manager et un certain nombre de "sonde" sous forme de plugins. Pas de client mail, irc, im, web, office… Donc en gros pas d'appli, mais des gadgets pour savoir combien de mail en attente, les news, l'etat du reseau, …
[^] # Re: Applications ?
Posté par cedric . En réponse à la dépêche Enlightenment 0.17 a un release manager. Évalué à 10.
Euh, comparer E16 et E17, ca n'a juste rien a voir. E17 aujourd'hui n'a pas une seule ligne en commun avec E16. Il est aussi plus performant que E16 (Mais ca ce n'etait pas tres difficile).
Pour le cote configurable, j'avoue ne pas comprendre ta remarque. C'est un des windows manager les plus configurable. On peut configurer la disposition des fenetres par bureau virtuel. L'un en tile, un autre classique. On peut attacher des bindings claviers ou souris a toutes les actions. Tous les modules peuvent etre active ou desactive a la demande de l'utilisateur et il est tres simple d'ecrire son propre module. De ce cote la, je pense qu'on n'a pas a rougir de la concurrence !
Pour ce qui est du theme par contre, c'est clair que celui par defaut est moche ! C'est pas comme si on pouvait en changer facilement, mais avoir un theme complet et joli ca prend du temps. Si il y a des designers motives pour nous aider, la porte est grande ouverte. La plus grande difficulte pour nous, c'est de faire les graphismes, modifier le theme est facile apres. Donc si quelqu'un veut proposer un nouveau theme par defaut, on attend vos idees. A vos GIMP et Inkscape :-)
Ensuite, E17 n'est pas GNOME ou KDE, c'est a comparer plutot avec kwin ou Compiz…
[^] # Re: Applications
Posté par cedric . En réponse à la dépêche Enlightenment 0.17 a un release manager. Évalué à 10.
Je note un certain manque d'imagination. Tout d'abord les effets speciaux sur le curseur, ca permet de toujours le retrouver rapidement. Les videos et images, permettent certe de completement customiser son terminal, mais cela ouvre surtout la porte a une preview rapide de tous les fichiers sans application externe.
Il est tant de repenser les limites de son terminal…
[^] # Re: Applications ?
Posté par cedric . En réponse à la dépêche Enlightenment 0.17 a un release manager. Évalué à 10.
Alors non, "Desktop Shell" n'a pas ete invente car on manquait de ressource. C'est la ligne directrice de E17 depuis le debut. Avoir un window manager, leger, souple, tres configurable. Les EFL ne sont qu'un effet de bord de cette objectif.
En fait, l'existence des EFLs, montre un gros disfonctionnement dans notre communaute. A chaque fois que quelqu'un veut faire une application, il commencait par faire la bibliotheque generique et reutilisable. L'application venait ensuite, peut etre… Resultat, on a un toolkit tres complet et efficace, mais peu d'application !
Le developpement de E17 a aussi ete complique par cette manie. A chaque fois qu'on ecrit un petit bout de code, on se rend compte qu'on pourrait le partager et qu'il serait utile a d'autre. Hop, une lib ! Resultat 10 ans pour faire un window manager… Ca finit par payer en terme de developpement de nouvelle fonctionnalite, de performance et de souplesse. Mais ce qui attire les developpeurs en general, c'est les applications. Ceux sont les entreprises qui sont attirees par les bibliotheques.
Raster regrette d'ailleur de ne pas avoir fait prendre au projet une orientation "Desktop" plus tot que "Desktop Shell". C'est aussi une des raisons de cette release de E17. Ce refocaliser sur les applications… Mais ce sera plus qu'un environement de bureau, car fonctionnant sur tous vos terminaux (telephone, tv, pc, …). Et ce sera le meme code sur chaque terminal, ce qui ouvre la porte a une plus grande cooperation entre les developpeurs des differents environnements… On verra bien ce que cela donnera !
[^] # Re: Applications
Posté par cedric . En réponse à la dépêche Enlightenment 0.17 a un release manager. Évalué à 10.
Tout a fait d'accord avec l'analyse de Aaron. Il est preferable d'avoir le moins de process possible pour economiser des ressources. Et le code source xterm et urxvt est effectivement en mauvais etat du fait de son age.
Mais bon, ici on parle de deux chose, consommation memoire et performance. Tout d'abord pour les performances, le benchmark utilise est "time cat http://www.gutenberg.org/files/100/100.txt" (Le fichier etant en local sur la machine, et le temps retenu est le plus faible apres plusieurs lancement). Le resultat est sans appel, le temps d'execution est du plus grand au plus petit: Linux console > GNOME Terminal (et tous les utilisateurs de libvte) > Konsole > xterm > urxvt & Terminology.
Terminology : 2Mo dans le tas, 136K dans la stack
urxvt: 2.4Mo, 136K dans la stack
konsole: 3Mo dans le tas, 136K dans la stack (avec 4 tabs, on passe a 3.6Mo)
Conclusion pour l'instant, Aaron a raison, il y a plus de donnee partage dans konsole avec des tabs que dans urxvt. Donc assez rapidement, konsole prendra l'avantage sur urxvt. Il n'y a pas de tab pour l'instant dans Terminology, mais une partie des ressources peuvent etre mise en commun grace a CServe2 entre toutes les instances (Image et glyph de font). Cela genere une economie de 1.5Mo par instance, le cout d'un nouveau Terminology etant de 500K. On n'est plus tres loin de ce que fait Konsole avec ces tabs, mais sans tab on ne pourra pas faire beaucoup mieux.
Mais bon pour ces 500K, vous avez un terminal qui fonctionne en frame buffer, sous wayland et X (en soft ou avec acceleration OpenGL) sans aucune modification. La version frame buffer peut suivant les machines etre en 10 et 50 fois plus rapide que la console Linux par defaut. Il est presque fonctionnel sur touchscreen (manque le scroll back au touch).
Mais le fait d'avoir un toolkit complet ouvre des possibilites nouvelles. Pour le meme prix, vous avez le droit a la preview des images et des videos directement dans Terminology sans lancer d'application. Il suffit de cliquer sur un chemin, et si c'est une image, un pdf, une video, vous avez directement un player d'afficher. Il reste a maintenant patcher tous les outils classiques pour qu'il detecte Terminology et emettent un code d'echapement permettant d'avoir cette fonctionnalite de disponible partout. L'idee etant que dans mc, vous cliquez sur un fichier image et ca l'afficher instantanement. Pareil, une url dans mutt ou irssi vers une image, et ca vous l'affichera d'un simple click, pas besoin de lancer un browser pour.
Bon, et tout ca, ca a pris combien de temps ? Et bien Terminology a tout juste un mois ! Il a recu les contributions d'une dizaine de developpeur durant ce laps de temps. On a passez beaucoup de temps a ecrire les bibliotheques, mais aujourd'hui se framework se revele extremement productif ! Il est probable qu'on puisse finaliser Terminology (sans tab) pour la release de E17.
[^] # Re: Second degré...
Posté par cedric . En réponse au journal Quand Linus énervé, Linus faire ça !. Évalué à 8.
Ou nettement plus certainement de leur manager malheureusement…
[^] # Re: mes 2 cents
Posté par cedric . En réponse au journal Leap Motion, révolution ou I2BP-like ?. Évalué à 3.
Peut etre parce que techniquement, ca semble jouable d'arriver a un resultat correspondant a la video contrairement a I2BP…
[^] # Re: mes 2 cents
Posté par cedric . En réponse au journal Leap Motion, révolution ou I2BP-like ?. Évalué à 6.
Il y a une difference majeur avec Kinect, c'est que tu te trouves a petite distance, juste au dessus du capteur. Un bon eclairage infrarouge et deux camera de bonne definition elimineront beaucoup de bruit deja. Ensuite pas la peine de reconstituer tous un corps, mais ici il n'est necessaire que de caler le nuage de point sur une main d'une forme generique. Ca permettra de differencier directement les doigts par la meme occasion. Je pense qu'en prenant suffisament de raccourci ca doit pouvoir passer pour cet usage.
[^] # Re: Irrémédiable
Posté par cedric . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 5.
Sauf que uniformiser les API est une bonne chance. La situation actuelle, c'est plein de patch plus ou moins bon par distrib difficilement maintenable plus un peu de biniouterie upstream pour gerer ce qu'il est possible de gerer. Resultat un systeme branlant et difficilement maintenable. Ce que fait systemd, mettre une API claire en dbus au milieu.
C'est comme la libc, on n'a pas tous la meme, mais l'API a globalement converge. Donc maintenant la seule vrai dependence, c'est dbus. Le reste c'est un choix de distrib. Et on s'en fiche de l'independance des briques tant qu'on a une API claire et qu'on peut faire les wrapper que l'on veut.
[^] # Re: Irrémédiable
Posté par cedric . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 4.
Il y a une difference entre le fait que le dev principal n'en ai rien a faire de BSD et soit un communicant specialise dans la polemique. Si ca ne l'amuse pas de demarrer un BSD pour essayer de faire tourner son soft dessus, bah, rien ne l'y force. C'est a ceux qui utilisent cet OS et qui veulent voir ces fonctionnalites de se bouger (En plus, c'est pas comme si c'etait une boite noire, il y a de la doc, du code et meme pour certains morceaux des specs).
Et en meme temps le projet en lui meme n'empeche personne de proposer des patchs pour le rendre portable. Donc c'est encore un raccourci, Lennart == systemd && Lennart != portabilite donc systemd != portabilite. C'est une insulte a tous les gens qui ont contribue a systemd deja. Ensuite c'est revele a quel point on ne comprend pas le logiciel libre et que on a le droit de se bouger pour regler le probleme.
[^] # Re: Irrémédiable
Posté par cedric . En réponse au journal Gnome3 et systemd, c'est la fin des haricots!. Évalué à 1.
Je ne vois pas en quoi. J'ai l'impression que tu fais un raccourci distribution == Linux. Alors que Linux n'est qu'un noyau utilise dans beaucoup de distribution. Mais les BSD sont tout autant des distributions et je n'y vois aucune difference. Donc peux-tu ettayer ton propos et me dire en quoi il est linuxo-centric ?