Forum: PC-Programmierung GUI für LINUX Serial Port erstellen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von schmeißfliege (Gast)


Lesenswert?

Hallo ich habe einen Mikrocontroller den ich über meinen seriellen 
Monitor in Linux steuere.
Das geht über plink und der Baudrate 115000 UART.

In Windows kann man glaube ich eine GUI für sowas erstellen.
Wie mache ich das am besten in Linux?

Also eine GUI die Buttons hat und dann mit der Seriellen Schnittstelle 
kommunizieren kann.

Kann ich irgendwie mit einer Programmiersprache die serielle 
schnittstelle ansprechen?
Das sollte doch mit irgendeiner Bibliothek gehen oder?
Dann müsste ich nur noch eine GUI hinzufügen.


...
Danke :D

von Karl (Gast)


Lesenswert?

Mit Python ist das problemlos möglich.
Neben Tk gibt es Qt for Python und wxPython.

von Fredl (Gast)


Lesenswert?

QT, Gtk, Mingw, Lazarus, Python (numpy)

von Daniel A. (daniel-a)


Lesenswert?

schmeißfliege schrieb:
> Kann ich irgendwie mit einer Programmiersprache die serielle
> schnittstelle ansprechen?

Das ist in der regel eine ganz normale Datei in dev. Im Programm 
einfach ganz normal öffnen, lesen & schreiben. Dann gibt es noch einen 
ioctl, um die baud rate usw. zu setzen. Kann man im Program,  oder 
vorher einmal mit dem stty Program machen. Oder halt eine lib nehmen, 
die das alles abstrahiert. Gibts vermutlich hunderte für so ziemlich 
jede Sprache.

schmeißfliege schrieb:
> In Windows kann man glaube ich eine GUI für sowas erstellen.
> Wie mache ich das am besten in Linux?

In Linux gibt es auch GUI Programme. Klar kannst du ein GUI Programm 
machen. Auch dafür gibt es hunderte Toolkits und Libraries, für so 
ziemlich jede Sprache.

Such dir einfach aus, was du nehmen willst (Programmiersprache, evtl. 
GUI Library, evtl. Serial Library (oder selbst machen)). Es gibt nie den 
einen richtigen Weg. Programmieren ist eine Artform.

Falls du QT für die GUI nimmst, die haben auch Abstraktionen für Serial 
Ports. Die abstrahieren sowieso alles. Hat Vor und Nachteile.

von linuxguru (Gast)


Lesenswert?

schmeißfliege schrieb:
> Kann ich irgendwie mit einer Programmiersprache die serielle
> schnittstelle ansprechen?

Sehr wahrscheinlich mit jeder.

von c-hater (Gast)


Lesenswert?

Fredl schrieb:

> QT, Gtk, Mingw, Lazarus, Python (numpy)

Nicht zu vergessen: mono

Hat den extremen Vorteil, dass man mit einer wirklich komfortablen IDE 
(sprich: Visual Studio) entwickeln kann, sich um das ganze Gedöhns mit 
Compiler- und Linkerkonfigurationen und all so'n Zeug keinerlei Kopp 
machen muss und dass das Ergebnis dann auf Windows und Linux 
gleichermaßen läuft, ohne es mehrfach kompilieren zu müssen.

So weit die Theorie... In der Praxis gibt es natürlich dann doch noch 
diverse Fallstricke. Im großen und ganzen aber löppt das schon recht 
ordentlich.

Nur Performance-Wunder sollte man natürlich nicht erwarten. Insbesondere 
auch der (erste) Start einer Anwendung kann merklich zäh sein.

Aber wohl längst noch nicht relevant bei Anwendungen, die solche Leute 
wie der OT produzieren...

von Karl (Gast)


Lesenswert?

c-hater schrieb:
> Nicht zu vergessen: mono

Wenn er Linux nutzt wird er sich wohl kein Windows installieren um 
Visual Studio zu installieren um dort ein Programm zu entwickeln das 
dann auf Linux laufen soll.

Auf Linux kann man es gleich in Python machen ohne dieses halbfertige 
MS-Gefrieckel.

von Freitagsbrater (Gast)


Lesenswert?

Für kleine Sachen sollte Python + TKinter ( + PySerial) reichen. TKinter 
ist unter Windoofs standardmäßig bei Python dabei, somit sollte ein 
Wechsel von Linux zu Windoofs einfach gehen. Du kannst auch PySimpleGUI 
anschauen, das basiert direkt auf TKinter. Warum Python: Gute 
Portabilität und leichter Einstieg. Als IDE würde ich PyCharm empfehlen.

Wer richtig low cost möchte: Bash-Script und xmessage für die "GUI" 
Programmierung. Die Buttons können dann direkt die plink-Befehle callen 
und eine "neue GUI" ;-)

von Εrnst B. (ernst)


Lesenswert?

Und für die eher graphisch veranlagten Menschen:

mit node-red ein serial-port-modul mit diversen dashboard-ui-elementen 
verdrahten. Dann läuft die Bedienung über Browser und ist damit direkt 
plattformunabhängig, inklusive Android und iOS...

von //|\\ (Gast)


Lesenswert?

minicom tuts's wohl nicht ?

von Norbert (Gast)


Angehängte Dateien:

Lesenswert?

Hier mal eine kleine Einstiegshilfe für's GUI:
1
#!/usr/bin/env python
2
# -*- coding: UTF-8 -*-
3
4
import wx
5
6
class NewFrame(wx.Frame):
7
8
    def __init__(self, *args, **kwds):
9
        kwds["style"] = kwds.get("style", 0) | wx.DEFAULT_FRAME_STYLE
10
        wx.Frame.__init__(self, *args, **kwds)
11
        self.SetSize((200, 217))
12
        self.button1 = wx.Button(self, wx.ID_ANY, "Button 1")
13
        self.button2 = wx.Button(self, wx.ID_ANY, "Button 2")
14
        self.textctrl1 = wx.TextCtrl(self, wx.ID_ANY, "Text 1")
15
        self.textctrl2 = wx.TextCtrl(self, wx.ID_ANY, "Text 2")
16
        self.SetTitle("New Frame")
17
        sizer = wx.BoxSizer(wx.VERTICAL)
18
        sizer.Add(self.button1, 0, wx.EXPAND, 0)
19
        sizer.Add(self.button2, 0, wx.EXPAND, 0)
20
        sizer.Add(self.textctrl1, 0, wx.EXPAND, 0)
21
        sizer.Add(self.textctrl2, 0, wx.EXPAND, 0)
22
        self.SetSizer(sizer)
23
        self.Layout()
24
        self.Bind(wx.EVT_BUTTON, self.onClick1, self.button1)
25
        self.Bind(wx.EVT_BUTTON, self.onClick2, self.button2)
26
27
    def onClick1(self, event):
28
        print("Button1")
29
        self.textctrl1.SetValue('Button 1 pressed.')
30
        event.Skip()
31
32
    def onClick2(self, event):
33
        print("Button2")
34
        self.textctrl2.SetValue('Button 2 pressed.')
35
        event.Skip()
36
37
class NewApp(wx.App):
38
39
    def OnInit(self):
40
        self.frame = NewFrame(None, wx.ID_ANY, "")
41
        self.SetTopWindow(self.frame)
42
        self.frame.Show()
43
        return True
44
45
if __name__ == "__main__":
46
    app = NewApp(0)
47
    app.MainLoop()

von Zeno (Gast)


Lesenswert?

