Benutzer Diskussion:Y2kbug

aus Wikipedia, der freien Enzyklopädie
Letzter Kommentar: vor 10 Tagen von 78.54.147.227 in Abschnitt Durch Winzigweich verzerrte Größenangaben
Zur Navigation springen Zur Suche springen
Archiv
Zur Archivübersicht
Wie wird ein Archiv angelegt?
  Lieber Wikipedianer, wie du sicherlich auch, lege ich Wert auf einen freundlichen Umgangston und möchte dich herzlichst bitten, hier Gelassenheit walten zu lassen. In entspannter Atmosphäre diskutiert es sich viel besser. Danke. Benutzer:Y2kbug

Ich komme nicht mehr

[Quelltext bearbeiten]

Es ist immer das gleiche. Siehe: https://de.wikipedia.org/wiki/Wikipedia:Vandalismusmeldung#Benutzer:Schotterebene_(erl.) Also, mach's gut, du musst jetzt zukünftig die Artikel selber verbessern. --84.140.201.87 19:51, 28. Feb. 2024 (CET)Beantworten

Hinweis zur Löschung der Seite Bcachefs

[Quelltext bearbeiten]

Hallo Y2kbug,

die am 17. März 2024 um 12:39:07 Uhr von Dir angelegte Seite Bcachefs (Logbuch der Seite Bcachefs) wurde soeben um 16:37:47 Uhr gelöscht. Der die Seite Bcachefs löschende Administrator Toni Müller hat die Löschung wie folgt begründet: „Unerwünschte Wiederanlage einer nach Löschdiskussion gelöschten Seite, siehe dazu Löschprüfung“.
Der Artikel Bcachefs wurde in der Vergangenheit nach Abschluss einer Löschdiskussion schon einmal gelöscht. Das erneute Anlegen des Artikels Bcachefs steht im Widerspruch zur damaligen Entscheidung. Der korrekte Weg zur Wiederanlage des Artikels führt über eine Löschprüfung. Für die Durchführung einer Löschprüfung müssen – im Vergleich zur letzten Löschdiskussion des Artikels Bcachefs – grundlegend neue und vor allem belegbare Argumente vorliegen, die für eine Aufnahme des Artikels in den Artikelbestand der Wikipedia sprechen. Dies kann beispielsweise das Erfüllen der Relevanzkriterien durch eine plötzliche überregionale mediale Präsenz sein. In einer möglichen Löschprüfung des Artikels Bcachefs können alle Benutzer der Wikipedia Argumente für oder gegen eine Wiederherstellung des Artikels einbringen. Nach Abschluss der Löschprüfung entscheidet ein Administrator auf Basis der vorgebrachten Argumente und der Richtlinien (z.B. Relevanzkriterien) über eine mögliche Wiederherstellung des Artikels Bcachefs.
Solltest Du weitergehende Fragen zum Ablauf der Löschprüfung haben, so kannst Du gerne Toni Müller auf seiner Diskussionsseite kontaktieren.

Beste Grüße vom --TabellenBotDiskussion 16:38, 17. Mär. 2024 (CET)Beantworten

Deine Meinung zählt: Teste eine neue Funktion

[Quelltext bearbeiten]

Du erhältst diese Nachricht, weil du bei der letzten Umfrage der Technischen Wünsche für den Themenschwerpunkt „Wiederverwendung von Einzelnachweisen vereinfachen“ gestimmt hast. Vielen Dank nochmal für deine Teilnahme!

Im Zuge des Themenschwerpunktes „Wiederverwendung von Einzelnachweisen vereinfachen“ arbeitet das Team Technische Wünsche von Wikimedia Deutschland aktuell an einer Lösung, mit der man Einzelnachweise mit unterschiedlichen Details (z.B. Seiten, Kapitel, …) wiederverwenden kann. Bisher muss bei verschiedenen Seiten desselben Werks immer das gesamte Werk angegeben werden. Das Team hat dazu eine neue Funktion entwickelt, die bisher noch ein Prototyp ist. Hier ist deine Meinung gefragt! Wir sind auf der Suche nach Personen, die im Quelltext-Modus arbeiten und Lust haben, die neue Funktion zu testen. Dabei geht es vor allem darum zu erfahren, ob du die Funktion hilfreich findest, sie für dich einfach zu bedienen ist und ob du Fragen oder Bedenken dazu hast. Deine Rückmeldungen und Eindrücke können dabei die Weiterentwicklung maßgeblich beeinflussen.

