Diskussion:Semitronische Hyperraum-Schnittstelle

Aus Perrypedia
Zur Navigation springen Zur Suche springen

Eigener Artikel?

Hin und wieder muss ich nachfragen: Lohnt sich ein eigener Artikel? Die Datenlage zur Semitronik ist sowieso dünn, also warum nicht ein Redirect dorthin? --Klenzy (Diskussion) 16:25, 5. Jan. 2019 (CET)

Wieso ist die Datenlage dünn? Es gibt doch alles, was man braucht. Eine Beschreibung, ein Geschichtsteil und eine Quellenangabe. Welcher Vorteil hat den aus Sicht des Wikis ein Redirect? Nach meiner Meinung - und die ist ja nun kein Geheimnis :-) - hat ein Redirect keinen Vorteil, sondern nur Nachteile. Ich verstehe auch nicht, warum die Diskussion immer wieder aufkommt? Es gibt keine inhaltliche Mindestvorgabe für einen Artikel, sondern nur formelle (Quelle, Kategorie, Aufbau) und die hält der Artikel ein. --Poldi (Diskussion) 17:37, 5. Jan. 2019 (CET)
Ich möchte »meinen« Artikel diesmal ebenfalls verteidigen. Gerade der Geschichtsteil ist nur auf die SHS bezogen. Die Datenlage bei »Semitronik« ist so dünn, weil dieser Artikel mMn ein Stub ist. Ich kann es mir nicht vorstellen, dass die Autoren so wenig über einen neuen Rechnertyp zu sagen hatten, als die ANANSI eingeführt wurde. --Zoltar (Diskussion) 18:12, 5. Jan. 2019 (CET)
@Poldi: Vorhandene Informationen über die Semitronik: exakt zwei Zeilen. Das nenne ich dünne Datenlage.
Ich lese Semitronik und finde dort den Link auf »Semitronische Hyperraum-Schnittstelle«. Neugierig klicke ich auf den Link und finde: exakt dieselbe Info, die dort auch so steht. Was gewinne ich durch die Aufteilung also?
Die einzige neue Info hier sind geschichtliche Infos, die mich aber auch im Artikel Semitronik interessieren würden, denn das deutet auf eine Manipulierbarkeit des Rechners per SHS.
Was die Frage der wiederkehrenden Diskussion angeht: Kein Grund, an die Decke zu gehen, wenn ich mal ne dämliche Frage stelle. Fragen stellen ist erlaubt und da es keine Mindestvorgabe gibt, ist sowohl die Aufteilung der Infos in zwei als auch die Zusammenfassung in einen Artikel erlaubt. --Klenzy (Diskussion) 18:21, 5. Jan. 2019 (CET)
@Zoltar: verteidigen deutet auf ein Missverständnis, das war kein Angriff. Der Artikel ist kein Stub. Er ist gut und vollständig. Ich hätte mir eine Zusammenfassung gewünscht (überstimmt), da ich mögliche zukünfige Daten nicht für einen guten Grund für eine Aufteilung halt. Nun, für den Moment ist alles gut. --Klenzy (Diskussion) 18:21, 5. Jan. 2019 (CET)
Meine Meinung (unmittelbar nach Poldis erstem Kommentar geschrieben, das andere noch nicht gelesen):
Potentiell Nutzen für redirect und Integration im Hauptartikel würde ich sehen, wenn Semitronische Hyperraum-Schnittstelle integraler Teil von Semitronik wäre und es für mich als Leser angenehmer wäre, da gleich den gesamten Artikel zu lesen.
O.k., wenn ich das recht verstehe, dann ist das schon mal gegeben.
Dann wäre für mich Grund das trotzdem in eigenen Artikel auszulagern, um einen Aspekt besonders beleuchten zu können.
Wenn man den Blickwinkel von einem Begriff zu einem anderen verlagert kann es "viel runder" sein über einen interessanten Teilaspekt zu reden.
Mal überlegen was ein Beispiel sein könnte...
Tastatur und Computer?
Für das Beispiel mal kurz ausgeklammert, dass Tastaturen auch an anderen Geräten üblich sind (was für sich schon ein Grund für eigenen Artikel wäre): In einem Artikel über Computer könnte erwähnt werden, dass Eingabe via Tastatur erfolgt. Der Rahmen (Begriff "Computer") würde aber etwas einschränken, was man an Detail-Menge über mechanische, halbmechanische, ergonomische, ... Tastaturen in den Artikel schreiben würde. Eigener Artikel Tastatur: Öffnet ganz neue Möglichkeiten einen interessanten und zugleich Fokusierten und damit gut lesbaren Artikel zu schreiben.
Ähnlich Begriff CPU.
Hängt ein ganz klein wenig an Datenlage, aber nicht nur. Auch bei sehr dünner Datenlage kann im entsprechenden Kontext ein Auslagern sinnvoll sein, um den Lesern des Wikis ein - über subjektiv unterschiedliche Vorlieben hinaus - optimales Erlebnis zu bieten.
In dem Fall jetzt: Hm. (<--Hab mir fest vorgenommen, meine schlechte Angewohnheit, hm zu schreiben, abzulegen. Aber irgendwie scheint das hier passend ;-) )
Ehrlich gesagt, so wie es jetzt ist, würde ich den Geschichtsteil als sehr gut integrierbar in Geschichte der Semitronik (oder dort in einen Sicherheitsaspekte-Abschnitt) sehen. Ansonsten ist wirklich fast nix an weiteren Daten da und die Schnittstelle ist schon mal von der Namensgebung her definitiv ein Teil der Semitronik und nur von dieser.
Da sich Datenlage ändern kann hab ich jetzt auch nichts dagegen, dass hier die Teilinformation zur Semitronik extra ausgelagert ist.
Falls irgendwann mal ein vollständiger Semitronik-Artikel steht und man dann sieht, dass die Auslagerung nicht wirklich rund ist, dann sollte man denke ich aber nochmal drüber nachdenken. --NAN (Diskussion|Beiträge) 18:28, 5. Jan. 2019 (CET)
PS: @Zoltar: Als IT-ler lese ich den Geschichtsteil als "Potentielle Sicherheitsschwachstelle einer Semitronik ist die SHS. Das zeigte sich z.B. während ... Nach erkennen der Sicherheitslücke wurde ... getan." Von daher, da mag aber auch mein Background mit reinspielen, nicht so wirklich speziell über die Schnittstelle und mehr über die Bedeutung für Semitroniken. --NAN (Diskussion|Beiträge) 18:32, 5. Jan. 2019 (CET)
PPS: Bezüglich Interesse, das mit der Sicherheitslücke im Artikel Semitronik haben zu wollen bin ich einer Meinung wie Klenzy. --NAN (Diskussion|Beiträge) 18:34, 5. Jan. 2019 (CET)
@Klenzy: Ich fühle mich keineswegs angegriffen, wenn Du mir Hinweise zu einem Artikel gibst. Das mit dem verteidigen war nicht so martialisch gedacht, wie es sich vielleicht liest. :-)
@NAN: Ich verstehe jetzt das Problem besser und habe absolut nichts dagegen, wenn »SHS« in die »Semitronik« integriert wird. Mir fehlt halt das Wissen um die Einführung und bisherige Verwendung der Semitroniken. Ich dachte mir, die Sache mit der SHS bezieht sich womöglich nur auf ANANSI (und nach meinem momentanen Stand in der Serie ist das auch so). Daher hatte ich nicht den Mut, direkt an »Semitronik« herumzuschrauben. :-) --Zoltar (Diskussion) 19:24, 5. Jan. 2019 (CET)
Das haben wir alles schon mal diskutiert. Ich habe es per Zufall vor ein paar Tagen in einem Archiv gefunden. Jetzt wo ich es brauche, finde ich es nicht mehr :-(
Argumente wie: "wenn ich das als Redirect mache, finde ich aber viel mehr Informationen (im Zielartikel)" kann man mit dem Argument beantworten: "Wenn ich auf den Link xyz klicke, will ich was zu xyz lesen und nicht auch noch was zu abc und vielleicht muss ich auch noch nach meinen Informationen suchen. Wenn ich dann mehr wissen will, klicke ich auf die Links. Ist schließlich ein Wiki."
Bzgl. des Argument "die Datenlage ist aber dünn" frage ich mich, wann ist eine Datenlage denn nicht mehr dünn? Die Diskussion hatten wir bei dem Thema Redirects auf Listen.
Das Argument "das haben wir dann aber doppelt (wenn man die Informationen zusätzlich im großen Artikel unterbringt, weil sie da ja auch passen)" stimmt. Nur, wen stört es? Wir haben kein Platzproblem und es verstößt auch gegen keine Regel Informationen doppelt zuhaben. Besonders, wenn es eh nur ein paar Sätze sind.
Ich verstehe einfach nicht, was euch an dieser Art Artikel stört? --Poldi (Diskussion) 19:32, 5. Jan. 2019 (CET)
Denke Poldi, das ist eine Sache, die man nicht in schwarz/weiß Regeln festgießen kann (und falls Du die andere Diskussion noch findest wird es für mich interessant, wie ich das damals sah ;-) ).
Die Argumente mögen ähnlich sein. Was zutrifft ist aber kontextabhängig und subjektiv. Die meiste Zeit werden wir wohl ein ähnliches Gefühl haben. Ab und an kommt das dann aber halt in einen Grenzbereich, indem sich einer die Frage stellt "Wäre nicht doch besser...?".
Denke ist cool in so einem Fall dann einfach ein paar Meinungen via Diskussionseite einzuholen und für den aktuellen Fall zu entscheiden.
Am Prinzip, dass "Kleinheit" eines Artikels kein Grund für redirect ist rütteln ja auch all die Argumente oben nicht wirklich. Gibt halt andere Gründe, die man vielleicht doch beachten kann. --NAN (Diskussion|Beiträge) 20:08, 5. Jan. 2019 (CET)