Karl schrieb:
> Wenn er Linux nutzt wird er sich wohl kein Windows installieren um
> Visual Studio zu installieren um dort ein Programm zu entwickeln das
> dann auf Linux laufen soll.
>
> Auf Linux kann man es gleich in Python machen ohne dieses halbfertige
> MS-Gefrieckel.
Ich bin zwar auch nicht unbedingt ein Fan von Visual Studio respektive 
C#, aber so unrecht hat der c-hater hier gar nicht. Zum einen gibt es 
wohl auch eine Studioversion die unter Linux läuft (s. hier 
https://www.linux-magazin.de/ausgaben/2015/10/visual-studio-code/ bzw. 
https://visualstudio.microsoft.com/de/downloads/). Man kann schon mit 
.Net recht fix gut aussehende Oberflächen zusammenklicken und 
Visualstudio ist schon als IDE nicht schlecht und nimmt einen viel 
Arbeit ab. Mit Mono ist das ganze auch portabel auf andere Platformen 
(wäre es mit Python natürlich auch). Allerdings wird das ganze mit einen 
mehr oder weniger großen Framework, welches auf der Zielplattform 
vorhanden sein muß, erkauft. Das ist einer der Hauptgründe meiner 
Abneigung gegen .Net (Mono) und auch interpretierte Sprachen wie z.B. 
Python. Ich brauche immer auf dem System eine passende Laufzeitumgebung.
Ein natives ausführbares Programm ist mir da allemal lieber, da dieses 
Programm in aller Regel unter dem Zielsystem läuft ohne das ich da noch 
irgend etwas brauche. Nachteil des nativen Programmes ist natürlich, das 
ich es für die Zielplattform kompilieren muß, was allerdings z.B. mit 
Lazerus kein wirkliches Problem darstellt.

von Fredl (Gast)


Lesenswert?

//|\\ schrieb:
> minicom tuts's wohl nicht ?

Kann man sich damit eine GUI zusammenbauen? Das hat der TO gefragt.

von Εrnst B. (ernst)


Lesenswert?

Zeno schrieb:
> Zum einen gibt es
> wohl auch eine Studioversion die unter Linux läuft

VScode != Visual Studio.

VScode ist im Herzen eine Webanwendung, nur dass der Server zusammen mit 
dem Webbrowser in ein Binary verpackt wurde.

Klicki-Bunti-.NET GUIs gehen damit nicht.

von Bauform B. (bauformb)


Lesenswert?

Freitagsbrater schrieb:
> Wer richtig low cost möchte: Bash-Script und xmessage für die "GUI"
> Programmierung.

richtig low cost, mit Bash-Script, aber trotzdem mit voller GUI-Optik, 
geht auch: man überlässt den ganzen Grafikaufwand einem Browser. Das 
Script verbindet sich mit der seriellen Schnittstelle und liefert am 
anderen Ende simples HTML. Das allermeiste funktioniert sogar ohne 
Javascript. Natürlich darf man statt Bash auch seine Lieblingssprache 
verwenden.

Aber vor allem muss man sich nicht für Qt, GTK oder oder entscheiden, 
weil man das alles nicht braucht. Keine IDE und kein Framework, nur 
einen kleinen Webserver (nicht gerade apache, bozohttpd ist besonders 
pflegeleicht).

Bonus: es funktioniert vom Start weg auch auf Windows und ähnlich 
exotischen Oberflächen oder auf der Linux-Console mit w3m -- und alles 
ohne zusätzliche Installation.

von c-hater (Gast)


Lesenswert?

Karl schrieb:

> Wenn er Linux nutzt wird er sich wohl kein Windows installieren

Sagt wer? Ich nutze seit 25 Jahren auf jedem meiner Arbeitsrechner 
Linux, habe aber auch immer ein Windows installiert.

Dummgeschwalle von ideologisch verblendeten OS-Fanboys war mir jederzeit 
verhaßt. Das sind Leute arm im Geiste und fern jeder Realität.

von c-hater (Gast)


Lesenswert?

Εrnst B. schrieb:

> VScode != Visual Studio.

Richtig. Für Linux gibt es MonoDevelop. Das versucht, das unerreichte 
Visual Studio nachzuempfinden, kann es allerdings nicht wirklich 
erreichen.

Man kann damit durchaus entwickeln, habe ich selber schon getan. Aber 
wirklich komfortabel, so wie das Original, ist es nicht.

Aber immer noch um viele, viele Größenordnungen besser als jeder andere 
Scheiß, den es unter Linux gibt. Für die Entwicklung von GUI-Anwendungen 
ist praktisch nix davon wirklich geeignet.

Ausnahme ist Eclipse (mit den passenden Plugins), was dann aber auch 
wieder auf etwas setzt, was nicht nativ ist. Statt mono-RT halt java-RT. 
Prinzipiell kein Unterschied.

von Zeno (Gast)


Lesenswert?

Εrnst B. schrieb:
> VScode != Visual Studio.

Ich hatte nur mal Google bemüht und geschaut was es da so gibt. Habe das 
dann aber auch nicht näher untersucht (da mich der .Net Kram nicht 
wirklich interessiert, die 2 Jahre die ich mich auf Wunsch eines 
einzelnen Chefs damit befassen mußte reichen für den Rest des Lebens) 
und deshalb auch im Konjunktiv formuliert.

Εrnst B. schrieb:
> VScode ist im Herzen eine Webanwendung, nur dass der Server zusammen mit
> dem Webbrowser in ein Binary verpackt wurde.
Das wäre ja erst mal nicht weiter tragisch, dem Anwender ist das völlig 
Rille, wenn es funktioniert. Bei Delphi gab's/gibt es so etwas auch und 
man konnte damit sogar richtige GUIs erstellen, habe ich aber auch nur 
mal testweise ausprobiert genauso wie Delphi.Net. Da mir beides nicht 
wirklich zugesagt hat und ich da auch nicht wirklich einen Mehrwert 
erkennen konnte habe ich es nicht weiter verfolgt.
Ich bevorzuge native ausführbare Programme die ohne jegliches 
zusätzliches Framework oder irgendwelche Runtimeumgebungen auskommen. 
Wenn es mit GUI sein soll dann geht das mit Delphi bzw. Lazarus sehr gut 
und man kann damit problemlos Windows, Linux und Mac abdecken, was für 
meine Zwecke bei weitem ausreichend ist.

von Karl (Gast)


Lesenswert?

Zeno schrieb:
> Ein natives ausführbares Programm ist mir da allemal lieber, da dieses
> Programm in aller Regel unter dem Zielsystem läuft ohne das ich da noch
> irgend etwas brauche.

Wenn du das Programm auf mehr als eine Hand voll Rechner installieren 
willst sicher keine verkehrte Einstellung. Eine GUI ohne Framework zu 
programmieren ist aber sicher nicht ohne. Wie schon angemerkt wurde ist 
Tk bei Pythin in der Grundinstallation vorhanden. Außerdem lassen sich 
z.B. mit PyInstaller u.ä. Pakete schnuren.

Freitagsbrater schrieb:
> Wer richtig low cost möchte: Bash-Script und xmessage für die "GUI"
> Programmierung.

Ist das billiger als Python? Spuckt der Computer dann Geld aus?

Bauform B. schrieb:
> Das
> Script verbindet sich mit der seriellen Schnittstelle und liefert am
> anderen Ende simples HTML. Das allermeiste funktioniert sogar ohne
> Javascript. Natürlich darf man statt Bash auch seine Lieblingssprache
> verwenden.
>
> Aber vor allem muss man sich nicht für Qt, GTK oder oder entscheiden,
> weil man das alles nicht braucht. Keine IDE und kein Framework, nur
> einen kleinen Webserver (nicht gerade apache, bozohttpd ist besonders
> pflegeleicht).

Da ist aber der Programmieraufwand für das Skript doch recht hoch. Was 
man in Python in 3 Zeilen macht, macht man in dem Bashskript über 10 
Zeilen mit verworrenen Zeichen. Kann man machen, wenn man neu lernt kann 
man aber auch was zeitgemäßes lernen. Außerdem läuft das Backend auch 
nicht plattformunabhängig.

c-hater schrieb:
> Sagt wer? Ich nutze seit 25 Jahren auf jedem meiner Arbeitsrechner
> Linux, habe aber auch immer ein Windows installiert.
>
> Dummgeschwalle von ideologisch verblendeten OS-Fanboys war mir jederzeit
> verhaßt. Das sind Leute arm im Geiste und fern jeder Realität.

Was ist dir denn für eine Laus über die Leber gelaufen? Ich habe eine 
Annahme getroffen, die wahrscheinlich ist (er arbeitet ja an seinem 
Projekt auf Linux), aber nicht richtig sein muss und du beschimpfst mich 
als dummschwallenden ideologisch verblendeten OS-Fanboys. Bist du noch 
ganz normal?

von c-hater (Gast)


Lesenswert?

Zeno schrieb:

> Ich bevorzuge native ausführbare Programme die ohne jegliches
> zusätzliches Framework oder irgendwelche Runtimeumgebungen auskommen.

Das wäre dann Assembler-Entwicklung. Das ist dir doch hoffentlich klar? 
Selbst primitive "Hochsprachen" wie C benötigen bereits eine Runtime. 
OK, sie können sie immerhin selbst im Executable mitführen...

Bei fetteren Sachen führt das dann dazu, dass die Exe mal eben 40..100MB 
groß ist, weil sie alle Abhängigkeiten statisch gelinkt hat.

Ob das wirklich clever ist? Insbesondere mit Rücksicht auf die 
Sicherheitslücken, die in den Abhängigkeiten typisch regelmäßig 
aufpoppen?

Wer will jede verschissene Anwendung regelmäßig auf verwundbare 
Abhängigkeiten durchforsten, die Abhängigkeit updaten und dann die 
Anwendung neu kompilieren und an alle Benutzer verteilen?

Das ist SCHWACHSINN, der konsequent in den Abgrund führt.

von chris_ (Gast)


Lesenswert?

Hier ein paar einfache Beispiele in tkinter:
Beitrag "Python <-> MC serial"

von DPA (Gast)


Lesenswert?

Von mono und all dem MS scheiss würde ich dringend abraten. Mono mag 
vielleicht in der Theorie Portabel sein, und bei Entwicklern, die ihre 
Anwendungen unter Linux testen, funktioniert das auch. Aber wenn 
nicht... bei Windows Anwendungen sehe ich häufiger die mono runtime 
Fehler werfen und sich verweigern, als selbst normale Windows 
Anwendungen in wine.
Nicht alle teile von mono sind gleich offen. Wo die reise mit der 
neusten version hin geht sieht da auch nicht schön aus. Und abgesehen 
von all dem, ich finde die meisten mono GUIs sehen generell erstmal 
richtig scheisse aus, rein visuell.

Nein, nimm was anderes. Ganz egal was, schlimmer gehts nicht mehr.

von DPA (Gast)


Lesenswert?

c-hater schrieb:
> Selbst primitive "Hochsprachen" wie C benötigen bereits eine Runtime.

Per default linken c Compiler meistens eine dazu, aber das kann man oft 
abstellen. Ist nur nicht besonders sinvoll, dann muss man sich nämlich 
selbst um den kram kümmern. Die Suchbegriffe da dürften "freestanding" 
und "hosted" sein.

von Andreas B. (bitverdreher)


Lesenswert?

c-hater schrieb:
> Zeno schrieb:
>
>> Ich bevorzuge native ausführbare Programme die ohne jegliches
>> zusätzliches Framework oder irgendwelche Runtimeumgebungen auskommen.
>
> Das wäre dann Assembler-Entwicklung.

Noe, Lazarus (Object Pascal) z.B.
Da wird eine ausfuehrbare Datei erzeugt, die auf dem Zielsystem kopiert 
wird und fertig.
Daher mein absoluter Favorit was systemuebergreifende Entwicklungen 
angeht.

von linuxguru (Gast)


Lesenswert?

c-hater schrieb:
> Dummgeschwalle von ideologisch verblendeten

schreibt einer, der "hater" im Nicknamen hat. Klar.

von Rolf M. (rmagnus)


Lesenswert?

c-hater schrieb:
> Zeno schrieb:
>
>> Ich bevorzuge native ausführbare Programme die ohne jegliches
>> zusätzliches Framework oder irgendwelche Runtimeumgebungen auskommen.
>
> Das wäre dann Assembler-Entwicklung. Das ist dir doch hoffentlich klar?
> Selbst primitive "Hochsprachen" wie C benötigen bereits eine Runtime.

Was du meinst ist die Standardbibliothek. Er spricht wohl eher von 
diesen umfangreichen JIT-Framworks, die dann unter anderem erstmal beim 
Start das Programm noch fertigcompilieren müssen.

> Bei fetteren Sachen führt das dann dazu, dass die Exe mal eben 40..100MB
> groß ist, weil sie alle Abhängigkeiten statisch gelinkt hat.
>
> Ob das wirklich clever ist?

Wieviel kosten 100 MB heutzutage? Und was ist das schon im Vergleich zu 
den Gigabytes an .net-Frameworks? Schließlich sind die Versionen ja alle 
nicht kompatibel, so dass man praktisch für jedes Programm ein eigenes 
.net-Framework installiert haben muss.
Aber ja, alles statisch zu linken, hat durchaus erhebliche Nachteile. 
Muss man aber nicht.

> Das ist SCHWACHSINN, der konsequent in den Abgrund führt.

DU bist derjenige, der statisches Linken überhaupt in den Raum geworfen 
hat.

von db8fs (Gast)


Lesenswert?

c-hater schrieb:
> Das wäre dann Assembler-Entwicklung. Das ist dir doch hoffentlich klar?

Was ist denn da so groß anders mit Assembler... meines Wissens nach 
erzeugen doch auch die üblichen Compiler bloß Assemblercode, der dann 
assembliert und gelinkt werden muss. Man kann auch Barebone mit C/C++ 
entwickeln. Oder Ada. Oder Pascal.

Ums Linken gegen externe Symbole kommt man auch mit Assembler kaum 
drumrum.

> Bei fetteren Sachen führt das dann dazu, dass die Exe mal eben 40..100MB
> groß ist, weil sie alle Abhängigkeiten statisch gelinkt hat.

Ja, funktioniert aber gut. Hatte mal 2003/04 mir CivCTP für Linux auf CD 
(!) gekauft, das lief dann mit der richtigen glibc auch 10 Jahre später 
noch auf nem damals aktuellen Linux, wo schon die halbe 
Desktop-Infrastruktur wieder ganz anders aussah.

So schlimm find ich statische Binaries nicht.

> Ob das wirklich clever ist? Insbesondere mit Rücksicht auf die
> Sicherheitslücken, die in den Abhängigkeiten typisch regelmäßig
> aufpoppen?

Nicht aller Code in den Abhängigkeiten wird auch wirklich aufgerufen.

> Wer will jede verschissene Anwendung regelmäßig auf verwundbare
> Abhängigkeiten durchforsten, die Abhängigkeit updaten und dann die
> Anwendung neu kompilieren und an alle Benutzer verteilen?

Das ist die große Herausforderung des Deployments, die auch riesen Buden 
wie Microsoft lange gekotzt haben dagegen (Dll-hell). Ob's .net die 
richtige Lösung gegen die Dll-Hölle war, sei mal noch dahingestellt - 
denn eigentlich sind die Abhängigkeiten dann auch nicht weg, sondern 
bestenfalls im CLR irgendwo verborgen. Selbes Problem, nur auf anderem 
Layer...

von Zeno (Gast)


Lesenswert?

Karl schrieb:
> Eine GUI ohne Framework zu
> programmieren ist aber sicher nicht ohne.
Nö, das ist überhaupt kein Problem. Mit Delphi oder auch Lazarus geht 
das völlig problemlos. Da habe ich am Ende eine Exe (Windows) bzw. ein 
ELF-Binary (Linux). Da braucht es weder ein Framework noch irgendwelche 
Libs. Wie schwierig das am Ende ist ein Programm mit einer GUI zu 
erstellen hängt letzlich nur von der dazu verwendeten IDE ab. Unter Mac 
mit XCode geht das auch prima.
Ich kann mich noch an frühere Zeiten erinnern wo es keine komfortablen 
Komponentenpaletten, von denen man nur die gewünschte Komponente auf's 
Formular ziehen kann, gab. Da hat mat man wirklich alles zu Fuß gemacht 
und jedes einzelne Objekt der GUI mit etlichen Zeilen COde selbst 
erstellt. Die Zeiten sind heute Gott sei dank vorbei und so ein 
Terminalprogram z.B. hat in wenigen Stunden fertig, wenn man die 
passenden KOmponenten zu Verfügung hat.

von Rolf M. (rmagnus)


Lesenswert?

Zeno schrieb:
> Karl schrieb:
>> Eine GUI ohne Framework zu
>> programmieren ist aber sicher nicht ohne.
> Nö, das ist überhaupt kein Problem. Mit Delphi oder auch Lazarus geht
> das völlig problemlos.

"Ohne Framework" heißt im Prinzip, jeden Pixel selbst in den 
Grafikspeicher zu schreiben. Ich hoffe nicht, dass das bei Delphi 
erforderlich ist.

> Da habe ich am Ende eine Exe (Windows) bzw. ein ELF-Binary (Linux). Da
> braucht es weder ein Framework noch irgendwelche Libs.

Natürlich braucht es die. Die sind eben nur statisch statt dynamisch 
gelinkt.

von Zeno (Gast)


Lesenswert?

c-hater schrieb:
> Das wäre dann Assembler-Entwicklung.
Da muß ich Dir widersprechen.

c-hater schrieb:
> Selbst primitive "Hochsprachen" wie C benötigen bereits eine Runtime.
Das mag für C zutreffend sein, ich kann es aber nicht wirklich 
beurteilen. Andererseits braucht es auf einem µC z.B. auch keine Runtime 
und warum sollte das auf einem PC anders sein. Solange ich da nicht 
gegen irgendwelche Lib's/DLL's linke braucht es da gar nichts.
Mit Borland Pascal oder Delphi erstellte Programme brauchen da gar 
nichts, es sei denn das OS ist für Dich schon eine Runtime.
Ich habe vor langer Zeit Programme mit Turbo Vision (Bestandteil von 
Turbopascal) geschrieben, die ich auf eine bootfähige Diskette kopiert 
habe und die haben wunderbar ohne jegliche Runtime funktioniert 
MSDOS.SYS und IO.SYS waren da völlig ausreichend.

c-hater schrieb:
> OK, sie können sie immerhin selbst im Executable mitführen...
Achso also doch keine Runtime die vom OS bereitgestellt wird. Wie das 
die Exe intern regelt ist dem Anwender und am Ende auch mir doch völlig 
egal.

c-hater schrieb:
> Bei fetteren Sachen führt das dann dazu, dass die Exe mal eben 40..100MB
> groß ist, weil sie alle Abhängigkeiten statisch gelinkt hat.
Wo ist da das Problem? Es hindert Dich niemand daran bestimmte 
Programmteile in eine Lib/DLL auszulagern und selbige dann mit dem 
Programm ins Programmverzeichnis zu kopieren.
Habe ich z.B bei einem modular aufgebauten Programm so gemacht. Da gibt 
es eine Basis-Exe die kommt ganz ohne DLL aus und kann dann demzufolge 
auch nur einen bestimmten Umfang an Aufgaben ausführen. Wenn man mehr 
Funktionalität möchte braucht es halt die passenden Module in Form einer 
DLL dazu. Da ist auch nichts statisch gelinkt, weil das nach meinem 
Verständnis Scheiße ist, denn da baut man Abhängigkeiten auf die man so 
nicht möchte und die sich auch nur schwer pflegen lassen. Nichts ist 
häßlicher, als wenn sich ein Programm schon beim Start verabschiedet, 
weil irgendeine Lib fehlt und man dann angeblökt wird die Lib X in 
Version Y kann nicht gefunden werden. Klasse das braucht der Anwender.
In .Net ist so etwas gang und gäbe. Da braucht man in der Applikation 
nur ein einzige Feature aus dem aktuellsten Framework zu verwenden und 
schon klatscht die App bei nächsten User auf bloß weil dieser noch eine 
Versionsnummer zurück ist. Der ist dann genötigt mehrere 100MB 
nachzuinstallieren um das aktuelle Framework (wenn es denn auf der 
vorhandenen OS-Version läuft) zu haben, damit er die App nutzen kann.

c-hater schrieb:
> Ob das wirklich clever ist? Insbesondere mit Rücksicht auf die
> Sicherheitslücken, die in den Abhängigkeiten typisch regelmäßig
> aufpoppen?
Ja ein bissel Mimi muß natürlich auch noch sein.

c-hater schrieb:
> die Abhängigkeit updaten und dann die
> Anwendung neu kompilieren
Du hättest halt kein Programmierer werden sollen, wenn Dir das zu viel 
ist. Außerdem gibt es da diverse Tools die das mehr oder weniger 
automatisch machen. Während die arbeiten kann man in aller Ruhe eine 
Tasse Kaffe trinken.

DPA schrieb:
> Mono mag
> vielleicht ....
Damit ist es halt genauso wie mit .Net, man braucht das zur App passende 
Framework und muß dabei noch hoffen das es auf dem vorhandenen OS 
funktioniert. Wenn's ganz dumm läuft muß man dann auch da noch ein 
Update durchführen (s.o.).

Rolf M. schrieb:
> Was du meinst ist die Standardbibliothek. Er spricht wohl eher von
> diesen umfangreichen JIT-Framworks, die dann unter anderem erstmal beim
> Start das Programm noch fertigcompilieren müssen.
Du hast es erkannt.

db8fs schrieb:
> Ob's .net die
> richtige Lösung gegen die Dll-Hölle war,
Nö ist es nicht. Jetzt sind es noch mehr DLL's.

von schmeißfliege (Gast)


Lesenswert?

Danke Leute!
Ich freue mich schon auf mein erstes GTK+ hello world.

Nur so falls es jemanden interessiert was meine aktuellen Vorstellungen 
sind:

Ideal:
* buttons und textfelder zur eingabe.
* Ebenfalls auslesen des seriell ports in der GUI über ein Fenster.
* Und ggfs. noch parsen  der Daten
* Verbindungsaufbau auch über diese GUI damit ich ein rundes Programm 
hab xD

Realität: Buttons und und ich muss ein extra bash aufmachen um den 
output zu sehen xD


haha

von W.S. (Gast)


Lesenswert?

Rolf M. schrieb:
> "Ohne Framework" heißt im Prinzip, jeden Pixel selbst in den
> Grafikspeicher zu schreiben. Ich hoffe nicht, dass das bei Delphi
> erforderlich ist.

Leute, ihr schmeißt euch mal wieder Schlagworte um die Ohren.
Also:
Pascal ist eine Programmiersprache.
Delphi ist eine Programierumgebung, oft auch IDE genannt
VCL und FCL sind Bibliotheken visueller Komponenten, wird von manchen 
auch Framework genannt.

Natürlich hat man auch bei Delphi mit einem Framework zu tun. Das ist 
etwas ganz anderes, als das alles dirkt auf dem API von Windows zu 
machen. Den Unterschied kenne ich näher, denn das, was man bei EVC für 
WinCE vor sich hat, ist genau das Programmieren auf dem API von Windows. 
Allerdings bedeutet das keineswegs "jeden Pixel selbst in den 
Grafikspeicher zu schreiben".

Windows (und vermutlich auch der Grafikaufsatz bei Linux) hat ganz 
entschieden etwas gegen derartiges. Es bedeutet eher, am Event-Geschehen 
von Windows teilzunehmen und die bereits im OS angelegte Funktionalität 
der diversen grafischen Komponenten zu ergänzen.

Also Menüs, Listen, usw. mit dem applikationsspezifischen Zeugs zu 
versehen und deren Reaktionen auf Benutzeraktionen zu ergänzen. So etwas 
wird einem natürlich von einer Bibliothek grafischer Elemente (VCL und 
Konsorten) zum größten Teil abgenommen. auch dann, wenn die eigentliche 
Basis-Funktionalität im OS selber drinsteckt.

Allerdings hat das alles überhaupt nichts mit dem Thema dieses Threads 
zu tun:
schmeißfliege schrieb:
> Also eine GUI die Buttons hat und dann mit der Seriellen Schnittstelle
> kommunizieren kann.

Gemeinhin nennt man so etwas ein Terminalprogramm. In verständliche 
Worte konvertiert, lautet also dein Vorhaben: "Ich will ein Programm 
schreiben, das sowohl ein GUI hat als auch mit einigen Standard-Geräten 
wie seriellen Schnittstellen umgehen kann".

Sehr schön, aber das sollte man 2022 schlichtweg können. Und wenn der TO 
bemerkt:
schmeißfliege schrieb:
> Hallo ich habe einen Mikrocontroller den ich über meinen seriellen
> Monitor in Linux steuere.
dann sollte eigentlich der Umgang mit o.g. Schnittstellen bereits 
geläufig sein. Bleibt bloß noch der Umstieg von einer Konsolen-App auf 
eine App mit GUI.

Was mich an solchen Stellen immer wundert: der TO läßt (wie ganz viele 
Andere) die Daten auf der Seriellen mit 115kBaud laufen. Wozu? So 
schnell kann niemand mit den Fingern tippen. Gemütliche 9600 Baud wären 
in solchem Falle völlig ausreichend.

W.S.

von Mehr GHz! (Gast)


Lesenswert?

Das ist doch alles widerliche Mausklickergruetze.

Um an den Nippeln einer seriellen Schnittstelle zu spielen,
gibt es seit Urzeiten stty.

Und die ueberaus schwachsinnige Frage "wieviel" 100 MB
Speicherplatz heute kostet, beweist nur, dass der Dummfrager
den ganzen Rattenschwanz an Implikationen solcher Monster
weder erkennt, noch hinreichend Ernst nimmt.
Aber es ist sein eigenes Verderben in das er rennt.

von c-hater (Gast)


Lesenswert?

Mehr GHz! schrieb:

> Das ist doch alles widerliche Mausklickergruetze.

Natürlich. Nur ist es den allermeisten Leuten halt sehr viel angenehmer, 
ein bissel mit der Maus zu klicken anstatt ellenlange kryptische und oft 
nur unvollständig dokumentierte Parameter auf irgendeiner verschissenen 
Kommandozeile einzugeben.

Nicht umsonst haben sich halt graphische Shells als absoluter Standard 
für produktive Arbeit etabliert. Schon vor Jahrzehnten...

Wenn jemand (ggf. sogar zu Recht) meint, dass Ausweichen auf das CLI was 
bringt bezüglich der Produktivität, heißt das nur genau nur eins: Das 
GUI ist suboptimal und somit verbesserungswürdig.

Auf sowas trifft man mit überragender Signifikanz im OSS-Sektor. Das GUI 
war hier oft das Stiefkind der Entwicklung. Ja, das macht halt auch sehr 
viel mehr Arbeit...

von Zeno (Gast)


Lesenswert?

W.S. schrieb:
> Leute, ihr schmeißt euch mal wieder Schlagworte um die Ohren.
> Also:
> Pascal ist eine Programmiersprache.
> Delphi ist eine Programierumgebung, oft auch IDE genannt
Ich glaube diese Erläuterung kannst Du Dir an dieser Stelle durchaus 
sparen, auch wenn Du recht hast. Allerdings sind Delphi oder auch 
Lazarus im allgemeinen Sprachgebrauch auch Synonyme für Pascal. Beide 
sind ohne Pascal schwer vorstellbar, auch wenn es theoretisch möglich 
wäre mit der IDE was anderes zu machen. Wenn jemand von Delphi redet, 
dann meint er damit in aller Regel Pascal - auch wenn es so nicht ganz 
korrekt ist.

Die VCL Bibliotheken würde ich nun eher nicht als Framework bezeichnen. 
Das sind schlichtweg Klassenbibliothen, wie in anderen 
Programmiersprachen auch.
Unter Framework verstehe ich eher so etwas wie .Net also eine 
Runtimeumgebung ohne die die App halt nicht funktionieren würde. 
Vielleicht wäre auch Runtimeumgebung der bessere Ausdruck an dieser 
Stelle.
Ich meine hier  https://de.wikipedia.org/wiki/Framework ist es ganz gut 
erklärt.

Mehr GHz! schrieb:
> Das ist doch alles widerliche Mausklickergruetze.
>
> Um an den Nippeln einer seriellen Schnittstelle zu spielen,
> gibt es seit Urzeiten stty.
Einige Linuxleute finden es halt geil ellenlange Befehlssequenzen auf 
der Konsole einzutippen - je kryptischer um so besser. Die Zeit ist halt 
nicht stehen geblieben und graphische Oberflächen haben sich aus gutem 
Grund durchgesetzt. Es ist halt mehr als angenehm wenn man z.B. 
komfortabel durch die Konfiguration der seriellen Schnittstelle geführt 
wird. Dabei bedeutet dies nicht das das (Terminal)Programm riesig wird. 
Mit den passenden Komponenten bringt man in einer Exe die kein MB groß 
ist schon sehr viel Komfort unter.

von W.S. (Gast)


Lesenswert?

c-hater schrieb:
> Auf sowas trifft man mit überragender Signifikanz im OSS-Sektor. Das GUI
> war hier oft das Stiefkind der Entwicklung.

Das hast du aber zart formuliert.
Ich kann mich daran erinnern, daß mich Linuxer noch nach 2000 zur Zeit 
von Windows XP zu belehren suchten, daß grafische User-Interfaces nur 
unnützer Kram für Dummköpfe sei und die Kommandozeile hingegen das 
einzig geeignete für den echten Profi.

Inzwischen haben sich die Linuxer zwar dem Druck der Zeit beugen müssen, 
aber das GUI wird insgeheim noch immer gehaßt. Vehement. Und 
entsprechend behandelt.

OK, es ist für manche Programmierer ganz offensichtlich ein erhebliches 
Problem, so etwas wie objektorientiertes Programmieren und 
ereignisgesteuertes Verhalten zu kapieren, anstelle auch weiterhin mit 
der Keule und mit einem PAP geradeaus zu programmieren - und eben 
deswegen ist gerade beim Übergang zum GUI zunächst Unverständnis und 
dann vehemente Ablehnung aufgekommen.

Aber das o.g. Problem zieht sich auch hier bei den Mikrocontrollern 
durch. Ich hatte bereits Anfang 2017, also vor reichlich 5 Jahren mal 
eine konkrete Realisierung für ein Event-System bei einer Firmware für 
die STM32F103 gepostet und noch viele Jahre davor das Menüsystem bei der 
Lernbetty quasi objektorientiert gemacht (soweit man das in C kann), 
aber keinen hat's interessiert. Stattdessen hat es seitdem alle Nase 
lang Gejammer gegeben, weil jemand für seine µC-Anwendung ein Menü 
benötigt und es nicht gebacken kriegt oder ein anderer nicht weiß, wie 
er nicht blockierend programmieren kann.

W.S.

von Zeno (Gast)


Lesenswert?

W.S. schrieb:
> Inzwischen haben sich die Linuxer zwar dem Druck der Zeit beugen müssen,
> aber das GUI wird insgeheim noch immer gehaßt. Vehement. Und
> entsprechend behandelt.
Naja ganz so ist es ja nun auch nicht. Man denke nur mal an Solaris, 
welches ja auch unixoid ist, die hatten schon 1989 eine grafische 
Oberfläche.
Ich hatte seit ca. 1993 viel mit HP-UX zu tun und auch dort gab es die 
grafische Oberfläche (X11). Die Systeme mit denen ich zu tun hatte 
booteten auch in die grafische Oberfläche und man hat sich dort auch 
grafisch angemeldet. Es war auch nicht so, das das einfach nur 
Kommandozeilenprogramme waren, denen man ein GUI übergestülpt hat.
Dennoch sollte man nicht verkennen, das die Kommandozeile gerade für 
administrative Zwecke durchaus ein mächtiges Werkzeug ist - selbst bei 
Windows.
Es steht aber auch außer Frage, das für den normalen Anwender die 
grafische Oberfläche das Maß der Dinge ist. Selbst als auf dem PC 
grafische Oberflächen noch nicht unbedingt Mode waren hat man sich ja 
Gedanken gemacht wie die Handhabung für den normalen Anwender 
vereinfachen kann, was halt mal besser oder schlechter gelungen ist.

Die Crux bei OSS ist halt das es zwar viel gute Ansätze und Ideen gibt, 
die dann am Ende oftmals nur halbherzig umgesetzt werden. Für den der im 
Thema drin steckt oftmals kein Problem, da man meist einen Workaround 
findet, aber für normalen User der mit der SW sein Tagesgeschäft 
erledigen möchte halt einfach nur nervig. Der hat dann auch wenig Lust 
stundenlang nach einer Lösung zu suchen und sich dabei von der Commutity 
noch dumm an machen zu lassen.

von Olaf (Gast)


Lesenswert?

> Ich hatte seit ca. 1993 viel mit HP-UX zu tun und auch dort gab es die
> grafische Oberfläche (X11).

Meine allererste Linuxversion bestand aus 4Disketten und hatte noch 
keine Grafik. 1992 kam dann SLS raus und dort gab es X11 und openlook. 
Das fand ich optisch durchaus cool und nett. Bloed war nur das es das 
nur in zwei Versionen gab, einmal ohne Farben und einmal mit 256Farben. 
Wobei jedes Fenster seine eigenen 256Farben hatte. Schon man also seinen 
Mousecursor (focus follows mouse!) auf ein anderes Fenster sahen die 
anderen inaktiven Fenster ploetzlich komisch aus.
Das lief bei mir auf einem 386SX25 mit 6Mbyte bereits brauchbar.

Auch damals konnte man schon problemlos Grafikprogramme entwickeln indem 
man direct X11 angesprochen hat, oder das openlook framework. ES ging 
aber auch mit Motiv. Die Lizenz dafuer musste ich aber kaufen.

Natuerlich kann der heutige Nachwuchs sowas heute nicht mehr weil man
dazu ja ein Buch kaufen und lesen muesste.

Heute wuerde ich daher eher QT empfehlen. Das ist relativ innovativ und 
idiotensicher wenn man C++ kann. :)