Du hast Interesse daran, die Entwicklung dieser Lösung mitzugestalten? Dann freuen wir uns, wenn du dich hier einträgst und die Fragen beantwortest.

Unsere UX-Kollegin Eline wird dann eine Auswahl von Personen treffen, die die Funktion testen. Wenn du ausgewählt wirst, hast du ca. zwei Wochen Zeit die Funktion in deinem eigenen Tempo auszuprobieren. Alle weiteren Informationen, auch zum Ablauf der Tests, findest du im Anmeldeformular. Bei Fragen, melde dich gern auf meiner Diskussionsseite. Herzlichen Dank, Thereza Mengs (WMDE) 14:30, 26. Mär. 2024 (CET)Beantworten

Bcachefs

[Quelltext bearbeiten]

Hallo,

gegen den im Betreff genannten, von Dir angelegten oder erheblich ausgebauten Artikel wurde gestern ein Löschantrag gestellt (nicht von mir). Bitte entnimm den Grund dafür der Löschdiskussion - zu erreichen über den Link im Löschhinweis oben im Artikel. Ob der Artikel tatsächlich gelöscht wird, wird sich im Laufe der siebentägigen Löschdiskussion entscheiden.

Du bist herzlich eingeladen, Dich an der Löschdiskussion zu beteiligen. Wenn Du möchtest, dass der Artikel behalten wird, kannst Du dort die Argumente, die für eine Löschung sprechen, entkräften, indem Du Dich beispielsweise zur enzyklopädischen Relevanz des Artikels äußerst. Du kannst auch während der Löschdiskussion Artikelverbesserungen vornehmen, die die Relevanz besser erkennen lassen und die Mindestqualität sichern.

Da bei Wikipedia jeder Löschanträge stellen darf, sind manche Löschanträge auch offensichtlich unbegründet; solche Anträge kannst du ignorieren.

Vielleicht fühlst Du Dich durch den Löschantrag vor den Kopf gestoßen, weil durch den Antrag die Arbeit, die Du in den Artikel gesteckt hast, nicht gewürdigt wird. Sei tapfer und bleibe dennoch freundlich. Der andere meint es vermutlich auch gut.

Leider erfolgt aktuell nicht immer die automatische Information per Bot. Daher der Hinweis in dieser Form.

Freundl. Grüsse --Nordprinz (Diskussion) 14:41, 27. Mär. 2024 (CET)Beantworten

Grafikkarte#Softwareprobleme_mit_Grafikkarten

[Quelltext bearbeiten]

Hi, du was mir da aufgefallen ist, das der Abschnitt veraltert ist, Durch HDMI und DisplayPort Anschlüssen, die an Grafikkarten und TVs gibt, kan man ohne probleme eine Grafikkarte an einen TV anschliesen, sollte man das nicht mal akt.?--Conan (Eine private Nachricht an mich? Bitte hier lang.) 14:29, 4. Apr. 2024 (CEST)Beantworten

Der Artikel ist definitiv veraltet. Ich weiß jedoch nicht, ob ich im Moment so viel Zeit habe/investieren will, das zu überarbeiten. Es wird derzeit wohl bei Kleinigkeiten bleiben. ‣Andreas 14:31, 4. Apr. 2024 (CEST)Beantworten
arg noch schlimmer, ich wollte es dir nicht aufhalsen, falls es so geklungen hat, tschuldigung.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 14:32, 4. Apr. 2024 (CEST)Beantworten
Nö, hat es nicht. Keine Entschuldigung notwendig. Ich bin dankbar. Über's Reden kommen die Leut z'samm'... --‣Andreas 14:35, 4. Apr. 2024 (CEST)Beantworten

Vorlage:Monospace

[Quelltext bearbeiten]

Ich hoffe dir ist klar, dass solche Vorlagen eigentlich unerwünscht sind Hilfe:Textgestaltung#nicht = keine andere Schriftart, in dem Fall in BIOS (DOS) wäre eine Verwendung von code-Tags 86DOS.SYS ausreichend gewesen. --Liebe Grüße, Lómelinde Diskussion 13:46, 16. Mai 2024 (CEST)Beantworten

