Nur mit einer Software grundsätzlich gar nicht. Um Programmierkenntnisse kommst du nicht drum herum.

Wichtiger als der Preis ist mir die Qualität und die Möglichkeiten. Bei der Programmierung möchte ich aber nicht so sehr in die Tiefe gehen.

"Qualität" und "nicht so sehr in die Tiefe gehen" sind gegensätzlich und schließen sich gegenseitig aus. Du musst dich für eins von beiden entscheiden! :)

Nein, float hat einige Besonderheiten und kann NICHT 2^32 unterscheidbare Werte darstellen, sondern fast ein ganzes Prozent (ca. 33 Mio. Werte) weniger.

Das kannst du auch selbst überprüfen:

// gcc -std=c99 -Ofast -march=native -Wall -Wextra -Wpedantic -Werror fc.c && time -p ./a.out

#include <math.h> // fpclassify
#include <stdio.h> // printf, puts
#include <stdlib.h> // size_t
#include <string.h> // memcpy

int main(void) {
	puts("Iterating (may take a while) ...");

	size_t valid = 0;

	float as_float = 0.0f;

	for (size_t i = 0; i <= 0xFFffFFff; ++i) {
		unsigned int as_int = (unsigned int)i;

		memcpy(&as_float, &as_int, sizeof(float));

		if (isnormal(as_float)) {
			++valid;
		}
	}

	++valid; // +0.0f and -0.0f
	++valid; // nan
	++valid; // +inf and -inf

	const size_t range = 0xFFffFFfflu;
	const size_t diff = range - valid;

	printf(
		"float: %lu / int: %lu / diff %lu\n",
		valid, range, diff
	);

	printf(
		"float: 0x%08lX / int: 0x%08lX / diff 0x%08lX\n",
		valid, range, diff
	);

	const double partial = ((double)valid) / range * 100.0;
	const double missing = 100.0 - partial;

	printf(
		"partial: %.5f %% / missing: %.5f %%\n\n",
		partial, missing
	);
}

Als Ausgabe erhältst du u. a. das hier:

float: 4261412867 / int: 4294967295 / diff 33554428
float: 0xFE000003 / int: 0xFFFFFFFF / diff 0x01FFFFFC
partial: 99.21875 % / missing: 0.78125 %

Der Datentyp "float" ist - auf den gängigsten Plattformen - zwar gleich breit wie "int", nämlich 32 Bit, aber die Anzahl der damit darstellbaren Werte liegt merklich darunter!

Das liegt daran, dass es zwei verschiedene Typen von "0" gibt, nämlich positiv und negativ, als auch unzählige verschiedene Infity- und Nan-Werte. Darüber hinaus gibt es die sog. "subnormalen" Werte, die nicht eindeutig sind, weil sie zwischen Null und dem kleinsten darstellbaren Wert liegen.

Zählt man also wie im obigen Progrämmchen ausschließlich die Werte zusammen, die gültig und nutzbar sind (inklusive beider Varianten von Null, einem Infinity und einem NaN), dann kommt man auf knapp 33 Mio. weniger mögliche Werte, als mit einem Integer darstellbar wären, was - wie man oben sehr schön sieht, rund 0,78% entspricht. :)

Warum das so ist, würde den Rahmen sprengen, aber es liegt an der internen Repräsentation von Gleitpunktzahlen im IEEE 754 Format. Siehe dazu:

https://de.wikipedia.org/wiki/IEEE_754

Also dann ... Merk dir einfach, dass "float" eben NICHT 2^32 unterschiedliche Werte darstellen kann, denn das geht nur mit "int". :)

Früher oder später hatte ich bislang immer irgendwelche größeren oder kleineren Probleme mit Wayland. Es macht einfach noch lange keinen so stabilen Eindruck wie X eben. :)

X ist zwar fetter, aufgeblasener und hat mehr Overhead, aber bietet eben auch viel mehr Features, auch wenn die teilweise schon antiquarischen Character aufweisen.

Bei komplett aufeinander abgestimmten Distributionen funktioniert Wayland zwar meistens in akzeptablem Umfang, aber wenn man sich etwas selber baut - mit Arch oder LFS z. B. - ist X einfach komfortabler, vor allem da man aufgrund der Verbreitung mehr / bessere Troubleshooting-Anleitungen findet.

Trotzdem werde ich Wayland auch weiter hin alle paar Jahre eine Chance geben, auch wenn es vermutlich noch länger dauern wird, bis es ein wirklicher Ersatz für X sein wird ... falls das überhaupt möglich / angestrebt ist. :)

Ich bin Softwareentwickler und Musiker.

Als Musiker merke ich, dass in letzter Zeit meine Videos auf Youtube von Sony & Co "geclaimt" werden, und ich NICHTS dagegen tun kann. Einsprüche haben bisher noch nicht gefruchtet, obwohl ALLES an der Musik von mir ist. Sogar die Instrumente sind selbst eingespielt und die Software zum Aufnehmen und Arrangieren ist von mir persönlich entwickelt.