Linux war vor allem im Grafikbereich zu jederzeit besser als das was 
Windows zu gleichen Zeit konnte. So war es z.B damit schon moeglich 
1280x1024pixel zu haben als Windows nicht wusste was das ist. Virtuelle 
Screen waren viel eher da. Die Moeglichkeit ein Programm auf einem 
anderen Rechner zu starten das seine Ausgabefenster auf dem eigenen 
Rechner oeffnet konnte Windows nichts entgegensetzen.
Ich wuerde nicht seit 30Jahren Linux als Hauptbetriebssystem nutzen wenn 
es nicht besser waere. Allerdings laesst Linux in den letzen 10Jahren 
nach weil es durch seine Verzettelung auf ein Dutzend Distributionen 
multipliziert mit tausenden Libaries in unterschiedlichen Versionen 
immer schwieriger wird Software zu installieren. (also mit dem Compiler 
ihr Schnullerbubis. .-) )


Interessanterweise hat es aber gerade bei der Benutzung der seriellen 
Schnittstelle einen Nachteil gegenueber Windows. :-)
Windows uebergibt direkt die Baudrate und kann so auch schraege 
Baudraten, wenn man eine Hardware hat die sie unterstuetzt. Oder auch 
Baudraten groesser B115200. Bei Linux ging das lange nicht, spaeter 
wurde aber das Interface dafuer erweitert. Dafuer muss man aber relativ 
schraeg/complex die Schnittstelle oeffnen. Kann sein das QT einem das 
abnimmt, hab ich dort noch nicht gebraucht. Aber bei Minicom hab ich mir 
bestimmt eine Stunde erstaunt am Kopf gekratzt bis ich da 230400 
eingebaut hatte.

Olaf

von Mehr GHz! (Gast)


Lesenswert?

> Linux war vor allem im Grafikbereich zu jederzeit besser als das was
> Windows zu gleichen Zeit konnte. So war es z.B damit schon moeglich
> 1280x1024pixel zu haben als Windows nicht wusste was das ist.

Windows war die Grafikaufloesung voellig egal. Die Programmerer
des Treibers der Grafikkarte waren entscheidend.
Und man konnte ohne Probleme Grafikkarten erwerbern, die deutlich
mehr als der Marktdurchschnitt konnten.
Hatte man einen passenden Monitor, waren auch 1600x1200 ueberhaupt
kein Problem. Wohlgemerkt mit Windows und nicht mit Linux.
Auch mit "Grafikbeschleunigern" wie IBM8514 oder TIGA tat sich
Linux eher sehr schwer.

Ein X11 unter Linux auf einem i386SX25 (8 MB RAM/ET4000)
war schlicht unbenutzbar langsam.
Ein parallel installiertes SCO-Unix war da bedeutend schneller
ohne natuerlich die Geschwindigkeit einer 8514-kompatiblen
Karte zu erreiechen.


Und Qt ist nun wirklich Mausklickergruetze in Reinkultur.

von Olaf (Gast)


Lesenswert?

> Windows war die Grafikaufloesung voellig egal. Die Programmerer
> des Treibers der Grafikkarte waren entscheidend.

Du musst das zeitgleich sehen. Als ich 1280x1024 genutzt haben waren 
meine
Windows-kumpels alle noch bei 800x600 oder 1024x768 weil die gar keinen 
Monitor hatten der diese Aufloesung konnte. Ich dagegen hatte einen 
Trinitron Festfrequenzmonitor den ich als Student irgendwo guenstig 
gebraucht gekauft hatte. Den haetten Windowsnutzer nicht verwenden 
koennen weil die gar nicht die Frequenzen selber programmieren konnte 
die der gebraucht hat. Ich musste mir sogar das Kabel von VGA auf 5xBNC 
selber basteln.

Als dann die Windowsuser aehnliche Aufloesungen konnten, da hatte ich 
schon eine Mach32 (spaeter dann Mach64) die ich auf 1280x1024 nutzen 
konnte, aber zusaetzlich noch mit einem groesseren virtuellen Screen.