Mir geht es nicht um eine andere Schriftart, sondern um die Zeichenbreite. ‣Andreas 14:39, 16. Mai 2024 (CEST)Beantworten
Um weiter auszuholen: Es gibt etliche Texte, in denen ein Wort eigentlich ein Kommando oder eine Pfadangabe ist. Siehe z.B. Filesystem Hierarchy Standard. Jeder Pfad, jedes Kommando, wie cmd.exe, könnte man natürlich jedesmal im Fließtext in <code>-Tags einbauen, aber das stört den Lesefluss ungemein. Andererseits ist die command.com nunmal nicht nur ein Name, sondern auch ein Kommando. Kommandos schreibt man traditionell und der Übersichtlichkeit halber gerne in Monospace. So wie Pfade. Oder auch mal Dateinamen, wenn sie eben KEIN Code sind. Die Vorlage:Monospace findet sich auf Wikidata offenbar in vielen anderen Sprachversionen der Wikipedia ebenfalls.
Aber, natürlich, das kann man auch alles anders machen. <code> ist aber oft eher der Overkill und unpassend, während "normaler" Text auch nicht wirklich gut passt.
Siehe auch:
Ich habe mir einfach mal gedacht, WP:Sei mutig, und es einfach gemacht. Ich kann aber auch gerne wieder überall mit <span> arbeiten. Kommt halt auf das gleiche raus, nur umständlicher.
Andreas 14:47, 16. Mai 2024 (CEST)Beantworten
@Lómelinde: Geben Sie mir ein Ping, Vasili.Andreas 19:21, 16. Mai 2024 (CEST)Beantworten
Siehe: Vorlage Diskussion:Monospace#Zeichenbreite oder Schriftart?Andreas 08:50, 17. Mai 2024 (CEST)Beantworten

Abstimmen und weitersagen: Die Umfrage Technische Wünsche läuft!

[Quelltext bearbeiten]
Deine Stimme ist wichtig. Denn Verbesserungen sollen allen helfen, die in den Wikis mitarbeiten.

Hallo, weil du der in der Technische-Wünsche-Umfrage im Jahr 2022 abgestimmt hast, interessiert dich möglicherweise, dass aktuell wieder eine Umfrage läuft. Du kannst wieder darüber mitentscheiden, in welchem Bereich das Team Technische Wünsche die Arbeit in den Wikis vereinfachen soll. Zehn Themenschwerpunkte stehen dieses Jahr zur Wahl.

Die Abstimmung läuft noch bis zum 9. Dezember. Bitte weitersagen!

Wir möchten mit der Umfrage möglichst breite Teile der Community erreichen. Falls du solche Nachrichten lieber nicht erhalten möchtest, gib bitte kurz Bescheid.

– Für das Team Technische Wünsche, Johanna Strodt (WMDE) (Diskussion) 09:46, 26. Nov. 2024 (CET)Beantworten

Tschuldigung

[Quelltext bearbeiten]

dafür [1]. Habs übersehen gehabt.--Conan (Eine private Nachricht an mich? Bitte hier lang.) 18:19, 30. Nov. 2024 (CET)Beantworten

Absolut kein Problem... ich wusste schon, dass das keine Absicht war... ‣Andreas 18:38, 30. Nov. 2024 (CET)Beantworten

Durch Winzigweich verzerrte Größenangaben

[Quelltext bearbeiten | Abschnitt hinzufügen]

Hallo Andreas.
Zu dieser Änderung, gestern Nacht: Deine Sichtweise zu den Speichergrößen scheint (mir, vor allem auch durch Winzigweich beeinflußt, noch immer) verzerrt zu sein, denn Winzigweich zeigt bspw. in ihrem Erkunder (üblicherweise, in ihrer dortigen Detail-Ansicht, für Dateien) nur ihren alten Binär-Kram (fast immer bis aufs ganze Kibibyte gerundet) an, nennt das aber (wohl, also bestenfalls, nur aus historischen Gründen) noch immer (1) „KB“ (obwohl das erste Zeichen des vorgenannten Kürzels, wie es dir auch bekannt ist oder sein sollte) eigentlich für kilo (und ebenso zu ihrem byte, sowie zum dazu ursprünglichen bit = Bissen sowie Häppchen, zudem hierher weiter übersetzt, außerhalb der Winzigweichen Welt, für genau 1.000 Happen) steht.
Übrigens zeigt Winzigweich (in ihrem Erkunder) aber auch die (echten, also ungerundeten sowie ganzen und ohne ihre ewiggestrige Vermurkßung, die wahren Datei-)Größen an, (dummerweise aber nur) wenn man dessen Einzelheiten (über dessen teilweise auch noch immer, unübersetzt, also nur aus ihrer Sprache entlehnt, sobezeichneten Dateiattribute, bspw., nach Vorauswahl einer Datei, über Alt+Eingabe) aufruft.
Und was diese Erklärung, von oder bei Heise, angeht (welche ganz offensichtlich auch durch Winzigweich beeinflußt ist), so kann man das auch nicht so verallgemeinern, da es durchaus auch (vernünftige Festplatten-)Hersteller gibt, bei denen bspw. (auch schon lange) 1 GB = 1.000.000.000 Byte sind.
-- 77.11.238.196 12:53, 25. Dez. 2024 (CET)Beantworten

