protection mémoire

15 sujets de 16 à 30 (sur un total de 138)

  • leo

      #80127

      @Breed: joli ! tu m’as coupé l’herbe sous le pied :)

      Sinon, pour ce qui est de la protection mémoire, resource_tracking,…

      En effet il y a un système de ressource tracking, mais il n’est pas activé par défaut, le programmeur *doit* le spécifier pour l’avoir.

      Tu prouves par A+B que ce n’est pas possible d’avoir quelque chose de fonctionnel, avec le système (la compatibilité) actuel.

      Il n’y a pas à chercher plus loin. Soit on perd complètement la compatibilité (que l’on peut conserver, dans un premier temps, à l’aide d’une approche à la MacOSX, MorphOS/ABox,…) soit c’est pas possible.

      Et le resource_tracking sans une réelle protection mémoire, je ne vois pas non plus l’intérêt :)

      @+,

      Léo.

      elwood

        #80128

        @seg

        > la protection memoire est plus un garde fou pour les developpeurs foireux.

        Euh non, c’est contre l’être humain car nous faisons tous des erreurs. La MP permet d’éviter les dégats. Bon développeur ou pas.

        centaurz

          #80129

          Pour ce qui est de la mémoire sous OS4, il me semblait qu’il y avait déjà un espace d’adressage pour chaque tâche au niveau de la mémoire déclarée “private”, depuis la version finale, mais j’ai du confondre avec autre chose. Enfin je crois que l’idée c’est quand même d’aller vers ça.

          @ sinisrus

          ce que je ne comprend pas c’est pourquoi les dev (os4.0, morphos) ne font-il pas une protection mémoire total du system (que l’on puisque activer ou désactiver) de façon à gader la comptatibilitée et aussi évoluer il suffirai juste de rebouté pour passé d’un mode à l’autre. mais je pense que cela est bien plus compliqué

          parce que le dos, intuition et quasiment tous les composants d’AOS ont besoin de partager la mémoire à l’heure actuelle

          Alex

            #80130

            @leo

            Tu prouves par A+B que ce n’est pas possible d’avoir quelque chose de fonctionnel, avec le système (la compatibilité) actuel.

            Je n’ai pas dis le contraire, d’ailleurs relis mon premier post qui commence par “on est quand même marrants nous les amigaïstes“…

            EDIT: pour être totalement clair l’idée que je développai c’est que l’on veut à la fois la mémoire protégée ET la compatibilité TOTALE (et pas dans un sandbox à la manière de MacOs9 hein, bien sûr ! La solution “je fais tourner EUAE pour lancer mon appli” n’est bien sûr pas acceptable non plus, même si elle garantit 100% (ou 99,9%) de compatibilité).

            seg

              #80131

              elwood a écrit :


              @seg

              > la protection memoire est plus un garde fou pour les developpeurs foireux.

              Euh non, c’est contre l’être humain car nous faisons tous des erreurs. La MP permet d’éviter les dégats. Bon développeur ou pas.

              Tu te places du cote utilisateur la. Et j’avais plus une pensee pour le resource tracking en fait.

              Un bon nombre de developpeurs n’est pas methodique du tout: Tester les ressources et les liberer systematiquement ne font pas partie de leurs preoccupations.

              Avec le couple MP/RT, c’est devenu moins grave de manquer de rigueur a ce niveau. Peut-etre que la pression des utilisateurs est moins fortes du fait que ces mecanismes systemes les evitent de freezer leur becane.

              Bon developpeur ou pas, on glisse vers du j’en foutisme au niveau code puisque mal programmer n’a pas d’incidence grave.

              L’erreur est humaine, certes! Mais au niveau ou on est rendu, c’est carrement de l’elevage industriel. Il suffit d’ouvrir un code source un peu partout pour voir qu’il n’y a rien de teste du tout. Mais si une ressource plante et que le code se gauffre par une succession de cause a effet, c’est pas grave, on a le couple MP/RT…

              A l’epoque ou j’ai commence a programmer, ce genre de negligeance etait inadmissible. Aujourd’hui, d’une maniere generale, on s’en branle. Il n’y a qu’a voir l’influence du monde Java ou on generalise l’idee que “c’est pas au developpeur de gerer la memoire” alors qu’on voit bien qu’il est primordial de la gerer meme en Java pour eviter les Memory Leaks et donc les Out of Memory quand t’as 2 gigas de memoire (pardon, 1.5, y a une limitation)…

              You see what I mean?

              Je sens qu’on digresse mais si ca interesse du monde, hein…

              a+

              Socrate1

                #80132

                Tu prouves par A+B que ce n’est pas possible d’avoir quelque chose de fonctionnel, avec le système (la compatibilité) actuel.

                Je n’ai pas dis le contraire, d’ailleurs relis mon premier post qui commence par “on est quand même marrants nous les amigaïstes”…

                EDIT: pour être totalement clair l’idée que je développai c’est que l’on veut à la fois la mémoire protégée ET la compatibilité TOTALE (et pas dans un sandbox à la manière de MacOs9 hein, bien sûr ! La solution “je fais tourner EUAE pour lancer mon appli” n’est bien sûr pas acceptable non plus, même si elle garantit 100% (ou 99,9%) de compatibilité).

                Désolé si je dis une bêtise, n’étant pas particulièrement technicien ni programmeur, et récent immigré dans ce débat qui remonte manifestement à des années, mais une carte sur le modèle de la future Clone-A ne pourrait-elle pas représenter une alternative ?

                La Sam440ep possède au moins un connecteur FPGA, et je me disais qu’il serait possible, en continuant sur le modèle d’Apple, de recourir à un double-boot, un peu sur le modèle de Boot Camp, sur la même machine.

                L’ordi, à la base, serait un Amiga NG, fonctionnant sous OS4 ou MOS. Que les développeurs pourraient enfin nettoyer des scories liées au code résiduel imposé par la recherche systématique de la sacro-sainte compatibilité en délégant cette fonction à une carte-fille optionnelle, qui fonctionnerait grâce à un “WB d’époque” adapté pour l’occasion, qui reprendrait en hardware une ou plusieurs puces simulant les copros graphiques d’époque, ECS ou AGA. Le principe de la Clone-A en fait, mais non plus en tant que cm principale comme dans le projet actuel, mais comme carte d’extension que l’on acquerrait ou non selon son envie ou le besoin.

                L’avantage serait de permettre enfin aux OS Amiga de se moderniser plus rapidement, tout en offrant une roue de secours à ceux qui ne veulent pas perdre la compatibilité avec les anciens softs, qu’il s’agisse de jeux ou de programmes plus sérieux. Peut-être même serait-il possible de les utiliser en simultané, de manière transparente, grâce au double hardware, même si cela n’encouragerait pas les programmeurs à les adapter malheureusement

                Et, heu, question bête de néophyte, pourquoi diantre certains condamnent-ils l’éventualité d’une Sandbox pour un vieux WB 680×0 sous un futur AOS 4.x ou MOS 1.x ? J’ai bossé grâce à ça pendant deux/trois ans sur quelques projets XPress 4 résiduels alors que j’étais déjà passé à OSX et In-Design au boulot, et cela fonctionne fantastiquement même si la gestion des polices peut-être un peu lourde (pour un paoïste, hein, s’entend, pour le commun des mortels le problème ne se pose pas).

                centaurz

                  #80133

                  @ leo

                  Il n’y a pas à chercher plus loin. Soit on perd complètement la compatibilité (que l’on peut conserver, dans un premier temps, à l’aide d’une approche à la MacOSX, MorphOS/ABox,…) soit c’est pas possible.

                  Ouais, mais c’est pas une raison pour tout faire péter ! ;-)

                  Tu vas un peu vite. Si la “communauté” (avec tout les guillemets que tu veux) Amiga survit, c’est grâce à tous les développeurs qui continuent à programmer dessus, parce que justement l’environnement leur est familier, ils sont rodés (et aussi grace aux utilisateurs, ça va de soit).

                  Si on décide de recréer un nouveau système Amiga-like sans les défauts de l’actuel, c’est cool on aura un super OS qui déchire mais combien se forceront à se convertir à cet hypothétique “nouveau système”, en sachant tout les efforts qui ont été dépensés pour MOS et OS4 ? Est-ce que faire un nouvel OS alternatif peut encore intéresser des gens ?

                  leo

                    #80134

                    @centaurz: quel communauté ? Les gens qui se tapent dessus parce qu’ils ne peuvent pas se blairer (sans savoir pourquoi) ? Ou alors la dizaine de développeurs (ouais, on les compte sur les doigts d’une main) qui se prennent pour des Dieu ?

                    A mon avis il n’y a pas de communauté, et entre repartir *proprement* de zéro avec en tout et pour tout 150 utilisateurs+dévelopeurs, ou continuer comme maintenant (avec quoi ? 1000 utilisateurs dans le monde au max ?), à se taper dessus, à réécrire/re-porter les mêmes softs 3 fois d’affilée (oui: OS4, MOS, AROS, et encore je compte même pas OS3.x), tout en gardant toujours les mêmes limites, bein je vois pas vraiment la différence.

                    Est-ce que faire un nouvel OS alternatif peut encore intéresser des gens ?

                    Ca c’est une bonne question. Celà dit, tous les gens qui sont encore ici (qu’ils soient sur OS4, AROS, MOS, OS3), c’est parce qu’ils sont dans ce cas, non ?

                    @+,

                    Léo.

                    Mod

                    Tcheko

                      #80135

                      Repartir de zéro. Faisons table rase du passé.

                      L’os minimaliste :

                      Index = 0

                      Faire tant que

                      Lire touche

                      Si touche = entrée

                      sauter à l’adresse contenue dans index – 8

                      Fin si

                      Si touche = 0 à F

                      écrire touche à la position index

                      index = index + 1

                      Fin si

                      Fin tant que

                      NB : index est de taille quartet.

                      Normalement, avec un tel OS, il est possible de refaire le monde. Ca risque d’être long, pénible et douloureux, vous êtes prévenu.

                      Pas besoin de mémoire protégée. C’est pour les nuls. Les dieux peek et poke librement…

                      Alex

                        #80136

                        @Tcheko

                        ton nouvel OS me plait bien ;-)

                        seg

                          #80137

                          Si vous cherchez un nouvel OS, y en a plein d’autres. Pourquoi en vouloir un nouveau incompatible avec tout?

                          Sas_

                            #80138

                            A titre personnel, la protection memoire je m’en bat un peu, je veux croire qu’en plus ça rend faineant le codeux de base “rien a foutre de ce bug si ça explose ça n’ecroulera pas l’OS”.

                            Maintenant si l’on doit passer un jour à une autre famille de processeurs (x86 pour Logo) et que par ce fait la compatibilité avec les machines actuelles devra se faire à travers une emulation il serait surement dommage de s’en priver ne serais-ce que pour avoir un vrai argument en moins en defaveur d’ AOS4/MOS (au prés des developpeurs par exemple).

                            leo

                              #80139

                              Hum… juste comme ca: il faudrait arrêter 5 minutes de dire que plus personne ne fait aucun test depuis qu’il y a de la protection mémoire,… Juste, un exemple au hasard:

                              Durant mes cours de C++ en licence informatique, nous faisions des TP de C++ sur du Linux. Un système qui possède donc la protection mémoire. Et nous utilisions un outil qui s’appelle valgrind et qui permet de vérifier les fuites mémoires des programme (le programme indiquait exactement le nombre d’octets non libérés). Et nous *devions* utiliser cet outil, et avions des points en moins si des fuites apparaissaient dans nos TP…

                              C’était juste pour info. Ca n’empêche que certaines personnes font peut être moins gaffe (quoique elles ne le faisaient pas forcément avant, même sans protection mémoire: voir 95% des jeux… Amiga justement, qui étaient incapables de rendre la main au système). Mais de là à utiliser cette excuse pour ne pas l’utiliser… non.


                              @Seg
                              : parce que à part Unix, il n’y a aucune alternative à Windows. Aucune. Tout est basé sur Unix. Et il y a des gens qui aimeraient avoir un système solide, qui n’est pas un Unix. C’est pas imaginable ca ?

                              @+,

                              Léo.

                              Sas_

                                #80140

                                @Leo:

                                Note le “codeux de base” :)

                                Encore heureux qu’il y ai encore des devs qui font bien leur boulot.

                                Admet tout de même que ce genre de “securité” pousse au vice :)

                                Fab1

                                  #80141

                                  Dans tous les gros softs opensource linux/windows que j’ai croisés, j’ai toujours vu des malloc non vérifiés, et plus généralement une non vérification des retours de fonction d’allocations. A titre d’exemples que je connais bien, je peux citer scummvm, snes9x, mame, mplayer, stellarium, wesnoth, uae, vlc, xchat.

                                  Un exemple de fonction de xchat pris au pif :

                                  void fe_new_server (struct server *serv)

                                  {

                                  serv->gui = malloc (sizeof (struct server_gui));

                                  memset (serv->gui, 0, sizeof (struct server_gui));

                                  }

                                  (après vérification, aucun malloc dans xchat n’est vérifié)

                                  Je suis sûr que je pourrais trouver la même chose dans les outils GNU, dans le serveur X11 et pt être même dans le noyau et certains drivers. :)

                                  Et cet oubli de vérification n’est qu’une petite partie du problème. On passera sur les leaks, les overflows potentiels de partout (qui sont quand même surveillés pour les serveurs, vu les dégâts que ça peut engendrer), …

                                  Alors oui, on apprend pt être aux gens à vérifier les retours pendant leur formation, mais apparemment c’est vite oublié, peut être parce que justement un plantage localisé est moins frustrant qu’un reboot obligé, tellement moins qu’on s’abstient de régler le problème. :)

                                15 sujets de 16 à 30 (sur un total de 138)

                                • Vous devez être connecté pour répondre à ce sujet.

                                Forums AmigaOS, MorphOS et AROS Général protection mémoire

                                Amiga Impact