Also auf meinem Thinkpad (P3-M 700MHz) mit 384MB RAM läuft YouTube und so noch perfekt, allerdings dann schon mit einer Auslastung von 90%...
Alternativ lässt man das üble Flash-Plugin weg und schaut sich die .flv-Datei in einem herkömmlichen Media-Player, der eh mehr drauf hat.
Zitat von pETe!Meinste nicht man kann mit irgendeiner Rewriterule den Direktzugriff verbieten?
Man könnte Referer-Prüfung machen, lässt sich aber auch umgehen.
Was man könnte, wären temporäre URLs. Am sichersten ist es, via PHP-Script die Datei selber auszuliefern. Da kommt dann keiner mehr an die Datei ran. Aber eben, aufwändig und nen Stück langsamer.
Am sinnvollsten und einfachsten dünkt mich eine schlichte Weiterleitung, die zählt. Kostet nichts, du brauchst dich nicht um die Sicherheit kümmern und jeder Browser- oder Dateimanager kommt damit klar.
Ich mach sonst heut' Nacht oder dann halt morgen früh was. Jetzt muss ich aber weg.
Zitat von Dirkbtw kennt sich jemand mit php downloadzählern aus? wobei ich gelesen habe, das wohl bei einfachen gerne sicherheitslücken entstehen?
Das Problem ist halt, dass wenn du die Dateien via readfile() oder ähnliches via PHP durchreichst, dass du da filtern musst, was jetzt in Ordnung ist und was nicht. Nicht, dass dir jemand Passwortdateien oder so (falls vorhanden) runterlädt. Zudem ists langsamer, braucht mehr Ressourcen, bietet keine Wideraufnahme und keine Caching. Letzere zwei lassen sich zwar implementieren, aber ist halt mehr Aufwand. Du machst sozusagen einen HTTP-Server in PHP.
Mein Vorschlag wäre, dass du die Dateien zwar auf ein PHP-Skript verlinkst, im Skript den Zähler eins hochzählst und dann via HTTP 302 auf die richtige Datei weiterleitest.
Damit lässt sich der Zähler zwar umgehen, wenn man den Link aus dem HTTP-Header rausholt und manuell verlinkt, aber dafür ist es schnell und sicher und besser.
Wenn du willst bastel ich dir da was.
Das MIPS-Plugin ist nichts weiter als das normale cpuinfo-Plugin mit anderen Strings. Damit kannst du nichts anfangen.
Naja, momentan steht die Entwicklung. Ich hab rausgekriegt, wie man mit POSIX Code aus .so-Dateien nachladen kann - also dass man die Plugins nicht mehr reinkompilierne muss. Nur ist das nicht grad trivial. Mal schauen wann ich eine 0.2.0 mache.
Live-Alben sind schon so ne Sache - kommt ganz auf die Band, das Publikum und die Aufnahme bzw. das Mastering drauf an.
Gibt Live-Alben, die sind einfach nur scheisse und es gibt solche, die cooler sind als alle anderen Studio-Alben.
Pflichten sind selten toll - aber die Idee klingt nicht schlecht.
Warum nicht einfach ein "Soll-Gesetz" einführen? Am Ende liegts im Interesse des Autofahrers - also soll auch der entscheiden. In der Schweiz gibt es z.B. ein "Soll-Gesetz", dass man auch bei Tag mit eingeschaltetem Licht herumfährt - mit dem Ergebnis dass geschätzte 80-90% der Leute jetzt auch am Tag das Licht eingeschaltet haben, was die Sichtbarkeit ernorm erhöht.
Stopp. Keine Flames hier. Ich werde jeden höchstpersönlich verachten, der hier jetzt anfängt zu streiten. Wenn euch der Thread hier egal ist, dann ignoriert ihn, und er wird von alleine verschwinden.
tk1908, was meinst du damit? Noch nie davon gehört oder es bei dem Vista da gesehen.
Zitat von meekee7gandro, es ist nun mal theorie vs. praxis
Dieses Argument gilt in der Physik. Aber nicht in der Informatik.
Einziger Kritikpunkt an meinem Beitrag, den ich vorhin bemerkt habe, ist, dass sich NTFS evtl. etwas anders verhält als das, von dem ich ausgegangen bin (ext*, UFS, XFS etc...).
Zitat von meekee7so erreichte ich mehr einfach einen Fragmentierungsgrad von 30-40 Prozent
Sag mal, rede ich an eine Wand?
Herrgott. Also.
Früher:
MS-DOS-Rechner, das heisst auf dem Rechner läuft genau ein Programm. Wir haben Festplatten oder gar Disketten mit Zugriffszeiten, die Ausreichen zwischen einzelnen Bytes sich nen Kaffee zuholen *narf*. Arbeitsspeicher ist überigens auch knapp, so dass man da nichts überflüssiges drin haben will.
Ein durchschnittliches Programm liest eine angeforderte also byteweise (Zeichen für Zeichen) in den RAM ein und verarbeitet die Daten auch möglichst schnell wieder (denn den RAM braucht man für anderes) wie möglich. Da macht es natürlich Sinn, wenn die Datei schön von Anfang bis Ende zusammenhängt, damit möglichst keine Rechenzeit mit Zugriffszeiten und Suchen vergeuded wird. Also defragmentiert man.
Heute:
Multitaskingsysteme wo mehrere duzend bis hunderte von Prozesse gleichzeitig am laufen sind. Festplatten mit Zugriffszeiten von weniger als 10ms. Arbeitsspeicher im GByte-Bereich.
Das bedeutet, so ein Multitaskingkernel muss meistens mehrere Dateien gleichzeitig verarbeiten. Damit er da nicht von Datei zu Datei springen muss, sortiert er die Zugriffe also vorher kurz, so dass er vorne anfangen kann und hinten aufhört und zwischendrin seine Dateien rauspickt. Zudem liest er nicht nur die angeforderten Bytes, sondern in der Regel grad ganze Blöcke, weil Arbeitsspeicher ist genug vorhanden. Zudem erkennen moderne Betriebsysteme (Vista, Linux 2.6) was der Prozess vermutlich als nächstes haben will, und laden das präventativ auch grad noch ins RAM, wenn sie sowieso grad am Daten auslesen sind.
Das Auslesen ist also relativ optimiert. Das meiste befindet sich bereits im RAM bevor es überhaupt angefordert wird. Also bringt hier Defragmentieren wenig. Und selbst wenn sich die Daten noch im RAM befinden: Meistens werden eh verschiedene Dateien gleichzeitig eingelesen, also muss das Betriebsystem so oder so an verschiedenen Orten im Dateisystem auslesen, da hilft auch Defragmentieren nicht dagegen - dafür ist dieses Auslesen so sortiert, dass nicht herumgesprungen werden muss. Zudem sind die Zugriffszeiten von Festplatten heutzutage ebenfalls schnell genug.
Für dieses "wenig" zu Defragmentieren ist allerdings ebenfalls Blödsinn: Denn Schreibvorgänge muss man ja auch tätigen. Wenn man also in mitten einer schön aufgeräumten (defragmentierten) 700MB grossen Datei ca. 15 MB hinzufügen will, kann man das nicht an der ursprünglichen Stelle tun, man muss dies anderswo machen (sonst würd man ja Daten überschreiben). Diesen Platz zu finden braucht Zeit. Aus diesem Grund fragmentieren moderne Dateisysteme grosse Dateien absichtlich und lassen Blöcke in der gleichen Blockgruppe frei, damit bei einer Änderungen diese in der gleichen Blockgruppe geschrieben werden können (weil die Informationen, welche Blöcke in der gerade geöffneten Blockgruppe frei und welche belegt zum Lesen bereits geöffnet werden mussten, man also nicht noch extra suchen muss).
Wird der Speicherplatz knapp, wird dieses Verhalten abgestellt, weil es sonst kontraproduktiv wäre. Darum sollte man Dateisysteme nicht überfüllen, denn dann werden sie langsam - egal ob defragmentiert oder nicht.
Dazu kommen noch dateisystemabhängige Spezialitäten, auf die ich hier nicht eingehen will.
Lange Rede, kurzer Sinn: Defragmentieren ist fürn Arsch. Und ist oftmals sogar kontraproduktiv. Die Dateisysteme nicht überfüllen (weniger als 80% füllen) ist die einzige richtige Massnahme, um ein Dateisystem schnell zu halten.
Nachtrag: Nur der Vollständigkeithalber, aber wurde ja bereits ansatzweise diskutiert: SSDs defragmentieren ist im übrigen dann völliger Blödsinn: Flashspeicher-Zellen überstehen nur eine gewisse Anzahl an Schreibe- (bzw. Lösch-)Zyklen. Dafür sind die Zugriffszeiten für alle Zellen identisch (anders als bei einer Platte spielt der physische Abstand zwischen zwei Bits kein Unterschied). Aus diesem Grund verteilen SSD-Controller die Schreibvorgänge, damit alle Zellen in etwa gleich beansprucht werden (und nicht Zellen wo z.B. Logdateien drauf gespeichert sind, schneller abgenutzt werden). Da mit einem Festplatten-Defragmentierungstool drüberzufahren wäre übelster Blödsinn. Für SSDs empfehlen sich zudem andere Dateisysteme als für Festplatten. Hier gibt es verschiedene Optimierungsebenen (Dateisystem, Betriebsystem, SSD-Controller) - ob SSDs ab 50% freiem Speicherplatz einbrechen ist also von diesen drei Faktoren abhängig.
Zitat von meekee7HDD defragmentieren kann auch einiges einbringen
Nö. Ein Mythos der seit Win95 jegliche Wahrheit verloren hat, aber sich trotzdem hartnäckig hält.
Nochmal fürs Protokoll: Multitasking-Betriebsysteme profitieren so gut wie nichts von einer defragmentierten Festplatte. Ich erklärs bei Bedarf gerne nochmal warum genau.
Zitat von HOMEBOY87- das EP43 Light board (DS3L = Light/Lite) gekickt und ein bekannt gutes (dafür älteres) genommen (huhu gandro :P)
Jup, das GA-EP35-DS4 läuft toll hier. Kann ich auch weiterempfehlen. Hat ein paar nette Features. Wird ab Linux 2.6.28 inkl. Temperatursensoren vollständig unterstützt. (Einzig ob dieser Dynamic Energy Saver unter Linux aktiv ist, hab ich noch nicht rausgefunden, aber halb so tragisch).
Achtung: Nur 8800/9800 GT. Aber wie gesagt, die kriegst du fast nur noch gebraucht.
Nachtrag: Zum Netzteil, ich find 600W völlig überdimensioniert.
Deine 9800GT braucht max. 115W, dein E8400 hat eine TDP von 65W. Ich glaub kaum, dass das Mainboard, die Peripherie und die Verlustleistung des Netzteils die "übrigen" 420W verbraten.
Zitat von DirkBei den Nvidia Karten sehe ich inzwischen auch nicht mehr durch. zuviele renames. aber denke die taugt schon was?
Die 9800GT ist eigentlich eine umgelabelte 8800GT. Siehe Wikipedia
Chrisse, wenn du also eine gleichwertige aber günstigere 8800GT kriegen kannst, kannst du getrost umsteigen. Wobei es die 8800GT neu kaum mehr zu kaufen gibt, und selten günstiger.
Glaub ich jedenfalls.
Naja, der Kommentar da auf der Seite stimmt schon: Die entsprechenden Anwälte werden das jetzt auch gehört haben und mit ihrer Bank geredet haben, dass die andere Konditionen kriegen.
Also Arbeitspeicherverbrauch ist bei beiden ja gleich (200kB (10000Bx5Bx32b)). Vom Rendering her könnte es rein theoretisch einen Unterschied machen (aber das wäre browserabhängig), wobei ich keine Ahnung hab, ob die Browser da irgendwie auf höhere Seiten optimiert sind oder nicht
Was dann noch überig bleibt, wäre das Dateiformat an sich. JPEG kennt sowohl horizontale als auch vertikale Muster. PNG meines Wissens ebenfalls. Aber der Aufbau des Dateiformat dürfte eigentlich der einzige browserunabhängige relevante Punkt sein, wenn es denn einer ist.
Kurz um: Ich weiss es auch nicht 
Abgesehen von der schwachsinnigen Sperre. Die Befürworter hier übersehen hier etwas: Das Internet ist nicht die Ursache des Problemes. Musik wurde schon lange vor dem Internet kopiert und wird auch "nach" dem Internet noch kopiert werden.
Ich hab noch vor wenigen Jahren auf dem Schulhof gebrannte CDs mit Spielen und Musik getauscht - erst seit ich Breitband habe, mache ich das ernsthaft übers Internet.
Mit den fallenden Preisen von Speicherplatz (grad heute wieder nen kleinen Schock gekriegt, einen 4GB USB-Stick krieg man zum Preis von 3 Kaffees) wird sich die Szene im Falle eines abgeschottenten Internets halt wieder zurück auf die Schulhöfe verlagern.
Das Kopieren von Kulturmaterial ist nunmal seit immer Teil der Kultur. Neu ist dank der Informationstechnologie lediglich, dass das Kopieren heutzutage einfach ist - und das lässt sich nicht mehr rückgängig machen. Genau so wenig wie sich die Erfindung der Atombombe hat rückgängig machen lassen, um ein sehr unpassendes Beispiel zu wählen. Damit muss sich die Content-Mafia abfinden.
Zitat von oreissigVon den Features her sind eigentlich alle Betriebssysteme so halbwegs state of the art, jedes gängige Unix hat inzwischen Paging statt Swapping, jedes gängige hat ladbare Kernelmodule, jedes hat mehrere Dateisysteme, jedes hat Netzwerk mit TCP/IP, etc...
Das wird jetzt Off-Topic, aber "State of the art" geht im Jahr 2009 meiner Meinungnach über TCP/IP (wenn, dann sowieso IPv6) hinaus, da hat sich in den letzten Jahren nämlich schon was getan: Dinge wie Speicherausführungsschutz, Dateisysteme mit ACLs, Snapshots, Scheduler mit Prozessheuristik, Virtualisierungssuport etc. (Off-Topic Ende).
Zitat von meekee7Ist doch gar nicht so abwegig.
Wer mehr als gelegentlich gegen die Verkehrsregeln verstößt kann auch ein Fahrverbot erhalten.
Oder Spieler, die sich auf dem Platz daneben benehmen werden gesperrt.
Wieso dann nicht auch im Internet?
Ganz einfach: Du vergleichst hier Äpfel mir Birnen.
Man wird nämlich aus dem gesamten Internet rausgeschmissen - wenn du nicht Autofahren darfst, darfst du nach wie vor noch ÖV, Fahrräder und den Fussgängerweg verwenden. Es gibt genügend Alternativen.
Zum Internet gibts keine Alternative.
Technische Unterschiede zwischen Linux und... welchem Unix? Die Frage lässt sich einfach so nicht stellen.
Was verstehst du unter "technisch"? Von der Anwendung her und der Quellcodekompatibilität sind sich die meisten unixoiden Betriebsysteme recht ähnlich, dank Standard wie POSIX oder SUS.
Unter der Haube hingegen findest du alles mögliche. Linux ist monolithisch (mit modularen Erweiterungen), die *BSDs meines wissens auch. Minix hingegen ist ein Mikrokernel, OS-X ist ein Gemisch aus Mikrokernel (Mach) und Monolith (BSD). Tru64 hingegen ist wieder ein Mikrokernel-System.
Weil es DAS Unix nicht gibt, sondern eben mehrere Systeme, die sich selber Unix nennen (sich als UNIX® vermarkten dürfen sich nur SUS-konforme Systeme - diese haben aber im Falle von OS X nichts mit dem ursprünglichen AT&T UNIX am Hut), kannst du auch keine festen Unterschiede herausstreichen.
Linux ist ein Unix-Derivat. Ein System, dass sich an all den anderen Unixen und Unix-Derivaten (wie z.B. Minix) orientiert hat, inzwischen aber viele Features hat, welche den traditionellen Unix-Systemen fehlten und daher dort wieder übernommen wurden.
