Beiträge von gandro

    Wenn ich Pac-Man richtig verstehe, weiss er was internal tut, viel mehr will er das entsprechende Äquivalent in C++.

    Ich habe wenig Ahnung von .NET Assembly und wenig von C++, aber so wie es scheint, verwendet selbst VC++ für C++-Binärdateien ein anderes System, ist ja letztendlich auch kein .NET Bytecode es gibt in C++ also gar keine direkte Möglichkeit, die Sichtbarkeit eines Symbols einzuschränken - du musst mit Headerfiles und dem Linker arbeiten. Aber keine Ahnung wie das bei MSVC++ geht.

    C# internal == public C++?
    C#: Can i write “private:” or “protected:” regions like in C++?

    Wobei ich keinen Grund sehe, warum man das unbedingt will. Falls jemand nen Unsinn mit dem Binärcode anstellen will, hält ihn auch "Internal" nicht davon ab.

    Kann sein dass ich keine Ahnung habe, aber bei OS X zahlt man für Minor-Updates (z.B. OS X 1.6.5) genau so nichts wie bei Windows. Und bei Betriebsystem-Updates (10.5 auf 10.6, Vista auf 7) zahlt man nen geringen Preis (der bei OS X weniger ist als bei Windows)

    Wie startet man das Teil. Hab Spring und Zero-K installiert. Kann Zero-K als Mod auswählen, aber bei "Test the Game" will er ne Map haben, da ist aber keine. Find nix im Internet dazu.

    Kann definitiv keinen Performance-Unterschied erkennen. Der "Boot-Vorgang" braucht definitiv länger als Openbox, aber danach ist es genau so fix wie XFCE oder OpenBox. Vll Grafiktreiberprobleme?

    Bezüglich Einstellungen: Weiss nicht. Ja, dürfte hier und da noch etwas mehr sein, aber die meisten (definitiv nicht alle) Einstellungen die die meisten User vermissen sind einmalige Dinge. Das Theme wechselt man einmal nach der Installation. Das Standard-Bildschirm-Timeout ebenso. Das macht sowieso der Sysadmin wenn er das System installiert.

    Einstellungen die des öfteren geändert werden, wie Bildschirme/Auflösungen, Tastaturshortcuts oder Lautstärke sind ja vorhanden. Sicherlich dürfte es da etwas mehr werden, aber ich hätte kein schlechtes Gefühl meinen Eltern jetzt ein GNOME 3 einzurichten, die würden da vermutlich nichts Einstellen wollen, was nicht über die Standard-GUI erreichbar ist.

    Zitat von DosAmp


    Ja, eben. Aber mit meiner Ubuntu-Installation zu Hause am Desktop-PC komm ich schon einigermaßen klar, wenn man sich einmal etwas dran gewöhnt hat, merkt man den Unterschied zur standardmäßigen Win7-Superbar oder dem OS-X-Dock kaum noch. Zur Oberflächen-Performance kann ich sagen, dass es bei mir mit C2D und einer GF8400GS mit offenen Nouveau/Gallium3D-Treibern ausreichend flott läuft, auf einem Netbook mit Atom und GMA950 dagegen so grenzwertig, wie man es nicht vom ehemaligen »Netbook Remix« erwarten würde. Sollte vielleicht endlich mal das Ubuntu 10.10 an meinem Dienstlaptop (Core i5 mit integrierter Grafik) upgraden und dann mal vergleichen.

    GNOME 3 kommt mir trotzdem um einiges polierter als diese auf GNOME 2 aufgesetzte Oberfläche vor. Hab mir jetzt halt mal Fedora 15 installiert, einerseits um die alte Arch-Installation hier zu ersetzen, wo ich mit jeder Kernel-Version selber die Module für Catalyst und WLAN neu bauen musste, andererseits um einfach mal ins kalte Wasser zu springen.


    Ich komm mit GNOME 3 recht gut klar. Für Konfiguration brauchts halt [dg]conf-editor und Shell-Extensions, aber ob ich jetzt meine Applets jetzt für awesome in dessen Lua-Config-File programmiere oder in GNOME in den Shell-Ordner als JS-Extension macht irgendwie auch keinen Unterschied. Wer GUI-Konfiguration will war bei GNOME eh immer schon fehl am Platz, mit Version 3 wurde es halt noch etwas krasser. Einstellen kann man in gewohnter Unix-Manier trotzdem alles, wenn man weiss wo.

    Zitat von DosAmp

    Was ich übrigens auf technischer Ebene mitbekommen habe: Früher war die Firefox-Versionsnummer immer eng an die Versionsnummer der Gecko-Renderingengine gebunden (…, Firefox 3.0: Gecko 1.9, Firefox 3.5: Gecko 1.9.1, Firefox 3.6: Gecko 1.9.2, Firefox 4.0: Gecko 2.0) und jede neue Revision von Gecko hat auch eine neue Revision von Firefox (und umgekehrt) impliziert.


    Wirklich gepasst hat das damals nur bei der Mozilla Suite (heute SeaMonkey), wo die Gecko-Versionsnummer auch die vom Browser war. Beim Firefox gabs schon Unstimmigkeiten, z.B. Firefox 1.0: Gecko 1.7, Firefox 1.5: Gecko 1.8, Firefox 2.0: Gecko 1.8.1. Sicherlich, die Versionsnummer wurde erhöht, aber Major/Minor-Schritte sind asynchron.

    Es empfiehlt sich überigens, da auch mal noch die Stromspar-Optionen von fdapm anzuschauen. Damit läuft die CPU nicht mehr ständig auf 100%, sondern es werden Schlafbefehle dazwischen gestreut, wenn ein Programm gerade auf den User wartet (o.ä.). Erhöht die Akkulaufzeit ernom.

    Neues Versionsschema ist gut so. Gibt schon nen Grund warum gerade Browser darauf stehen:
    Im Web ist es für die Web-Entwickler wichtig, dass die Leute aktuelle Browser benutzen, damit man einigermassen brauchbare Features hat und nicht auf Steinzeitkompatibilität machen muss.

    Lieber häufig die Major-Versionnummer erhöhen, als grosse Änderungen in kleinen Versionssprüngen verstecken. Firefox 3.0 auf 3.5 war unter der Haube der technisch grössere Sprung als von 3.5 auf 4.0.

    Wenn einem Enduser die 3.5er aus irgendeinem Grund nicht gefällt, dann wird er bei der 3.0er bleiben: "Ist ja nicht viel geändert, sieht immer noch gleich aus". Ist hingegen 4.0 draussen und man hat 3.5, ist der Update-Drang stärker. Mit grossen Versionsnummernsprüngen wollen die Entwickler die User zum Updaten motivieren. Damit der User merkt, dass seine Chrome 10.0 jetzt mit dem Release von 13.0 doch recht veraltet ist, was er bei einem Firefox 3.0 auf 3.7 nicht merken würde.

    4K Sektoren machen meines Wissen eh alle Dateisysteme mit, weil die auch alle kein kleineren Einheiten als 4K verwalten. Einfach bei der Partitionierung aufs Alignment achten, dass die Partiton bei einem 4K-Block beginnt. Im Zweifelsfall die Dokumentation der Distribution nachschlagen, da sollte betreffend dem Installer etwas drinstehen.

    Zur Kompression: Transparente Kompression hat meines Wissens leider nur Reiser4 (recht alt, nahezu tot) oder btrfs (recht neu, noch nicht stabil). Benutzbar wird bei Debian wohl nur Reiser 4 sein, wenns denn unterstützt wird. An sich wird es schon laufen, aber modern ist es halt nicht.

    Ansonsten wüsste ich nur von readonly komprimierten Dateisystem wie squashfs. Aber die sind eher für Live-Systeme in Kombination mit einem Union-Mount-Dateisystem gedacht.

    Nachtrag: Ah, fusecompress kannte ich gar nicht. Klingt auch gut, nimm im Zweifelsfall das mit deinem bevorzugten Dateisystem.

    Ich hab auch nur Halbwissen, aber DosAmp scheint recht zu haben: Gemäss dem Wikipedia-Artikel erzeugt der Atom viel mehr Microcode-Instruktionen als die Vorgänger, hat also viel weniger Instruktionen direkt in Hardware implementiert als andere x86er-Prozessoren. Und diejenigen, die sie in Hardware implementiert haben, wird kaum der alte Legacy-Scheiss sein.

    Des weiteren hat der Atom wirklich sehr primitives Pipelining, deswegen hat er auch Hyperthreading, damit die CPU bei Multitasking-Systemen immer etwas zu tun hat. Alte DOS-Programme werden nur einen logischen Kern nutzen und die CPU wird damit häufiger im Leerlauf sein. Okay, der Pentium scheint das genau gleich zu machen, auch wenn ohne HT.

    Aber für eine wirklich korrekte Aussage müsstest du mal Benchmarking machen. 10x langsamer klingt irgendwie nach Fehler.