Ich glaube unter Win3.11 war denen das nicht so wichtig weil das sowieso 
bei mehr wie zwei Programmen gleichzeitig abgestuerzt ist. :-D

> Hatte man einen passenden Monitor, waren auch 1600x1200 ueberhaupt
> kein Problem. Wohlgemerkt mit Windows und nicht mit Linux.

Aber nicht als Student der sich seine Kohle selber verdienen musste. Ich 
sah das halt aus dem Blick eines 25Jaehrigen Studenten der Kohle nicht 
scheissen konnte. In Firmen war man da vermutlich schon weiter.

> Ein X11 unter Linux auf einem i386SX25 (8 MB RAM/ET4000)
> war schlicht unbenutzbar langsam.

Nein. Das lief gut. Kann aber sein das ich das mit dem 486DLC 
verwechsel. (das war so ein aufgebohrter 386er von Cyrix) Ist ja schon 
was her. Ich weiss jedenfalls das damals ein Freund entweder SCO oder 
Interactive auf einem 486DX33 laufen hatte und der war erstaunt wie 
schnell X11 bei mir lief. Nur musstest man damals sehr viel Raubsoft 
verschieben um sich einen 486DX33 leisten zu koennen. Das waren sehr 
viele tausend DM! Das wollte nicht jeder machen. Ich hab z.B noch in 
Erinnerung das alleine die 1GB SCSI Platte damals 5000DM kostete.

> Und Qt ist nun wirklich Mausklickergruetze in Reinkultur.

Das will man heute halt. Aber du kannst das ja auch ohne die Oberflaeche 
machen. :-D Aber ich finde das erstellen des Look&Feel seines Programms 
mit der Maus durchaus okay und als Verbesserung.

Olaf

von Olaf (Gast)


Lesenswert?

Um mal was substanzielles beizutragen. Es gibt immer noch xforms:

http://xforms-toolkit.org

Ja, das ist steinalt. Aber als Anfaenger kommt man damit sehr
schnell zu Ergebnissen. Es kann sicher 100x weniger wie Qt,
aber es ist auch 100x schneller gelernt.

Ich nutze das immer noch gelegentlich fuer kleine Test, z.B
wenn ich eine Mikrocontrollersache zum testen auf einen PC
laufen lassen will. Ich wuerde damit keine dicke Anwendung
schreiben, aber fuer erste Spielereien ganz nett, vor allem
wenn man nur C und noch kein C++ kann.

Olaf

von Mehr GHz! (Gast)


Lesenswert?

> Du musst das zeitgleich sehen.

Muessen muss ich gar nichts. Ich war aber mit dem Studium schon
fertig, und stand im Berufsleben.
Ein 21" Multisync war zwar teuer, aber fuer professionelles Arbeiten
auch unverzichtbar. Der konnte mit einer passenden Grafikkarte
angesteuert auch FHD mit Interlace. Zum Arbeiten war das eher nichts,
aber ausgezeichnet geeignet sich an den ersten HD-Uebertragungen
zu erfreuen.

Bei meinem Urteil ueber X11 unter den fruehen Linuxreleases
(bei mit LST1.8) bleibe ich aber. Das war schlicht unbrauchbar.
Allerdings hatte der Rechner "daneben" auch schon einen
Grafikbeschleuniger und das was auch kein 386SX mehr.
Aber auch auf dem lief ein SCO Open Desktop. Treiber fuer Linux
waren da immer noch Fehlanzeige.

Was ein 386SX haette leisten koennen, konnte man ja im parallel
installierten SCO Unix gut sehen.

Deine Einschaetzung erinnert mich eher an einen Bekannten,
der die Qualitaet einer mit 3 bit gewandelten Audiodatei
aus einem Commodore C-16 als "gut" bezeichnete.
Da konnte man nur mit dem Kopf schuetteln.

von Alexander S. (alesi)


Lesenswert?

Olaf schrieb:
> Um mal was substanzielles beizutragen. Es gibt immer noch xforms:
>
> http://xforms-toolkit.org

Neben dem xforms-toolkit gibt es auch noch das Fast Light Toolkit FLTK
https://www.fltk.org/
Es gibt dazu auch ein interaktives UI-Tool FLUID. FLTK verwendet aber 
C++.

von Olaf (Gast)


Lesenswert?

> Aber auch auf dem lief ein SCO Open Desktop. Treiber fuer Linux
> waren da immer noch Fehlanzeige.

Ich hatte in 30Jahren nie ein Treiberproblem mit Linux. Das lag daran
das ich die Hardware immer passend zu den in Linux verfuegbaren
Treibern gekauft habe und nicht umgekehrt. .-)

> Deine Einschaetzung erinnert mich eher an einen Bekannten,

Du warst einfach zu verwoehnt. :)

BTW: Ich hab vor 10Jahren mal meinen alten ][+ in Betrieb genommen,
mein erster Gedanke: Oh..was flimmert der Bildschirm. Dabei
hatte ich einen Monocrom-Monitor mit entsprechender Nachleuchtdauer
Und frueher haben wir ja sogar mit HF-Modulator auf dem TV
gecodet und fanden es okay. Kann man sich heute echt nicht mehr
vorstellen. Jaja...Opa erzaehlt vom Krieg. :-D

Olaf

von Zeno (Gast)


Lesenswert?

Olaf schrieb:
> Meine allererste Linuxversion bestand aus 4Disketten und hatte noch
> keine Grafik.
Ja, ja Disketten - das waren noch Zeiten. Mein erstes Linux hatte, wenn 
ich mich recht entsinne 40 Disketten. X11 war da auch dabei und wenn man 
den vi bedienen konnte (was ich damals noch nicht wirklich konnte) dann 
hat man es sogar geschafft X11 zum Laufen zu bringen. Wirklich produktiv 
arbeiten konnte man damals aber mit dem Ganzen nicht wirklich. 
Irgendwann gab's dann Dreamlinux  (auf CD) aber ein Traum war es nicht 
wirklich. Mein erstes Linux mit dem man halbwegs vernünftig was machen 
konnte, war eigentlich RedHat. Da lief dann auch Kylix drauf, so das man 
schon kleine Dinge mit GUI machen konnte.

Olaf schrieb:
> Ich glaube unter Win3.11 war denen das nicht so wichtig weil das sowieso
> bei mehr wie zwei Programmen gleichzeitig abgestuerzt ist. :-D
Kann man so auch nicht sagen. Ich habe lange mit der 3.1, später dann 
mit dem Aufsatz Win32s gearbeitet. Man konnte da schon mehr als 2 
Programme laufen lassen, wenn die ordentlich programmiert waren und die 
sich an die Regeln gehalten haben, war halt preemptives Multitasking mit 
all seinen Schwächen. Dem System ging da eher der Speicher aus. Damals 
waren 4MB schon viel. Ich habe mir da irgendwann mal zusätzliche 4MB 
gegönnt weil ich OS/2 ausprobieren wollte. Eigentlich ein gutes System 
es hat halt hohe Hardwareanforderungen gestellt und die war seinerzeit 
eben richtig teuer. Die 8MB waren ja nur ne Minimalanforderung, richtig 
flüssig lief es da nicht. Da OS/2 auch DOS- und Windowsprogramme 
ausführen konnte, war SW auch kein Problem. Es lief eigentlich auch 
recht stabil. Hauptproblem war die Hardware. Es gab nur wenige 
Hersteller die Treibe für OS/2 bereitgestellt haben.

Olaf schrieb:
> (also mit dem Compiler
> ihr Schnullerbubis. .-) )
Warum mußt Du hier schon wieder rum rotzen? Bist Du was Besseres? Mit 
solchen Äußerungen tust Du der Linuxcommunity keinen Gefallen. Du 
stärkst damit nur die Meinung das ein Großteil der Linuxuser die Nase 
etwas zu hoch trägt. Im Übrigen spricht Softwareinstallation durch 
Kompilieren aus den Quellen nicht unbedingt für das System. Das zeigt 
nur das es da zuviel Wildwuchs gibt und es oftmals gar keine andere 
Möglichkeit gibt, als die Software auf diesem Weg zu installieren. Das 
ist für die Allgemeinheit eher negativ als positiv. Da zeigen andere OS, 
und das muß noch nicht einmal Win sein, das so etwas besser geht.

Olaf schrieb:
>> Ein X11 unter Linux auf einem i386SX25 (8 MB RAM/ET4000)
>> war schlicht unbenutzbar langsam.
>
> Nein. Das lief gut.
Aber nicht auf einem 386SX mit 25MHz. Ich hatte seinerzeit einen 386DX 
mit 40MHz + Coprozessor und da ging es dann so halbwegs. Mit einem 486 
lif es dann deutlich besser.

von Olaf (Gast)


Lesenswert?

> ich mich recht entsinne 40 Disketten. X11 war da auch dabei und wenn man
> den vi bedienen konnte (was ich damals noch nicht wirklich konnte) dann
> hat man es sogar geschafft X11 zum Laufen zu bringen. Wirklich produktiv
> arbeiten konnte man damals aber mit dem Ganzen nicht wirklich.

Wie definierst du arbeiten? Ich hab damals darauf mit LaTeX meine 
Diplomarbeit geschrieben und ausgedruckt. Einfach so. Ein Freund hat den 
Fehler gemacht das mit Word zu machen und das ist dann jedesmal beim 
Ausdruck abgestuerzt wegen Speichermangel und 16MB haben da noch 1000DM 
gekostet. Die musste er sich dann fuer den finalen Druck zusammenleihen.
Ausserdem hatte ich den Eindruck das auf den Windowskisten in >80% der 
Zeit Spiele liefen und das konnte man unter Linux wirklich nicht so gut. 
Das scheint mir die Produktivitaet doch sehr Richtung Linux zu 
verschieben. .-)

> Warum mußt Du hier schon wieder rum rotzen? Bist Du was Besseres?

Nein, ich bin nur kein Opa der zum Lachen in den Keller geht.

> Mit einem 486 lif es dann deutlich besser.

Das ist unbestritten. Muss man sich aber leisten koennen. Als ich mit 
dem 386SLC angefangen habe da hatte mein gesamter Freundeskreis noch 
286er weil man erstmal die Kohle haben musste. Ich hatte auch nur 
deshalb so frueh aufgeruestet weil das halt fuer Linux die 
Minimalausstattung war.

> etwas zu hoch trägt. Im Übrigen spricht Softwareinstallation durch
> Kompilieren aus den Quellen nicht unbedingt für das System. Das zeigt

Ist halt manchmal praktisch wenn man etwas veraendern will. Siehe z.B 
mein im Thread genanntes Beispiel wo ich minicom gepatcht habe damit es 
230400Baud konnte.

Oder schau mal hier:

http://www.verycomputer.com/169_2c700e4d74d6d026_1.htm

Die reden da ueber einen Patch zu tin den ich 1996 geschrieben habe
damit man usenet in Farbe lesen konnte. Haette ich wohl kaum gemacht
wenn ich den Reader nicht selber haette uebersetzen koennen.
Man muss nicht muessen, aber es waere schoen wenn man noch koennte...

> nur das es da zuviel Wildwuchs gibt und es oftmals gar keine andere
> Möglichkeit gibt, als die Software auf diesem Weg zu installieren.

Das kritisiere ich durchaus. (auch in diesem Thread) Linux wird seit 
10Jahren eher schlechter als besser.

Olaf

von Norbert (Gast)


Lesenswert?

Olaf schrieb:
> Das kritisiere ich durchaus. (auch in diesem Thread) Linux wird seit
> 10Jahren eher schlechter als besser.

Verdammt. Jetzt hatte ich mich während der vergangenen 18 Jahre so daran 
gewöhnt, es lieb gewonnen und zu meinem Betriebssystem der ersten (und 
ausschließlichen) Wahl gemacht.
Und jetzt das!
Sollte ich doch besser wechseln? Hmmm, decisions, decisions…

von W.S. (Gast)


Lesenswert?

Olaf schrieb:
> Linux war vor allem im Grafikbereich zu jederzeit besser als das was
> Windows zu gleichen Zeit konnte.

Jetzt sind wir wieder beim Üblichen: Schlammschlacht zwischen Windows 
und Linux.

Also erstmal ne Klärung: der PC, genauer der PC von IBM war gedacht als 
eine Kiste, die sich leistungsmäßig von "echten" Rechnern nach unten hin 
unterscheidet und dennoch sowohl recht leicht erweiterbar ist als auch 
für die übliche Büroarbeit geeignet ist. Eben der 8088 - und zwar mit 
DOS. Dort überhaupt Grafik ins Betriebssystem zu kriegen, ist das 
Verdienst von Microsoft. Grafik überhaupt gab es schon früher. Ich 
entsinne mich, bereits zu DOS-Zeiten mit Autocad 3D-Konstruktionen 
gemacht zu haben. Das war damals noch ein recht umständliches Arbeiten - 
nicht wegen des allgegenwärtigen 'Hochziehens' für die 3. Dimension, 
sondern wegen der vielen notwendigen Tastaturarbeit.
Linux ist eine Kopie von Unix, um dessen Lizenzen zu umgehen. Und das 
eigentliche Betriebssystem war und ist grafiklos, zum Gucken gibt es 
dort eben einen grafischen Aufsatz und zum Drucken gibt es dort 
Ghostsript, was wegen des edleren Namens in CUPS umbenannt wurde. Unix 
und damit Linux ist also strenggenommen weder grafikfähig noch 
druckfähig - beides ist Angelegenheit von anderweitigen Programmen.

Aber das ist hier kein Thema, sondern das Ansinnen des TO, ein Programm 
zu schreiben, was sowohl ein GUI hat als auch mit seriellen 
Schnittstellen umgehen kann. Und da der TO zumindest in Sachen GUI noch 
Rat sucht, wäre es hier angemessen, eben darüber zu diskutieren.

Zeno schrieb:
> Naja ganz so ist es ja nun auch nicht. Man denke nur mal an Solaris,
> welches ja auch unixoid ist, die hatten schon 1989 eine grafische
> Oberfläche.

Doch, doch. Mein erstes Linux war die "DLD 1.0" auf CD. Und das war 
1994. Und es war grauenhaft. Ja, X11 gab's schon damit, aber man hatte 
da einen SEHR aufgeräumten grob geditherten Bildschirm, mit dem man rein 
garnix hat anfangen können.
Und was andere 'unixoide' Kisten betrifft: Da entsinne ich mich an die 
Leute, die unsereinem eine Iris-Indigo mit einem CAD-System drauf 
schmackhaft machen wollten. Das sah zwar erstmal ganz nett aus, aber 
allein die Indigo war preislich weit über dem Budget. Von den 
Lizenzkosten für das CAD ganz zu schweigen.

W.S.

von Norbert (Gast)


Lesenswert?

W.S. schrieb:
> Und da der TO zumindest in Sachen GUI noch
> Rat sucht, wäre es hier angemessen, eben darüber zu diskutieren.

Ja das stimmt.
Hatte ich schon. Oben. Sehr weit oben.

Wenn er in Python programmieren möchte, würde ich wxWidgets empfehlen. 
Der GUI-Designer wxGlade kann dann sofort Python Code generieren. Den 
kann man modifizieren oder aber in größere Projekte importieren.

