> Autant d'un coté rendre cette mesure obligatoire est stupide notamment pour les gens qui ont des IP dynamique, mais aussi pour les gens qui voyages beaucoup.
C'est bien l'objet de mon énervement : c'est une mesure obligatoire qui n'est pas désactivable par le panneau d'administration. De plus, elle a été mise en place sans aucun mail d'avertissement ou d'explication.
> D'un autre coté on ne peut nier que limiter les connections qu'a certaines IP renforce la sécurité.
Je ne le nie pas et je comprends tout à fait la nécessité de ce genre de sécurité pour certains utilisateurs. Mais pour moi cela n'est qu'une gêne.
> Fin bref au lieu de pleurnicher ici tu devrait plutôt argumenter sur le problème des IP dynamiques, tu n'est très certainement pas le seul dans ce cas chez cet hébergeur.
pleurnicher ?? D'où tu sors ça ? C'est un journal, j'écris mes réactions à ce que j'estime être un manque total de respect par un hébergeur envers un client. C'était également dans le but de savoir si des lecteurs avaient déjà fait l'expérience de ce genre de situation, et si oui, comment ils l'avaient résolu.
Si cela trouble ton dimanche, passe ton chemin.
Techniquement il n'y a pas de changement dans le contrat parce que ce type de détails n'est pas marqué noir sur blanc dans les conditions d'utilisation.
Mais c'est en effet ce que j'ai vérifié en premier.
Merci pour la proposition sur toile-libre.org, j'y penserai pour mon prochain hébergement :)
> Ouais mais bon, ce serait ridicule d'en arriver là !
Oui et c'est bien ce que je reproche à l'hébergeur. je me doute bien que des solutions seraient envisageable pour contourner de près ou de loin cette restriction, mais je pars du principe que ça ne remplacera jamais ce pourquoi j'avais souscrit initialement, à savoir un accès SSH/SFTP sans restrictions.
> Utopiquement, le mieux serait de faire annuler le contrat parce que les conditions d'utilisation ont changées !
Les conditions d'utilisations ne portent malheureusement aucune mention précise à ce niveau. Il est seulement fait référence au SSH comme d'un service inclus dans l'offre d'éhbergement, sans plus de détails.
Par contre, il est clairement marqué qu'aucun remboursement n'aura lieu passé le délai de 7 jours. Comme cela fait plus de 6 mois... je pense que ce n'est pas applicable.
Je plussoie le commentaire précédent. Une des grosses qualités de Source est d'être plutôt optimisé, et adaptable à la dernière carte high-tech, comme au PC d'il y a 4 ans. Et d'ailleurs il n'est plus nécessaire d'avoir cette "dernière carte high-tech" pour faire tourner un jeu basé sur Source avec les graphismes au maximum.
Mon portable dont le modèle date de 2007 fait parfaitement tourner L4D en détails max. Essaye ça avec un jeu du même âge que L4D, tu n'auras certainement pas les mêmes résultat.
Ben apparemment c'est justement ça qui est intéressant. Il devrait y avoir tous les jeux basés sur Source directement utilisables, partant du fait que c'est ce moteur qui a été porté sous OSX et Linux.
Je pense que nous avons affaire à la plus grande révolution du jeu vidéo sur Linux. Même si on aurait préféré que ça soit avec des jeux... libres eux-aussi, je me contenterai de voir qu'une tripotée d'excellents titres deviennent disponibles autre part que sur Windows (et OSX, mais pour ce que j'en connais...).
Je suis absolument étonné (y'a quoi de plus fort qu'étonné, parce que ça le vaudrait) de voir que personne n'a encore rappelé l'utilisation du "+" magique.
Ben oui, recherchez "+lapins" sur Google et vous chercherez que des lapins. Maintenant enlevez le "+" et vous aurez des lapins singuliers (enfin... j'me comprends...).
Je dois ajouter que ça s'applique aussi aux expressions entre guillemets quand on le place avant le premier guillemet justement ? Allez non.
Oui c'est même plus simple que ça. Comme je le dis plus haut, eyeNav utilise par défaut une simple iframe, un élément HTML qui permet d'afficher une page... au sein d'une autre page. Mais rien ne passe par le serveur eyeOS ici. C'est un peu comme si un onglet de ton navigateur s'ouvrait dans un espace au milieu d'un page déjà ouverte. Les cookies et tout le reste s'appliquent à cette page interne.
En conclusion, eyeNav n'est pas un vrai navigateur. Mais il offre l'avantage de sauvegarder ses favoris et de les rouvrir tout en restant dans l'environnement du bureau eyeOS.
Je viens de remarquer une erreur d'environ 365 jours concernant le début de ma participation au projet. C'était en août... 2007 ! Et pas 2006 comme je l'ai marqué dans mon message.
Cela fait donc un an et demi environ aujourd'hui. Veuillez pardonner cette négligence, je n'ai pas eu la chance de participer à la série 0.x du projet, mais uniquement 1.x.
Excellent ! Je l'avais installé il y a un certain temps, il faut reconnaître qu'il a fait un bon bout de chemin depuis!
Oui ! J'ai eu la chance d'arriver au bon moment me semble-t-il, le projet venait juste d'avoir sa base stabilisée grâce au boulot de deux passionnés catalans.
Je développe à mes heures perdues un client jabber en javascript [...] Je me demandais si ça pouvait avoir un intérêt à être intégré dans ce genre de projets, sous forme d'applis.
Bien sûr que oui ! Ce genre d'application est extrêmement intéressant pour le projet ! Je t'encourage très fortement à regarder un peu comment sont construites les applications eyeOS et à en créer une pour ton client Jabber. Au début tu peux te limiter au plus simple, sans arrangement graphique pour coller au reste, et tu le déposes sur eyeos-apps.org.
Nous n'avons justement pas de client Jabber par défaut pour l'instant, ton application pourrait très bien remédier à ça :)
Ne t'inquiète pas pour les librairies JS additionnelles, chaque application peut charger les scripts nécessaires à son exécution. Le problème risque de se poser si une autre application a besoin des mêmes librairires (mais non-modifiées, dans ton exemple avec Mootools) pour fonctionner. On risque d'obtenir un résultat assez... aléatoire.
Dans tous les cas, ça ne coûte rien d'essayer (à part un peu de temps).
L'échange entre le JS et le PHP, c'est du JSON ? de l'XML ?
Que ce soit entre JS => PHP ou PHP => JS c'est de l'XML.
Côté JS un moteur maison se charge de parser les réponses et de lancer les tâches à effectuer.
Côté PHP, la requête est traitée selon ses variables GET et des paramètres additionnels peuvent être passés par XML.
Dans la série 1.x en service aujourd'hui, de nombreuses librairies JS ont été faites from scratch ou pas loin.
Mais j'hésite à dire que le plus gros soit côté JS. Le javascript gère la couche "présentation" comme on dit. C'est elle qui affiche et dispose les éléments, reçoit les actions utilisateur, et les transmet à la partie contrôle. C'est un gros boulot effectivement, mais ça reste de l'affichage.
La partie contrôle doit dialoguer avec cette partie affichage, mais également gérer l'exécution des applications, le routage des messages, la gestion des droits utilisateurs, les opérations sur le système de fichiers, etc. Et ça c'est un autre gros boulot !
Donc dans eyeOS, je pense que le plus gros du système reste situé côté PHP, même si le noyau JS représente une part évidemment non-négligeable.
Dans la version 2.0 en préparation, la gestion des widgets (boutons, champs, fenêtres, etc.) devrait être assuré côté JS non plus par une librairie développée en interne, mais par Qooxdoo, un framework Javascript très puissant, très complet et très extensible. Mais ça c'est une autre histoire...
Je ne suis pas non plus un fan du web2.0 et je suis un peu parano alors confier mes données perso à un serveur tiers, pas question mais c'est très bien réalisé.
Merci, ça représente un boulot assez conséquent !
Concernant ta remarque sur le stockage de donnée perso, c'est justement là qu'eyeOS représente une alternative à toutes ces applications priv[ées/atives] !
Le serveur eyeos.info est accessible à tout le monde, et effectivement là, il n'y a pas de contrôle direct des utilisateurs sur leurs données. Libre à chacun de s'inscrire et de l'utiliser en "prenant le risque" (comme on "prend le risque" d'utiliser Facebook, GoogleDocs, Gmail, etc.).
Mais ce n'est pas tout ! Et c'est ÇA qui m'a attiré quand j'ai découvert le projet. Je ne suis PAS dépendant d'un serveur propriétaire situé je-ne-sais-où. Je télécharge le package eyeOS et je l'installe sur le serveur de mon choix, à la maison, sur un hébergement mutualisé, sur un hébergement dédié, etc. Je n'ai besoin que d'Apache et PHP. Et c'est encore mieux comme ça, puisque ça me permet de gérer l'administration d'eyeOS moi-même. Je garde ainsi un total contrôle des données stockées sur mon système eyeOS.
Vous proposez des solutions d'entreprise et tout le tralala ou c'est juste pour la beauté du code ?
Les solutions entreprises sont prises en charge par la société eyeOS (www.eyeos.com). Elle fournit le support, le développement et la maintenance d'applications tierces pour le compte de sociétés privées.
eyeOS propose une double licence concernant les développement spécifiques : dans le premier cas, la société devient propriétaire du source de ses applications/modules/etc et elle seule peut décider de son utilisation.
Dans l'autre, si les développement effectués présentent un intérêt pour la communauté libre, la société peut léguer ses droits sur le source et payera en contrepartie un prix plus faible que dans le premier cas.
C'est d'un certain point de vue gagnant-gagnant, notamment pour les administrations publiques qui sont prêtes, on le sait, à payer le moins cher possible, et qui n'ont que faire du source du logiciel fourni.
... mais sinon c'est aussi pour la beauté du code ;)
J'ai remarqué un bug assez choquant tout de fois (concernant le navigateur), si je l'ouvre et que je fais "précédent" cela fait faire "précédent" au "vrai" navigateur :(
Effectivement. Comme nombre d'applications AJAX, les appels aux boutons "Précédent" et "Suivant" ne font pas ce que l'on attendrait d'eux.
Je sais que les applications Google ont partiellement résolu ce problème, je note ça et je jetterai un oeil pour au moins "désactiver" ces boutons sous eyeOS (en attendant de trouver de meilleures actions en remplacement).
Merci de la remarque !
Effectivement le "navigateur" interne d'eyeOS ne propose par défaut qu'une simple iframe et donc aucun moyen d'anonymat puisque c'est le poste client qui effectue les requêtes et non le serveur.
La seule utilité de ce mode est de pouvoir sauvegarder ses bookmarks et de gérer les pages consultées au sein d'eyeOS, sans avoir d'onglets supplémentaires ouverts dans son navigateur.
Cependant, et bien que je ne l'ai jamais essayé, eyeNav propose un plugin de navigation basé sur anonymouse.org. Ce n'est plus alors le client qui effectue les requêtes, mais ce n'est pas non plus le serveur eyeOS. Le plus gênant ici est que bon nombre de proxys (notamment en entreprise) bloquent les accès à ces sites de surf anonyme.
Il n'y a donc pas de réelle solution pour le moment en considérant que les librairies de proxy PHP ne sont, pour la grande majorité, pas au point...
Malheureusement de nombreux "contributeurs" ont créé des packages pour avoir leur nom sur eyeos-apps.org en tant que "développeurs". Souvent ces personnes ne sont que des programmeurs peu expérimentés qui voient un projet en PHP et se disent "Je connais le PHP, je vais faire mon application".
Le résultat est souvent peu convaincant et parfois dangereux pour les utilisateurs comme pour le projet eyeOS qui perd en crédibilité, même si ces applications sont clairement présentées comme étant "tierce-parties" et dont nous ne pouvons vérifier le code de chacune par simple manque de temps.
Si je me rappelle bien, il y a aussi une application "eyeGmail", typique dans le genre des applications inutiles proposées par des personnes extérieures : une simple fenêtre avec une iframe pointant vers la page de Gmail...
Merci pour eyeSSH, j'avertirai le webmaster de eyeos-apps pour supprimer le package correspondant.
D'autre part, après avoir un peu testé eyeOS, et apprécié ses qualités, je regrette quand même qu'il faille en passer par son format de fichiers. Comme dit plus haut, on aimerait pouvoir accéder à toutes ses photos, son lot de musiques etc, sur un serveur perso.
C'est en partie pour cela que le service VFS (Virtual File System, mais plus que ça en fait depuis longtemps) est en passe d'être entièrement reconçu.
Nous avons reçu beaucoup de demandes dans ce sens là, et il est clair que l'intérêt est suffisant pour en prendre compte dans les prochaines versions.
Dans l'idéal, il s'agirait de recréer ce qu'on retrouve sur les vrais OS, à savoir des points de montage et des gestionnaires de protocoles qui permettent aux applications d'accéder aux données et de les manipuler sans savoir où elles sont réellement situées. Cela permettrait (comme je l'explique brièvement dans une réponse plus bas) de taper l'URL d'un server FTP dans le gestionnaire de fichiers, puis d'ouvrir un fichier texte avec l'éditeur en double-cliquant, de modifier le fichier et d'enregistrer. Simplement.
Et que ce fichier soit sur la machine locale (j'entends, le serveur), un serveur SSH distant, ou FTP ou autre ne serait d'aucune différence du point de vue de l'utilisateur. C'est ça "ouvrir eyeOS aux services du réseau". C'est un grand objectif mais assez complexe à mettre en oeuvre. Néanmoins nous y travaillons.
L'agenda va probablement subir un rafraichissement général lui aussi dans les versions à venir.
Encore une fois, c'est un projet relativement jeune, à qui on propose énormément d'idées mais dont les développeurs manquent de temps pour tout faire. Si vous êtes intéressé(e)s pour contribuer, n'hésitez pas !
avec LTSP, je bootais les machines sur une disquette, ca aller sur le reseau chercher l'OS et les applis qui etaient toutes stocker sur un serveur.
finalement eyeOS n'invente rien, on en reviens simplement à ce qu'oon faisait il y a 15 ans :D
À cela près qu'on trouve maintenant plus d'ordinateurs avec un navigateur et connectés à Internet, qu'avec un lecteur de disquette et la possibilité de booter dessus. Il y a une évolution, mais rien de t'empêche d'essayer d'utiliser LTSP sur le premier ordinateur que tu trouves.
eyeOS est encore au stade de PoC, même si c'est à grande échelle. Il y a quantité d'idées qui fleurissent sur le forum et d'utilisations possibles qui n'ont pas encore été implémentées. Nous avons les idées, mais nous manquons encore de doigts pour les réaliser.
Une chose également, la série 1.x d'eyeOS a jeté les bases de l'architecture, du concept et de la philosophie du projet. Mais elle a atteint depuis quelques temps les limites de son évolution, et il est apparu nécessaire d'apporter un changement dans le coeur du système afin d'en préserver son évolutivité et son actualité dans le monde du web d'aujourd'hui. C'est pourquoi une nouvelle version 2.0 est en ce moment même planifiée par la communauté, afin de voir le jour dans quelques mois. Elle devrait apporter de nombreuses améliorations par rapport aux limitations pré-citées.
Personnellement, je suis en charge avec deux membres de l'équipe "centrale", de concevoir et implémenter le nouveau module de gestion de fichiers. Il devrait permettre à terme, comme sous KDE notamment, de fournir au développeur d'application une transparence réseau avec les principaux protocoles, y compris ceux internes au système eyeOS. Cela ouvrira les applications eyeOS basées sur ce système (c'est-à-dire une grande majorité, voire la totalité à terme) à tous les services qu'on retrouve sur un réseau, en faisant jouer au serveur d'eyeOS le rôle de proxy pour toutes ces opérations.
La version en développement offre un gestionnaire de fichiers simplifié qui permet à l'utilisateur, par simple drag&drop, de transférer un fichier sur un serveur FTP depuis la fenêtre A vers un dossier sur le serveur local, ou sur autre serveur FTP distant sur la fenêtre B. À aucun moment bien sûr le développeur du gestionnaire de fichier ne fait référence au protocole qui est utilisé, et laisse le module système se charger des véritables opérations. C'est un petit exemple, mais je le assez parlant et plus user friendly qu'une commande dans un shell.
Salut à tous les lecteurs et rédacteurs !
Je suis les news de ce site depuis quelques temps déjà, et j'avoue que j'ai souvent eu envie d'ajouter mon petit grain de troll... pardon, de sel, dans les débats qui se déroulent ici. Mais ce journal m'offre là une occasion trop importante pour ne pas apporter quelques précisions au sujet. Mon compte créé, me voilà.
Je m'appelle Anaël et je fais partie de la communauté eyeOS en tant que développeur depuis un an et demi maintenant. J'ai découvert ce projet un peu comme beaucoup, par hasard, en cherchant un moyen esthétique d'accéder à mon serveur FTP maison et d'en gérer les fichiers (notamment les transferts) depuis un poste restreint. En l'occurrence : un de la fac.
Le projet alors était assez jeune et un faible nombre d'applications était disponible. Néanmoins, en jetant un oeil à l'architecture du système j'ai trouvé que ça tenait largement la route et que ça méritait d'être testé plus en profondeur. J'ai alors commencé à développer dans mon coin l'application qui allait devenir à terme le client FTP par défaut, j'ai nommé eyeFTP. J'ai rencontré de nombreuses difficultés pour bien prendre en main l'API et cerner le fonctionnement de l'engin, mais petit à petit mon ébauche a pris forme et j'ai proposé une version beta à l'équipe, qui n'avait d'ailleurs cessé de m'aider à chaque souci. Le résultat après plusieurs mois d'évolutions est l'application que vous pouvez trouver dans les releases d'eyeOS 1.5 et suivantes.
J'ai eu des contacts très réguliers avec l'équipe (basée à Barcelone) pendant tout ce temps, et elle m'est apparue extrèmement ouverte aux contributions et aux participations extérieures (original me direz-vous, pour un projet libre). J'ai finalement passé les mois d'avril à août de cette année au sein de l'équipe afin de les connaître et de participer au développement de ce qui, je pense, pourrait devenir le Linux des web OS. Car pas besoin d'être devin, mais ce genre de système, même s'il n'intéresse pas le geek moyen directement (qui a comme chacun sait, un serveur FTP, HTTP, VNC, SSH et j'en passe accessible 24/24 depuis le web*), va devenir une alternative intéressante pour les organisations telles que les établissements scolaires à court ou moyen terme (c'est déjà le cas, c'est pour cela que j'ai pris cet exemple).
Alors que dire d'un projet tel que celui-ci ? Le traiter de useless et no-future sans avoir pensé qu'il offre UNE alternative libre à un panel de projets dont peu peuvent réellement se vanter d'être aussi abouti quand ils sont libres, et aussi libres quand ils sont sous licences propriétaires ?
Si, comme je le pense, ce concept de bureau en ligne perce au niveau technique, philosophique et commercial dans les prochaines années, n'est-il pas intéressant que le monde du libre participe activement et revendique cette évolution ?
Il y a tant de choses à dire, mais je ne tiens pas à perdre des lecteurs avec un post de deux kilomètres. Je vais donc tenter de répondre (subjectivement bien entendu) aux quelques remarques qui ont été formées précédemment.
- Je soupçonne que ça tourne quand même vachement plus vite quand le site s'appelle localhost plutôt que quand il s'appelle www.chez-moi.com/ et qu'on a une connexion moyenne (voire lente).
C'est l'évidence même. Néammoins un fonctionnement normal ne requiert qu'une bande passante modeste. Mais bien sûr, si vous avez de gros fichiers à transférer ça risque de devenir moins réactif...
- J'ai essayé la démo pour voir, apparemment, il n'y a pas de lien entre le client mail et le carnet d'adresse (uniquement entre le client de messagerie internet et le carnet d'adresse...)
En effet, mais le client mail est un proof of concept qui date de la release de la version 1.0. Il a d'ailleurs été retiré de la version 1.7 car il n'offre pas la qualité attendue par rapport au reste des applications. Une refonte est planifiée et devrait aboutir à un client mail avec support IMAP/POP3 et ce type de lien devrait y être inclu.
- Il est où le client chat? (XMPP bien sûr, sinon ça compte pas)
Un application tierce nommé eyeIRC est disponible sur eyeos-apps.org. Personnellement je ne l'ai pas testée, mais elle semble remplir ton besoin.
- Combien d'applis disponibles? Ou sont les fonctions multimédia? (ça serait vachement mieux si je pouvais écouter la musique de mon pc depuis n'importe où à travers ça)
Il y a actuellment plusieurs dizaines d'applications tierces disponibles sur eyeos-apps.org en plus de celles fournies par défaut avec le système. Elle sont peut être de qualité et d'utilité très inégale, mais complètent bien l'offre par défaut.
- Qui va héberger si tu n'as pas de serveur perso connecté H24 avec adresse IP fixe?
Pour l'hébergement, un simple support tu PHP suffit, donc n'importe quel hébergement free.fr au semblable peut faire l'affaire.
Hélas ! Cela serait le paradis évidemment, mais c'est loin d'être aussi simple. Les comptes pages perso de Free sont très bridés justement parce qu'ils sont gratuits, et n'offrent en conséquence pas toutes les fonctionnalités de PHP requises par eyeOS. Un hébergement chez un vrai fournisseur est la meilleure option, mais le plus simple pour tout bon geek reste d'avoir une redirection DNS (très justement conseillée plus haut) sur son propre serveur artisanal.
* Une suite bureautique: Google Docs, Zoho..
* un agenda: Google Calendar et autres
* un carnet d'adresse: Plaxo, n'importe quel webmail
* un RSS News Reader: Google Reader, Bloglines (ah non celui-la il est mort), Netvibes, et plein d'autres
* et même des jeux: y'en a plein partout en flash, et en javascript des fois
C'est vrai. Mais deux questions cependant :
- d'après ta liste, cela fait à peu près un compte par service, et autant de logins ?
- tu sais comment sont gérées les données par le fournisseur de ces services ? Moi non, et pour cause, je ne connais ni le code de leur application ni les intentions de leurs propriétaires.
Évite les chmod -R 777, c'est pas top niveau sécurité... À la limite un chown -R apache.apache.
Très juste remarque. À corriger dans la doc sous peu.
Le RSS Reader... j'en cherche un comme ça sous Linux depuis que... RSS existe.
Merci, c'est mon bébé... :)
C'est beaucoup d'honneur de citer Torvalds pour quelque chose qui ne relève même pas de l'économie de moyen -- un système de type VNC / rdekstop serait beaucoup plus court et facile à créer et beaucoup plus puissant (et d'ailleurs il en existe déjà pleins)
Je pense aussi qu'il est prématuré de comparer directement eyeOS à Linux. Mais dans le concept, la citation de Linus est parfaitement adaptée. C'est aussi ce que je me suis dit quand j'ai commencé à bidouiller dessus : je le fais pour moi parce que j'en ai besoin, et puis après on verra.
Enfin, pour tous ceux qui tiquent sur le terme OS (et vous n'êtes pas les seuls bien entendu), sachez déjà que si le projet se nomme eyeOS, c'est parce que "OS" peut aussi signifier Open Source, et que c'est sur ces bases qu'il a démarré et grandi.
Ensuite, bien sûr ce n'est pas un OS dans le pur sens "système d'exploitation". Et ça n'en a pas l'ambition de le devenir. Mais dans le concept, dans l'architecture, c'est très similaire de l'OS qui tourne actuellement sur votre machine. Techniquement, il est possible de séparer le partie "noyau", qui régit les fonctions basses du système (gestion des fichiers, des processus, etc.), de la partie affichage et encore plus "bureau", qui ne sont que des services remplaçables, utilisés par celui-ci. Ce qu'un OS classique fait au niveau matériel sur une machine, eyeOS le fait au niveau supérieur, au travers du serveur HTTP et de PHP.
Pour terminer, sachez qu'il existe désormais une distribution Linux minimale qui permet de ne lancer... qu'un navigateur (Firefox of course), et d'accéder ainsi un serveur eyeOS distant. Cette distribution n'est peut être pas directement disponible pour le moment, mais elle équipe déjà les ordinateurs des élèves d'une école de Catalogne ( http://blog.eyeos.org/2008/11/16/eyeos-in-the-school-video/ ).
Je m'arrête ici, c'est déjà trop long pour le commun des mortels (mais je sais que vous n'en faites pas partie, et que donc vous lirez aussi ces lignes).
N'hésitez pas à poser des questions sur le forum ( http://forums.eyeos.org/forum ) et ici-même si le coeur vous en dit. Je serais heureux de pouvoir vous éclairer sur ce modeste projet.
Merci à Sébastien pour avoir lancé le sujet, et m'avoir ainsi permis de faire cette petite pub pour mon projet, qui j'espère améliorera un peu la vision qu'en ont les lecteurs de DLFP.
[^] # Re: Il est où le problème ??
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Accès SSH sur compte mutualisé. Évalué à 5.
C'est bien l'objet de mon énervement : c'est une mesure obligatoire qui n'est pas désactivable par le panneau d'administration. De plus, elle a été mise en place sans aucun mail d'avertissement ou d'explication.
> D'un autre coté on ne peut nier que limiter les connections qu'a certaines IP renforce la sécurité.
Je ne le nie pas et je comprends tout à fait la nécessité de ce genre de sécurité pour certains utilisateurs. Mais pour moi cela n'est qu'une gêne.
> Fin bref au lieu de pleurnicher ici tu devrait plutôt argumenter sur le problème des IP dynamiques, tu n'est très certainement pas le seul dans ce cas chez cet hébergeur.
?? D'où tu sors ça ? C'est un journal, j'écris mes réactions à ce que j'estime être un manque total de respect par un hébergeur envers un client. C'était également dans le but de savoir si des lecteurs avaient déjà fait l'expérience de ce genre de situation, et si oui, comment ils l'avaient résolu.
Si cela trouble ton dimanche, passe ton chemin.
[^] # Re: Il est où le problème ??
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Accès SSH sur compte mutualisé. Évalué à 1.
[^] # Re: Rupture de contrat ?
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Accès SSH sur compte mutualisé. Évalué à 1.
Mais c'est en effet ce que j'ai vérifié en premier.
Merci pour la proposition sur toile-libre.org, j'y penserai pour mon prochain hébergement :)
[^] # Re: Une solution de contournement via un VPN
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Accès SSH sur compte mutualisé. Évalué à 1.
Oui et c'est bien ce que je reproche à l'hébergeur. je me doute bien que des solutions seraient envisageable pour contourner de près ou de loin cette restriction, mais je pars du principe que ça ne remplacera jamais ce pourquoi j'avais souscrit initialement, à savoir un accès SSH/SFTP sans restrictions.
> Utopiquement, le mieux serait de faire annuler le contrat parce que les conditions d'utilisation ont changées !
Les conditions d'utilisations ne portent malheureusement aucune mention précise à ce niveau. Il est seulement fait référence au SSH comme d'un service inclus dans l'offre d'éhbergement, sans plus de détails.
Par contre, il est clairement marqué qu'aucun remboursement n'aura lieu passé le délai de 7 jours. Comme cela fait plus de 6 mois... je pense que ce n'est pas applicable.
[^] # Re: Mouais
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Steam et source pour linux : c'est officiel. Évalué à 3.
Mon portable dont le modèle date de 2007 fait parfaitement tourner L4D en détails max. Essaye ça avec un jeu du même âge que L4D, tu n'auras certainement pas les mêmes résultat.
[^] # Re: Mouais
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Steam et source pour linux : c'est officiel. Évalué à 6.
Je pense que nous avons affaire à la plus grande révolution du jeu vidéo sur Linux. Même si on aurait préféré que ça soit avec des jeux... libres eux-aussi, je me contenterai de voir qu'une tripotée d'excellents titres deviennent disponibles autre part que sur Windows (et OSX, mais pour ce que j'en connais...).
[^] # Re: déjà
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Un moteur de recherche aussi futé et précis que bash?. Évalué à 0.
Allez, y'a aussi la page anglaise de Wikipédia en page 2. Nouveau troll Nouvelle question : faut-il bannir Wikipedia des résultats Google ?
[^] # Re: déjà
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Un moteur de recherche aussi futé et précis que bash?. Évalué à 2.
Ben oui, recherchez "+lapins" sur Google et vous chercherez que des lapins. Maintenant enlevez le "+" et vous aurez des lapins singuliers (enfin... j'me comprends...).
Je dois ajouter que ça s'applique aussi aux expressions entre guillemets quand on le place avant le premier guillemet justement ? Allez non.
[^] # Re: navigateur dans le navigateur
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 2.
En conclusion, eyeNav n'est pas un vrai navigateur. Mais il offre l'avantage de sauvegarder ses favoris et de les rouvrir tout en restant dans l'environnement du bureau eyeOS.
# Oups, erreur de date !
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 1.
Cela fait donc un an et demi environ aujourd'hui. Veuillez pardonner cette négligence, je n'ai pas eu la chance de participer à la série 0.x du projet, mais uniquement 1.x.
[^] # Re: Une appli jabber ?
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 1.
Oui ! J'ai eu la chance d'arriver au bon moment me semble-t-il, le projet venait juste d'avoir sa base stabilisée grâce au boulot de deux passionnés catalans.
Je développe à mes heures perdues un client jabber en javascript [...] Je me demandais si ça pouvait avoir un intérêt à être intégré dans ce genre de projets, sous forme d'applis.
Bien sûr que oui ! Ce genre d'application est extrêmement intéressant pour le projet ! Je t'encourage très fortement à regarder un peu comment sont construites les applications eyeOS et à en créer une pour ton client Jabber. Au début tu peux te limiter au plus simple, sans arrangement graphique pour coller au reste, et tu le déposes sur eyeos-apps.org.
Nous n'avons justement pas de client Jabber par défaut pour l'instant, ton application pourrait très bien remédier à ça :)
Ne t'inquiète pas pour les librairies JS additionnelles, chaque application peut charger les scripts nécessaires à son exécution. Le problème risque de se poser si une autre application a besoin des mêmes librairires (mais non-modifiées, dans ton exemple avec Mootools) pour fonctionner. On risque d'obtenir un résultat assez... aléatoire.
Dans tous les cas, ça ne coûte rien d'essayer (à part un peu de temps).
[^] # Re: C'est beau
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 1.
Que ce soit entre JS => PHP ou PHP => JS c'est de l'XML.
Côté JS un moteur maison se charge de parser les réponses et de lancer les tâches à effectuer.
Côté PHP, la requête est traitée selon ses variables GET et des paramètres additionnels peuvent être passés par XML.
[^] # Re: C'est beau
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 2.
Mais j'hésite à dire que le plus gros soit côté JS. Le javascript gère la couche "présentation" comme on dit. C'est elle qui affiche et dispose les éléments, reçoit les actions utilisateur, et les transmet à la partie contrôle. C'est un gros boulot effectivement, mais ça reste de l'affichage.
La partie contrôle doit dialoguer avec cette partie affichage, mais également gérer l'exécution des applications, le routage des messages, la gestion des droits utilisateurs, les opérations sur le système de fichiers, etc. Et ça c'est un autre gros boulot !
Donc dans eyeOS, je pense que le plus gros du système reste situé côté PHP, même si le noyau JS représente une part évidemment non-négligeable.
Dans la version 2.0 en préparation, la gestion des widgets (boutons, champs, fenêtres, etc.) devrait être assuré côté JS non plus par une librairie développée en interne, mais par Qooxdoo, un framework Javascript très puissant, très complet et très extensible. Mais ça c'est une autre histoire...
[^] # Re: Déjà...
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 1.
Pourvu qu'il n'y ait pas trop de monde quand même ^^
[^] # Re: Très propre
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 4.
Merci, ça représente un boulot assez conséquent !
Concernant ta remarque sur le stockage de donnée perso, c'est justement là qu'eyeOS représente une alternative à toutes ces applications priv[ées/atives] !
Le serveur eyeos.info est accessible à tout le monde, et effectivement là, il n'y a pas de contrôle direct des utilisateurs sur leurs données. Libre à chacun de s'inscrire et de l'utiliser en "prenant le risque" (comme on "prend le risque" d'utiliser Facebook, GoogleDocs, Gmail, etc.).
Mais ce n'est pas tout ! Et c'est ÇA qui m'a attiré quand j'ai découvert le projet. Je ne suis PAS dépendant d'un serveur propriétaire situé je-ne-sais-où. Je télécharge le package eyeOS et je l'installe sur le serveur de mon choix, à la maison, sur un hébergement mutualisé, sur un hébergement dédié, etc. Je n'ai besoin que d'Apache et PHP. Et c'est encore mieux comme ça, puisque ça me permet de gérer l'administration d'eyeOS moi-même. Je garde ainsi un total contrôle des données stockées sur mon système eyeOS.
[^] # Re: C'est beau
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 2.
Les solutions entreprises sont prises en charge par la société eyeOS (www.eyeos.com). Elle fournit le support, le développement et la maintenance d'applications tierces pour le compte de sociétés privées.
eyeOS propose une double licence concernant les développement spécifiques : dans le premier cas, la société devient propriétaire du source de ses applications/modules/etc et elle seule peut décider de son utilisation.
Dans l'autre, si les développement effectués présentent un intérêt pour la communauté libre, la société peut léguer ses droits sur le source et payera en contrepartie un prix plus faible que dans le premier cas.
C'est d'un certain point de vue gagnant-gagnant, notamment pour les administrations publiques qui sont prêtes, on le sait, à payer le moins cher possible, et qui n'ont que faire du source du logiciel fourni.
... mais sinon c'est aussi pour la beauté du code ;)
[^] # Re: Retransmission?
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 1.
Ce n'est pas prévu malheureusement. Je suis seul à m'occuper de l'organisation et je n'ai pas le matériel pour le retransmettre en direct ou différé.
PS: a toi et à l'équipe, chapeau pour eyeOS, c'est bluffant! Bon courage pour la suite.
Merci ! Cela reste un début, mais les améliorations vont grandissantes au fil des mois !
[^] # Re: navigateur dans le navigateur
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 1.
Effectivement. Comme nombre d'applications AJAX, les appels aux boutons "Précédent" et "Suivant" ne font pas ce que l'on attendrait d'eux.
Je sais que les applications Google ont partiellement résolu ce problème, je note ça et je jetterai un oeil pour au moins "désactiver" ces boutons sous eyeOS (en attendant de trouver de meilleures actions en remplacement).
Merci de la remarque !
[^] # Re: navigateur dans le navigateur
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 1.
La seule utilité de ce mode est de pouvoir sauvegarder ses bookmarks et de gérer les pages consultées au sein d'eyeOS, sans avoir d'onglets supplémentaires ouverts dans son navigateur.
Cependant, et bien que je ne l'ai jamais essayé, eyeNav propose un plugin de navigation basé sur anonymouse.org. Ce n'est plus alors le client qui effectue les requêtes, mais ce n'est pas non plus le serveur eyeOS. Le plus gênant ici est que bon nombre de proxys (notamment en entreprise) bloquent les accès à ces sites de surf anonyme.
Il n'y a donc pas de réelle solution pour le moment en considérant que les librairies de proxy PHP ne sont, pour la grande majorité, pas au point...
[^] # Re: Déjà...
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal Conférence eyeOS le 24 février à Toulouse. Évalué à 1.
Non c'est clair tu as totalement raison, en le relisant une dixième fois ça saute aux yeux. J'aurais pas dû m'arrêter à neuf ^^
Merci et à bientôt
[^] # Re: Merci pour l'info !!!
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal EyeOS 1.7.0. Évalué à 3.
Le résultat est souvent peu convaincant et parfois dangereux pour les utilisateurs comme pour le projet eyeOS qui perd en crédibilité, même si ces applications sont clairement présentées comme étant "tierce-parties" et dont nous ne pouvons vérifier le code de chacune par simple manque de temps.
Si je me rappelle bien, il y a aussi une application "eyeGmail", typique dans le genre des applications inutiles proposées par des personnes extérieures : une simple fenêtre avec une iframe pointant vers la page de Gmail...
Merci pour eyeSSH, j'avertirai le webmaster de eyeos-apps pour supprimer le package correspondant.
[^] # Re: Droit de réponse
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal EyeOS 1.7.0. Évalué à 2.
C'est en partie pour cela que le service VFS (Virtual File System, mais plus que ça en fait depuis longtemps) est en passe d'être entièrement reconçu.
Nous avons reçu beaucoup de demandes dans ce sens là, et il est clair que l'intérêt est suffisant pour en prendre compte dans les prochaines versions.
Dans l'idéal, il s'agirait de recréer ce qu'on retrouve sur les vrais OS, à savoir des points de montage et des gestionnaires de protocoles qui permettent aux applications d'accéder aux données et de les manipuler sans savoir où elles sont réellement situées. Cela permettrait (comme je l'explique brièvement dans une réponse plus bas) de taper l'URL d'un server FTP dans le gestionnaire de fichiers, puis d'ouvrir un fichier texte avec l'éditeur en double-cliquant, de modifier le fichier et d'enregistrer. Simplement.
Et que ce fichier soit sur la machine locale (j'entends, le serveur), un serveur SSH distant, ou FTP ou autre ne serait d'aucune différence du point de vue de l'utilisateur. C'est ça "ouvrir eyeOS aux services du réseau". C'est un grand objectif mais assez complexe à mettre en oeuvre. Néanmoins nous y travaillons.
L'agenda va probablement subir un rafraichissement général lui aussi dans les versions à venir.
Encore une fois, c'est un projet relativement jeune, à qui on propose énormément d'idées mais dont les développeurs manquent de temps pour tout faire. Si vous êtes intéressé(e)s pour contribuer, n'hésitez pas !
[^] # Re: LTSP et XDMCP
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal EyeOS 1.7.0. Évalué à 1.
Évidemment...
[^] # Re: LTSP et XDMCP
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal EyeOS 1.7.0. Évalué à 5.
avec LTSP, je bootais les machines sur une disquette, ca aller sur le reseau chercher l'OS et les applis qui etaient toutes stocker sur un serveur.
finalement eyeOS n'invente rien, on en reviens simplement à ce qu'oon faisait il y a 15 ans :D
À cela près qu'on trouve maintenant plus d'ordinateurs avec un navigateur et connectés à Internet, qu'avec un lecteur de disquette et la possibilité de booter dessus. Il y a une évolution, mais rien de t'empêche d'essayer d'utiliser LTSP sur le premier ordinateur que tu trouves.
eyeOS est encore au stade de PoC, même si c'est à grande échelle. Il y a quantité d'idées qui fleurissent sur le forum et d'utilisations possibles qui n'ont pas encore été implémentées. Nous avons les idées, mais nous manquons encore de doigts pour les réaliser.
Une chose également, la série 1.x d'eyeOS a jeté les bases de l'architecture, du concept et de la philosophie du projet. Mais elle a atteint depuis quelques temps les limites de son évolution, et il est apparu nécessaire d'apporter un changement dans le coeur du système afin d'en préserver son évolutivité et son actualité dans le monde du web d'aujourd'hui. C'est pourquoi une nouvelle version 2.0 est en ce moment même planifiée par la communauté, afin de voir le jour dans quelques mois. Elle devrait apporter de nombreuses améliorations par rapport aux limitations pré-citées.
Personnellement, je suis en charge avec deux membres de l'équipe "centrale", de concevoir et implémenter le nouveau module de gestion de fichiers. Il devrait permettre à terme, comme sous KDE notamment, de fournir au développeur d'application une transparence réseau avec les principaux protocoles, y compris ceux internes au système eyeOS. Cela ouvrira les applications eyeOS basées sur ce système (c'est-à-dire une grande majorité, voire la totalité à terme) à tous les services qu'on retrouve sur un réseau, en faisant jouer au serveur d'eyeOS le rôle de proxy pour toutes ces opérations.
La version en développement offre un gestionnaire de fichiers simplifié qui permet à l'utilisateur, par simple drag&drop, de transférer un fichier sur un serveur FTP depuis la fenêtre A vers un dossier sur le serveur local, ou sur autre serveur FTP distant sur la fenêtre B. À aucun moment bien sûr le développeur du gestionnaire de fichier ne fait référence au protocole qui est utilisé, et laisse le module système se charger des véritables opérations. C'est un petit exemple, mais je le assez parlant et plus user friendly qu'une commande dans un shell.
Librement.
# Droit de réponse
Posté par Nanawel (site web personnel, Mastodon) . En réponse au journal EyeOS 1.7.0. Évalué à 10.
Je suis les news de ce site depuis quelques temps déjà, et j'avoue que j'ai souvent eu envie d'ajouter mon petit grain de troll... pardon, de sel, dans les débats qui se déroulent ici. Mais ce journal m'offre là une occasion trop importante pour ne pas apporter quelques précisions au sujet. Mon compte créé, me voilà.
Je m'appelle Anaël et je fais partie de la communauté eyeOS en tant que développeur depuis un an et demi maintenant. J'ai découvert ce projet un peu comme beaucoup, par hasard, en cherchant un moyen esthétique d'accéder à mon serveur FTP maison et d'en gérer les fichiers (notamment les transferts) depuis un poste restreint. En l'occurrence : un de la fac.
Le projet alors était assez jeune et un faible nombre d'applications était disponible. Néanmoins, en jetant un oeil à l'architecture du système j'ai trouvé que ça tenait largement la route et que ça méritait d'être testé plus en profondeur. J'ai alors commencé à développer dans mon coin l'application qui allait devenir à terme le client FTP par défaut, j'ai nommé eyeFTP. J'ai rencontré de nombreuses difficultés pour bien prendre en main l'API et cerner le fonctionnement de l'engin, mais petit à petit mon ébauche a pris forme et j'ai proposé une version beta à l'équipe, qui n'avait d'ailleurs cessé de m'aider à chaque souci. Le résultat après plusieurs mois d'évolutions est l'application que vous pouvez trouver dans les releases d'eyeOS 1.5 et suivantes.
J'ai eu des contacts très réguliers avec l'équipe (basée à Barcelone) pendant tout ce temps, et elle m'est apparue extrèmement ouverte aux contributions et aux participations extérieures (original me direz-vous, pour un projet libre). J'ai finalement passé les mois d'avril à août de cette année au sein de l'équipe afin de les connaître et de participer au développement de ce qui, je pense, pourrait devenir le Linux des web OS. Car pas besoin d'être devin, mais ce genre de système, même s'il n'intéresse pas le geek moyen directement (qui a comme chacun sait, un serveur FTP, HTTP, VNC, SSH et j'en passe accessible 24/24 depuis le web*), va devenir une alternative intéressante pour les organisations telles que les établissements scolaires à court ou moyen terme (c'est déjà le cas, c'est pour cela que j'ai pris cet exemple).
Alors que dire d'un projet tel que celui-ci ? Le traiter de useless et no-future sans avoir pensé qu'il offre UNE alternative libre à un panel de projets dont peu peuvent réellement se vanter d'être aussi abouti quand ils sont libres, et aussi libres quand ils sont sous licences propriétaires ?
Si, comme je le pense, ce concept de bureau en ligne perce au niveau technique, philosophique et commercial dans les prochaines années, n'est-il pas intéressant que le monde du libre participe activement et revendique cette évolution ?
Il y a tant de choses à dire, mais je ne tiens pas à perdre des lecteurs avec un post de deux kilomètres. Je vais donc tenter de répondre (subjectivement bien entendu) aux quelques remarques qui ont été formées précédemment.
- Je soupçonne que ça tourne quand même vachement plus vite quand le site s'appelle localhost plutôt que quand il s'appelle www.chez-moi.com/ et qu'on a une connexion moyenne (voire lente).
C'est l'évidence même. Néammoins un fonctionnement normal ne requiert qu'une bande passante modeste. Mais bien sûr, si vous avez de gros fichiers à transférer ça risque de devenir moins réactif...
- J'ai essayé la démo pour voir, apparemment, il n'y a pas de lien entre le client mail et le carnet d'adresse (uniquement entre le client de messagerie internet et le carnet d'adresse...)
En effet, mais le client mail est un proof of concept qui date de la release de la version 1.0. Il a d'ailleurs été retiré de la version 1.7 car il n'offre pas la qualité attendue par rapport au reste des applications. Une refonte est planifiée et devrait aboutir à un client mail avec support IMAP/POP3 et ce type de lien devrait y être inclu.
- Il est où le client chat? (XMPP bien sûr, sinon ça compte pas)
Un application tierce nommé eyeIRC est disponible sur eyeos-apps.org. Personnellement je ne l'ai pas testée, mais elle semble remplir ton besoin.
- Combien d'applis disponibles? Ou sont les fonctions multimédia? (ça serait vachement mieux si je pouvais écouter la musique de mon pc depuis n'importe où à travers ça)
Il y a actuellment plusieurs dizaines d'applications tierces disponibles sur eyeos-apps.org en plus de celles fournies par défaut avec le système. Elle sont peut être de qualité et d'utilité très inégale, mais complètent bien l'offre par défaut.
- Qui va héberger si tu n'as pas de serveur perso connecté H24 avec adresse IP fixe?
Pour l'hébergement, un simple support tu PHP suffit, donc n'importe quel hébergement free.fr au semblable peut faire l'affaire.
Hélas ! Cela serait le paradis évidemment, mais c'est loin d'être aussi simple. Les comptes pages perso de Free sont très bridés justement parce qu'ils sont gratuits, et n'offrent en conséquence pas toutes les fonctionnalités de PHP requises par eyeOS. Un hébergement chez un vrai fournisseur est la meilleure option, mais le plus simple pour tout bon geek reste d'avoir une redirection DNS (très justement conseillée plus haut) sur son propre serveur artisanal.
* Une suite bureautique: Google Docs, Zoho..
* un agenda: Google Calendar et autres
* un carnet d'adresse: Plaxo, n'importe quel webmail
* un RSS News Reader: Google Reader, Bloglines (ah non celui-la il est mort), Netvibes, et plein d'autres
* et même des jeux: y'en a plein partout en flash, et en javascript des fois
C'est vrai. Mais deux questions cependant :
- d'après ta liste, cela fait à peu près un compte par service, et autant de logins ?
- tu sais comment sont gérées les données par le fournisseur de ces services ? Moi non, et pour cause, je ne connais ni le code de leur application ni les intentions de leurs propriétaires.
Évite les chmod -R 777, c'est pas top niveau sécurité... À la limite un chown -R apache.apache.
Très juste remarque. À corriger dans la doc sous peu.
Le RSS Reader... j'en cherche un comme ça sous Linux depuis que... RSS existe.
Merci, c'est mon bébé... :)
C'est beaucoup d'honneur de citer Torvalds pour quelque chose qui ne relève même pas de l'économie de moyen -- un système de type VNC / rdekstop serait beaucoup plus court et facile à créer et beaucoup plus puissant (et d'ailleurs il en existe déjà pleins)
Je pense aussi qu'il est prématuré de comparer directement eyeOS à Linux. Mais dans le concept, la citation de Linus est parfaitement adaptée. C'est aussi ce que je me suis dit quand j'ai commencé à bidouiller dessus : je le fais pour moi parce que j'en ai besoin, et puis après on verra.
Enfin, pour tous ceux qui tiquent sur le terme OS (et vous n'êtes pas les seuls bien entendu), sachez déjà que si le projet se nomme eyeOS, c'est parce que "OS" peut aussi signifier Open Source, et que c'est sur ces bases qu'il a démarré et grandi.
Ensuite, bien sûr ce n'est pas un OS dans le pur sens "système d'exploitation". Et ça n'en a pas l'ambition de le devenir. Mais dans le concept, dans l'architecture, c'est très similaire de l'OS qui tourne actuellement sur votre machine. Techniquement, il est possible de séparer le partie "noyau", qui régit les fonctions basses du système (gestion des fichiers, des processus, etc.), de la partie affichage et encore plus "bureau", qui ne sont que des services remplaçables, utilisés par celui-ci. Ce qu'un OS classique fait au niveau matériel sur une machine, eyeOS le fait au niveau supérieur, au travers du serveur HTTP et de PHP.
Pour terminer, sachez qu'il existe désormais une distribution Linux minimale qui permet de ne lancer... qu'un navigateur (Firefox of course), et d'accéder ainsi un serveur eyeOS distant. Cette distribution n'est peut être pas directement disponible pour le moment, mais elle équipe déjà les ordinateurs des élèves d'une école de Catalogne ( http://blog.eyeos.org/2008/11/16/eyeos-in-the-school-video/ ).
Je m'arrête ici, c'est déjà trop long pour le commun des mortels (mais je sais que vous n'en faites pas partie, et que donc vous lirez aussi ces lignes).
N'hésitez pas à poser des questions sur le forum ( http://forums.eyeos.org/forum ) et ici-même si le coeur vous en dit. Je serais heureux de pouvoir vous éclairer sur ce modeste projet.
Merci à Sébastien pour avoir lancé le sujet, et m'avoir ainsi permis de faire cette petite pub pour mon projet, qui j'espère améliorera un peu la vision qu'en ont les lecteurs de DLFP.
____
* (je le sais j'en ai un :P)