Laptops, Tablets, Convertibles 11.829 Themen, 56.657 Beiträge

Verfolgung starten Optionen
News: Neuer Stoff für Gejammer

Bei Microsoft Surface Pro droht knappe Speicherkapazität

Michael Nickles / 25 Antworten / Baumansicht Nickles

Mitte November vergangenen Jahres hat ein Rechtsanwalt Microsoft in den USA verklagt: wegen dem Speicherverbrauch von Windows RT beim Surface Tablet. Der Anwalt regte sich auf, weil bei seinem mit 32 GByte gekauften Surface RT Tablet nur 16 GByte frei waren.

Rund die Hälfte des Speichers wurde also vom RT-Betriebssystem und den vorinstallierten Anwendungen verbraten. In der Werbung zum Surface RT hatte Microsoft nicht mitgeteilt, wie viel Speicher frei ist.

Jetzt könnte es aber bald noch viel übler kommen, wenn man einem Bereicht von Softpedia Glauben schenkt. Microsoft soll mitgeteilt haben, dass beim in Kürze kommenden Surface Pro mit Windows 8 Pro von 128 GByte nur 83 GByte frei sind.


Die Surface Pro Modelle mit Windows 9 Pro lässt Microsoft ab 9. Februar erstmal nur in den USA und Kanada raus. (Foto: Microsoft)

Stimmt diese Angabe, dann belegt Windows 8 Pro auf dem Tablet also rund 45 GByte. Im Fall des Tablet-Modells mit 64 GByte würden also nur rund 19 GByte für eigene Zwecke verbleiben. Konkret sollen von den 64 GByte laut Bericht von The Verge 23 GByte frei bleiben.  

Die komplette Wahrheit wird wohl in wenigen Tagen am 9. Februar rauskommen, wenn Microsoft das Surface Pro mit Windows 8 in den Handel bringt.

Michael Nickles meint:

Gut 40-45 GByte sind bei einem Desktop oder Laptop "nichts", auf einem Tablet-PC allerdings ein ganz schön fetter Brocken. Generell ist es natürlich schnuppe, wie viel ein Betriebssystem braucht - was zählt, ist was rauskommt, wie es funzt.

Sollte Windows 8 Pro auf Tablets allerdings wirklich gut 40 GByte brauchen, dann sollte man sich den Kauf eines Surface Pro Modells mit "nur" 64 GByte schon sehr gründlich überlegen. Das kann schnell eng werden.

Natürlich wird ein Teil der Speicherkapazität für ein Backup des Systems, den Fall einer "Neuninstallation" benötigt - und den kann man frei kratzen. Laut Microsoft kann man einen bootfähigen USB-Backup-Datenträger anfertigen und die Recovery-Partition löschen.

Eine saubere Lösung ist das aber nicht - wer viel unterwegs ist, muss dann halt immer für den Notfall diesen Datenträger dabei haben.

bei Antwort benachrichtigen
reader Michael Nickles „Bei Microsoft Surface Pro droht knappe Speicherkapazität“
Optionen

was machen die mit dem speciher? die müssen doch keine riesendatenbanken an treibern mitführen!? wisst ihr noch - Win98 auf 500Mb? WinXp auf 4GB? 
Was ist passiert - haben die schmiere von speicherherstellern gekriegt oder deren programmierer mit reis bezahlt?

bei Antwort benachrichtigen
sea reader „was machen die mit dem speciher? die müssen doch keine ...“
Optionen

@reader:
Ganz einfach, heutzutage wird schluddrig programmiert.

Wo früher ein Druckertreiber vielleicht 10 MB benötigte, sind heutzutage für beinahe dieselben Funktionen locker mal 500 MB fällig. Manche Patches sind fetter als früher ganze Games.

Ich mag mir nicht vorstellen, wie rasend schnell die Hardware wäre, wenn sämtliche Softwarehersteller schlank und effizient programmieren würden. 

Gruss
sea

bei Antwort benachrichtigen
Newton2k1 sea „@reader: Ganz einfach, heutzutage wird schluddrig ...“
Optionen