Wieso diskutieren wir hier und nicht dort, wo es "aufgefallen" ist?
Aber nur mal so für den Blick über den Tellerrand: unter Unix/Linux kann ich mir mit ls ein Directory Listing anzeigen lassen. Das gibt bei der Größe der Dateien diese standardmäßig in Byte an. Mit der Kommandozeilenoption --human-readable werden diese Größen in gut lesbare Summen "gerundet", also z.B. 631M für 661.651.456 Byte bzw. 661651456. Gebe ich zusätzlich --si an, wird die Größe in einer 10er-Potenz (1000er) angegeben statt in 23er-Schritten, dann steht dort 662M.
Wichtig: in beiden Fällen nutzt ls die Einheit M für Megabyte/Mebibyte oder G für Gigabyte/Gibibyte. Nur bei Kilobyte/Kibibyte gibt es einen Unterschied: 23 wird mit K angegeben, 103 mit k.
andreas@localhost:~/Downloads/Linux$ dd if=/dev/zero of=4k.bin bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4,1 kB, 4,0 KiB) copied, 5,3079e-05 s, 77,2 MB/s
andreas@localhost:~/Downloads/Linux$ ls -Al
insgesamt 6365764
-rw-r--r-- 1 andreas andreas       4096 25. Dez 21:19 4k.bin
-rw-r--r-- 1 andreas andreas 3994091520 31. Aug 14:08 debian-12.7.0-amd64-DVD-1.iso
-rw-r--r-- 1 andreas andreas  661651456 11. Okt 17:59 debian-12.7.0-amd64-netinst.iso
-rw-r--r-- 1 andreas andreas  900988928 21. Dez 14:17 grml32-full_2024.02.iso
-rw-r--r-- 1 andreas andreas  961806336 21. Dez 14:15 grml-full-2024.12-amd64.iso
andreas@localhost:~/Downloads/Linux$ ls -Al --human-readable
insgesamt 6,1G
-rw-r--r-- 1 andreas andreas 4,0K 25. Dez 21:19 4k.bin
-rw-r--r-- 1 andreas andreas 3,8G 31. Aug 14:08 debian-12.7.0-amd64-DVD-1.iso
-rw-r--r-- 1 andreas andreas 631M 11. Okt 17:59 debian-12.7.0-amd64-netinst.iso
-rw-r--r-- 1 andreas andreas 860M 21. Dez 14:17 grml32-full_2024.02.iso
-rw-r--r-- 1 andreas andreas 918M 21. Dez 14:15 grml-full-2024.12-amd64.iso
andreas@localhost:~/Downloads/Linux$ ls -Al --human-readable --si
insgesamt 6,6G
-rw-r--r-- 1 andreas andreas 4,1k 25. Dez 21:19 4k.bin
-rw-r--r-- 1 andreas andreas 4,0G 31. Aug 14:08 debian-12.7.0-amd64-DVD-1.iso
-rw-r--r-- 1 andreas andreas 662M 11. Okt 17:59 debian-12.7.0-amd64-netinst.iso
-rw-r--r-- 1 andreas andreas 901M 21. Dez 14:17 grml32-full_2024.02.iso
-rw-r--r-- 1 andreas andreas 962M 21. Dez 14:15 grml-full-2024.12-amd64.iso
andreas@localhost:~/Downloads/Linux$
Auch interessant, und was man auch ganz oben erkennen kann, ist, dass dd das doppelt angibt, einmal binär und einmal dezimal: 4096 bytes (4,1 kB, 4,0 KiB) copied; aus der manpage von dd:
N und BYTE können folgende multiplikative Endungen tragen: c=1, w=2, b=512, kB=1000,
K=1024, MB=1000*1000, M=1024*1024, xM=M, GB=1000*1000*1000, G=1024*1024*1024, und so
weiter für T, P, E, Z, Y. Binäre Präfixe können ebenfalls verwendet werden: KiB=K,
MiB=M usw. Falls N mit „B“ endet, zählt es keine Blöcke, sondern Byte.
Was ich damit sagen will: wieso "Windows-Welt"? Es kommt immer darauf an, was man will und wo man schaut. Auf Computersystemen ist 210⋅n der Standard, außer bei der Größenangabe für Festplatten vom Hersteller, denn die machen das absichtlich, dass sie 103⋅n verwenden... weil eine größere Zahl besser aussieht als eine kleinere. Werbung und Geschäftemacherei eben. Aber das Computersystem selbst nützt dann im Normalfall die binäre Zahl.
Weil das so ist, ist es widersinnig, immer "MiB" und "kiB" und "GiB" zu schreiben, weil das eh klar bzw. selbstverständlich ist. (Bei dd ist es offenbar traditionell immer nur in Byte angegeben gewesen... dass das umgerechnet wird in "human readable" ist quasi ein Zuckerl, wo der Programmierer dann die Einheiten "korrekt" abgebildet hat...) Und dort, wo der Benutzer was angeben muss oder es dem Benutzer angezeigt werden soll, muss eben erklärt werden, was womit gemeint ist (wie es die manpages von ls und dd tun).
Ich habe ls und dd übrigens unter Linux genutzt, nicht unter macOS und auch nicht unter irgend einem BSD. Die verwendeten Programme sind also aus den coreutils, und damit aus dem GNU-Projekt. Kann gut sein, dass BSD das anders macht...
Das Programm, das es unter Linux "richtig" anzeigt, ist bei mir unter KDE Plasma 6 der Dateimanager Dolphin (wie im Bild im Artikel zu Dolphin auch zu sehen: dort steht für die Datei "COPYING", sie hätte eine Größe von "17,8 KiB").
Die Sachlage ist aber die, dass es immer noch von demjenigen abhängt, der etwas -- wie einen Namen oder eine Bezeichnung -- festlegt. Die 1-MB-Grenze von DOS im Real Mode etwa wird jetzt nicht zur 1-MiB-Grenze, nur weil es technisch gesehen eben ein MiB (1024*1024*1024) ist, und nicht ein MB (1000*1000*1000). Auch wird es richtigerweise "Ein-Megabyte-Grenze" gesprochen.
Es kommt also darauf an, wie es in Fachbüchern und Fachzeitschriften steht. Und nur darauf. Natürlich werden wir hier immer dann, wenn es darum geht, die korrekte Zahl zu nennen, z.B. 1 MiB bei der 1-MB-Grenze schreiben. Allerdings sind einige der "Einzelfälle" eben genau das: Einzelfälle. Schauen wir uns diese doch genauer an:
  • Gerade die 4-GB-Grenze der 32-Bit-Architektur ist zwar genaugenommen eine 4-GiB-Grenze. Allerdings ergibt sie sich aus 232 Byte, während das Gibibyte mit 230 definiert ist. 230 * 4 = 4294967296, und 232 = 4294967296, und dennoch findet sich in der Literatur nur eine Grenze bei "4 GB"...
  • Die Grenze bei 2 TB für Festplatten... was soll das sein? Wegen des MBR? Dessen Limit ist nicht 2 TB! Es ist auch nicht 2,2 TB...
    Was ist denn nun das Limit? Zwar grundsätzlich wieder die größte 32-Bit-Zahl, aber so einfach ist es nicht. Beim MBR wird die Festplatte in 512-Byte große Blöcke aufgeteilt, und dank LBA (ja, Gott-sei-Dank nicht mehr C/H/S!) von 0 bis n gezählt. 2 Blöcke à 512 sind also 1024 Byte, also 1 KB (oder 1 KiB, wenn man so will; aber kein kB, denn das wären 1000 Byte, zumindest unter Linux mit ls). Die größte 32-Bit-Zahl ist 4.294.967.295 (weil in 32 Bit eben 4.294.967.296 Möglichkeiten reinpassen: 232; Block 0 ist aber auch schon ein 512-Byte-Block und wird natürlich mitgezählt).
    Das ergibt in Summe: 512 * 4294967296 / 210*4 = 2 TB oder, korrekt: TiB.
    Warum schreibt Microsoft dann von 2,2 TB?etwa hier Weil 512 * 4294967296 / 103*4 = 2,19902325555e+12 TB (SI-Einheit), also aufgerundet 2,2 TB.
    Und warum ist das dennoch Bullshit? Weil es eigentlich kein vollständiges MBR-Limit ist, sondern eines von 32-Bit-Software im allgemeinen. Wenn ein Treiber eine 32-Bit-Zahl für einen LBA-Sektor verwendet, dann kann eben kein 512-Byte-Sektor über 4294967295 adressiert werden, denn 4294967295 + 1 ergibt bei 32 Bits durch den resultierenden Ganzzahlüberlauf denn eben 0, wo meist der Bootsektor zu finden ist, und das führt dann meist zu Datenverlust. Nun ist es jedoch nicht deswegen Bullshit, sondern, weil der MBR selbst nur den Startsektor in 32 Bits definiert. Die Größe einer Partition kann dann wieder 32 Bits umfassen. Man kann also im MBR eine Partition festlegen, die bei Startsektor 4294967295 beginnt -- die Struktur des MBR lässt dies zu und der MBR ist damit absolut korrekt und innerhalb der Limits verwendet, das ist also keine Trickserei! Die Partitionsgröße kann man nun aber ebenfalls wieder mit der größten 32-Bit-Nummer festlegen. Damit ergibt sich in mindestens 2 Partitionen (eine große Partition ab 2 TB bis 4 TB, davor sind im Bereich von 0 bis 2 TB beliebig viele Partitionen möglich, oder aber bis zu drei primäre Partitionen) eine nutzbare Größe von knapp 4 TB auch mit dem MBRref -- obwohl überall steht, dass es mit MBR bei Festplatten > 2 TB Probleme gibt (Etwa hier: "MBR-Partitionierung funktioniert nur bis zu einer Festplattengröße von 2 Terabyte") -- ja, möglicherweise wegen auf 32-Bit-Systemen vorzufindenden Treibern (oder Firmware oder Controllerchips, usw.), die eine 32-Bit-Zahl für die Verarbeitung der LBA-Sektornummern verwenden... das muss bei Sektornummern >4294967295 ja schief gehen (mit allem, was dazugehört: Datenverlust etwa).
    Und das alles hat noch nicht einmal die theoretische Möglichkeit in Betracht gezogen, einfach eine andere Blockgröße zu verwenden ("Advanced Format"), also anstatt 512 Byte z.B. 4096 Byte je Block ("4k-Blockgröße")... Was natürlich abermals mit massiven Kompatibilitätsproblemen bestehender Software einherginge und daher den Aufwand nicht wert ist...
  • Wie bei 32-Bit ist es auch bei der 64-Bit-Architektur. Die kann theoretisch (wenn alle 64 Bits verdrahtet sind, und nicht nur etwa 48) 16 Exabyte adressieren. Wirklich Exabyte, nicht Exbibyte? Nun ja, dasselbe wieder: 260 * 16 ist dasselbe wie 264, also sind es eigentlich Exbibyte... Und dennoch findet sich in der Fachpresse oder Fachliteratur fast ausschließlich "Exabyte (EB)"wie hier und hier. Natürlich mit einzelnen Ausnahmen: "Die 64-Bit-Architektur räumt dieses Problem aus dem Weg: Hier können 2^64 Byte und damit rund 16 Exbibyte Arbeitsspeicher adressiert werden." (Markierung für "rund" von mir, denn... müsste es nicht "exakt 16 Exbibyte" heißen? Die Quelle, die die Einheit richtig schriebt, macht also gleich den nächsten Fehler...)
    Letzteres ist keine Einladung, alles wieder auf Binärpräfixe zu ändern. Die Regel bleibt Exabyte.Bsp. #1, #2, #3, #4, #5