Sollte er jedoch in C++ programmieren, würde ich wxWidgets empfehlen. 
Der GUI-Designer wxGlade kann dann sofort C++ Code generieren.

Nennt sich die Sprache seiner Wahl Lisp, würde ich wxWidgets empfehlen. 
Der GUI-Designer wxGlade kann dann sofort Lisp Code generieren.

Falls er aber lieber Perl Code schreiben möchte,  würde ich wxWidgets 
empfehlen. Der GUI-Designer wxGlade kann dann sofort Perl Code 
generieren.

Soll das Ganze auf Windows laufen, würde ich…

von Karl (Gast)


Lesenswert?

Der TO hat sich für GTK entschieden. Die alten Männer Geschichten 
interessiert den nicht mehr.

von Norbert (Gast)


Lesenswert?

Karl schrieb:
> Der TO hat sich für GTK entschieden.

Da schau her. Das ist ja eine ganz wichtige Information.

Das Gute daran ist: Alle die später mal bei einer Suche nach GUI und 
Linux diesen Thread finden, können dann auch automatisch GTK nehmen.

Wohl durchdacht dein Einwand, Hut ab der Herr…

von Lothar (Gast)


Lesenswert?

Karl schrieb:
> Der TO hat sich für GTK entschieden

FLTK in C++ wäre einfacher gewesen.

GTK ist der schlechte Versuch in C OOP zu machen.

von Zeno (Gast)


Lesenswert?

Olaf schrieb:
> Ich hab damals darauf mit LaTeX meine
> Diplomarbeit geschrieben und ausgedruckt.
Ja schön für Dich. Ich habe meine Diplomarbeit mit Schreibmaschine auf 
Transparentpapier geschrieben, denn wir hatten noch keine Computer auf 
denen man das hätte tun können.

von Norbert (Gast)


Lesenswert?

Zeno schrieb:
> Olaf schrieb:
>> Ich hab damals darauf mit LaTeX meine
>> Diplomarbeit geschrieben und ausgedruckt.
> Ja schön für Dich. Ich habe meine Diplomarbeit mit Schreibmaschine auf
> Transparentpapier geschrieben, denn wir hatten noch keine Computer auf
> denen man das hätte tun können.

Immerhin gab's wohl schon Schreibmaschinen, Prototypen vielleicht? ;-)

von Zeno (Gast)


Lesenswert?

W.S. schrieb:
> Ja, X11 gab's schon damit, aber man hatte
> da einen SEHR aufgeräumten grob geditherten Bildschirm, mit dem man rein
> garnix hat anfangen können.
Ich schrieb nix anderes.

W.S. schrieb:
> Da entsinne ich mich an die
> Leute, die unsereinem eine Iris-Indigo mit einem CAD-System drauf
> schmackhaft machen wollten. Das sah zwar erstmal ganz nett aus, aber
> allein die Indigo war preislich weit über dem Budget.
Ja das war wohl seinerzeit so und ist heutzutage letztendlich auch nicht 
anders. Mit einem Unterschied, heutzutage ist die für jedermann 
bezahlbare Technik deutlich weiter und man kann damit Dinge machen von 
denen wir vor 30 Jahren, ja ja so lang ist schon her, nicht zu träumen 
gewagt hätten. Mit anderen Worten, heutzutage sind mit der zu einem 
vernünftigen Preis verfügbaren Technik eigentlich die meisten Dinge 
abgedeckt. Selbst anspruchsvolle SW läuft heute auf den meisten Systemen 
problemlos.
Wer an sein Equipment höhere Ansprüche stellt muß aber auch heute noch 
tief in die Tasche greifen, sowohl bei HW als auch bei SW, wenn auch 
nicht mehr ganz so stolze Preise wie Anfang der 90'ziger aufgerufen 
werden.

von Rolf M. (rmagnus)


Lesenswert?

Zeno schrieb:
> Ja, ja Disketten - das waren noch Zeiten. Mein erstes Linux hatte, wenn
> ich mich recht entsinne 40 Disketten. X11 war da auch dabei und wenn man
> den vi bedienen konnte (was ich damals noch nicht wirklich konnte) dann
> hat man es sogar geschafft X11 zum Laufen zu bringen. Wirklich produktiv
> arbeiten konnte man damals aber mit dem Ganzen nicht wirklich.

X11 war damals Gerüchten zufolge hauptsächlich dafür da, mehrere 
Terminals gleichzeitig anzuzeigen.

> Olaf schrieb:
>> Ich glaube unter Win3.11 war denen das nicht so wichtig weil das sowieso
>> bei mehr wie zwei Programmen gleichzeitig abgestuerzt ist. :-D
> Kann man so auch nicht sagen. Ich habe lange mit der 3.1, später dann
> mit dem Aufsatz Win32s gearbeitet. Man konnte da schon mehr als 2
> Programme laufen lassen, wenn die ordentlich programmiert waren und die
> sich an die Regeln gehalten haben, war halt preemptives Multitasking mit
> all seinen Schwächen.

Du meinst kooperatives Multitasking. Ich hatte damals Windows 3.1 als 
eher stabil im Vergleich zu den darauf folgenden Versionen empfunden. 
Aber wie du schon sagst, hängt es bei 3.1 noch sehr stark von der 
genutzten Software ab.

: Bearbeitet durch User
von Zeno (Gast)


Lesenswert?

Rolf M. schrieb:
> Du meinst kooperatives Multitasking.
Ja hast recht, habe mich da vertan.

von Norbert (Gast)


Lesenswert?

Wir können auch gerne noch ein wenig über Sinix, Xenix, und Santa Cruz 
Operations reden, aber ging es hier nicht um GUI Programmierung auf 
einem Linux System?

Und zwar im Jahre 2022? Irgendwann gegen Vormittag?

Frag' ja nur…

von Mehr GHz! (Gast)


Lesenswert?

> Ich habe meine Diplomarbeit mit Schreibmaschine auf
> Transparentpapier geschrieben, denn wir hatten noch keine Computer auf
> denen man das hätte tun können.

So kenne ich das auch.

Man haette die(den) Komputer der Universitaet nutzen koennen.
Allerdings nur im Time-Sharing. Sowas kennt heute gar keiner mehr :).

Die Schreibmashcine, auf der schon meine Mutter ihre wissenschaftlichen
geschrieben hatte, stand zu 100% zur Verfuegung.
Und: Ich habe selber getippt!


Wenn das einer 2062 liest, findet er den "Alte Maenner"-Teil
sicher interessanter, als das Palaver um eine GUI.

von Karl (Gast)


Lesenswert?

Norbert schrieb:
> Da schau her. Das ist ja eine ganz wichtige Information.
> Das Gute daran ist: Alle die später mal bei einer Suche nach GUI und
> Linux di

Na besser als die Schreibmaschine scheint es ja zu sein.

Lothar schrieb:
> FLTK in C++ wäre einfacher gewesen.
> GTK ist der schlechte Versuch in C OOP zu machen.

wx wäre noch besser gewesen und c++ ist der schlechte Versuch C in OOP 
zu machen.

von Zeno (Gast)


Lesenswert?

Mehr GHz! schrieb:
> Man haette die(den) Komputer der Universitaet nutzen koennen.
> Allerdings nur im Time-Sharing. Sowas kennt heute gar keiner mehr :).
Vielleicht ja, aber ich meine die Drucker von damals konnten nur 
Endlospapier und das Druckbild war zudem noch beschissen.
So eine Diplomarbeit sollte schon irgendwie ordentlich aussehen. 
Transparentpapier war Vorschrift, damit das Ganze am Ende pausfähig 
(Lichtpausen) war. Frag da heute mal einen was Lichtpausen ist.

von c-hater (Gast)


Lesenswert?

Olaf schrieb:

> Linux war vor allem im Grafikbereich zu jederzeit besser als das was
> Windows zu gleichen Zeit konnte.

Nein, sicher nicht. Siehe allein das Thema Multi-Monitor. Als es unter 
Windows längst völlig normal war, eine sich über mehrere Monitore 
erstreckenden Desktop zu haben, war das mit Linux sehr lange eine 
überaus kitzlige Sache. Selbst als die Funktion grundsätzlich gegeben 
war, hat es nochmal sehr lange gedauert, bis es dann auch (einigermaßen) 
komfortabel über das GUI eingerichtet werden könnte.

> Interessanterweise hat es aber gerade bei der Benutzung der seriellen
> Schnittstelle einen Nachteil gegenueber Windows. :-)
> Windows uebergibt direkt die Baudrate und kann so auch schraege
> Baudraten, wenn man eine Hardware hat die sie unterstuetzt. Oder auch
> Baudraten groesser B115200. Bei Linux ging das lange nicht, spaeter
> wurde aber das Interface dafuer erweitert.

Ja, die allseits beliebte termiosX-Scheiße. Aber das ist ein sehr 
schönes Beispiel dafür, wie schwachsinnig eng gedachte Konzepte den 
Fortschritt stören können. Auch o.g. Multimonitor-Problem geht letztlich 
ja auf so eine zu eng konzipierte Schnittstelle zurück.

Man kann viel negatives über Windows sagen (wer wüßte das besser als die 
Leute, die ihre Brötchen damit verdienen, für dieses Zielsystem zu 
programmieren), aber die API-Designer von MS haben definitiv deutlich 
mehr Weitblick bewiesen. Allerdings gibt es leider natürlich auch hier 
viele Beispiele für Fälle, wo auch die nicht weitsichtig genug waren. 
Man schaue sich einfach nur eine Liste der Funktions- und/oder 
Strukturnamen an, die auf "Ex" enden...

Fazit: überall wird nur mit Wasser gekocht.

von W.S. (Gast)


Lesenswert?

Norbert schrieb:
> Soll das Ganze auf Windows laufen, würde ich…

...na lieber nicht. Ich hatte ein Weile etwas gegen Embarcadero, weil 
die kein frei zugängliche Bastler-Edition hatten. Ist mittlerweile 
anders, ein jeder kann sich ein kostenloses Delphi herunterladen. Und 
wenn es Linux sein soll, dann würde ich zu Lazarus greifen.

W.S.

von W.S. (Gast)


Lesenswert?

Mehr GHz! schrieb:
> Man haette die(den) Komputer der Universitaet nutzen koennen.

Also am Annahme-Fensterchen vom Rechenzentrum anstehen, den Blechkasten 
mit den Lochkarten die ganze Zeit am Arm?
Oder:
Zu unmöglichen Zeiten (so 3 Uhr 15 bis 4 Uhr in der Nacht) den Rechner 
in der Sektion benutzen dürfen und sich seine Lochbandrollen selber 
mitbringen?

W.S.

von Mehr GHz! (Gast)


Lesenswert?

> Transparentpapier war Vorschrift

Und ein Kohlebogen fuer die Rueckseite!
Sonst gab es Abzuege in der Haltungsnote.

> Also am Annahme-Fensterchen vom Rechenzentrum anstehen, den Blechkasten
> mit den Lochkarten die ganze Zeit am Arm?
> Oder:
> Zu unmöglichen Zeiten (so 3 Uhr 15 bis 4 Uhr in der Nacht) den Rechner
> in der Sektion benutzen dürfen und sich seine Lochbandrollen selber
> mitbringen?

Ja, so in etwa. Such dir ein Szenario aus.
Gegen eine Schreibmaschine kommen beide nicht an.
Am "grossen" Rechner wurden nur Karten gestanzt.
Lochband war da Fehlanzeige. Und gedruckt wurde auf
Kettenraddruckern mit dem typisch etwas unregelmaessigen
Schriftbild.
Die "kleinen" haetten immerhin Typenraddrucker gehabt.
Ich bin mir aber gerade nicht sicher ob die nur Grossbuchstaben
im Typenrad hatten :).

Sehr lustik ist auch der parallele Fred zum Thema
Desktop-Linux und die damit verbundenen Wehwehchen:
"Umstieg auf Kinux von Win"

Ich habe uebrigens mit der Verwendung diverser Unixe/Linuexxe
ueberhaupt kein Problem. Die Erkenntnis das zumindest
bei Linux etwas "abgestandene" Hardware heute einfacher
zum Erfolg fuehrt. Das war frueher aber auch schon so.

von Mehr GHz! (Gast)


Lesenswert?

> Ich hatte in 30Jahren nie ein Treiberproblem mit Linux

Ein GRML von 2018 (fuer Nichteingeweihte: eine Linuxdistribution)
verweigert sich bis hin zur Unbenutzbarkeit wegen einem SD-Karten Leser
in einem Rechnersystem von ca. 2012.
Man muss vor der Benutzung tatsaechlich die SD-Karte herauspuhlen.
Da haette man also schon ca. 6 Jahre Zeit gehabt das zu fixen.

Das aktuelle GRML kann nun zwar mit dem SD-Karten-Leser umgehen,
schafft es aber nicht mehr die WLAN-Schnittstelle zu bedienen:
Firmwareerror -6!

Gut das ich nicht darauf angewiesen bin dass es funktioniert.

von Lothar (Gast)


Lesenswert?

c-hater schrieb:
> termios ... Windows

Ein serial.c unter Linux ist doch nicht schwieriger als unter Windows. 
Das Einzige was man unter Linux beachten muss ist, dass sich read() ohne 
poll() aufhängen kann, selbst wenn es auf non-blocking gesetzt wurde.

Die Unix und die Arduino Programmierer scheinen ähnlich zu denken ;-)

Rolf M. schrieb:
> Du meinst kooperatives Multitasking

RISC OS ist natürlich das Beste für seriell :-)

https://www.riscosopen.org/wiki/documentation/show/OS_GBPB%204

von Maxe (Gast)


Lesenswert?

W.S. schrieb:
> Lochkarten

"The future is now, old man!"

von Zeno (Gast)


Lesenswert?

Mehr GHz! schrieb:
> Und ein Kohlebogen fuer die Rueckseite!
Genau so!
Und wenn man sich in der letzten Zeile vertippt hat - die ganze Seite 
noch einmal.

von Zeno (Gast)


Lesenswert?

Mehr GHz! schrieb:
> Das aktuelle GRML kann nun zwar mit dem SD-Karten-Leser umgehen,
> schafft es aber nicht mehr die WLAN-Schnittstelle zu bedienen:
> Firmwareerror -6!
Na dann sei mal froh das Du keine alte NVidia Karte in Deinem Rechner 
hast. Da gibt es zwar einen ein freien Treiber (nouveau), aber der 
funktioniert nicht wirklich. Ist offenbar sehr abhängig vom 
Gesamtsystem. Unter Ubuntu aktuellste Version > Totalversagen, nach dem 
3.Mausschubser schmiert dann das System ab. Debian11 mit alter 
Gnomeoberfläche da funktioniert er so leidlich, allerdings scheiter er 
am 2.Monitor. Linux Mint 20.03 mit XFCE funktioniert recht brauchbar. 
Allerdings ist es mir mit viel Mühe gelungen, Mint den propitären 
Treiber von NVidia zu verklickern und jetzt funktioniert es wie es soll.

von Olaf (Gast)


Lesenswert?

> Gut das ich nicht darauf angewiesen bin dass es funktioniert.