Unsere HP-UX-Maschinen haben 512MB (!!!) RAM, 200MB Boot Partition und zwischen 9 bis 72GB Harddisk. Auf einer Maschine arbeiten ca. 3 bis 20 Personen, jeder mit einer grafischen Oberfläche versteht sich. Es ist alles nicht so bunt und hat weniger Funktionen aber wir schaffen damit Werte! Ohne Virenscanner oder automatischen Systemupdates. Reboot wird aller zwei Jahre gemacht wenn wir den Staub aus den Kisten saugen. Durch den Dauerbetrieb saugen die ziemlich viel ein und das liegt dann auf dem MoBo hinter den Lüftern.

Jedes Windows ist dagegen einfach nur Spielzeug. MacOS X reicht am ehesten in punkto Stabilität an UNIX heran. Und bei iOS ist soviel GB drin wie drauf steht :-)

Man kann gut programmieren, aber ich vermute, das Microsoft unter seinen eigenen Altlasten leidet. Sie wollen gern UNIX-ähnlich sein aber der träge Moloch der enormen Menge Programmierer klebt im Sumpf seines eigenen, in Jahrzehnten gewachsenen SourceCode fest und kann einfach keine neuen Technologien flächendeckend einführen.

Apple hat da einfach eine Zäsur durchgeführt und bei Beibehaltung der Abwärtskompatibilität eine neue CPU und danach auch noch ein neues OS eingeführt. 

Obendrein funktioniert fast jedes LINUX auf Windows-kompatiblen Rechnern viel besser als Windows höchstdaselbst. Bei IBM- bzw. Lenovo-Computern kann man ein Windows installieren und es wird nicht einmal die Netzwerkschnittstelle erkannt, bei ruckelnder VGA Auflösung (640x480). Sowas passiert mit LINUX nie. 

Ja, da müssen viele schlechte Programmierer am Werke sein... Was sonst?

bei Antwort benachrichtigen
Xdata sea „@reader: Ganz einfach, heutzutage wird schluddrig ...“
Optionen

Absolute Zustimmung!

Die können garnicht mehr programmieren.

Es scheint nur noch übelste Bloatware zu geben..
hatte schon mal, die zugegeben übertriebene Vision,
-- man braucht bald für ein "Hello World" die vollen 64GB RAM die eine 64Bit CPU direkt adressieren kann!

Die alten Pascal - ja selbst Algol Programmierer waren anscheinend besser.
-- Haben noch richtig "direkt" programmiert und auch compiliert.
Nicht aus, millionen mal lahmeren, modernen scriptähnlichen Sprachen zusammengebastelt.

Auch c und deren Derivate sind nicht soo der Renner.
Erstere ist wohl, laut Aussage eines Ada Programmierers
-- ein nicht gelungener Hybrid aus einer maschinennahen und dem Versuch einer Hochsprache.

Die ist aber wohl  nicht der Grund warum anscheinend alles immer fetter und lahmer wird.
Wobei fett nicht selten noch untertrieben ist.

Es scheint an den vermeintlich ganz modernen Methoden der heutigen Programmierung zu liegen.

Alles indirekt und allgemein, nicht mehr aufwendig da spezieller, hauptsache die Umsetzung geht schnell.
Dabei scheint die Spezialisierung (Abhängigkeit) durch mächtig umfangreiche "Umgebungen" eher zuzunehmen.
Was muß nicht alles installiert sein um die einfachsten Geschichten zu machen*.

Selbst Grafikkarten und anderes, eigentlich autonom von der Hardware aus funktionierendes,
ist von Entwicklungsumgebungen oä. künstlich abhängig gemacht.

* Dieses und jenes geht nicht wenn nicht zwingend dies und sonstwas zwingend installiert ist.

Gute alte Rechner sind fast nicht mehr brauchbar, neue und ganz neue auch nicht wirklich schnell.
Effektivität sieht anders aus.

Sebst surfen wird zur Qual, falls mal ein paar Webseiten mehr auf sind.
Und besser als noch 256MB RAM reichten sieht Internet heute  auch nicht aus.
Die Animationen waren genau so gut.
Ohne irre viel RAM.

Nachtrag:

Wenigstens einige Mobiltelefone haben gezeigt:

Es geht auch anders.

Dann ist es bedauerlich wenn jetzt ein fettes Desktop Betriebssytem bestimmt:
"es geht auch lahm dick und schwerfällig!"

bei Antwort benachrichtigen
Maybe Xdata „Absolute Zustimmung! Die können garnicht mehr ...“
Optionen