Andreas 23:43, 25. Dez. 2024 (CET)Beantworten
Hallo Andreas,
erstmal zu deiner ersten (Gegen-)Frage: Nun, es wurde hier angebracht, weil es bei dir (in zeitlich recht kurzem Abstand, also zeitnahe, an mehreren Einträgen/Orten) aufgefallen ist (siehe hier oben, oder eben, noch mal, genauer dort, wo du ja auch auf die [ohne das genauere i, also im Ansatz nur umgangssprachliche] 4-GB-Grenze, genauer auf die zugehörige, zweite Besprechung[sseite, mit zugehörigem Abschnitt], hingewiesen hast).
Dann zu diesem (vorgeblichen) --human-readable, oder so wie es dann wohl die (bevorzugt wohl amerikanischsprachigen) Linuxer sehen. Es ist schön, daß es dort, wenigstens im Ansatz, mittlerweile auch für (gewöhnliche Alltags-)Menschen angedacht ist. Dumm nur, daß die (amerikanisch[sprachig]en) Entwickler dabei (dort, anscheinlich) auch wieder nur auf ihrem verrückten Binär-Schwachsinn beharren (oder, wohl im besten Fall, einfach nur die historischen Altlasten, so gut es ihnen möglich ist, aufzuarbeiten versuchen). Naja, immerhin haben sie ja dann auch das (hier teilweise noch immer unübersetzt sobezeichnete) internationale Einheitensystem (oder zudem eben kurz, und dummerweise aber französisch, das SI), für alle Anderen (außerhalb ihrer Binär-Welt) entdeckt (und wohl auch schon, ansatzweise, unterstützt). Also ich würde das (als deutschsprachiger) Entwickler so jedenfall nicht machen, denn hier (wenigstens in D-Land, so sehe ich das jedenfalls) haben wir (übrigens wohl wenigstens auch in ganz Europa) eben die (hier zudem weiter übersetzt, völkerübergreifenden oder noch besser) völkerverbindenden Maßeinheiten (vvMen), welche ich (als Deutscher und Europäer, eben auch hier und hier) ganz klar (als Voreinstellung oder auch [als lokalisierten] Default[wert]) bevorzugen würde (gleichgültig was all die Ammis und deren Anhänger [auf ewig] sonst noch so von sich geben [werden]). Zudem ist dieser (aus meiner Sicht, verrückte) Binär-Schwachsinn, in den aller meisten Fällen (also im Alltag) gut und gerne verzichtbar, und sollte daher nur noch als zusätzliche Auswahl (bspw. für Anwendungsentwickler, irgendwo im Hintergrund[-Rauschen]) nutzbar sein, damit die Endanwender (was mich übrigens, als Anwendungsentwickler, einschließ) nicht mehr mit diesem alten Schwachsinn, immer und immer wieder, belästigt werden. Aber gut, man muß ja (auch) diesen (vor allem amerikanischen) Linux-Murks nicht nutzen (und, soweit ich das sehe, macht die Mehrheit das ja auch nicht, also bei Steam, die dazu auch hin und wieder mal Zahlen veröffentlichen, liegt Windows irgendwo, ich glaub bei über Neun von Zehn [Anteilen], und im Rest ist da irgendwo Linux, Mäkk [also wohl Stevens Umgebung, mit dem angebissenen Apfel] und was es da sonst noch so, im Hintergrundrauschen, gibt).
Dann von wegen „Auf Computersystemen ist 210⋅n der Standard“: Ja, und bei (gewöhnlichen Alltags-)Menschen (außerhalb dieser Binär-Welt und ihrer verrückten Sprache[n]), für welche die vorgenannten Computersysteme Rechner wohl eigentlich gedacht sind, ist (eben wenigstens wohl in Europa) die Zehnerschreibweise das Übliche.
Und zum Rest deiner letzten (rund 13 echten KB, also über 13.000 (Happen oder hier treffender, über 13.000) Zeichen langen) Antwort ggf. später mal mehr. Tut mir leid, diesen Teil habe erstmal nur überflogen, zudem muß man hier wohl auch nicht alle möglichen Grenzen, und damit, in der Vergangenheit gemachten (Programmier-)Fehler, aufführen, um zwischen der, außerhalb der Binär-Welt, eigentlich üblichen Zehnerschreibweise (10er-) und der dortigen Zweierschreibweise (2er-Zahlschreibweise) unterscheiden zu können, zumal eben dafür, also vor allem wohl für die Anwendungsentwickler, und weniger für die Endanwender, ja auch schon die vorgenannten Binärpräfixe, bspw. eben für die dort genannten 4-Gibibyte- und 2-Tebibyte-Grenzen, wohl nach den vvM(aßeinheit)en, geschaffen wurden.
Mit lieben Grüßen. -- 78.54.147.227 12:27, 26. Dez. 2024 (CET)Beantworten
Zu "Warum hier" nur als Anmerkung: dadurch wird das zu einem Zwiegespräch, und das bringt nichts. Niemand wird hier mitdiskutieren, nichts wird gemeinsam entschieden. Selbst wenn wir uns einig wären -- was wir nicht sind! -- würde das nicht bedeuten, dass es so nun akzeptiert oder gar richtig ist. ‣Andreas 20:47, 26. Dez. 2024 (CET)Beantworten
Auch gut, dann sind wir uns ja wenigstens darin einig, daß wir uneins sind. Und wenn schon! Die Welt besteht aus unzähligen Wi(e)dersprüchen. Im Übrigen sehe ich (als Entwickler, was möglicherweise auch daran liegt), anscheinlich im Gegensatz zu dir, neben dem was IST, AUCH (wenigstens, noch so alles, neben dem was [ver]öffentlich[t] ist, eben auch noch) sein kann. Und das was (öffentlich) ist, ist eben nicht nur das, was die Großen (oder auch Riesen, wie „Winzigweich“) tagtäglich in die Welt rausplärren. Klar wirst du jetzt gleich wieder mit deinem WP:TF kommen, nunja, dann ist das eben so (so arm, in der eigentlich [schon vom Grundgedanken] großartigen Wikipedia). Außerdem hat (wenigstens) mir, dieses Zwigespräch geholfen. Wäre schön, wenn du auch was Gutes daraus ziehen könntest (und nicht mehr so beharrlich nur die Ansichten der Großen vertrittst und diese, Ansicht, auch, ohne mal weiter darüber nachzudenken, auch als die deine annimmst). Mit lieben Grüßen. -- 78.54.147.227 21:29, 26. Dez. 2024 (CET)Beantworten
Nein, nein, ich verstehe schon. Ich hatte damals bei Windows XP ein sehr großes Problem damit, dass im (damals noch:) Microsoft Update (heute: Windows Update) im Infobereich regelmäßig vermeldete: "Updates downgeloadet"... Das ist nicht Deutsch. Es heißt "heruntergeladen". Inzwischen wurde das ja auch nochmals etwas besser übersetzt. Aber es fand sich dann leider überall in zitierter Form wieder...
Die Quintessenz: der Forscher, der den Urknall gefunden hat (nicht erfunden), nannte diesen ja auch nicht so. Als Big Bang ging er zwar erst in den 1970ern in die Geschichte ein, aber nur deswegen, weil er von Fred Hoyle in einer Radioübertragung des BBC 1949 so bezeichnet wurde (en:Big Bang #Etymology). Wie etwas bezeichnet wird, oder in unserem Fall: welche Einheiten üblich sind, hat oft nichts damit zu tun, was eigentlich richtig wäre, oder was irgendwer, der viel mehr Ahnung hat, für richtig(er) hält...
Und, auch wenn ich dich gut verstehen kann, ohne WP:BLG ist es eben nicht so: in der Wikipedia. Zumindest nicht in Abschnittstiteln und auch nicht in Lemmata. Wie gesagt, natürlich werden wir hier die korrekten Binärpräfixe bei der technischen Beschreibung verwenden, denn so ist es ja eindeutig richtig. Da sind wir uns alle einig. Aber bei der Bezeichnung, bei den Titeln, ist die Wikipedia von dem abhängig, was publiziert ist: ob nun richtig oder falsch, gewollt oder passiert. (Big Bang... Oder: Raubkopie, 4K alias UHD, u.v.m.)
Andreas 22:04, 26. Dez. 2024 (CET)Beantworten
Ja, da stimme ich dir sogar (im strengen Rahmen der WP-Regeln/-Richtlinien/-Gesetze) zu. Andererseits, stell dir vor, es ist Krieg, und niemand geht hin. Und dazu eben übertragen, stell dir vor jemand gibt Unsinn/Schwachsinn von sich, und niemand wiederholt diesen (auf ewig, ODER berichtigt ihn sogar, wenn der alte Schwachsinn, als überholt erkannt wird). :-) Was wäre das wohl für eine (einfache[re]) Welt. Alles Gute. -- 78.54.147.227 22:31, 26. Dez. 2024 (CET)Beantworten
Im Übrigen wird es solche (harten Speicher-)Grenzen wahrscheinlich immer geben (und ggf. ebenso hart zu spüren sein, solange da kein Weg/keine Möglichkeit gefunden oder, bspw. eine [ausreichend mächtige sowie fortgeschrittene, selbsttätige] Speicherbereinigung genutzt wird), also auch die vorgenannte 16-Exbibyte-(Arbeitsspeicher-)Grenze wird irgendwann (sehr) wahrscheinlich auch ausgereizt werden (und sei es nur durch [wohlwollende] Sicherheitsforscher, welche eben diese Grenze[n], oder eher dessen Absicherung, nur aus Neugier, ausforschen möchten). Also wird man (sowie Mensch) auch immer wieder solche Grenzen (als Anwendungsentwickler, gegen sowas wie Pufferüber- und seltener auch -unterläufe) absichern (müssen), damit die Anwendungen (im besten Fall einfach) nicht (unvermittelt) anhalten (dem Endanwender gegenüber, ohne vernünftige Rückmeldung scheinbar „einfrieren“) oder abbrechen („abstürzenoder, im schlechtesten Fall, den ich jetzt gerade sehe, dabei auch noch zu Datenverlust(en) führen oder gar, beim Durchlauf in einer (ggf. ungewollten) Endlosschleife, den gerade verwendeten Rechner, bspw. durch Überhitzung, [unabsichtlich] beschädigen). -- 78.54.147.227 13:40, 26. Dez. 2024 (CET)Beantworten