Warum jammerst du dann rum? Wenn du unbedingt irgendeinen Exotenkram 
nutzen willst dann fix das doch. Und wenn du das nicht kannst dann 
kannst du dir ja immer noch den neuesten Kernel runterladen und den 
installieren.
Und wenn du alles nicht kannst und auch keine Hardware kaufen willst 
fuer die es brauchbare Treiber gibt dann bist du halt nicht der richtige 
User fuer Linux.

Olaf

von Mehr GHz! (Gast)


Lesenswert?

> Warum jammerst du dann rum? Wenn du unbedingt irgendeinen Exotenkram
> nutzen willst

Es war mir ja fast klar, dass man bei Kritik mehr oder weniger sofort
angepflaumt wird.
Der vermeintliche Exotenkram ist Intel-/Broadcomhardware verbaut von HP.

Und ja, frueher habe ich meine Kernel noch selber gebaut.
Mit einem umfaenglichen Sets an Patchen, und Treibern die ich
zum Teil sogar selber geschrieben habe.

Besagtes GRML kommt aber als ISO daher, mit der Intention das
man es einfach nur auf einen USB-Stick schreiben und dann
genauso einfach benutzen kann.
Nicht das ich es nicht koennte den dort enthaltenen Kernel
durch einen "Eigenbau" zu ersetzen. Ich will es einfach nicht.
Ich puhle also lieber die SD-Karte aus dem Leser und benutze
einfach die Version von 2018...
Besagte Hardware ist mir uebrigens erst kuerzlich "zugelaufen".
Ich finde die Zeitspanne von 2012 bis 2018 eigentlich auch schon
so als lang genug, dass solche Bugs:
- bemerkt werden
- und gefixt werden.

Im andern Fred schrieb jemand etwas von 2 % Anteil an
Desktop-Linuxusern. Ich bin ueberzeugt, dass ca. die Haelfte
davon auch einen Kernel bauen koennten. Bei der anderen Haelfte
wird die Hardware eventuell auch so funktionieren.
Und jetzt rate mal warum es nur (noch?) 2 % sind, die ueberhaupt
mal ein Linux an ihren Rechner lassen.

Mein Eindruck von der Treiberentwicklung im Linuxumfeld ist
ohnehin eher desastroes. Da werden bereits funktioriende Treiber
ohne Ruecksicht auf Verluste fuer neuere Hardware "zurechtgepatcht",
mit der Folge dass die aeltere Hardware mit diesem Treiber
dann nicht mehr funktioniert. Und mit ein wenig Pech endet
der Support fuer die Majorline, so dass diese Bugs dann auch
nicht mehr gefixt werden. Weil es ja ein "neues" Majorrelease
gibt...

Selbst bei Kunden wird heute eher eine Windowslizenz gekauft,
und eine Applikation darunter betrieben, als das ueberhaupt noch
ernsthaft eine alternative Installation der auch fuer Linux
verfuegbaren Applikation in Erwaegung gezogen wird.
Die Support-(Folge-)kosten der Linuxumgebung sind schlicht nicht
mehr abschaetzbar.

von Zeno (Gast)


Lesenswert?

Mehr GHz! schrieb:
> Im andern Fred schrieb jemand etwas von 2 % Anteil an
> Desktop-Linuxusern.
Da war ich der Bösewicht.

Mehr GHz! schrieb:
> Selbst bei Kunden wird heute eher eine Windowslizenz gekauft,
> und eine Applikation darunter betrieben, als das ueberhaupt noch
> ernsthaft eine alternative Installation der auch fuer Linux
> verfuegbaren Applikation in Erwaegung gezogen wird.
> Die Support-(Folge-)kosten der Linuxumgebung sind schlicht nicht
> mehr abschaetzbar.
Genauso ist es. In den 90'zigern hat man öfter mal auch was anders als 
Windows bei den Kunden gesehen. Ich habe öfter mal ein CAD Programm 
gesehen welches unter HP-UX lief. Bei einigen Kunden gab es auch Sun. 
Die Firma in der ich arbeite hatte ebenfalls eine Software die auf HP-UX 
lief und die wurde zw. 1995 und 2000 auf auf Linux portiert. Beide 
Softwarepakete wurden sehr viel eingesetzt.
Mittlerweile ist das alles verschwunden und an Stelle der Unixkisten 
werkelt halt ein Windowsrechner. Auch unsere Kunden sind mittlerweile 
auf von UX auf Windows umgestiegen, obwohl der Umstieg für viele erst 
mal ne gewaltige Investition war.
Das muß ja einen Grund haben warum das gemacht wird. Linux auf dem 
Desktop habe ich im industriellen Umfeld in in 40 Jahren eher nicht 
gesehen, mit Ausnahme unserer Anlagen.

von W.S. (Gast)


Lesenswert?

Olaf schrieb:
> Und wenn du alles nicht kannst und auch keine Hardware kaufen willst
> fuer die es brauchbare Treiber gibt dann bist du halt nicht der richtige
> User fuer Linux.

Tja, genau DAS ist die Linux-Sichtweise: Der Mensch als Zubehör zur 
Maschine. Nur die Menschen taugen, die zur Maschine passen.

Da braucht man sich nicht drüber zu wundern, daß so etwas zu der 
Marktsituation führt, wie wir sie haben.

W.S.

von Norbert (Gast)


Lesenswert?

Olaf schrieb:
> Und wenn du alles nicht kannst und auch keine Hardware kaufen willst
> fuer die es brauchbare Treiber gibt dann bist du halt nicht der richtige
> User fuer Linux.

Full-ACK!

W.S. schrieb:
> Tja, genau DAS ist die Linux-Sichtweise: Der Mensch als Zubehör zur
> Maschine. Nur die Menschen taugen, die zur Maschine passen.
> Da braucht man sich nicht drüber zu wundern, daß so etwas zu der
> Marktsituation führt, wie wir sie haben.

Vielleicht wäre es ja mal eine gute Idee einige der Hardware-Hersteller 
anzuschnauzen. Die nämlich, welche es nicht für möglich erachten Treiber 
für ihr Hardware-Gelumpe zur Verfügung zu stellen.
Oder zumindest das wenige was sie haben der Open-Source Gemeinschaft zur 
Verfügung zu stellen. Selbst der Source-Code für ihre Windows Treiber 
wäre da schon eine Hilfe.

Aber nein, es ist bequemer Linux die Schuld zu geben…

von udok (Gast)


Lesenswert?

Norbert schrieb:
> Vielleicht wäre es ja mal eine gute Idee einige der Hardware-Hersteller
> anzuschnauzen. Die nämlich, welche es nicht für möglich erachten Treiber
> für ihr Hardware-Gelumpe zur Verfügung zu stellen.
> Oder zumindest das wenige was sie haben der Open-Source Gemeinschaft zur
> Verfügung zu stellen. Selbst der Source-Code für ihre Windows Treiber
> wäre da schon eine Hilfe.

Typisch Linux User.  Schuld sind immer die anderen...
Warum machst du das "Hardware-Gelump" nicht selber?

Wenn du zu blöd dazu bist, überweise doch 100 Euro / Stunde,
damit jemand mit Ahnung das zusammenlumpen kann...

von linuxguru (Gast)


Lesenswert?

Norbert schrieb:
> Vielleicht wäre es ja mal eine gute Idee einige der Hardware-Hersteller
> anzuschnauzen.

Allen voran die Nvidia-Fuzzies.

von Norbert (Gast)


Lesenswert?

udok schrieb:
> Typisch Linux User.  Schuld sind immer die anderen...
> Warum machst du das "Hardware-Gelump" nicht selber?

Hast du getrunken, Bub?

von c-hater (Gast)


Lesenswert?

Lothar schrieb:

> Ein serial.c unter Linux ist doch nicht schwieriger als unter Windows.

Doch, natürlich. Unter Windows muss man sich eben nicht mit gleich vier 
verschiedenen Sätzen von von Funktionen und Strukturen zur 
Initialisierung der Schnittstelle herumschlagen.

Außerdem sind die Strukturen/Funktionen unter Windows sinnvoll nach 
Teilaspekten separariert.

Meiner Meinung nach ist das Hauptproblem der Linux-Lösung, die 
Eigenschaften der eigentliche Schnittstelle mit dem Terminal zu 
"verheiraten", welches sie benutzt. Das hat, verdammt nochmal, nur sehr 
eingeschränkt miteinander zu tun. Sprich: hier wurde beim 
Schichtenmodell der Kommunikation dramatisch geschlampt.

von udok (Gast)


Lesenswert?

Norbert schrieb:
> Hast du getrunken, Bub?

Hast du keine 100 Euro / Stunde? Oder einfach nu

Norbert schrieb:
>> Typisch Linux User.  Schuld sind immer die anderen...
>> Warum machst du das "Hardware-Gelump" nicht selber?
>
> Hast du getrunken, Bub?

Keine Argumente?
Keine Ahnung?
Keine 100 Euro?
Stänkert fremde Leuten an?
Muss ein Linux Jünger sein.

von Yalu X. (yalu) (Moderator)


Lesenswert?

linuxguru schrieb:
> Norbert schrieb:
>> Vielleicht wäre es ja mal eine gute Idee einige der Hardware-Hersteller
>> anzuschnauzen.
>
> Allen voran die Nvidia-Fuzzies.

Ist ja bereits geschehen:

  https://youtu.be/_36yNWw_07g

... leider nicht sehr erfolgreich ;-)

von Norbert (Gast)


Lesenswert?

udok schrieb:
> Norbert schrieb:
>>> Typisch Linux User.  Schuld sind immer die anderen...
>>> Warum machst du das "Hardware-Gelump" nicht selber?

Das schrieb ich ganz sicher nicht!

Du meine Güte Bub, du bist ja sogar zu dämlich korrekt zu zitieren.
Dieser Grad an geistiger Verwahrlosung muss echt Schlimm für dich sein.
Aber es besteht zumindest ein wenig Hoffnung für dich. Sobald du es 
schaffst von der Baumschule in eine Sonderschule versetzt zu werden, 
könntest du mit viel Arbeit etwas Boden gutmachen. Ein IQ mit zwei 
Ziffern ist selbst für dich erreichbar. Du schaffst das! Das Komma 
zwischen den Ziffern darfst du dann aber nicht beachten.

von Zeno (Gast)


Lesenswert?

Norbert schrieb:
> Die nämlich, welche es nicht für möglich erachten Treiber
> für ihr Hardware-Gelumpe zur Verfügung zu stellen.
Für 2% Desktopuser tagelang eine Entwicklungsabteilung beschäftigen? Was 
soll der Treiber am Ende kosten? Dazu kommt noch der allseits bekannte 
Wildwuchs im Linuxbereich, zich Distributionen komibiniert mit vielen 
Desktop(manager)varianten, dazu noch als Schmankel die diversen 
Kernelversionen. Da hat keiner mehr einen Überblick und es kann auch 
keiner einschätzen ob der (Binär)Treiber dann auch mit allen möglichen 
Kombinationen reibungsfrei zusammenarbeitet. Am Ende hängt da ja auch 
noch Support dran. Das tut sich freiwillig kein Hersteller an und da 
bleiben halt 2% einfach auf der Strecke und es wird der Mainstream 
bedient. Ist nicht nur in diesem Bereich so.
Ich habe selbst gerade das Theater mit einer NVidiakarte, die 
dummerweise den 304'er Treiber braucht. Der wird seit einiger Zeit von 
NVidia nicht mehr supportet. Mit Kernelversionen unter 5 läßt sich der 
Treiber problemlos installieren und funktioniert dann auch. Ich wollte 
ein relativ aktuelles Debian und habe mich für Debian11 (Kernel 5.10) 
entschieden. Dafür bekomme ich den Treiber ums Verrecken nicht 
installiert. Ich habe dann mal entnervt ein Mint mit Kernel 5.4 
installiert. Mit einer sehr guten Anleitung die ich mit viel Mühe im 
Netz gefunden habe, war der Treiber dann installierbar auch das war kein 
Spaziergang und hat ne Weile gedauert) und funktioniert auch.
So etwas tut sich kein Hardwarehersteller an. Man darf auch nicht 
erwarten das er den Quelltext zu seinem Treiber veröffentlicht, denn 
damit würde er am Ende sein Know How offen legen. Das tut man als 
Unternehmen normalerweise nicht.

von Zeno (Gast)


Lesenswert?

Yalu X. schrieb:
> Ist ja bereits geschehen:
>
>   https://youtu.be/_36yNWw_07g
So wie das der Herr Torvalds dort macht wird das bei NVidia auch 
niemanden hinterm Ofen hervor locken. Arroganz und Nase hoch ist eben 
nicht immer das beste Mittel der Wahl. Und deshalb kommt dann das raus 
was raus kommen mußte:
Yalu X. schrieb:
> ... leider nicht sehr erfolgreich ;-)

von Zeno (Gast)


Lesenswert?

Norbert schrieb:
> udok schrieb:
>> Norbert schrieb:
>>>> Typisch Linux User.  Schuld sind immer die anderen...
>>>> Warum machst du das "Hardware-Gelump" nicht selber?
>
> Das schrieb ich ganz sicher nicht!
Nö das hast Du nicht geschrieben, aber Du kannst offensichtlich selbst 
nicht zitieren. Du läßt einfach die Zeile weg die Du zu diesen 2 Zeilen 
verfasst hast. Wenn man das richtig macht dann sieht man nämlich 
ziemlich genau was Du geschrieben hast, sofern man in der Lage ist die > 
Zeichen vorm Zitat abzuzählen. Wenn diesen von Dir hier unterschlagenen 
Satz mit hinzunimmt
Norbert schrieb:
> Hast du getrunken, Bub?
dann dürfte schnell klar sein, wer hier die Defizite hat. Aber ist schon 
klar der Satz hat nicht ins Konzept gepasst, denn mit diesem Satz hätte 
man dann anschließend sicht so schön pöbeln können.

von Olaf (Gast)


Lesenswert?

> Es war mir ja fast klar, dass man bei Kritik mehr oder weniger sofort
> angepflaumt wird.

Das habe ich nicht getan. Ich habe nur die Moeglichkeit aufgezeigt
das du nicht zur Menge der Linuxuserbasis gehoeren koenntest.
Das ist einfach eine Eigenschaft sie ist weder boese noch schlecht.

> Und jetzt rate mal warum es nur (noch?) 2 % sind, die ueberhaupt
> mal ein Linux an ihren Rechner lassen.

Ich muss nichts raten. Es interessiert mich schlicht nicht.
Es ist in keiner Weise erstrebenswert viel oder wenig Prozent zu sein.
Ich hab keine Linuxaktien im Portfolio.

> Mein Eindruck von der Treiberentwicklung im Linuxumfeld ist
> ohnehin eher desastroes.

Da hab ich vermutlich eine weitere schlechte Nachricht fuer dich,
es gibt kaum so etwas wie eine Treiberentwicklung wie du sie dir
vorstellst. Einfach deshalb weil es Aufgabe eine Firma ist einen Treiber
zu entwickeln und ihre Angestellten dafuer zu bezahlen das in ihrer
Arbeitszeit zu machen. Treiber werden ueberwiegend von Leuten in ihrer
Freizeit und aus Spass programmiert. Du hast daran keine Ansprueche zu
stellen. Genau wie ich auch keine Ansprueche daran stellen wuerde
was du in deiner Freizeit machst. Nimm was da ist oder lass es.