Moin,

meine rudimentären Programmierkenntnisse sind lange veraltet. Wie kann man das vergleichen? Wie wird heute programmiert.

Ich stelle mir das am Beispiel MS Frontpage und reiner HTML-Programmierung vor, evtl. mit Javascript und CSS. Eine Frontpage-Website ist oft elend fett und schleppt viel Balast mit, der wohl der einfachen Bedienung geschuldet ist.

Wenn Programmierung heute ähnlich läuft, also nur fertige Baukästen zusammengefügt werden, so könnte ich mir das vorstellen.

Sorry für die dumme Frage, ich möchte es mir halt nur verdeutlichen, was den reinen Source-Code so aufbläht.

Win8/RT baut afaik immer noch auf Vista auf und schleppt somit vieleicht wirklich sehr viele überflüssige Altlasten mit. Im Falle von RT kann ich das schon garnicht nachvollziehen, denn das hätte man gravierend entschlacken und anpassen können.

Gruß
Maybe

"Es gibt nur eine falsche Sicht der Dinge: der Glaube, meine Sicht sei die einzig Richtige!" (Nagarjuna, buddhistischer Philosoph)
bei Antwort benachrichtigen
Xdata Nachtrag zu: „Absolute Zustimmung! Die können garnicht mehr ...“
Optionen

Hab` ganz bescheiden zur Zeit der Atari und Amiga Rechner Programmiert.

Mein erster Atari 800 sieht auch heute noch klasse aus :)
Hatte schon mal ein paar Bilder hier reingestellt.



Da gab es nur Zeilen BASIC.
Dennoch konnte man mit dem Gita Chip ganz gute dynamische Grafische Tapeten damit programmieren.


Später, der Amiga 600
Konnte allein mit dem "Bios" so Programmiert werden um die Tasten in ein elektronisches
Instrument zu verwandeln:
Englisch  konnte der Kleine auch :-)
In der Tastatur getippt - und schon sagte er das Wort auf Englisch.







In der PD Community bekam man freie Programmiersprachen die viel strukturierter als BASIC waren.
fast Pasccal ähnlich.

LOGO war der Hammer, eine listen orientierte Sprache mit der man Ingenieur mäßige Geschichten
Regelungen oder geometrische Abläufe schreiben konnte,
mit BASIC auch von einem Meister wohl unerreichbar.

An die heutigen großen Umgebungen würd` ich mich nicht mehr rantraun.
Die ändern sich auch ständig. Der "Code;-)" wäre wohl nicht lange kompatibel..

Sicher gibt es im Internet noch Bilder von  älteren Schätzchen :-)
So einen der modernen großen  SincLair in schicken  Schwarz hätt ich gern gehabt...