Hinzu kommt, dass ich jetzt schon bei jedem Video-Upload ein nervtötendes Formular ausfüllen muss, was sich in spätestens 2 Jahren - wenn die ganzen neuen beschlossenen Gesetze in Kraft treten - noch verschlimmern wird.

Gesagt wird: Artikel 11/12/13/17 schützt die Kreativen.

Fakt ist: Artikel 11/12/13/17 behindert freischaffende Künstler dank Bürokratiemonster massiv und nutzt ausschließlich den Verwertern.

Es ist technisch unmöglich (!) funktionierende Upload-Filter zu entwickeln, und zwar nicht nur jetzt, oder in zehn, sondern auch in 50 Jahren. Wer das Gegenteil behauptet ist entweder gekauft, lügt, oder hat einfach keinen Sachverstand.

Momentan liegt die Rate meiner fälschlicherweise erkannten Musikstücke bei Youtube bei ca. 15% und das betrifft nicht mal Mashups oder Remixes, die zwar ebenfalls legal, aber noch wesentlich schwerer zu erkennen sind.

Es gibt keine magische Zauber-Software, die einem Nutzer, einer Plattform oder einem Verwerter sagt: "Dieser Inhalt ist urheberrechtlich geschützt" oder eben nicht. So eine Software existiert nicht nur nicht, sie ist prinzipbedingt nicht zu entwickeln.

Und daran erkennt man, wie Weltfremd diese neuen Gesetze sind: Frei von jeglichem Sachverstand wurden Dinge beschlossen, die einfach nicht umzusetzen sind, und deshalb einen Kollateralschaden mit sich ziehen werden, der die positiven Effekte (für Rechteverwerter und eine Hand voll Top-Künstler) auffressen wird. Darunter leiden 99,9% aller anderen kleineren und unbekannteren Künstler.

Es ist ein schwerer Eingriff in die Kultur zugunsten sehr weniger reicher Lobbygruppen.

Wenn eine angebliche "Absicht" und deren "Formulierung" den wahren Auswirkungen so dermaßen entgegenstehen, ist es Aufgabe der Politik, solche Gesetze zu verhindern / abzuändern / anzupassen, oder sie muss sich z. B. eben Korruption vorwerfen lassen.

Fazit aus Musikersicht: Für kleine Künstler eine Katastrophe.

Fazit aus Entwicklersicht: Technisch schlicht nicht umsetzbar.

Genauso gut könnte man auch Fußgängerwege verbieten und gesetztlich beschließen, dass die Leute fortan mit ihren Armen flattern und wie Vögel fliegen sollen ... ist genauso wenig umsetzbar. :)

Wie die anderen schon geschrieben haben: Gar nicht.

Einfach weil du als Anfänger überhaupt nicht weißt, worauf es ankommt.

Es ist völlig unerheblich ob du deinen Algorithmus und Schlüssel geheim hältst, aber normalerweise wird jeder Kryptologe deine primitive Verschlüsselung knacken können.

Weißt du was ein "One-Time-Pad" ist? Das ist bislang die einzige mathematisch nachweisbar unknackbare Verschlüsselung, die darüber hinaus sogar noch sehr leicht mit ein paar Zeilen Code auch von Einsteigern implementiert werden kann.

Im Studium - genauer gesagt im Bereich "Kryptoanalyse" - haben wir allerdings zu Übungszwecken auch diverse One-Time-Pads geknackt. Das war möglich, weil die Implementierung schlechte Seeds oder schlechte Pseudozufallszahlengeneratoren genutzt hat.

Und genau das ist der Punkt: Selbst die stärkste Verschlüsselung ist leicht knackbar, wenn sie von einem ahnungslosen Einsteiger implementiert wird, der überhaupt keine Vorstellung davon hat, worauf es ankommt.

Grundsätzlich gibt es EINE ganz wichtige goldene Regel unter Softwareentwicklern: Entwickle NIEMALS deine eigene Verschlüsselung! Die einzigen, die sich nicht daran halten müssen, sind ausgebildete Kryptologen, aber 99% aller Softwareentwickler verfügen nicht über die notwendigen (mathematischen) Kenntnisse, um eine vernünftige Verschlüsselung selbstständig zu entwickeln.

Als Anfänger ist diese Aufgabe also um mehrere Faktoren zu hoch für dich. Deshalb nimm die anderen Antworten bitte ernst, die dir davon abraten, und tue sie nicht als unbegründet ab.

Verschlüsselungen entwickelt man nicht selbst. Auch nicht als Programmierprofi und erst recht nicht als Einsteiger. Punkt.

Egal was du auf deinem jetzigen Stand entwickelst, du kannst dir sicher sein, dass generische Entschlüsselungswerkzeuge - die jeder Kryptoanalytiker ständig nutzt - nur Bruchteile von Sekunden benötigen werden, um deine Verschlüsselungen zu knacken. Und zwar völlig unabhängig davon, ob der Algorithmus an sich bekannt ist, oder nicht.

Fazit: Auch wenn du das nicht hören willst ... vergiss es. Du wirst nicht mal ein One-Time-Pad zufriedenstellend sicher implementieren können. :)