Allerdings findet derzeit vermehrt ein Umdenken bei Firmen statt, 
dahingehend
das sie ploetzlich doch Mitarbeiter dafuer bezahlen. Erst letzte Woche
eine bemerkenswerter Sinneswandel bei Nokia.

> Selbst bei Kunden wird heute eher eine Windowslizenz gekauft,
> und eine Applikation darunter betrieben, als das ueberhaupt noch
> ernsthaft eine alternative Installation der auch fuer Linux
> verfuegbaren Applikation in Erwaegung gezogen wird.

Ich beobachte eigentlich eher das Gegenteil, das Firmen naemlich
verzweifelt Leute mit Linuxwissen suchen weil denen aufgefallen
ist das Linux mittlerweile in extrem vielen Geraeten drin steckt und man
Linuxkenntnisse im Portfolio der Mitarbeiter braucht.




> Tja, genau DAS ist die Linux-Sichtweise: Der Mensch als Zubehör zur
> Maschine. Nur die Menschen taugen, die zur Maschine passen.

Das ist in keinster Weise meine Sichtweise. Wirklich ganz und gar nicht.

Es stoert mich z.B an aktuellen Linuxdistribution das sich dessen 
Look&Feel immer mehr an Windows annaehert weil dessen Nutzer halt echte 
Betonkoepfe sind, die wenig neues lernen wollen und ich verwende immer 
mehr Zeit nach einer Installation das System an genau meine Beduerfnisse 
anzupassen.
Das ist aber noch sehr gut moeglich. Unter anderem weil ich den Source
des Systems habe und weil es weitestgehend gut dokumentiert ist. Das ist 
ein extremer Unterschied zur Windowswelt wo es friss oder stirb heisst.

> Da braucht man sich nicht drüber zu wundern, daß so etwas zu der
> Marktsituation führt, wie wir sie haben.

Es gibt keine Marktsituation von Linux. Es kostet nichts. Es gibt 
allenfalls eine Marktsituation von einzelnen Firmen die bestimmte 
Distributionen durchsetzen moechten.



> Du meine Güte Bub, du bist ja sogar zu dämlich korrekt zu zitieren.
> Dieser Grad an geistiger Verwahrlosung muss echt Schlimm für dich sein.

Du musst sowas ignorieren. Die meisten Windowsuser sind sicherlich nette 
Leute die man kennenlernen kann. Allerdings wegen dem einfachen Zugang 
zu Windows sind auch ein kleiner Teil unter ihnen, die mit der 
komplexeren Einstiegshuerde eines Unix nicht klarkommen. Die haben sich 
mit aeusserter Muehe Windowswissen angeeignet und merken jetzt (s.o.) 
einen gewissen Druck hin zu Linux und kommen damit nicht klar, das 
frustriert sie. Man muss sie einfach ignorieren und gut.

Und ja, keineswegs alles an Linux ist gut! Da halt jeder so wie er Bock 
hat zum System beitraegt oder auch nicht, fuehrt dies auch zu einer 
gewissen Diversifikation! Anarchie hat ihren Reiz, aber auch Nachteile. 
:-)

Olaf

von Christoph M. (mchris)


Lesenswert?

schmeissfliege schrieb
>Nur so falls es jemanden interessiert was meine aktuellen Vorstellungen
>sind:

>Ideal:
>* buttons und textfelder zur eingabe.
>* Ebenfalls auslesen des seriell ports in der GUI über ein Fenster.
>* Und ggfs. noch parsen  der Daten
>* Verbindungsaufbau auch über diese GUI damit ich ein rundes Programm
>hab xD

Das hatte ich schon erwähnt:

Beitrag "Re: Python <-> MC serial"

Textfelder und Slider drann zu hängen ist kein Problem.

von Norbert (Gast)


Lesenswert?

Olaf schrieb:
> Du musst sowas ignorieren. Die meisten Windowsuser sind sicherlich nette
> Leute die man kennenlernen kann.

100% Zustimmung.

> Allerdings wegen dem einfachen Zugang
> zu Windows sind auch ein kleiner Teil unter ihnen, die mit der
> komplexeren Einstiegshuerde eines Unix nicht klarkommen. Die haben sich
> mit aeusserter Muehe Windowswissen angeeignet und merken jetzt (s.o.)
> einen gewissen Druck hin zu Linux und kommen damit nicht klar, das
> frustriert sie. Man muss sie einfach ignorieren und gut.

Haha, da hast du sicher Recht. Aber der kleine Teil ist oftmals so 
fürchterlich laut wenn er auf seiner Erdscheibe sitzt und die Welt 
erklären will. Und dabei noch so einfach gestrickt das es schon fast ein 
wenig weh tut. ;-)

Beitrag #7066822 wurde von einem Moderator gelöscht.
von Yalu X. (yalu) (Moderator)


Lesenswert?

Zeno schrieb:
> Yalu X. schrieb:
>> Ist ja bereits geschehen:
>>
>>   https://youtu.be/_36yNWw_07g
> So wie das der Herr Torvalds dort macht wird das bei NVidia auch
> niemanden hinterm Ofen hervor locken.

Ich glaube, das war dem Herrn Torvalds durchaus bewusst :)

Nachdem Nvidia auf frühere, freundlicher formulierte Anfragen nicht
positiv reagiert hatte, war klar, dass die Firma keinerlei Interesse
daran hat, Open-Source-Treiber zu liefern oder auch nur technische
Unterstützung für deren Entwicklung durch die Linux-Community zu bieten.

Torvalds Fingergeste war dann nur noch dazu gedacht, das Problem
medienwirksam publik zu machen.

von Lothar (Gast)


Lesenswert?

c-hater schrieb:
>> Ein serial.c unter Linux ist doch nicht schwieriger als unter Windows.
>
> Doch, natürlich

HANDLE port = CreateFileA(device, GENERIC_READ | GENERIC_WRITE, 0, NULL, 
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
...
DCB state = {0};
...

vs.

int fd = open(device, O_RDWR | O_NOCTTY);
...
struct termios options;
...

von Ein T. (ein_typ)


Lesenswert?

Zeno schrieb:
> Norbert schrieb:
>> Die nämlich, welche es nicht für möglich erachten Treiber
>> für ihr Hardware-Gelumpe zur Verfügung zu stellen.
> Für 2% Desktopuser tagelang eine Entwicklungsabteilung beschäftigen? Was
> soll der Treiber am Ende kosten?

Mußt Du ja gar nicht. Es würde reichen, den Linux-Entwicklern die 
entsprechenden und selbstverständlich bereits vorhandenen Informationen 
zu übergeben. Dann machen die das alles selbst, kostet den 
Hardwarehersteller keinen Pfennig und seine Entwickler maximal fünf 
Minuten, um die entsprechenden Dokumente zusammenzustellen.

Irgendwo habe ich mal gelesen, daß es etwa 4,2 Milliarden Desktoprechner 
auf der Welt gäbe. Selbst wenn es nur die Hälfte wäre und von denen 
wiederum die Hälfte Grafikhardware dieses Herstellers benutzt, wären das 
immer noch 21 Millionen Einheiten dieser Grafikhardware. Selbst wenn der 
Hersteller nur einen Euro pro verkaufter Einheit erlösen würde, könnte 
man damit mehrere Entwickler bezahlen. Wohlgemerkt: diese Schätzung ist 
ausgesprochen konservativ und spiegelt die realen Verhältnisse 
zweifellos nicht einmal näherungsweise wider.

Was war nochmal die Frage?

von Karl (Gast)


Lesenswert?

Ein T. schrieb:
> Zeno schrieb:
>> Norbert schrieb:
>>> Die nämlich, welche es nicht für möglich erachten Treiber
>>> für ihr Hardware-Gelumpe zur Verfügung zu stellen.
>> Für 2% Desktopuser tagelang eine Entwicklungsabteilung beschäftigen? Was
>> soll der Treiber am Ende kosten?

Mal gemerkt, dass Google intensiv Werbung für Chromebooks macht? Schauen 
wir mal, wo Linux auf dem Desktop in 5 Jahren steht.

von Zeno (Gast)


Lesenswert?

Ein T. schrieb:
> Es würde reichen, den Linux-Entwicklern die
> entsprechenden und selbstverständlich bereits vorhandenen Informationen
> zu übergeben. Dann machen die das alles selbst, kostet den
> Hardwarehersteller keinen Pfennig und seine Entwickler maximal fünf
> Minuten, um die entsprechenden Dokumente zusammenzustellen.
Mit dieser Maßnahme veröffentlicht er sein Know How und macht dieses 
nicht nur der OSS-Community zugänglich, sondern auch dem Wettbewerb und 
das kann nicht sein Interesse sein. Und er macht das schon gar nicht um 
den Bedarf von knapp 2% (mehr Anteil hat Linux nun mal nicht im 
Desktopbereich) abzudecken, zumal von diesen 2% auch nur ein geringer 
Teil die spezielle Hardware nutzen werden. Am Ende geht es um einen 
Promillebedarf und das macht keiner, es lohnt sich einfach nicht.

Mal ein anderes Beispiel, auch wenn's Offtopic ist:
Wir regen uns auf das die Chinesen alles nachbauen, lassen aber im 
Gegenzug vieles in China fertigen, weil es ja so schön billig ist. Damit 
die das fertigen können, brauchen die auch entsprechende Unterlagen wie 
technische Zeichnungen, Verfahrenanweisungen etc. etc.. Genau damit 
haben wir schon Know How exportiert ohne es zu wollen. Der Chinese ist 
natürlich auch nicht blöd und weis dieses Angebot zu nutzen, spart er so 
doch jede Menge Entwicklungsarbeit.
Mit HW und SW ist es am Ende das Gleiche. Für die Position am Markt ist 
es eben eher nicht dienlich sein Wissen offen zu legen.

von Karl (Gast)


Lesenswert?

Zeno schrieb:
> Mit HW und SW ist es am Ende das Gleiche. Für die Position am Markt ist
> es eben eher nicht dienlich sein Wissen offen zu legen.

Komisch Google stellt fast alles als Open Source Version zur Verfügung 
bzw. bietet zu den Blackboxes gute Schnittstellen. Glaubst du MS hohlt 
mit seiner Strategie Google nochmal ein?

von db8fs (Gast)


Lesenswert?

> Lothar schrieb:
>
>> Ein serial.c unter Linux ist doch nicht schwieriger als unter Windows.
>
> Doch, natürlich. Unter Windows muss man sich eben nicht mit gleich vier
> verschiedenen Sätzen von von Funktionen und Strukturen zur
> Initialisierung der Schnittstelle herumschlagen.

Na so ganz als Referenz für einheitliche Lösungen nicht zu gebrauchen, 
glaub ich... man denke mal an Windows8 mit seinen 2 Systemsteuerungen ^^

> Außerdem sind die Strukturen/Funktionen unter Windows sinnvoll nach
> Teilaspekten separariert.

Beispiel Scanneransteuerung: Twain? WIA und COM+? .net? ^^

Windows ist ein guter Baukasten mit vielen Tools und APIs, teilweise 
sind da vermutlich bestimmt noch APIs aus den ersten Windows-Versionen 
mit drinne. Ist nix grundsätzlich schlechtes aus Sicht von 
Abwärtskompatibilität.

> Meiner Meinung nach ist das Hauptproblem der Linux-Lösung, die
> Eigenschaften der eigentliche Schnittstelle mit dem Terminal zu
> "verheiraten", welches sie benutzt. Das hat, verdammt nochmal, nur sehr
> eingeschränkt miteinander zu tun. Sprich: hier wurde beim
> Schichtenmodell der Kommunikation dramatisch geschlampt.

Nö, das nicht. Ne Trennung von GUI und Backend kann sinnvoll sein, weils 
helfen kann, überhaupt eine Layerung hinzukriegen. Dabei hilft Linux.

Wo ich glaub, das es schwächelt, ist die Kohärenz im Gesamten. Die 
Vielfalt von unterschiedlich GUI-Toolkits muss nix Schlechtes sein. Auf 
einem Uralt-Rechner (Pentium 2-4) würde man, wenn Linux oder BSD drauf 
genutzt werden sollte, doch vermutlich am ehesten sowas wie Fluxbox oder 
e16 installieren. Browser läuft wegen Webkit zwar dann vermutlich immer 
noch nicht gescheit, aber ne ganze Menge von hier ausrangierter 
Hardware, ist doch sehr wahrscheinlich die letzten 10-20 Jahren in 
anderen Ländern außerhalb Europas noch zum Einsatz gekommen.

Dafür kann Linux helfen, dass halt irgendwelche ältere Hardware auch 
noch lauffähig bleiben kann ohne auf vom Hersteller abgekündigte 
Betriebssysteme angewiesen zu sein. Sowas kann Linux/BSD leisten - 
abgesehen von der Rumdockerei, die ne sehr nützliche Sache sein kann.

Keine Ahnung ob ElementaryOS auf solchen alten Buden läuft (ist btw. 
auch GTK-basiert), ganz schlechts schauts von weiten nicht aus. ^^

von Zeno (Gast)


Lesenswert?

Karl schrieb:
> Mal gemerkt, dass Google intensiv Werbung für Chromebooks macht? Schauen
> wir mal, wo Linux auf dem Desktop in 5 Jahren steht.
Ich denke nicht das sich das so signifikant ändern wird. Linux dümpelt 
weltweit halt schon lang bei den 1,8% ziemlich konstant herum. In DE hat 
es mal im Januar einen Höhenflug, da lag der Anteil bei 4,2%. Seit dem 
geht es wieder bergab, im März waren es nur noch 2,5% Tendenz fallend.

Man hatte schon mal in den 90'zigern auf Linux gehofft. Da gab es nicht 
eine IT-Zeitschrift der irgendeine Linux-CD beilag. Ich meine Vobis hat 
damals sogar Rechner mit vorinstalliertem Linux verkauft. Es hat nix 
genutzt die überwiegende Mehrheit hat sich für Windows entschieden. Seit 
2009 geht geht zwar lt. Statistik der Windowsanteil stetig nach unten, 
was aber nicht Linux zu Gute kommt. Die die Windows den Rücken kehren, 
gehen zu Apple, denn deren Marktanteil steigt so stetig wie der von 
Windows fällt.

von Zeno (Gast)


Lesenswert?

Karl schrieb:
> Komisch Google stellt fast alles als Open Source Version zur Verfügung
> bzw. bietet zu den Blackboxes gute Schnittstellen. Glaubst du MS hohlt
> mit seiner Strategie Google nochmal ein?
Deren Hauptgeschäft ist eigentlich auch nicht Software. Bei 
Desktopsystemen erscheint Google noch nicht einmal in der Statistik.
Bei Smartphones hat Google mit Android die Nase vorn, was an der 
deutlich günstigeren Hardware liegen dürfte. Bei den Tablets ist 
weltweit iOS noch knapp vor Android. Allerdings fällt iOS und Android 
steigt.

von Ein T. (ein_typ)


Lesenswert?

Zeno schrieb:
> Karl schrieb:
>> Komisch Google stellt fast alles als Open Source Version zur Verfügung
>> bzw. bietet zu den Blackboxes gute Schnittstellen. Glaubst du MS hohlt
>> mit seiner Strategie Google nochmal ein?
>
> Deren Hauptgeschäft ist eigentlich auch nicht Software.

Das von NVidia auch nicht.

Schon lustig: erst argumentierst Du mit den Kosten bei überschaubarem 
Nutzeranteil. Dabei scheut NVidia diese Kosten offenbar gar nicht, 
schließlich bieten ja einen proprietären Linux-Treiber für diese wenigen 
Benutzer an.

NVidia hat aber offensichtlich keine Lust, ihre proprietären Treiber 
über einen gewissen Zeitraum hinaus zu pflegen. In diesem Fall reden wir 
von einer über zehn Jahre alten Grafikkarte, die aber bitteschön mit 
einem brandaktuellen System laufen sollen. Wieviel Promille von den 2% 
werden denn wohl noch dermaßen uralte Hardware haben, und gleichzeitig 
die allerneueste Software darauf nutzen wollen?

Zumal ein aktuelles Windows 10 oder 11 auf Deiner ollen Büchse schon 
aufgrund der Anforderungen von Windows selbst wohl gar nicht mehr 
installiert werden könnte. Anscheinend tut das der Verbreitung von 
Windows auf dem Desktop jedoch keinerlei Abbruch, was Deine 
Argumentation etwas absurd erscheinen läßt.

Auf mein anderes Argument, daß nämlich die besagten 2% trotzdem immer 
noch eine bedeutende Menge ist, mit der sich Geld verdienen läßt -- 
welches NVidia auch offensichtlich gerne mitnimmt --, antwortest Du mit 
Geschäftsgeheimnissen. Als ob die Wettbewerber diese Geheimnisse nicht 
ohnehin längst kennen würden, und als ob relevante Geschäftsgheimnisse 
nicht ohnehin mit Patenten geschützt wären.

Sei mir bitte nicht böse, aber ich habe gerade so ein bisschen den 
Eindruck, daß Du Dich ein bisschen... Pardon: kindisch aufführst. Wenn 
Deine Methusalem-Kiste nicht mit aktueller Software läuft, kannst Du die 
Hardware aktualisieren oder eben ältere Software benutzen. Ja, das geht, 
die Vielzahl an WinXP-Usern hier im Forum beweist es ja... You can't eat 
the cake and have it. ;-)