bei Antwort benachrichtigen
BastetFurry Xdata „Absolute Zustimmung! Die können garnicht mehr ...“
Optionen
An die heutigen großen Umgebungen würd` ich mich nicht mehr rantraun. Die ändern sich auch ständig. Der "Code;-)" wäre wohl nicht lange kompatibel..
Dann schau dir mal FreeBASIC an. Das ist ein freier Nachbau von QB45 in 32-Bit mit Erweiterungen wie Objektorientierung und der Möglichkeit alle Bibliotheken der GCC (Ja, "der" ;) ) mit zu nutzen.
bei Antwort benachrichtigen
Xdata Nachtrag zu: „Absolute Zustimmung! Die können garnicht mehr ...“
Optionen

Danke - BASIC weckt Erinnerungen .. Damals hieß es, bloß nicht so viel GOTOs verwenden.

Die Zeilennummerfreien fast Pascal ähnlichen Basic hatten dies
aber oft doch noch irgendwo verstekt.

bei Antwort benachrichtigen
kongking Xdata „Danke - BASIC weckt Erinnerungen .. Damals hieß es, bloß ...“
Optionen
Damals hieß es, bloß nicht so viel GOTOs verwenden.

Yo, die alte Regel. Die Sprache verführt aber dazu ;-)

Gruß- Kongking
kongking
bei Antwort benachrichtigen
Olaf19 Xdata „Danke - BASIC weckt Erinnerungen .. Damals hieß es, bloß ...“
Optionen
Die Zeilennummerfreien fast Pascal ähnlichen Basic hatten dies aber oft doch noch irgendwo versteckt.

Ja, zum Beispiel Omikron Basic. Da konnte man die Zeilennummerierung einfach auf Knopfdruck ein- und ausschalten. Ferner gab es einen RENUM-Befehl, mit dem sich die Nummerierung komplettt neu aufbauen ließ.

GOTO war bei Omikron verpönt; wenn überhaupt, dann nicht GOTO {Zeilennummer}, sondern GOTO {Marke}, einem String, den man selbst definiert und benannt hatte. Besser waren GOSUB-Befehle, mit denen man ein Unterprogramm ausführen konnte, und die eleganteste Möglichkeit waren selbstdefinierte Prozeduren (DEF PROC) und Funktionen (DEF FN).

CU
Olaf
Die Welt ist ein Jammertal ohne Musik. Doch zum Glueck gab es Bach, Beethoven, Haendel und Goethe (Helge Schneider)
bei Antwort benachrichtigen
Xdata Nachtrag zu: „Danke - BASIC weckt Erinnerungen .. Damals hieß es, bloß ...“
Optionen

Ja Omikron :)  Die Prozeduren waren da ein großer Fortschritt.

GOSUB reichte aber für einfache Dinge aus.
Das sag ich einfach so, dabei würde ich es so wahrscheinlich nicht mehr schreiben können..

Die Geräte waren aber noch überschaubarer, einiges eher von Elektronik autonom gelöst
wo man heute auch programmierem müßte.
Feste Funktionen die die Teile alleine konnten.

Wichtig war:

Programme waren weitgehend aus eigener Kraft lauffähig, Das Betriebssystem nicht
Sebstzweck oder für "alles" zuständig.
Compilierte liefen sogar ohne Betriebssystem direkt mit der Hardware.
Die Programme waren der Chef - nicht das Betriebssystem!
Da BS war nur der für den Betrieb  des Systems, der Hardware zuständig
und hat sich ansonsten rausgehalten.

Müßte sicher einige zeit Üben um die bescheidenen Programme von damals wieder zu Überblicken.

bei Antwort benachrichtigen
BastetFurry Xdata „Absolute Zustimmung! Die können garnicht mehr ...“
Optionen

Im vollen FreeBASIC-Modus kannst du IIRC keine Zeilennummern verwenden und musst deine Variablen mit Dim deklarieren.
Übrigens endlich in einer vielleicht ungewohnten aber lesbaren Syntax:
dim as integer foo, bar, baz(0 to 234)

Wer eher OldSchool QuickBASIC ohne die alten Limits haben will sollte sich QB64 ansehen. :)

bei Antwort benachrichtigen
Xdata Nachtrag zu: „Absolute Zustimmung! Die können garnicht mehr ...“
Optionen

FreeBasic sieht gut aus.

Ein Kollege der sich für erstes Kennenlernen des Programmierens sucht sowas.
..Java und c sind ungeeignet für den ersten Kontakt.. hat ein Programmierer ihm geagt.
Obwohl der selber mit .NET und klassischem c arbeiten muß.

QBasic hat dem Kollegen schon zugesagt, aber nur für einen  uralten LapTop mit Win3.11
DOS und Geoworks.
Letzteres war eine Empfehlung von mir.

bei Antwort benachrichtigen
Xdata sea „@reader: Ganz einfach, heutzutage wird schluddrig ...“
Optionen

Beim RAM Verbrauch ist Linux seit einiger Zeit deutlich unterlegen*.

Windows  7 oder Windows 8    64Bit kann man, wenn man nicht zu viel macht,
noch mit 1GB RAM akzeptabel betreiben.

Ein Celeron 440 mit einem Kern reicht da.

Mein Windows 8 ist versehentlich auf einem Via Sempron mit zuerst 1GB gelandet, hat sich aktiviert.
Moderne Linux starten da oft nicht mal..

* Bei mehr RAM ist Linux wieder gut :-)

Bei Linux liegt es an der Altlast X Server.

Mac UNIX ist da viel effizienter.

PS:

Bei Apple kann auch UNIX vernünftig "Grafik"

bei Antwort benachrichtigen
Borlander sea „@reader: Ganz einfach, heutzutage wird schluddrig ...“
Optionen
noch richtig "direkt" programmiert und auch compiliert. Nicht aus, millionen mal lahmeren, modernen scriptähnlichen Sprachen zusammengebastelt.

Das würde ich in Zeiten von funktionierenden Just-In-Time-Compilern nicht mehr als generelles Problem bezeichnen.

Es scheint an den vermeintlich ganz modernen Methoden der heutigen Programmierung zu liegen.

Das ist zum Teil auch ein Tribut an die heute erwartete Interaktion. Würdest Du heute noch eine Rechtschreibprüfung im Hintergrund verzichten wollen? Ich nicht.

Die können garnicht mehr programmieren. […] hauptsache die Umsetzung geht schnell.

Teilweise mag das stimmen. Selbst die besten Programmierer haben in der Realität aber häufig nicht die Möglichkeit Software so zu realisieren wie sie es selbst für gut halten…

Gruß
Borlander

bei Antwort benachrichtigen
Borlander sea „@reader: Ganz einfach, heutzutage wird schluddrig ...“
Optionen
Unsere HP-UX-Maschinen haben 512MB (!!!) RAM, 200MB Boot Partition und zwischen 9 bis 72GB Harddisk. Auf einer Maschine arbeiten ca. 3 bis 20 Personen, jeder mit einer grafischen Oberfläche versteht sich. Es ist alles nicht so bunt und hat weniger Funktionen aber wir schaffen damit Werte!
Was genau macht ihr auf den Kisten? 25 bis 170MB pro Nutzer sind nicht gerade viel. Mit Datenbeständen im Bereich von mehreren 100MB werden ihr wohl eher nicht arbeiten nehme ich an?
bei Antwort benachrichtigen
Xdata sea „@reader: Ganz einfach, heutzutage wird schluddrig ...“
Optionen

Ich war der Übeltäter ;-)

In einem Kurs in den Anfängen der Computerzeit ,
hat der Lehrer  geäußert:

Compiliert sei 1000 mal schneller als zum Beispiel eine Interpretersprache oder so.

Hat sich bei mir irgendwie festgesetzt.

Wahrscheinlich weil eins der damaligen Interpreter BASIC soo lahm war.


Gilt ja vielleicht nicht mehr so.
Und ALGOL oder FORTRAN Programmierer sind wahrscheinlich schon fast alle in Rente.

PASCAL soll dann später mal recht beliebt gewesen sein.
Alles noch überschaubar.

@sea die Antworten scheinen alle bei Dir zu Landen:)
auch meine auf Borlander.

bei Antwort benachrichtigen
Newton2k1 sea „@reader: Ganz einfach, heutzutage wird schluddrig ...“
Optionen

Wir steuern Messgeräte über LAN, lesen nach der Messung die Aufzeichnungen, also jedesmal so ca. 60 Kanäle mit jeweils einer halben bis 7 Millionen Messpunkten aus. Diese Daten werden dann angezeigt, ausgewertet (Steigungen, Maximalwerte, Zeitpunkte, etc.), komprimiert und abgespeichert. Als diese UNIX Systeme vor 20 Jahren entwickelt worden sind, musste man unbedingt eine Datenkomprimierung, also  sowas wie "JPEG your Data" einführen und wegen des allgemeinen Speichermangels immer sehr intelligent programmieren. So hat man z.B. diese verlustbehaftete Komprimierung von Daten eingeführt und musste die HD dann nur immer aller halbem Jahr entleeren um weiter arbeiten zu können. 

Wir profitieren noch heute davon und haben unsere seit 1985 aufgezeichneten Messdaten - mittlerweile über 600'000 Files - immer auf Abruf im Netzwerk parat. Unkomprimiert hätten wir statt 65GB (!!!) ca. 3TB zu pflegen. Vor allem auch die Übertragung der Daten in Netzwerken ist so viel schneller.

Viele Ideen, die damals entwickelt worden sind extrem wertvoll und verdienen es weitergepflegt zu werden, wie z.B. unsere Datenkomprimierung.

Um Windows als Nachfolger stabil benutzen zu können werden wir es in isolierten Netzwerksegmenten betreiben und können dort auf automagische Updates und Virenscanner verzichten. Denn Systeme die einmal stabile arbeiten sollte man nicht mehr antastet. Tuesday = Update day ist für uns der Killer.

bei Antwort benachrichtigen
Borlander Newton2k1 „Wir steuern Messgeräte über LAN, lesen nach der Messung ...“
Optionen
also jedesmal so ca. 60 Kanäle mit jeweils einer halben bis 7 Millionen Messpunkten aus.
verlustbehaftete Komprimierung von [Mess]Daten

Das hört sich erst mal nicht so an als ob das erstrebenswert sei. Gegen verlustefreie Kompression mit geringem Overhead ist dagegen nie etwas einzuwenden. Wird auch heute noch verwendet, weil auch auch aktuelle Systeme mit Messdaten an ihre Grenzen bringen kann. Durchschnittlich 5MB unkomprimiert erscheinen mir allerdings erst mal recht unspektakulär.

Gerade bei Messdaten ist ein unkomprimiertes vorhalten in einem einfachen Plain-Text häufig vorteilhaft um universelle Auswertungsmöglichkeiten zu haben. Mit Binärformaten ist man da eher eingeschränkt…

Gruß
Borlander

bei Antwort benachrichtigen
Newton2k1 Nachtrag zu: „Wir steuern Messgeräte über LAN, lesen nach der Messung ...“
Optionen

Wenn die Messtoleranz ca. zehnmal grösser als die, durch die verlustbehaftete Komprimierung entstehenden Abweichungen ist kann man nicht viel falsch machen. Außerdem haben wir Signale, die nur in ca. 10% der Aufzeichnungsdauer interessante Informationen enthalten. Wozu soll man die Flatlines vor und nach dem interessanten Stück mit voller Datenrate immer abspeichern? Sogar bei verrauschten Signalen können wir noch Kompressionsraten mit über 50% Einsparung erreichen. 
Oder denke nur an Digitalsignale: Für die Messung eines Impulses werden fast immer 500'000 Punkte aufgezeichnet und das bei jedem der 56 Digitalkanäle, d.h. 56MB Rohdaten. Nach der Komprimierung werden daraus 56 x 4 = 224 Punkte, die je 4 Bytes belegen plus einem Header von ca. 1kByte. Also exorbitante Einsparungen. Außerdem nutzen wir sogar die z.B. bei einem 12-Bit ADC ungenutzen 4 Bit für die Speicherung. Das ist eben echt effizient programmiert, da 20 Jahre alt und unter scharfen Einschränkungen bei RAM und HD entstanden. Ned so verschwenderisch wie das heute üblich ist. RAM kostet nix - wenn ich DAS schon höre ...

bei Antwort benachrichtigen
Borlander Newton2k1 „Wir steuern Messgeräte über LAN, lesen nach der Messung ...“
Optionen
Für die Messung eines Impulses werden fast immer 500'000 Punkte aufgezeichnet und das bei jedem der 56 Digitalkanäle, d.h. 56MB Rohdaten. Nach der Komprimierung werden daraus 56 x 4 = 224 Punkte, die je 4 Bytes belegen plus einem Header von ca. 1kByte. Also exorbitante Einsparungen

Das würde ich eher als Datenreduktion im Rahmen der Vorverarbeitung bezeichnen. Wenn Du eine halbe Million Datenpunkte auf 4 Werte reduzierst dann umfasst das bereits eine Form der Auswertung…

Außerdem nutzen wir sogar die z.B. bei einem 12-Bit ADC ungenutzen 4 Bit für die Speicherung. Das ist eben echt effizient programmiert, da 20 Jahre alt und unter scharfen Einschränkungen bei RAM und HD entstanden.

Da muss man allerdings abwägen. Die Effizienz der Speicherung steht hier im Konflikt mit der Effizienz der Auswertung. Z.B. bei Grafikkarten hat man ja trotz hoher Speicherpreise 24Bit Farbangaben mit 32Bit vorzuhalten, da die Verarbeitungsgeschwindigkeit davon signifikant profitiert hat. Sofern Speicher vorhanden ist tendiere ich dazu diesen auch zu nutzen um die Verarbeitungsgeschwindigkeit zu erhöhen. Bei sehr großen Datenmengen ist das allerdings auch bei aktuellen Speichergrößen beschränkt…

RAM kostet nix - wenn ich DAS schon höre ...

Eine Stunde Softwareentwicklung kostet mehr als 16GB (oder sogar 32GB) RAM. Bei Individuallösungen kannst Du selbst entscheiden was Du bezahlen willst. Den Aufpreis für die Entwicklung wirst Du nur bezahlen wollen wenn Du ansonsten an die Hardwaregrenzen stößt, oder bei Massenprodukten anderweitig davon profitierst. Die Zeiten in denen Kernspeicher von Hand geflochten wurden und das einzelne Bit noch über 1 Dollar gekostet haben sind seit langem Vorbei…

Gruß
Borlander

bei Antwort benachrichtigen
Newton2k1 sea „@reader: Ganz einfach, heutzutage wird schluddrig ...“
Optionen

Klar ist da vieles schludrig programmiert. Allerdings sind es ja auch sehr viele Programmierer-Köche, die da die Fenster-Suppe versalzen. Je grösser eine Firma wird umso weniger arbeiten Einzelpersonen zusammen. Beim heutigen Leistungsdruck ist das auch sehr schwer, denn Kommunikation braucht vor allem Zeit. Wozu eine Schnittstelle oder ein Programm oder Teil davon sauber definieren, wenn man mit mehr RAM das gleiche Ergebnis erzielen kann? 

Durch die Verwendung von Hochsprachen werden ausserdem Libraries mit Funktionen in den Code gelinkt, die ganz sicher viele Funktionen enthalten, die man gar nicht braucht. 

Ich hatte mal so ein Aha-Erlebnis mit einem Assemblerprogramm für den Motorola 68HC12 Einchip-Rechner. Ich brauchte unbedingt die Grundrechenarten mit 32-Bit Integer-Zahlenbereich und habe mir kurzerhand die vier Operationen in C geschrieben, compiliert und konnte sie nur allein, d.h. ohne irgendwelche andere Programme auf den nur 2kByte grossen EEPROM des 68HC12 schreiben da das Compilat fast 2kB gross war. Nach dem Debuggen und Umschreiben in Assembler konnte ich alles überflüssige, wie z.B. alle Real-Rechnungen und trigonometrischen Funktionen, eliminieren und alles ist dann auf knappe 400kByte zusammengeschrumpft, so dass doch genug Platz für die eigentliche Software war, die diese Rechenoperationen rufen sollten. 

Es gibt dazu das Argument: "Wieso Entwicklungszeit verbrauchen, wenn man es mit billigem Speicherplatz ebenso erledigen kann." Nunja, ich konnte es damals nicht, da ich diesen 68HC12 nehmen musste. Aber jetzt ist ja RAM und HD kein Problem mehr.

Deshalb möchte ich zu gern mal wissen wieviel Code von diesen 40GB des W8 auf den Surface-Tabletts NIEMALS angesprungen werden und behaupte, dass ganz sicher niemals alles davon gebraucht wird.

bei Antwort benachrichtigen
BastetFurry Michael Nickles „Bei Microsoft Surface Pro droht knappe Speicherkapazität“
Optionen

Cool. 40 GByte für ein OS nebst Standardanwendungen verbraten.

Ein frisch installiertes Ubuntu gibt sich übrigens mit ca 2 GByte zufrieden. Und da ist Office und Co schon bei.

bei Antwort benachrichtigen
Wiesner Michael Nickles „Bei Microsoft Surface Pro droht knappe Speicherkapazität“
Optionen

Apropos Speicherverbrauch, ich bin gerade bei einigen Tests mit Virtualisierungssystemen.
Mein Versuch muss auf eine alte Kiste (3 GB Ram).
Ich habe gerade VMware Vspere 5 (linux) via Microsoft HyperV 2012.

Das die "Kiste" mal läuft Vmware mind. 4 GB Arbeitsspeicher und MS Server mind. 512MB.
Vmware machte nicht mal Installation fertig.

Leider habe ich noch keine andere Alternative zum VMware Hypervisor gefunden.
Vmware hat ausser dem Speicherverbrauch aber technisch mehr Vorteile.

bei Antwort benachrichtigen
Newton2k1 Michael Nickles „Bei Microsoft Surface Pro droht knappe Speicherkapazität“
Optionen

Guck Dir mal das schlanke ESXi an. Ich habe es auf einem Lenovo Desktop PC mit nur 3GB installiert und konnte immerhin zwei VMs installieren, ein WXP und ein Ubuntu. Die laufen natürlich nicht schnell aber sie laufen stabil.

bei Antwort benachrichtigen