diff --git "a/resources/tests/golem/HTTP Error 418: Fehlercode \"Ich bin eine Teekanne\" darf bleiben.html" "b/resources/tests/golem/HTTP Error 418: Fehlercode \"Ich bin eine Teekanne\" darf bleiben.html" deleted file mode 100644 index aec51ec..0000000 --- "a/resources/tests/golem/HTTP Error 418: Fehlercode \"Ich bin eine Teekanne\" darf bleiben.html" +++ /dev/null @@ -1,65 +0,0 @@ - - -
- -
- -

- HTTP Error 418 - Fehlercode "Ich bin eine Teekanne" darf bleiben -

-

-Was als Aprilscherz begann, darf nach Meinung vieler Unterstützer nicht aus dem Internet verschwinden: Der HTTP Statuscode 418 "I am a Teapot" bleibt - und könnte sogar zum IETF-Standard werden. -

-
- - -, -
- -
- - - - -
-Teekannen sind Programmierern offenbar wichtig! -
-Teekannen sind Programmierern offenbar wichtig! -(Bild: auoob farabi/CC-BY-SA 3.0) -
-
-
- - - - - -
- - - -

Der im Jahr 1998 als Aprilscherz eingeführte HTTP-Stauscode 418 - "Ich bin eine Teekanne" wird vorerst nicht aus populären Projekten verschwinden. Der Entwurf für den Code wurde von Larry Masinter von der Internet Engineering Taskforce geschrieben, eine Initiative des australischen Programmierers Mark Nottingham zur Abschaffung wurde jetzt abgelehnt. Der Code gibt folgende Nachricht aus: "418 Ich bin eine Teekanne. Jeder Versuch, mit mir Kaffee zu brauen, sollte mit dem Statuscode 418 'Ich bin eine Teekanne' beantwortet werden."

- - - - - - -

Ursprünglich als Scherz über "viele schlechte HTTP-Extensions" gedacht, entwickelte der Statuscode ein Eigenleben und wurde in mehreren Projekten implementiert, etwa in Googles Programmiersprache Go, in Node.js und Asp.Net. Nottingham hatte in mehreren Repositories vorgeschlagen, den Code zu entfernen, weil die Nummer möglicherweise später für andere, wichtigere Zwecke gebraucht werden könnte. "Bitte zieht in Erwägung, 418 aus Go HTTP zu entfernen, weil er kein richtiger HTTP-Statuscode ist (nicht einmal nach der eigenen Definition). Ich weiß, dass es lustig ist und dass einige Menschen aus Spaß eigene Implementierungen entwickelt haben, aber das Kernprotokoll sollte nicht verschmutzt werden."

- -

418 muss bleiben

- -

Doch Nottinghams Vorschlag wurde von der Community nicht besonders herzlich aufgenommen, wie Gizmodo berichtet. Schnell wurde unter dem Motto "Wir sind die Teekannen" die Webseite Save418.com ins Leben gerufen, um die erhebliche Notwendigkeit des Codes zu begründen. Denn der Code 418 sei "eine Erinnerung daran, dass die dem Computer zugrundeliegenden Prozesse noch immer von Menschen gemacht werden." Es wäre daher sehr schade, "418 gehen zu sehen."

- - -

Auch der Initiator des Löschantrages, Mark Nottingham, war von der Argumentation offenbar überzeugt. Denn Mittlerweile hat er bei der IETF einen Antrag eingereicht, den Statuscode zu reservieren, anstatt ihn zu entfernen. Und so können Teekannen wohl auch in Zukunft ganz ohne Internet-of-Things-Technik ein wichtiger Teil des Internets bleiben.

- - -
- - - - - -
diff --git a/resources/tests/phoronix/Amazon EC2 Cloud Benchmarks Against Bare Metal Systems.html b/resources/tests/phoronix/Amazon EC2 Cloud Benchmarks Against Bare Metal Systems.html deleted file mode 100644 index 912aaf3..0000000 --- a/resources/tests/phoronix/Amazon EC2 Cloud Benchmarks Against Bare Metal Systems.html +++ /dev/null @@ -1,59 +0,0 @@ - - -
-

After earlier this month delivering new Amazon -EC2 cloud benchmarks, several Phoronix readers had requested some reference -benchmark results against some "bare metal" hardware systems. For those -not running their own performance comparisons against Amazon's Elastic Compute -Cloud, here's some more benchmark results showing different EC2 cloud instance -types compared to an Intel Ivy Bridge and Haswell system.

-

Today's data extends the Amazon EC2 performance benchmarks from earlier this -month with results from an Intel Core i3 3217U "Ivy Bridge" and Intel -Core i7 4750HQ "Haswell" systems. These are just two reference systems -to give a better idea for how Amazon's m1.small, m1.medium, m1.large, m1.xlarge, -and m3.xlarge EC2 instances compare to this modern Intel hardware with the benchmarks -running on the systems themselves without any form of virtualization/container. -These bare metal results were coming from an Ubuntu 13.10-based system, while -the EC2 cloud was running Amazon's AMI, so besides the obvious differences, take -the system

-

M1 Small - m1.small - 1 ECU / 1 Core / 1.7GB RAM / $0.060 -per Hour

-

M1 Medium - m1.medium - 2 ECU / 1 Core / 3.7GB RAM / $0.120 -per Hour

-

M1 Large - m1.large - 4 ECU / 2 Cores / 7.5GB RAM / $0.240 -per Hour

-

M1 Extra Large - m1.xlarge - 8 ECUs / 4 Cores / 15GB RAM / -$0.480 per Hour

-

M3 Extra Large - m3.xlarge - 13 ECUs / 4 Cores / 15GB RAM -/ $0.500 per Hour

-

These results are just some quick data points to give a better idea for rough -expectations of the different Amazon cloud instances. Via the open-source Phoronix -Test Suite software, you can easily repeat these benchmarks in a very easy, -fully automated, and reproducible manner.

-
-

With the Phoronix Test Suite installed on any Linux/BSD/Solaris/OSX system, -it's simply a matter of running phoronix-test-suite benchmark 1309198-SO-AMAZONCLO37 -from the command-line to download all of the captured test data, download and -install the selected tests and their configuration files, and then it proceeds -to run the benchmarks and compare the results side-by-side via integration with -OpenBenchmarking.org. There's also -commercial support -available and other custom engineering services for the dozens of enterprise-class -features that our open-source benchmarking software has queued up over the half-decade -of its public existence and nine years of internal development.

- -

-

-

-

-

-

The Core i7 4750HQ Haswell performance is far superior to that of any of the Amazon EC2 instances tested. The Core i3 3217U Ivy Bridge processor also had a competitive showing.

-
- -

-

-

-

-

-

View the rest of these Amazon -EC2 cloud benchmarks on OpenBenchmarking.org.

diff --git a/src/images/mod.rs b/src/images/mod.rs index e3f4de3..964cfd1 100644 --- a/src/images/mod.rs +++ b/src/images/mod.rs @@ -331,7 +331,7 @@ mod tests { .await .expect("Failed to downalod images"); let mut file = - fs::File::create(r"./resources/tests/planetGnome/fedora31_images_downloaded.html") + fs::File::create(r"./test_output/fedora31_images_downloaded.html") .expect("Failed to create output file"); file.write_all(result.as_bytes()) .expect("Failed to write result to file");