Schmeckt mir sehr gut. Nicht nur Lachs, auch andere Meeresfrüchte.
Da könnte ich mich rein legen. :)
9 Stunden kommt hin. Manchmal auch 10.
Vor 20 Jahren waren noch 13 bis 14 Stu nden normal.
Das sind sog. Figlets:
https://en.m.wikipedia.org/wiki/FIGlet
Weil sie es können und es ihre freie Entscheidung ist.
Ich habe da keine Präferenzen, und komme mit beiden problemlos klar.
Bei mir in der Familie 9 Leute Android, und nur eine Person iPhone.
Arbeitskollegen haben alle nur Android.
Verteilt auf drei Präfekturen.
Bin da aber sicher auch in einer Art Filterblase!
Unter Windows wirst du dafür vermutlich die Win32-API nutzen wollen.
Damit kannst du leicht GUI-Anwendungen ohne weitere Abhängigkeiten oder Ressourcendateien direkt im Code zusammenbauen.
Ein Hello-World mit GUI ist dann nur wenige KB groß.
Das ist doch alles totaler Pfusch.
Nimm std::thread, fixe den Bug mit der Endlosschleife, und beende den Thread ordnungsgemäß!
Das ist ja grausam bisher ...
Weil es seit einiger Zeit einen total ekelhaften Hype um DevSecOps gibt, was im Endeffekt dazu führt, dass Software immer verbuggter wird.
Kurz gesagt bedeutet das so viel wie: "Wir wissen, dass unsere Software voller fehler ist, aber wir wollen lieber mehrmals am Tag Updates verteilen, anstatt einmal alles richtig auf Herz und Nieren zu testen".
Weitere Gründe für immer schlechtere Software ist m. M. n.:
In den 90ern habe ich immer Grafikdemos und Malware in Assembler, aber auch in C betrachtet, analysiert, geschrieben. Da hatte dann eine EXE Datei eine Größe von unter einem einzigen Kilobyte, und konnte Dinge tun, die heute mit .NET in der tausendfachen Dateigröße münden.
Ja, man kann mit Low-Code, RAD, Electron, oder anderen gängigen Hypebullshit-Dingen, sowie auch .NET sehr schnell Software bauen. Aber die ist dann im Bezug auf Ressourcenhunger IMMER Mist.
Die jüngeren Entwickler so um die 20 kennen es leider gar nicht mehr anders und denken, es sei normal, dass z. B. das Laden einer Seite hier auf GF über eine Sekunde an Zeit verbrät.
Dass man einen Link auf einer Website anklickt, und der Content ist sofort da, weil im DOM-Tree nicht 10000+ Knoten vorhanden sind, das kennen viele Leute gar nicht mehr.
Selbst mit Glasfaserleitungen spürt man die Ladezeit auf den meisten Websites enorm.
Fazit: Software- oder Web-Developer aasen mit Ressourcen bis zum geht nicht mehr. Sie verschwenden alles mögliche, weil sie denken: "Geht doch!". Dass es aber viel besser "gehen" würde, wenn man ordentlich arbeiten würde, erkennen die wenigsten.
hahaha ... GENAU so etwas habe ich als Schüler mal in C geschrieben.
Ist sogar relativ trivial, da du nicht, wie bei normalem Fließtext überlappende Zeichen hat, für die eine OCR-Lösung wesentlich aufwändiger wäre.
Allerdings wird so ein Programm immer noch aufwändiger werden, als wenn du es per Hand machst.
Für nur eine einzige derartige Aufgabe lohnt sich ein Programm nicht.
Hättest du 1000 Stück davon, sähe die Sache anders aus.
Ja, ist nicht nur möglich, kam in der Vergangenheit sogar schon häufig vor.
Ist aber realistisch betrachtet relativ selten, also kein Grund zur Panik.
Die beiden häufigsten Angriffsvektoren von Zero-Click-Malware sind:
1) DLL-Hijacking: Wenn du also z. B. ein Musikalbum als ZIP-Datei mit lauter MP3-Dateien herunter lädst, und ein Angreifer in diesem Archiv eine DLL-Datei einbebaut hat, die zu deinem Medienplayer (Windows-Media-Player, VLC, WinAmp, etc.) kompatibel ist, wird der Code in dieser DLL ausgeführt, wenn du auf eine MP3-Datei im selben Verzeichnis klickst.
Allerdings ist das eine semi-gut bekannte Angriffsmethode, weshalb alle großen Meidenplayer diese Lücke geschlossen haben. Bei anderer Software, v. a. kleinerer Hersteller, wie PDF-Betrachter, Bildbetrachter, usw. gibt es aber ständig DLL-Hijacking. Es ist DIE einfachste Angriffsmethode unter Windows, und da Microsoft diese Lücke wegen Abwärtskompatibilität nicht schließt, wird sie uns auch noch weitere Jahrzehnte begleiten. (DLL-Hijacking ist seit Windows 95 bekannt, und wird seitdem auch ausgenutzt!)
2) Die zweite Möglichkeit ist ein Bug im Explorer, was eher selten ist, aber hin und wieder vorkommt. Vor etwas über einem Jahr reichte es, eine manipulierte ZIP-Datei herunter zu laden, und diese im Explorer zu betrachten ... also die Datei nicht mal zu öffnen, sondern nur das ZIP-Icon und den Dateinamen im Download-Verzeichnis anzusehen.
Alternativ wird auch manchmal die "Vorschau-Funktion" von Bildern oder komplexen Dateiformaten wie Photoshop, bzw. Corel ausgenutzt.
Fazit: Ja, gibt es alles, aber kommt wirklich nicht häufig vor, wobei DLL-Hijacking nochmal eine Größenordnung öfter genutzt wird, als seltene Bugs auszunutzen.
PS: Im Browser gibt es übrigens sog. Drive-By-Downloads. Das bedeutet, dass das betrachten einer Website ausreicht, um deinen Rechner mit Malware zu infizieren.
Das kommt auch nicht soooo oft vor, aber JEDER Browser hat jedes Jahr mindestens einmal Bugs, die so etwas ermöglichen. Das gibt normalerweise die höchsten Preisgelder bei Hackingveranstaltungen.
Deine Frage ist also mit einem klaren Ja zu beantworten. Aber wie gesagt: Keine Panik, denn soooo häufig kommt es nun auch wieder nicht vor!
Hier auf GF wurden bis vor einigen Jahren noch SHA256-Hashes der Passwörter gespeichert, mit individuellem Salt für jeden Nutzer.
Ich hoffe, dass es inzwischen mit bcrypt oder moderneren Alternativen gemacht wird.
Gehashte Passwörter ohne Salt mit veraltetem Algo wie MD5, SHAxxx, oder so, kann man auch gleich im Klartext abspeichern.
Leider machen das immer noch viel zu viele Firmen so.
Und wenn kein Bruteforceschutz vorhanden ist, kann man die meisten Passwörter auch binnen Sekunden knacken.
Achte also immer schön auf viele verschiedene Zeichen unterschiedlichster Kategorien, gute Gesamtlänge und vermeide Muster. Für Laien empfielt sich ein PW-Manager.
Dass Endlosschleifen ein Zeichen für schlechtes Design sind, und man auf sinnvolle Abbruchbedingungen achten sollte.
Und dass sich hinter scheinbar trivialen Dingen oft Generatoren verbergen, die im Worst-Case ordentlich Rechenleistung verbraten können.
Und dass man auf moderne Sprachfeatures wie "assignment expressions" setzt, um den Code übersichtlicher zu machen:
while line := input('Text: '):
print(line)
Java mit Swing oder JavaFX bietet eine enorme Fülle an Zeichenfunktionen.
C++ mit Qt oder GTK ebenfalls.
Und C# mit dem ganzen .net-Bloat sowieso.
Für Python gibt es Bindings aller oben genannten, aber ist nicht zu empfehlen, wenn du viel rechnen musst, da saulahm.
Ansonsten gehen allle genannten Sprachen!
PS: JS im Browser mit Canvas geht auch sehr gut, bietet aber deutlich weniger API von Haus aus, also ohne Drittanbieter.
Mir fallen spontan folgende Nachteile ein (die man aber im Hinblick auf die vielen Vorteile gerne in Kauf nehmen wird):
So, das wären jetzt die Haupteinschnitte, mit denen man bei OOP rechnen muss, aber wie gesagt, kann man die alle eigentlich vernachlässigen, da die Vorteile bei WEITEM überwiegen.
Außerdem bieten Sprachen wie C++ sehr elegante Entwicklungsmuster, mit denen man dynamisch mit abgeleiteten Klassen arbeiten kann, ohne dass ein herkömmlicher Objektzeiger notwendig wird.
Bei "gemanagedten" Sprachen, die mit einer Art GC arbeiten, muss man aber immer im Hinterkopf behalten, dass Objekte dort implizit VIEL größer sind und mehr Speicher fressen, als es den Anschein hat.
Wenn man z. B. bei Java eine Klasse hat, die eine einzige Membervariable vom Typ "byte" hat, dann frisst das Objekt auf x64-Systemen 20 Byte.
Der Grund ist, dass so ein Objekt auf dem Heap erzeugt wird, und auf dem Stack ein Zeiger bzw. eine Referenz liegt.
Java packt Zeiger seeeehr clever, sodass auf 64-Bit Systemen nicht 8 Byte, sondern nur 4 Byte verbraten werden. Das hat allerdings einen Preis: Eine weitere Indirektion beim Zugriff!
Naja, 4 Byte liegen also auf dem Stack, weitere 8 Byte werden für den internen Zeiger im Speichermanager der VM benötigt (diesmal ungepackt und direkt), dann gibt es einen Referenzzähler von nochmal 4 Byte.
Und da die Membervariable von einem Byte an ein Alignment gebunden ist, werden zusätzliche drei Byte verbraten, sodass wir hier auf 4 Byte kommen.
Deshalb ist ein 1-byte in Java 4 + 8 + 4 + 4 = 20 Byte groß.
Bei C++ würde das gleiche Objekt tatsächlich nur ein einziges Byte auf dem Stack verbrauchen, bzw. 1 Byte auf dem Heap und 8 Byte auf dem Stack bei x86, ... oooooder, wenn man es wie in Java mit eigenem Allokator nachbaut 1 Byte auf dem Heap und nur 1, 2, 3, oder 4 Byte auf dem Stack.
Aber in 99% aller Fälle muss man sich bei Kapselung in Kombination mit OOP um solche Dinge keine Gedanken machen. (Außer beim Aligning ... damit kommt man tatsächlich hin und wieder in Berührung.)
Alles in allem: OOP und Kapselung haben keine nennenswerten Nachteile. Und wenn man tatsächlich an Grenzen stoßen sollte, gibt es immer Mittel und Wege, diese zu umschiffen.
Erstmal einfach Programmieren lernen!
Jeder Marathonläufer hat irgendwann mal mit Krabbeln angefangen.
Wenn du dann irgendwann denkst, dass du was kannst, mach zur Übung ein paar CTFs.
