Announcement: there is an English version of this forum on Hallo allerseits, ich habe im vergangenen Semester C gelernt bzw die vertieften Grundlagen in Ansi C 99. Da mir das Programmieren in C Spaß gemacht hat, habe ich mich umgeschaut was man alles damit machen kann und bin auf vielen Hardware Projekten gestoßen. Neben der Mikrocontroller Programmierung bin ich auch auf die Unix Programmierung gestoßen. Mich hat der Aufbau von Betriebssystemen schon immer interessiert aber mir hat der Zugang dazu gefehlt. Gibt es hier welche die in dem Bereich arbeiten oder Erfahrung haben? Ich habe mir überlegt selbst eigene Programme zu schreiben um mein Ubuntu Betriebssystem mit eigenen Programmen zu erweitern. Wie immer stellt sich die Frage, wie steige ich ein? Was für Job Möglichkeiten hat man mit Kenntnissen in dem Bereich?
Mike schrieb: > Ich habe mir überlegt selbst eigene Programme zu schreiben um mein > Ubuntu Betriebssystem mit eigenen Programmen zu erweitern. Da gibt es nur einen Weg: Mach einfach. Zwar sind "Betriebssystem" und "Programme" zwei Welten, aber fang einfach mal an. Der Rest ergibt sich. Oliver
Mike schrieb: > Wie immer stellt sich die Frage, wie steige ich ein? Überleg dir, was du programmieren willst - was fehlt dir an Programmen? Installiere einen Compiler / eine IDE - leg los. > Was für Job Möglichkeiten hat man mit Kenntnissen in dem Bereich? Wenn du gut bist viele - wenn du schlecht bist keine. Btw: Klingt alles ein bisschen wie: Habe ein Autorennen gesehen, jetzt möchte ich auch Rennfahrer werden - wie fange ich das an? Autos haben mich schon immer interessiert. Kann mich aber auch täuschen.
Mike schrieb: > Wie immer stellt sich die Frage, wie steige ich ein? Mit einem aktuellen Unix (!). Eventuell noch einen Rechner besorgen, und darauf Arch Linux installieren. Hinsichtlich des Geldverdienens solltest du anfangen, Kontakte zu knüpfen. Mit etwas Glück wird deine Motivation noch viel stärker - sofern du was kannst.
rbx schrieb: > Mit einem aktuellen Unix (!). Eventuell noch einen Rechner besorgen, und > darauf Arch Linux installieren. Arch Linux ist aber kein Unix, mit oder oder Ausrufezeichen. OK, Linux und Unix sind dicht beieinander, aber Unix findet sich eher in Form der diversen BSDs.
:
Bearbeitet durch User
Mike schrieb: > Ich habe mir überlegt selbst eigene Programme zu schreiben um mein > Ubuntu Betriebssystem mit eigenen Programmen zu erweitern. > > Wie immer stellt sich die Frage, wie steige ich ein? sicherheitshalber, damit garnicht erst der Unfug mit deutschen Fehlermeldungen aufkommt: # apt purge manpages-de ein paar Werkzeuge für die Kommandozeile (Unix funktioniert ohne IDE). Na gut, make brauchst du erst nächste Woche # apt install xterm manpages manpages-dev gcc make vim Und dann $ gcc -Wall -Wextra -O -o hello-world hello-world.c Geheimtipp, damit du was zum Lesen hast: $ man apropos
(prx) A. K. schrieb: > Arch Linux ist aber kein Unix Immerhin besser als Ubuntu, aber ein guter Mittelweg ist doch https://devuan.org
Mike schrieb: > Ansi C 99 Dieser Begriff ist technisch korrekt, aber verwirrend. Unter ANSI-C versteht man normalerweise C89, also den allerersten Standard (das vorherige K&R C ist ja nicht standardisiert). Die nachfolgenden Versionen, also C99, C11, C17 sind zwar auch als Standard von der ANSI übernommen, aber werden üblicherweise einfach nur C99, C11, C17 genannt. "ANSI C 99" klingt daher widersprüchlich. Dazu kommt, dass viele Leute und Firmen oft von "ANSI-C" reden, damit auch C89 meinen, und dabei alle neueren Entwicklungen ignorieren (C89 ist 33 Jahre alt). Das hat für mich immer etwas von Kopf-in-den-Sand-Mentalität. Mike schrieb: > Mich hat der Aufbau von Betriebssystemen schon immer interessiert aber > mir hat der Zugang dazu gefehlt. Möchtest du am Betriebssystem selber arbeiten oder Programme dafür schreiben? Das ist ein riesiger Unterschied. An Betriebssystemen selber arbeiten relativ wenige Leute. Als Betriebssystem-Programmierer hat man es auf dem deutschen Arbeitsmarkt sehr schwer. Embedded-Linux-Entwicklung gibt es, aber das ist mehr "Linux so konfigurieren dass es auf dem Zielsystem läuft" als wirkliche Programmierung. Die eigentliche OS-Entwicklung, also z.B. Konzeptionierung von Multitasking, Dateisystemen, APIs gilt für viele als gelöstes Problem, die Antwort ist da immer "einfach Linux benutzen". Die Nische der RTOS-Entwicklung existiert, wird aber auch zunehmend von Linux verdrängt, und ist sowieso sehr eingeschränkt. Ich habe das Gefühl dass sich keiner mehr (professionell) für OS-Entwicklung interessiert. Ich finde zwar, dass Linux auch nur das geringste Übel ist und einiges besser ginge, aber wem kann man das verkaufen? Schließlich kann man einfach Linux nehmen, und dank jahrzehntelanger Optimierung ist es auch so effizient, dass es sowieso nicht zu toppen ist (GNU HURD lässt grüßen). Das Entwickeln von Anwendungen FÜR Unix-Systeme hingegen ist relativ verbreitet. Das ist heutzutage aber auch oft einfach "nur" Web-Entwicklung mit Technologien wie node.js, selbst im Embedded Bereich.
Mike schrieb: > vertieften Grundlagen > in Ansi C 99. Es gibt ANSI C, was auch C89 genannt wird. Alle nachfolgenden Normungen wurden von der ISO gemacht, wobei C90 dem C89 entspricht.
(prx) A. K. schrieb: > Arch Linux ist aber kein Unix, mit oder oder Ausrufezeichen. OK, Linux > und Unix sind dicht beieinander, aber Unix findet sich eher in Form der > diversen BSDs. Ich hatte das deswegen so geschrieben, weil die Unixe vor allem bei Notebooks, Hardwarezicken machen. Das ist natürlich auch eine Chance. Arch hatte ich genannt, als Vorschlag um ein tatsächlich alternativ laufendes System zu Ubuntu zu haben, auf dem man dann die Unixe (und Ubuntu) als VMs laufen lassen kann, wo die Hardwareprobleme weniger stören. Die Diskussion rund um Systemd macht natürlich auch nicht dümmer - vor allem weil es ja auch spannend ist, sich die Unix-Strategien diesbezüglich anzusehen.
Womöglich wäre ein embedded Linux etwas, da sind die üblichen Schnittstellen wie I2c, SPI, CAN, i2s, etc ... verfügbar und man kann das Mikrokontrollerwissen mal mit Linux OS verschmelzen. Wer damit dann Erfahrung gesammelt hat findet auch Jobs.
Bauform B. schrieb: > Mike schrieb: >> Ich habe mir überlegt selbst eigene Programme zu schreiben um mein >> Ubuntu Betriebssystem mit eigenen Programmen zu erweitern. >> >> Wie immer stellt sich die Frage, wie steige ich ein? > > sicherheitshalber, damit garnicht erst der Unfug mit deutschen > Fehlermeldungen aufkommt: > # apt purge manpages-de So etwas ist der Tipp eines Laien und Blödsinn! Wenn du eine englische Ausgabe willst, dann setzt du einfach ein:
1 | LC_ALL=C |
vor den Befehl. Die Manpage von bspw. printf ist dann auch auf Englisch und das obwohl die deutschen Manpages auch installiert sind:
1 | LC_ALL=C man printf |
Und wenn das noch nicht reicht, kannst du die Umgebungsvariable auch dauerhaft auf Englisch setzen oder du legst dir einen Alias für man an der das umsetzt. Die deutschen Manpages sind damit bei Bedarf immer noch verfügbar.
1 | LC_ALL=de_DE.UTF-8 befehl |
geht nämlich auch. > Und dann > $ gcc -Wall -Wextra -O -o hello-world hello-world.c Da fehlt noch -pedantic
Bauform B. schrieb: > (prx) A. K. schrieb: >> Arch Linux ist aber kein Unix > > Immerhin besser als Ubuntu, aber ein guter Mittelweg ist doch > https://devuan.org Ein Mittelweg wäre Debian. Denn Ubuntu hat SystemD und devuan ist Debian ohne SystemD, während das Original Debian immer noch SystemD hat.
Mike schrieb: > Hallo allerseits, > > ich habe im vergangenen Semester C gelernt bzw die vertieften Grundlagen > in Ansi C 99. Welcher Studiengang? > Mich hat der Aufbau von Betriebssystemen schon immer interessiert aber > mir hat der Zugang dazu gefehlt. > > Gibt es hier welche die in dem Bereich arbeiten oder Erfahrung haben? Auf Betriebssystemebene bei Linux dürftest du noch im Bereich der Treiberentwicklung unterkommen. Die Core Komponenten, also der Kernel selbst, werden aber schon seit Jahren schon lange von Vollzeitentwicklern gestemmt, die dann bei IBM (früher RedHat), Microsoft, Google, AMD, Intel, Facebook, der Linux Foundation und den sonstigen großen Firmen als Vollzeitentwickler arbeiten. Da reicht ein C Buch lesen, um da reinzukommen aber eher nicht als Qualifikation aus, da solltest du mehr können. Ein Informatikstudium schadet sicherlich nicht und da musst du dann auch wirklich gut sein. Die nehmen da nicht jeden. Der Umweg, anstatt über die Firmen wäre der klassische Versuch viele gute Kernel Commits in der Freizeit einzubringen, in der Hoffnung dann von den wichtigen Kernelentwicklern entdeckt zu werden, über so einen Weg kannst du dann auch bei den Vollzeitentwicklern mit viel Glück landen. Da musst du dann aber schon sehr viel geleistet haben. Was ganz anderes wäre das Programmieren an Betriebssystemen in der Freizeit. Da wirst du sicherlich bei den Nischenbetriebssystemen wie Haiku, ReactOS, FreeDOS und vielleicht noch FreeBSD und seine Derivaten einen Platz für dich finden. Die Konkurrenz ist da wesentlich kleiner und es werden da noch händeringend Leute gesucht. Auch das portieren oder entwickeln von Treibern dürfte dort noch sehr gefragt sein, weil es gerade da noch unzählige Baustellen gibt. Aber erwarte nicht, das du da einen bezahlten Job findest. Das wird dann schon eine Arbeit in der Freizeit sein und wohl auch auf absehbare Zeit so bleiben. Ob es als Einstiegshilfe hilft, wenn du bspw. an ReactOS in der Freizeit arbeitest, um dich dann später bei Microsoft für den Windows NT Kernel zu bewerben, weiß ich nicht. Sollte dir das aber gelingen, dann würde deine Freizeitarbeit an ReactOS abrupt enden müssen. > Ich habe mir überlegt selbst eigene Programme zu schreiben um mein > Ubuntu Betriebssystem mit eigenen Programmen zu erweitern. Anwendungsprogramme schreiben ist Userspace Ebene. Da kannst du dir ein beliebiges Open Source Projekt suchen und das dann um die Features erweitern, die da deiner Meinung nach noch fehlen. Erwarte aber nicht, dass du hier etwas mit bezahlter Arbeit findest. > Wie immer stellt sich die Frage, wie steige ich ein? Viel üben, viel lesen und dann die richtigen Bücher. > Was für Job Möglichkeiten hat man mit Kenntnissen in dem Bereich? Im Bereich der OS Entwicklung direkt am Kernel gibt es nur ein sehr geringes und hart umkämpftes Angebot und da brauchst du dann auch entsprechende Qualifikationen. Bei der Treiberprogrammierung kann das besser aussehen, also in der Form dass du bspw. für Firma XY arbeitet und die will dann für ihr Produkt einen Linuxtreiber haben.
https://www.youtube.com/watch?v=5heX60XkYd8 (DragonFly BSD 6.2.1 - Vorstellung 17.14 Min) (T: DragonFly BSD 6.2.1: High Performance and HAMMER2!)
rbx schrieb: > Mike schrieb: >> Wie immer stellt sich die Frage, wie steige ich ein? > > Mit einem aktuellen Unix (!). Eventuell noch einen Rechner besorgen, und > darauf Arch Linux installieren. Hinsichtlich des Geldverdienens solltest > du anfangen, Kontakte zu knüpfen. Mit etwas Glück wird deine Motivation > noch viel stärker - sofern du was kannst. na wattn nu? Unix oder Linux? Aktuelles Unix ist z.B. MacOS
:
Bearbeitet durch User
Jens B. schrieb: > Aktuelles Unix ist z.B. MacOS Vor allem auch eines was auf aktueller Hardware ordentlich läuft, was natürlich auch nicht zu verachten ist ;)
Programmierer schrieb: > Mike schrieb: >> Ansi C 99 > > Dieser Begriff ist technisch korrekt, aber verwirrend. Eigentlich ist er nicht korrekt, da C nach C99 nicht mehr von ANSI standardisiert wurde, sondern nur noch von der ISO, auch wenn man aktuelle Versionen auch im ANSI-Webshop kaufen kann. Genau genommen ist C99 gar kein Standard mehr, da neuere Versionen des ISO-C-Standards die alten ersetzen, die damit im Prinzip ungültig werden. Bauform B. schrieb: > sicherheitshalber, damit garnicht erst der Unfug mit deutschen > Fehlermeldungen aufkommt: > # apt purge manpages-de Die manpages haben nichts mit Fehlermeldungen zu tun. Die Übersetzungen für gcc sind für z.B. gcc 11 im Paket gcc-11-locales, das aber bei Ubuntu sowieso für alle gcc-Versionen ab 10 kaputt zu sein scheint. Das kann man sehen, wenn man mal https://packages.ubuntu.com/impish/all/gcc-11-locales/filelist mit https://packages.ubuntu.com/impish/all/gcc-9-locales/filelist > ein paar Werkzeuge für die Kommandozeile (Unix funktioniert ohne IDE). > Na gut, make brauchst du erst nächste Woche > # apt install xterm manpages manpages-dev gcc make vim sudo apt install build-essential Und ob man nun unbedingt xterm will? Jeder Desktop bringt eigentlich ein Terminal mit, das in der Regel deutlich mehr kann als ein xterm.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Arch Linux ist aber kein Unix, mit oder oder Ausrufezeichen. OK, Linux > und Unix sind dicht beieinander, aber Unix findet sich eher in Form der > diversen BSDs. Warum? Kannst du das begründen?
Rolf M. schrieb: > Eigentlich ist er nicht korrekt, da C nach C99 nicht mehr von ANSI > standardisiert wurde, Laut Wikipedia hat ANSI den Standard übernommen. Tunix schrieb: > Warum? Kannst du das begründen? Linux ist nicht Unix-zertifiziert. macOS X aber z.B. schon. Für Linux ist entwickeln in C oder C++ aber deutlich angenehmer als für macOS X. Für macOS wird man zu Objective-C oder Swift gedrängt, was dann sicherlich auch gut funktioniert, aber im Rest der Welt nicht so nützlich ist. Eine C oder C++ Anwendung von Linux nach Windows zu portieren kann paradoxerweise einfacher sein als der Port nach macOS X, denn dort sind die System-APIs (also die die nicht schon von UNIX kommen), nichtmal für C oder C++ dokumentiert. Eine Objective-C oder Swift Anwendung von macOS X nach Linux portieren könnte aber noch unangenehmer werden...
Programmierer schrieb: > Rolf M. schrieb: >> Eigentlich ist er nicht korrekt, da C nach C99 nicht mehr von ANSI >> standardisiert wurde, > > Laut Wikipedia hat ANSI den Standard übernommen. Wo? Auf der deutschen Seite wird nach C89 ANSI nicht weiter erwähnt. https://de.wikipedia.org/wiki/C_(Programmiersprache)#ANSI_C Die englische Version sagt noch etwas audrücklicher, dass ANSI das nicht mehr macht: "ANSI, like other national standards bodies, no longer develops the C standard independently, but defers to the international C standard, maintained by the working group ISO/IEC JTC1/SC22/WG14." Sie sagen also quasi: "Wenn du einen C-Standard willst, nimm den von ISO" und bieten ihn auch selbst zum Verkauf an, aber eine eigene Standardisierung haben sie soweit ich sehen kann nicht. Ich konnte auch nirgends einen Hinweis auf einen ANSI-C-Standard nach C89 finden, auch nicht im ANSI-Webstore. Eine Suche nach 9899 findet keinen ANSI-Standard, und unter der ursprünglichen ANSI-Bezeichnung X3.159 findet man gar nichts.
Rolf M. schrieb: >> Laut Wikipedia hat ANSI den Standard übernommen. > > Wo? https://en.wikipedia.org/wiki/C99?wprov=sfla1 "The standard underwent further revision in the late 1990s, leading to the publication of ISO/IEC 9899:1999 in 1999, which was adopted as an ANSI standard in May 2000" Fragt sich nur, was "adopted" heißt.
Warum wurde hier noch nicht POSIX erwähnt, das war/ist mal die Vorlage für Unix-Standardisierung, da er ein Grund-Set an Funktionsaufrufen in der API definierte. Aber ich glaube, inzwischen ist csh und skriptsprache als API-Ersatz akzeptiert. Sind halt kaum noch 'real Programmer' am Werk, nur noch script-kiddies ;-) https://openbook.rheinwerk-verlag.de/linux_unix_programmierung/Kap01-005.htm https://de.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX
rbx schrieb: > Jens B. schrieb: >> Aktuelles Unix ist z.B. MacOS > > Vor allem auch eines was auf aktueller Hardware ordentlich läuft, was > natürlich auch nicht zu verachten ist ;) Naja, nicht auf jeder aktuellen Hardware. Nur auf Apple Hardware. Auf so ziemlich jedem anderen PC geht erstmal gar nichts.
Fpgakuechle K. schrieb: > Warum wurde hier noch nicht POSIX erwähnt, das war/ist mal die Vorlage > für Unix-Standardisierung, da er ein Grund-Set an Funktionsaufrufen in > der API definierte. Es ist hier dabei: Programmierer schrieb: > Linux ist nicht Unix-zertifiziert. macOS X aber z.B. schon. Die Zertifizierung, um die es geht, ist die Single UNIX Specification (SUS), zu der auch der POSIX-Standard gehört. https://de.wikipedia.org/wiki/Single_UNIX_Specification
Rolf M. schrieb: > Und ob man nun unbedingt xterm will? Jeder Desktop bringt eigentlich ein > Terminal mit, das in der Regel deutlich mehr kann als ein xterm. Ja, man will, weil es um Unix geht. xterm ist nunmal die Referenz. Wenn ein anderes Terminal etwas anders macht, ist das wahrscheinlich falsch oder mindestens unzweckmäßig (für Unix-Programmierung). Andere Terminals werden für eine andere Zielgruppe gebaut. > Die manpages haben nichts mit Fehlermeldungen zu tun. Ja, tut mir leid, da sind 2 bis 3 Zeilen verloren gegangen.
Bauform B. schrieb: > Ja, man will, weil es um Unix geht. xterm ist nunmal die Referenz. Wenn > ein anderes Terminal etwas anders macht, ist das wahrscheinlich falsch > oder mindestens unzweckmäßig (für Unix-Programmierung). Das ist nicht wie das funktioniert. Ein terminal darf komplett andere Escape Sequenzen haben, als xterm. Die meisten versuchen lediglich einigermassen kompatibel zu sein, weil es vielen Skriptbauern nicht in den Kopf zu gehen scheint, dass sie die termcap/terminfo DB, btw. in einem Shellscript tput, nehmen sollten. Ein Beispiel für terminal welches oft recht eigen ist, wäre st. Aber viele Terminals, inklusive linux fbcon, screen, etc. haben nicht den selben Umfang an Escape Sequenzen wie xterm, auch wenn sie ein paar übereinstimmende haben. Die terminfo/termcap Datenbank / Dateien, geben an, was ein terminal unterstützt, und welche Funktion welche escape sequenz hat. Wenn ein Programm escape Sequenzen hart codiert, und dass dann auf manchen Terminals nicht läuft, ist nicht das Terminal falsch. Das Programm ist falsch, es steuert das Terminal falsch an. https://man7.org/linux/man-pages/man5/terminfo.5.html
Programmierer schrieb: > Linux ist nicht Unix-zertifiziert. Inspur war und EulerOS ist von der Open Group nach UNIX03 zertifiziert, und beide Systeme basieren auf Linux. Fraglich bleibt, wie relevant die Zertifizierung ist.
Rolf M. schrieb: > Und ob man nun unbedingt xterm will? Jeder Desktop bringt eigentlich ein > Terminal mit, das in der Regel deutlich mehr kann als ein xterm. Gut, besser als die bei Microsoft benutzten Terminals (inklusive das unter WSL) sind sie alle :-), allein schon deren schräges copy&paste ist ein Grauen. Diese neumodischen Teile sehen natürlich innerhalb ihrer Umgebung irgendwie besser integriert aus, aber ich habe bislang kaum was von deren erweiterten Features vermisst. Dafür erscheint mir xterm immer noch als das mit Abstand flinkeste. 🐧 DPA 🐧 schrieb: > Das ist nicht wie das funktioniert. Ein terminal darf komplett andere > Escape Sequenzen haben, als xterm. Das sehe ich allerdings genauso. Überhaupt hat "Unix-Programmierung" ja nun erstmal normalerweise nichts mit dem verwendeten Terminal zu tun. Mit Curses irgendwelche UIs wird sich wohl nur noch selten jemand antun, dann kann man lieber einen der plattformübergreifenden GUI-Toolkits benutzen und gleich ein GUI machen.
Bauform B. schrieb: > (prx) A. K. schrieb: >> Arch Linux ist aber kein Unix > > Immerhin besser als Ubuntu, aber ein guter Mittelweg ist doch > https://devuan.org Das ist -- zumal in dieser Pauschalität -- einfach, Pardon: Quatsch. Der TO fragt expressis verbis nach Ubuntu, weil er offenbar bereits eines hat, und hinsichtlich einer UNIX-kompatiblen Programmierung unterscheidet es sich in NICHTS von Arch. Vor dem Hintergrund, daß der TO auch noch nach Möglichkeiten fragt, seine gewonnenen Erkenntnisse beruflich zu nutzen, sind Empfehlungen für Arch und Devuan sogar nicht nur Quatsch, sondern sogar noch viel Quätscher. Man muß Ubuntu und seine Derivate ja nicht mögen, aber es sind und bleiben immer noch Linux-Systeme mit einem Linux-Kernel und einem Userland, das weitestgehend vom GNU-Projekt stammt. Diesbezüglich unterscheiden sie sich in nichts von Arch Linux oder Devuan. Man muß auch systemd nicht mögen, um ganz objektiv, sachlich und nüchtern festzustellen, daß ausnahmslos alle -- ALLE -- verbreiteten und insbesondere auch im kommerziellen, professionellen, mithin: beruflichen Umfeld genutzten Linux-Systeme allesamt auf systemd setzen. Jemandem, der seine unter UNIX oder Linux gesammelten Erfahrungen auch beruflich nutzen will, ein System aufschwatzen zu wollen, welches kein systemd benutzt, ist mindestens grob fahrlässig. Bist Du wirklich dermaßen in Deinen persönlichen Präferenzen gefangen, daß Du falsche Empfehlungen gibst?
Jörg W. schrieb: > Gut, besser als die bei Microsoft benutzten Terminals (inklusive das > unter WSL) sind sie alle :-), allein schon deren schräges copy&paste ist > ein Grauen. Diese neumodischen Teile sehen natürlich innerhalb ihrer > Umgebung irgendwie besser integriert aus, aber ich habe bislang kaum was > von deren erweiterten Features vermisst. Dafür erscheint mir xterm immer > noch als das mit Abstand flinkeste. Vor Jahren habe ich einmal einen Artikel gelesen, der dies genauer untersucht und dabei festgestellt hat, daß das KDE-Programm "Konsole" das Schnellste sei. Leider finde ich die Quelle nicht mehr, und ja: das ist länger her und könnte sich seit dieser Zeit natürlich geändert haben. > Das sehe ich allerdings genauso. Überhaupt hat "Unix-Programmierung" ja > nun erstmal normalerweise nichts mit dem verwendeten Terminal zu tun. > Mit Curses irgendwelche UIs wird sich wohl nur noch selten jemand antun, Ach, ich weiß nicht... das kommt IMHO auf den Anwendungsfall an. Erst vor wenigen Monaten habe ich ein Curses-UI für ein Administrationswerkzeug gebaut, weil das im Zweifelsfall auch über eine schmalbandige SSH-Verbindung genutzt werden soll. Klar, solche Anwendungsfälle sind eher eine Ausnahme, aber es gibt sie noch.
Ein T. schrieb: > Klar, solche Anwendungsfälle sind eher eine Ausnahme, aber es gibt sie > noch. Insbesondere sehe ich Curses an der Stelle halt als noch mehr die Ausnahme: Admin-Tools kann man gut und gern auch gleich direkt als CLI-Werkzeug machen. Klar, Ausnahmen bestätigen immer die Regel. Ein T. schrieb: > und einem Userland, das weitestgehend vom GNU-Projekt stammt Das wiederum ist aber eben erstmal nicht "Unix" (absichtlich nicht in Großbuchstaben geschrieben). In den allermeisten Fällen hat GNU einen Hang zu creeping featurism, wenn ich Unix programmieren lernen will, sollte ich zumindest wissen, an welcher Stelle das jetzt GNU-/Linux-spezifisch ist, und an welchen Stellen es "Unix" ist. Das natürlich insbesondere, wenn ich künftig auch auf anderen unixoiden Systemen arbeiten will. Sieh dir einfach die vielen herum geisternden Shellscripte an, die mit #!/bin/bash beginnen und dann bash-Eigenheiten nutzen, obwohl man die gleiche Funktion auch mit reinen Bordmitteln der Posix-Shell hätte haben können, dann weißt du, was ich meine. Aber immerhin, dass bei Ubuntu mit der dash eine ash (und damit Posix-Shell) dabei ist, ist da schon ein Fortschritt.
Jörg W. schrieb: > Gut, besser als die bei Microsoft benutzten Terminals (inklusive das > unter WSL) sind sie alle :-), allein schon deren schräges copy&paste ist > ein Grauen. Diese neumodischen Teile sehen natürlich innerhalb ihrer > Umgebung irgendwie besser integriert aus, aber ich habe bislang kaum was > von deren erweiterten Features vermisst. Dafür erscheint mir xterm immer > noch als das mit Abstand flinkeste. Ich finde das Microsoft Terminal, das es unter Windows 10/11 gibt, mit Abstand die beste Terminal-Anwendung. Copy&Paste klassisch via Strg-C/V, was gibt es da einzuwänden? Schnell genug ist es auch und dadurch dass die Tabs, wie bei Chrome und Firefox, in die Titelleiste verlagert werden geht nicht so viel vertikaler Platz flöten wie z.B. beim standard Gnome-Terminal.
Bauform B. schrieb: > Rolf M. schrieb: >> Und ob man nun unbedingt xterm will? Jeder Desktop bringt eigentlich ein >> Terminal mit, das in der Regel deutlich mehr kann als ein xterm. > > Ja, man will, weil es um Unix geht. xterm ist nunmal die Referenz. Wenn > ein anderes Terminal etwas anders macht, ist das wahrscheinlich falsch > oder mindestens unzweckmäßig (für Unix-Programmierung). Konsole, gtkterm oder LXTerminal sind auch nicht weniger "UNIX" als xterm. Die kommen aber halt mit dem jeweiligen Desktop gleich mit. > Andere Terminals werden für eine andere Zielgruppe gebaut. Für welche andere Zielgruppe sind die genannten denn gemacht? Welchen Nachteil haben sie gegenüber xterm für die Zielgruppe "Ubuntu-Programmierer"? ms terminal enjoyer schrieb: > Ich finde das Microsoft Terminal, das es unter Windows 10/11 gibt, mit > Abstand die beste Terminal-Anwendung. Copy&Paste klassisch via Strg-C/V, > was gibt es da einzuwänden? Dass Strg+C eigentlich das Tastenkürzel ist, um ein Programm abzubrechen und Strg+V auch in vielen Konsolenanwendungen verwendet wird. > Schnell genug ist es auch und dadurch dass > die Tabs, wie bei Chrome und Firefox, in die Titelleiste verlagert > werden geht nicht so viel vertikaler Platz flöten wie z.B. beim standard > Gnome-Terminal. Mich nervt es ziemlich, dass Microsoft inzwischen alles mögliche in die Titelzeile steckt, wo es einfach nicht hingehört. Bei manchen Programmen weiß man ja schon gar nicht mehr, wo man greifen soll, um das Fenster zu verschieben.
:
Bearbeitet durch User
Jörg W. schrieb: > Insbesondere sehe ich Curses an der Stelle halt als noch mehr die > Ausnahme: Admin-Tools kann man gut und gern auch gleich direkt als > CLI-Werkzeug machen. Klar, Ausnahmen bestätigen immer die Regel. Das stimmt natürlich, aber im vorliegenden Fall ging es zwar um Admin-Aufgaben, die aber von Nicht-Admins ausgeführt werden sollen, zum Beispiel einen Neustart unserer Serversoftware nach einer Konfigurationsänderung, damit unsere Berater nicht jedes Mal meine Admins anstoßen müssen. Da solche und ähnliche Operationen natürlich nur möglich sind, wenn der Nutzer entsprechende Privilegien hat, wir diese Privilegien jedoch nicht allgemein für die Berater verfügbar machen wollen, obendrein hie und dort aber auch einfache Diagramme (think Python termgraph oder drawille) angezeigt werden sollen, und außerdem viele unserer Berater wenig Erfahrungen mit der Shell haben, war ein Curses-Programm mit sudo(8) und, für ganz besondere Fälle, ein paar setuid-Wrappern, IMHO der eleganteste und komfortabelste Weg. Tatsächlich ist das sogar so komfortabel, daß mittlerweile auch meine Admins das Tool benutzen. ;-)
Rolf M. schrieb: > Mich nervt es ziemlich, dass Microsoft inzwischen alles mögliche in die > Titelzeile steckt, wo es einfach nicht hingehört. Was MS mit seinem scheiss macht, ist mir egal. Aber das Gnome damit auch angefangen hat (Stichwort CSD[1]), geht mir so richtig auf den Sack. Insbesondere, weil man früher über den Window Manager bequem selbst entscheiden konnte, ob man einen Fensterrahmen will, und wie der aussehen soll, aber jetzt ignorieren viele Programme einfach was der User will, und zeichnen ihre eigenen inkonsistenten Fensterrahmen. Mehr platz nimmt das auch weg, denn Nicht nur kann man den Rahmen nicht mehr abschalten, die CSD Titelleisten füllen ja die halbe Bildschirmhöhe! Und dann wird oft behauptet, es gäbe ja dieses gtk nocsd packet, um es abzuschalten. Funktioniert nur leider nicht. Das nimmt höchstens mal den schliessen Buttons von der CSD titelleiste weg, lässt die aber ansonsten da, und dann hat man 2 verfluchte Titelleisten!!!!!!!! Das schlimme an der Sache ist, ich nutze nicht das gnome Desktop Environment, und ich hab die scheisse trotzdem! Alle nicht-gnome Desktopumgebungen, auf einen schlag verunstaltet und kaputtgemacht! ********** **********!!! 1) https://wiki.gnome.org/Initiatives/CSD
Rolf M. schrieb: > ms terminal enjoyer schrieb: >> Ich finde das Microsoft Terminal, das es unter Windows 10/11 gibt, mit >> Abstand die beste Terminal-Anwendung. Copy&Paste klassisch via Strg-C/V, >> was gibt es da einzuwänden? > > Dass Strg+C eigentlich das Tastenkürzel ist, um ein Programm abzubrechen > und Strg+V auch in vielen Konsolenanwendungen verwendet wird. Und trotzdem funktioniert es. Wenn ich Text markiert habe, muss ich idR kein Programm gleichzeitig abbrechen und wenn ich ein Programm abbrechen möchte, habe ich idR kein Text markiert. Diese Unterscheidung zwischen einem Befehls- und einem Markier-Modus ist nichts neues und das kann vim schon seit Jahren ;) Strg-V hab ich bisher noch nie anderweitig verwendet und ich bezweifle dass das irgendjemand tut. Zumindest nicht häufiger als kopierten Text einzufügen. > >> Schnell genug ist es auch und dadurch dass >> die Tabs, wie bei Chrome und Firefox, in die Titelleiste verlagert >> werden geht nicht so viel vertikaler Platz flöten wie z.B. beim standard >> Gnome-Terminal. > > Mich nervt es ziemlich, dass Microsoft inzwischen alles mögliche in die > Titelzeile steckt, wo es einfach nicht hingehört. Bei manchen Programmen > weiß man ja schon gar nicht mehr, wo man greifen soll, um das Fenster zu > verschieben. Für mich ist eine leere Titelleiste einfach nur verschwendeter Platz. Zum ziehen reicht mir das kleine Feld links des minimieren-Buttons. Warum brauch ich dazu ne halbe Bildschirmbreite platz? Und nein ich brauch auch keinen Text a la "Mozilla Firefox" um zu erkennen dass ich hier gerade einen Firefox vor mir habe.
ms terminal enjoyer schrieb: > Strg-V hab ich bisher noch nie anderweitig verwendet Tja, dann hast du offenbar noch nie bspw. ein Ctrl-C (Zeichen 0x03) in einem einzugebenden Text gehabt. Ctrl-V ist das "next character verbatim"-Steuerzeichen. Wer sich für copy&paste an Maustaste 1 und 2 gewöhnt hat, für den ist die Tastenfummelei einfach nur lästig.
🐧 DPA 🐧 schrieb: > Rolf M. schrieb: >> Mich nervt es ziemlich, dass Microsoft inzwischen alles mögliche in die >> Titelzeile steckt, wo es einfach nicht hingehört. > > Was MS mit seinem scheiss macht, ist mir egal. Aber das Gnome damit auch > angefangen hat (Stichwort CSD[1]), geht mir so richtig auf den Sack. > Insbesondere, weil man früher über den Window Manager bequem selbst > entscheiden konnte, ob man einen Fensterrahmen will, und wie der > aussehen soll, aber jetzt ignorieren viele Programme einfach was der > User will, und zeichnen ihre eigenen inkonsistenten Fensterrahmen. Das liegt an Wayland, nicht an Gnome. "Unter X11 ist ein Extra-Programm, der Fenstermanager, für die Fensterdekoration (Titelleiste, Rahmen usw.) aller Fenster zuständig. Unter Wayland werden die Funktionen des Displayservers[9] und des Fenstermanagers im Wayland Compositor zusammengefasst; die Kommunikation zwischen den beiden entfällt somit. Nach wie vor kann jeder Client seine eigenen Fensterdekorationen zeichnen, oder sie können zentral vom Compositor gezeichnet werden. Weston verlangt Client-seitige Fensterdekorationen, Kwin sorgt für Server-seitige. " Quelle: https://de.wikipedia.org/wiki/Wayland_(Display-Server-Protokoll)#Aufbau Ich stimme dir aber dabei zu, was Gnome beim Wechseln von Gnome 2 zu Gnome 3 verbrochen hat. Für mich war das der ausschlaggebende Grund, mich von Gnome zu verabschieden. > Das schlimme an der Sache ist, ich nutze nicht das gnome Desktop > Environment, und ich hab die scheisse trotzdem! Alle nicht-gnome > Desktopumgebungen, auf einen schlag verunstaltet und kaputtgemacht! > ********** **********!!! Das ist leider wahr. Deswegen nutze ich auch keine GTK Programme mehr. Die leiden nämlich alle an der Vermurkserrei des Gnome Projekts. Zur Auswahl stehen somit KDE und eventuell noch LXQt. Letzteres nicht getestet.
Nano schrieb: > Weston verlangt Client-seitige Fensterdekorationen, Kwin sorgt für > Server-seitige. Das macht mir Wayland noch unsympathischer, als es mir sowieso schon (mehr unterschwellig) war. Aber vermutlich sind wir da "old school". In einer Zeit, wo alle Welt nur noch fullscreen windows (sind das überhaupt noch "windows"?) macht und dann immer neue Gimmicks erfindet, mit denen man die immer größer werdenden Bildschirme zwischen den Anwendung halbiert oder viertelt oder wasweißich, statt einfach verschiebbare Fenster zu haben, interessiert die Dekoration der Fenster vermutlich die Leute eh nicht mehr. Den Vogel schießt dabei Windows 10+ ab (sorry, off topic), bei dem ein nicht aktives Fenster "by design" gleich gar keinen Rahmen mehr bekommt. Da ist man dann bei Otto Waalkes angekommen und seiner ostfriesischen Flagge: "Weißer Adler auf weißem Grund".
:
Bearbeitet durch Moderator
Fpgakuechle K. schrieb: > Aber ich glaube, inzwischen ist csh und skriptsprache als API-Ersatz > akzeptiert. Sind halt kaum noch 'real Programmer' am Werk, nur noch > script-kiddies ;-) Trotz Smiley: Das gilt aber ebenso für die breite Masse der C-Programmier. Am echten System-API arbeitet auch von denen kaum einer, das OS-API ist doch auch über die C-Standard-Library abstrahiert (eben damit man in C OS-unabhängig programmieren kann). Da ist dann auch kein prinzipieller Unterschied zu anderen Sprachen – ob nun interpretiert oder kompiliert – mehr vorhanden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.