Daß der Nouveau-Treiber buggy sei, habe ich im Übrigen jetzt schon 
mehrmals gehört und gelesen, kann das aus meiner Erfahrung jedoch nicht 
bestätigen. Die Maschine, auf der ich diesen Treiber benutze, ist ein 
Dell E5580 mit NVidia Optimus, also durchaus keine ganz einfache 
Standard-Grafikhardware. Dennoch kann ich über den nouveau-Treiber nicht 
klagen, das funktioniert wunderbar und absolut stabil. (Ich schließe 
natürlich nicht aus, womöglich einfach Glück zu haben.)

von W.S. (Gast)


Lesenswert?

c-hater schrieb:
> Sprich: hier wurde beim
> Schichtenmodell der Kommunikation dramatisch geschlampt.

Genau das können wir hier jeden Tag beobachten. Unsereiner predigt den 
Leuten, die Dinge auseinander zu halten und saubere Schnittstellen 
zwischen den Schichten zu machen. Aber nein. Es wird immer wieder alles 
zu einer Art Eintopf verrührt und am Schluß heißt der Hilferuf immerzu 
nur "es geht nicht, helft mir".

Gerade das hier schonmal diskutierte Nichtauseinanderhalten von 
seriellem Kanal und Terminalprogramm bei Linux ist dann die Folge, wenn 
Leute bereits im Kleinen es nicht gelernt haben.

W.S.

von Karl (Gast)


Lesenswert?

Zeno schrieb:
> was an der
> deutlich günstigeren Hardware liegen dürfte.

Jo, MS ist am Hardwarepreis gescheitert. So muss es gewesen sein.

von W.S. (Gast)


Lesenswert?

Wegen des Anschnauzens oder dem Vorschlag dazu:
Yalu X. schrieb:
> ... leider nicht sehr erfolgreich ;-)

Nun ja, gibt es irgend ein Recht, vom Hersteller eines Produktes die 
Herausgabe seiner Interna zu verlangen, bloß weil man das Produkt zu 
einem anderen Zweck gebrauchen will, als der Hersteller es vorgesehen 
hat?

Dabei ist das eigentlich noch harmlos, denn in anderen Gefilden (z.B. 
USB) wäre eigentlich eine kostenpflichtige Mitgliedschaft in irgend 
einem obskuren Verein notwendig.

Die Alternative wäre, die besagten Treiber so zu verwenden, wie sie eben 
sind. Das hieße, zumindest "von unten" die höheren Schichten im OS 
passend zu machen, so daß sie zur Hardware und deren Treibern passen. 
Aber da höre ich bereits ein "Satan weiche!" schallen.

W.S.

von W.S. (Gast)


Lesenswert?

Olaf schrieb:
> Es stoert mich z.B an aktuellen Linuxdistribution das sich dessen
> Look&Feel immer mehr an Windows annaehert weil dessen Nutzer halt echte
> Betonkoepfe sind, die wenig neues lernen wollen...

Ach wo. Andere Leute machen etwas ganz anderes und wollen lediglich, daß 
ihre Werkzeuge (zu denen eben auch der PC gehört) funktionieren. Eben 
damit sie sich auf ihre eigene Profession konzentrieren können und sich 
nicht mit Hakeligkeiten der Werkzeuge befassen müsse. Wenn das aus 
deiner Sicht "halt echte Betonköpfe" sind, dann kommt mir der Witz vom 
Geisterfahrer in den Sinn (was, einer? nee hunderte!".

Aber das alles hat mit dem Anliegen des TO überhaupt nichts mehr zu tun. 
Er will eigentlich nur ein eigenes Terminalprogramm schreiben, wo er 
selbst noch Funktionalität für seine eigenen Bedürfnisse 
hineinprogrammieren kann.

W.S.

von Zeno (Gast)


Lesenswert?

Karl schrieb:
> Zeno schrieb:
>> was an der
>> deutlich günstigeren Hardware liegen dürfte.
>
> Jo, MS ist am Hardwarepreis gescheitert. So muss es gewesen sein.
Sag bist Du nicht im Stande richtig zu lesen?
Ich habe geschrieben:
Zeno schrieb:
> Bei Smartphones hat Google mit Android die Nase vorn, was an der
> deutlich günstigeren Hardware liegen dürfte.
Wo steht da bitte was von MS?

Ein T. schrieb:
> Zumal ein aktuelles Windows 10 oder 11 auf Deiner ollen Büchse
Och die olle Büchse erfüllt die Anforderungen an Win10 locker, ich 
könnte sogar die 64Bit Version installieren, habe ich aber aber nicht, 
für meine Zwecke reicht die 32Bit Version. Für 64Bit habe ich ja den 
Firmenlaptop.
Bei Win11 fallen sogar schon relativ neue PC durch, weil sie den 
Kompatibilitätstest der während der Installation gemacht wird nicht 
bestehen. Habe ich selbst erlebt mit einem PC der noch kein Jahr alt 
ist. Durch einen Eingriff in Registry, die schon während der 
Installation aktiv ist, ja ich wollt's auch nicht glauben, kann man 
diesen Test aber aushebeln.

Ein T. schrieb:
> kindisch aufführst.
Ja klar einer muß ja schuld sein. Wenn Linux nicht so tut wie gewünscht 
ist immer der User schuld. Ist halt so, typische Einstellung vieler 
Tuxer - also auch nichts Neues.

Ein T. schrieb:
> Als ob die Wettbewerber diese Geheimnisse nicht
> ohnehin längst kennen würden
Also bis zu den nouveau-Entwicklern scheinen die aber noch nicht 
vorgedrungen zu sein, denn dann müßte der Treiber perfekt funktionieren.

Ein T. schrieb:
> Daß der Nouveau-Treiber buggy sei, habe ich im Übrigen jetzt schon
> mehrmals gehört und gelesen, kann das aus meiner Erfahrung jedoch nicht
> bestätigen. Die Maschine, auf der ich diesen Treiber benutze, ist ein
> Dell E5580 mit NVidia Optimus
Dann hast Du mit dieser Karte offensichtlich Glück gehabt. Ich stehe ja 
mit den NVidia Problemen nicht alleine da. Desweiteren gibt es ja genug 
Enthusiasten, wo ich ausdrücklich den Hut ziehe, die auch für den alten 
Kram noch Patches zusammenbauen, damit die alten, von NVidia nicht mehr 
gepflegten Treiber auch mit neuem Kernel funktionieren. Es scheint da 
also durchaus Bedarf zu geben.

Ich habe es hinbekommen, kann jetzt mit dem System das erledigen wofür 
ich es installiert habe und damit ist das Thema Grafiktreiber für mich 
abgehakt.

@nano:
Es ist ne PCI-Karte könnte man also theoretisch tauschen. Aber nunmehr 
läuft es und damit ist es nun auch gut.

von Mehr GHz! (Gast)


Lesenswert?

> nicht zur Menge der Linuxuserbasis gehoeren koenntest

Ja, das waere mir auch egal. Ich habe mit UNIX™ bereits einige
Jahre vor dem Erscheinen des "experimentellen" Systems namens
Linux zu tun gehabt und in Teilzeit sowohl Systeme als auch
darauf befindliche Datenbanken administriert.
Linux war bei mir immer nur eine Facette innerhalb der
unixoiden Systeme.

Auf ein "Golden Linux Membership Award" kann ich also
gerne und dankend verzichten.

Meine ersten Begegnung war ein Kernel 0.96 und ein
dazu passendes Rootfilesystem. Damit konnte man kaum mehr
als die Faehigkeiten der Shell examinieren.
Wesentlich interessanter war dank guter Kontakte zur
oertlichen Universitaet z.B. ein Plan 9 von AT&T.
Wirklich praxistauglich wurde Linux erst mit den
Distributionsreleases SuSE5/6 und Redhat 7/8/9.
(Als Beispiel und nur so in etwa.)


Ganz bloed kann aber ich auch nicht sein, immerhin habe ich
fuer "meinen" IBM PC Server 320 (PCI/Microchannel) einen Treiber
fuer die PCI-Microchannelbridge geschrieben.
Ich habe mir aber die Unbill erspart, diesen Treiber oeffentlich
zu machen.

Den Server habe ich aus nostalgischen Gruenden immer noch.
Es war meine erste (SMP-)Maschine mit der besonderen
"Fluppdizitaet" die aus der zweiten CPU resultiert.

> das Firmen naemlich verzweifelt Leute mit Linuxwissen suchen
Die sie dann aber nicht ordentlich bezahlen koennen.
Sonst haetten sie ja genug.

Seitdem Heinis wie der Poettering am Linux herummurksen
habe ich allerdings zunehmend das Gefuehl:
"Das ist nicht mehr meins."

Bei einem System das nur noch einstellige Verbreitung findet, ist mit:
> Treiber werden ueberwiegend von Leuten in ihrer
> Freizeit und aus Spass programmiert.
eben auch nicht mehr zu rechnen.

von Karl (Gast)


Lesenswert?

Zeno schrieb:
> Karl schrieb:
>> Zeno schrieb:
>>> was an der
>>> deutlich günstigeren Hardware liegen dürfte.
>>
>> Jo, MS ist am Hardwarepreis gescheitert. So muss es gewesen sein.
> Sag bist Du nicht im Stande richtig zu lesen?
> Ich habe geschrieben:
> Zeno schrieb:
>> Bei Smartphones hat Google mit Android die Nase vorn, was an der
>> deutlich günstigeren Hardware liegen dürfte.
> Wo steht da bitte was von MS?

Du behauptest Google kan keine Software und es überzeugt der Preis. Wo 
war jetzt bei MS das Problem, die ja herforagend Software können und 
auch billige Hardware hatten. Einmal etwas weiter denken.

von Zeno (Gast)


Lesenswert?

Karl schrieb:
> Du behauptest Google kan keine Software
Du kannst immer noch nicht lesen und unterstellst mir hier Sachen die 
ich so nicht gesagt habe. Ich sagte:
Zeno schrieb:
> Deren Hauptgeschäft ist eigentlich auch nicht Software.
Das viele ein Smartphone mit Android wählen hat schon in erster Linie 
preisliche Gründe. Man bekommt für gut 200€ schon ein technisch 
einwandfreies Gerät was die wesentlichen Funktionen die ein Smartphon 
können sollte beherrscht. Das billigste Applegerät kostet mehr als das 
Doppelte. Das ist für viele schon ein wesentliches Argument. Hochwertige 
Geräte z.B von Samsung sind mittlerweile vom iPhone gar nicht mehr so 
weit entfernt, so das es doch einige gibt die sich für Apple 
entscheiden. Ich kenne deutlich mehr Leute die irgendwann zu Apple 
gewechselt haben als umgekehrt - muß ja einen Grund haben.
Für ne Smarthomegeschichte habe ich mir ein Tablet von Lenovo zu gelegt, 
weil mir das iPad für diesen Zweck zu teuer war. Das Lenovo ist von der 
Hardware her nicht schlecht und funktioniert schon ordentlich. Da meine 
Gattin ein iPad besitzt habe ich den direkten Vergleich und da muß ich 
sagen das da Apple schon die Nase vorn hat. Ich will aber nicht meckern, 
ich brauche für meinen Zweck nur den Browser und der tut das was er 
soll. Der Rest geht mir da am Allerwertesten vorbei.

Karl schrieb:
> Wo
> war jetzt bei MS das Problem, die ja herforagend Software können und
> auch billige Hardware hatten.
Ja klar es steht außer Frage, Software können die Jungs hervorragend, 
das beweisen sie ja schon seit gut 3 Jahrzehnten, wenn mal von ME, Vista 
und Win8 absieht, die sich nie wirklich durchsetzen konnten. Und dann 
gabs da noch einen Totalausfall und das waren seinerzeit die Win Phones. 
Ich hatte so ein Teil von Nokia als Firmenhandy und das Ding war eine 
einzige Katastrophe. Das Teil hat mehrfach am Tag selbständig gebootet. 
Wenn man das nicht gleich mitbekommen hat, war man halt für längere Zeit 
nicht erreichbar - gab dann meist Mecker vom Chef. Da wurden dann 
Updates ohne Ende durchgeführt, hat aber nix gebracht. Die Akkulaufzeit 
war einfach nur unterirdisch, das Ding mußte laufend geladen werden. 
Dazu ständige Verbindungsabbrüche. Diese komischen Kacheln waren auch 
sehr gewöhnungsbedürftig aber von allen noch das kleinste Übel. Das 
Beste an dem Teil war die Kamera, die war wirklich Spitze  - hatte ja 
auch Optik von Zeiss. Nach 2 Jahren hat dann auch die Geschäftsleitung 
mit bekommen das die Dinger nichts taugen und dann wurde auf Apple 
umgestellt.
Mit den Dingern hat sich MS auf dem Smartphonemarkt selbst ins Aus 
katapultiert und Nokia ham'se gleich mit genommen. Eigentlich schade, 
denn Nokia hat keine schlechte Hardware gebaut, aber sie haben halt den 
Aufsprung auf den Smartphonezug verpasst. Als sie es gemerkt haben und 
dann noch auf Windows gesetzt haben ist der Zug endgültig abgefahren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.