Es gibt ja Firmen die an Linux parasitieren ohne etwas, z. B. Code, beizutragen. Beispielsweise Microsoft mit Trivial-Patenten ( http://www.heise.de/ct/meldung/Microsoft-verklagt-TomTom-wegen-Patentverletzung-200928.html ). Deshalb, und auch weil ich nicht möchte das unbeteiligte Dritte an meiner Arbeit (u. a. Kernel modifizieren, patchen, kompilieren, installieren, ...) parasitieren, möchte ich das im Vorfeld verhindern, also bevor Recher mit Linux die Firma verlassen. Gibt es dazu Anleitungen oder genügt es bei der Kernel-Konfiguration alles unter # DOS/FAT/NT Filesystems auf disable zu setzen?
Gast
#4234126
Rolf F. schrieb: > Deshalb, und auch weil ich nicht möchte das unbeteiligte Dritte an > meiner Arbeit (u. a. Kernel modifizieren, patchen, kompilieren, > installieren, ...) parasitieren, möchte ich das im Vorfeld verhindern, > also bevor Recher mit Linux die Firma verlassen. Wenn du am kernel rumpatchst und das dann weitergibst, bist du an die Regeln der GPL gebunden, mußt also die Sourcen rausrücken, spätestens wenn einer deiner Kunden sie haben will.
Gast
#4234135
Rolf F. schrieb: > Es gibt ja Firmen die an Linux parasitieren ohne etwas, z. B. Code, > beizutragen. Beispielsweise Microsoft mit Trivial-Patenten ( > http://www.heise.de/ct/meldung/Microsoft-verklagt-TomTom-wegen-Patentverletzung-200928.html > ). http://www.heise.de/open/meldung/Microsoft-traegt-viele-Aenderungen-zum-Linux-Kernel-3-0-bei-1280500.html der Kernel ist wohl das kleinste Problem, du müsste jede lib prüfen ob sie nicht irgendwelche Patente verletzt. Teilweise ist es wirklich billiger, MS ein paar € für das embedded System zu geben und dann ist man sicher vor patentklagen. http://www.heise.de/newsticker/meldung/Microsoft-stellt-Handheld-und-Embedded-Partner-von-Patentklagen-frei-173686.html
Gast
#4234197
Wenn MS nur mal das Reboot-freie Austauschen von Dateien von Oinux abschauen würde, dann würde ich mich auf Arbeit nicht ständig über Restart wegen Updates von Popelprogrammen wärmend diese laufen ärgern. Und Linux kann inzwischen für alle "Kernel Patchen" im laufenden Betrieb. und ja, ich kenne beide Systeme gut genug, um zu verstehen warum das so ist.
Gast
#4234231
Das Problem dabei: du musst deine Rechte auch vor Gericht gegen die Parasiten durchsetzen. Dazu musst du einiges an Kosten für Anwälte und Gutachter vor strecken. Die Busybox Entwickler konnten das nur mit Hilfe des Software Freedom Law Centers.
Gast
#4234382
Bastler schrieb: > Wenn MS nur mal das Reboot-freie Austauschen von Dateien von Oinux > abschauen würde, dann würde ich mich auf Arbeit nicht ständig über > Restart wegen Updates von Popelprogrammen wärmend diese laufen ärgern. > Und Linux kann inzwischen für alle "Kernel Patchen" im laufenden > Betrieb. und ja, ich kenne beide Systeme gut genug, um zu verstehen > warum das so ist. seit systemd eingeführt wurden ist, muss man auch deswegen neu booten. Und nur weil Linux keine Pflicht zum Neustart bringt, würde ich mich nicht darauf verlassen das wenn z.b. glibc geupdatet wird das auch wirklich alles Prozesses neu gestartet sind.
Peter II schrieb: > Teilweise ist es wirklich billiger, MS ein paar € für das embedded > System zu geben und dann ist man sicher vor patentklagen. > > http://www.heise.de/newsticker/meldung/Microsoft-s... Das betrifft nur Mikrosoft-Software, hier aber geht es nur um Linux, also ganz was anderes, denn bisher gibt es kein Microsoft-Linux ( http://www.mslinux.org/ ).
Peter II schrieb: > der Kernel ist wohl das kleinste Problem, du müsste jede lib prüfen ob > sie nicht irgendwelche Patente verletzt. Nein, denn erstens gibt es die Unschuldsvermutung und zweitens ist gerade die Benutzung von Bibliotheken unproblematisch, da damit rechtlich keine Bindung entsteht; von einer Lib färbt nichts auf die eigene Software ab.
Gast
#4234444
Erwin M. schrieb: >> der Kernel ist wohl das kleinste Problem, du müsste jede lib prüfen ob >> sie nicht irgendwelche Patente verletzt. > > Nein, denn erstens gibt es die Unschuldsvermutung und zweitens ist > gerade die Benutzung von Bibliotheken unproblematisch, da damit > rechtlich keine Bindung entsteht; von einer Lib färbt nichts auf die > eigene Software ab. sobald man z.b. die libav ausliefert (und nutzt), hat man schon Probleme weil sie h264 encodieren kann. Da sind Lizenzgebühren fällig.
Peter II schrieb: > > sobald man z.b. die libav ausliefert (und nutzt), hat man schon Probleme > weil sie h264 encodieren kann. Da sind Lizenzgebühren fällig. Nein, nur bei einer Nutzung passiert das und da ein Messrechner oder Steuerrechner sowas wie h264 nicht nutzt, wird nichts fällig. Außerdem gibt es auch freie h264-Kodierer, z. B. x264: https://de.wikipedia.org/wiki/H.264 .
Peter II schrieb: > weil sie h264 encodieren kann. Da sind Lizenzgebühren fällig. Nicht in Europa, da gibts keine Softwarepatente.
Erwin M. schrieb: > Außerdem gibt es auch freie h264-Kodierer, z. B. x264: Wenn man sein Programm nicht unter GPL stellen will, muß man eine Lizenz kaufen: http://x264licensing.com/
Rolf M. schrieb: > Wenn man sein Programm nicht unter GPL stellen will, muß man eine Lizenz > kaufen Das ist ja bei jeder GPL-Library der Fall (entweder man kann eine andere Lizenz kaufen oder falls das nicht angeboten wird muss man sich eben an die GPL halten), das hat aber eher was mit dem Urheberrecht zu tun als mit Patenten.
Gast
#4235061
Rolf F. schrieb: > parasitieren, möchte ich das im Vorfeld verhindern, > also bevor Recher mit Linux die Firma verlassen. Bist du sicher, dass dich deine Firma DAFÜR bezahlt? Georg
Gast
#4235131
Peter II schrieb: > seit systemd eingeführt wurden ist, muss man auch deswegen neu booten. Wäre mir neu. Quelle?
Gast
#4235137
> Und nur weil Linux keine Pflicht zum Neustart bringt, würde ich mich
nicht darauf verlassen das wenn z.b. glibc geupdatet wird das auch
wirklich alles Prozesses neu gestartet sind.
Davon spreche ich nicht, sondern von dem Zwangs-Restart weil irgend ein
Mini-Tool gerade lief, wärend im Hintergrund ein Update darauf läuft.
Der Update legt brav die gerade in Benutzung befindlichen Dateien bei
"schieb's beim nächsten Restart an die richtige Stelle" ab. Und dann
laufen andere Updates offenbar erst wieder, wenn dieser Auftrag erledigt
ist. An manchen Tagen mach ich morgens erst ein paar Restart-Orgien, was
dann wegen Festplattenverschlüsselung auch nicht unbeaufsichtigt geht.
Dann lieber irgendwann mal selbst entscheiden, daß ich jetzt gern die
neuere Datei nutzen würde.
Gast
#4235191
Incognito schrieb: > Peter II schrieb: >> seit systemd eingeführt wurden ist, muss man auch deswegen neu booten. > > Wäre mir neu. Quelle? wie willst du denn Systemd neu starten? DAs ist der erste Prozess er läuft und diese kann nicht einfach beendet werden.
Gast
#4235197
Erwin M. schrieb: >> >> sobald man z.b. die libav ausliefert (und nutzt), hat man schon Probleme >> weil sie h264 encodieren kann. Da sind Lizenzgebühren fällig. > > Nein, nur bei einer Nutzung passiert das und da ein Messrechner oder > Steuerrechner sowas wie h264 nicht nutzt, wird nichts fällig. > Außerdem gibt es auch freie h264-Kodierer, z. B. x264: > https://de.wikipedia.org/wiki/H.264 . es spielt keine rolle ob der Kodierer frei ist oder nicht. Für das Format fallen Lizenzgebühren an, egal von wem er erzeugt wird. Ist doch wie oben das VFAT Beispiel, der code ist nicht das Problem die Nutzung von VFAT ist kostenpflichtig.
Peter II schrieb: > Incognito schrieb: >> Peter II schrieb: >>> seit systemd eingeführt wurden ist, muss man auch deswegen neu booten. >> >> Wäre mir neu. Quelle? > > wie willst du denn Systemd neu starten? DAs ist der erste Prozess er > läuft und diese kann nicht einfach beendet werden. Der erste Prozess ist /sbin/init mit pid 1, sofern das nicht geändert wurde.
Gast
#4235635
Rolf F. schrieb: > Beispielsweise Microsoft mit Trivial-Patenten Microsoft trägt sehr wohl zu Linux bei, zB die HyperV Treiber. Es gibt sogar offizielle Anleitungen von MS über zB Dual Boot mit Windows. FAT deaktivieren- super Idee, freu dich auf ein System das praktisch keine USB Sticks, SD Karten, UEFI Bootloader , alte Android Handies und Kameras usw. verwenden kann... FAT ist so omnipräsent und wird von so vielen Firmen verwendet, ohne kommt man kaum aus und MS würde kaum jemanden deswegen verklagen...
Gast
#4235682
Programmierer schrieb: > FAT ist so omnipräsent und wird von so > vielen Firmen verwendet, ohne kommt man kaum aus und MS würde kaum > jemanden deswegen verklagen... Gerüchten zufolge hat MS an jedem verkauften Android-Telefon mehr Geld durch Lizenzeinnamen kassiert als sie pro Windows-Phone Gerät an Verlust produzierten... Und ja, MS hat Firmen wegen dem FAT-Patent (Lange Dateinamen) verklagt, in DE bis zum BGH, und Recht bekommen. Opfer war z.B. TomTom. Soviel zu Bernd K. schrieb: > Nicht in Europa, da gibts keine Softwarepatente.
Gast
#4235683
Rolf F. schrieb: > Gibt es dazu Anleitungen ... An wessen Arbeiten möchtest du genau parasitieren?
Gast
#4235689
Außerdem: wieso parasitiert Microsoft an Linux, wenn Microsoft Lizenzgebühren für die Nutzung von Microsoft-Erfindungen (vfat) in Linux verlangt? Ist nicht eher Linux der Parasit, der ungefragt Technologien klaut?
Daniel A. schrieb: >> wie willst du denn Systemd neu starten? DAs ist der erste Prozess er >> läuft und diese kann nicht einfach beendet werden. > > Der erste Prozess ist /sbin/init mit pid 1, sofern das nicht geändert > wurde. Gut erkannt, und genau das ist systemd. Siehe https://de.wikipedia.org/wiki/Systemd
Gast
#4235753
Peter II schrieb: > Incognito schrieb: >> Peter II schrieb: >>> seit systemd eingeführt wurden ist, muss man auch deswegen neu booten. >> >> Wäre mir neu. Quelle? > > wie willst du denn Systemd neu starten? DAs ist der erste Prozess er > läuft und diese kann nicht einfach beendet werden. http://www.heise.de/ct/hotline/Linux-systemd-Neustart-ohne-Reboot-2198615.html Sollte das nicht reichen? Abgesehen davon musste man früher auch schon rebooten, um z.B. eine neue Kernel-Version zu nutzen. Und das ist heute auch nicht viel anders.
Programmierer schrieb: > Ist nicht eher Linux der Parasit, der ungefragt Technologien > klaut? Schonmal gefragt warum auch unter Windows Befehle wie mkdir funktionieren? Richtig: Weil das erste von M$ vertriebene OS praktisch nur "geklaut" war, und diese Zöpfe bis heute drin stecken. Windows hat ein Unix-Subsystem https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
1 | |
Wer also wo bei wem wann was geklaut hat, darüber kann man vortrefflich streiten. Bringt aber die ganze Diskusion nicht weiter.
Programmierer schrieb: > Außerdem: wieso parasitiert Microsoft an Linux, wenn Microsoft > Lizenzgebühren für die Nutzung von Microsoft-Erfindungen (vfat) in Linux > verlangt? Ganz einfach: Es geht dabei um Techniken, die es schon vorher gab, nicht von Microsoft. Die Patente wurden nur erteilt weil Anträge in USA zu 95 % durchgewunken werden und bei den letzten 5 % nur minimalste Anforderungen gelten, wobei die Prüfer meist wenig Ahnung vom Thema haben. Und wenn man sich deswegen beschwert wird da nicht das Patentamt da aktiv sondern man bekommt nur Hinweise wie man (kostenpflichtig und teuer) was machen könnte; das musste ich selbst erleben. Die wollen offenbar nicht das ihr eigner Mist offenbar wird. Jedenfalls nehme ich # DOS/FAT/NT Filesystems raus und bewerbe das als zusätzliche Sicherheit, als "gehärtetes Linux", was ja sogar doppelt stimmt, da sowohl Angreifer kein FAT/NTFS einsetzen können und auch Schutzgeldforderungen vorgebeugt ist. Und wer an dem Rechner sowas wie Sticks und MS-Windows verwenden will, kann ja einen der diversen ext-Treiber für Windows verwenden und ext2/3/4 einsetzen.
Rolf F. schrieb: > Jedenfalls nehme ich > # DOS/FAT/NT Filesystems > > raus und bewerbe das als zusätzliche Sicherheit, als "gehärtetes Linux" Das ist für Privatanwender nur völlig nutzlos, sofern sie damit ihre Mobilgeräte nutzen wollen. SD-Karten sind mit FAT, SDHC-Karten mit FAT32 und SDXC-Karten mit exFAT formatiert, das schreibt die Spezifikation so vor, und daran halten sich mp3-Player, eBook-Reader, Digitalkameras, Videokameras etc. Mit einem solchermaßen "gehärteten" Linux kann man nichts von alledem nutzen.
Gast
#4236836
Soweit ich weiß, betrifft zumindest bei FAT32 Microsoft's Patent nur die gleichzeitige Nutzung langer und kurzer Dateinamen. Wer sich für eine Variante entscheidet, verletzt das Patent demzufolge nicht. Allerdings kann ich nicht sagen, wie das bei exFAT aussieht.
Sebastian schrieb: > Soweit ich weiß, betrifft zumindest bei FAT32 Microsoft's Patent Wurde das europäische MS-FAT-Patent nicht bereits vor einiger Zeit richterlich für komplett nichtig erklärt? Ich meine da mal sowas gelesen zu haben, oder ist das nicht mehr der aktuelle Stand?
Kaj G. schrieb: > Windows hat ein Unix-Subsystem > https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem >
1 | |
2 | |
3 | |
Das ist ja nur Shell. Interessant wäre wenn man auch Posix-kompatible Programme dafür Kompilieren und darunter laufen lassen könnte. Funktioniert das, also beispielsweise Posix Threads verwenden, serielle Schnittstellen ansprechen wie im "Serial Programming Howto" beschrieben und wie sieht es da mit Echtzeit aus (maximale Latenzzeiten unter Last)?
Rolf F. schrieb: > Interessant wäre wenn man auch Posix-kompatible > Programme dafür Kompilieren und darunter laufen lassen könnte. Aus dem ersten Link den ich gepostet habe: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
1 | |
2 | |
3 | |
4 | |
So wie es aussieht ist die letzte Version aber die Version 3.5 von 2004
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Damit sollte auch die Frage nach POSIX Threads beantwortet sein :)
1 | |
2 | |
Naja, GCC 3.3... Compilieren koennte vielleicht ein kleiner Krampf werden. Also ja, Prinzipiel sollte Compilieren gehen, POSIX Threads sollte es geben, wie es mit der seriellen Schnittstelle aussieht, das weiss nur M$
Kaj G. schrieb: > So wie es aussieht ist die letzte Version aber die Version 3.5 von 2004 Damit ist es quasi gestorben. Eine Alternative ist Cygwin, aber ohne serielle Schnittstellen. Daher bleibe ich bei Linux, auch wegen dem Preept_RT-Patch, da es sowas nicht für MS-Windows gibt.
Gast
#4238283
Rolf F. schrieb: > Daher bleibe ich bei Linux, auch wegen dem Preept_RT-Patch, da es sowas > nicht für MS-Windows gibt. realtime gibt es auch für Windows. Und bei threads sich an Posix zu klammern halte ich auch nicht für sinnvoll. MS bietet da viele Funktionen die es in POSIX nicht gibt und umständlich nachgebildet werde müssen. z.b. auf das ende mehre Threads warten (WaitForMultipleObjects mit dem ThreadHandle).
Rolf F. schrieb: > Daher bleibe ich bei Linux, auch wegen dem Preept_RT-Patch, da es sowas > nicht für MS-Windows gibt. Es gibt einen Hersteller fuer Steuerungstechnik (ich glaube Beckmann?) die auch Windows in ihren Systemen einsetzt. Es gibt Digital-Oszilloskope auf denen Windows laeuft... Windows gibt es sehr wohl mit harter Echtzeitfaehigkeit, aber natuerlich nicht im Laden um die Ecke...
Kaj G. schrieb: > Beckmann Beckhoff
Peter II schrieb: > Und bei threads sich an Posix zu klammern halte ich auch nicht für > sinnvoll. MS bietet da viele Funktionen die es in POSIX nicht gibt und > umständlich nachgebildet werde müssen. > > z.b. auf das ende mehre Threads warten (WaitForMultipleObjects mit dem > ThreadHandle). Dazu braucht man doch nur in die Prozesstabelle sehen; da steht doch welcher Thread läuft und welcher nicht. Ein anderer und noch einfacherer Weg ist mit dem Pseudo-Signal 0 zu testen. Also Posix-Threads können viel und sie sind portabel sowie standardisiert. Daher bleibe ich dabei.
Gast
#4238358
Rolf F. schrieb: > Dazu braucht man doch nur in die Prozesstabelle sehen; da steht doch > welcher Thread läuft und welcher nicht. > Ein anderer und noch einfacherer Weg ist mit dem Pseudo-Signal 0 zu > testen. sag ich ja, alles fingerbrech. > Also Posix-Threads können viel und sie sind portabel sowie > standardisiert. Daher bleibe ich dabei. ist ja dein gutes Recht, wenn portabel aber keine rolle spielt nehme ich lieber die Windows Threads und bin damit schneller fertig. Der letzte Posix Standard ist scheinbar schon wieder 6Jahre her und das im schnelllebigen Computerzeitalter. Das ist wie Programmieren mit Hammer und Meisel.
Kaj G. schrieb: > Windows gibt es sehr wohl mit harter Echtzeitfaehigkeit, aber natuerlich > nicht im Laden um die Ecke... Im Prinzip schon, nur ist das nicht mit einem Realtime-Linux zu vergleichen, denn a) hat man nicht die OS-Sourcen; sowas wie die minimale MTU im Kernel kurz zu ändern, Kernel Kompilieren +Installieren sowie auch vieles andere geht da nicht, b) sind die Echtszeit-Zusätze teuer und nicht so performant wie der Preempt-RT-Patch. Hinzu kommmen weitere Unterschiede wie kostenpflichtige Lizenz für das OS (bei MS-Win, nicht bei Linux) und Updates (auf nächste Kernel-Version bzw. MS-Win-Version) sowie Stabilität und Resourcenverbrauch.
Peter II schrieb: > Rolf F. schrieb: >> Dazu braucht man doch nur in die Prozesstabelle sehen; da steht doch >> welcher Thread läuft und welcher nicht. >> Ein anderer und noch einfacherer Weg ist mit dem Pseudo-Signal 0 zu >> testen. > > sag ich ja, alles fingerbrech. Nö, das ist einfach, performant, wenig Code und außerdem passiert im Hintergrung unter MS-Win sicherlich nichts besseres. > Der letzte Posix Standard ist scheinbar schon wieder 6Jahre her und das > im schnelllebigen Computerzeitalter. Das ist wie Programmieren mit > Hammer und Meisel. Die gibt es ja seit den 80ern, so das die ausgereift sind und nicht ständig nachgebessert werden muss.
Gast
#4238371
Rolf F. schrieb: > Im Prinzip schon, nur ist das nicht mit einem Realtime-Linux zu > vergleichen, denn a) hat man nicht die OS-Sourcen; sowas wie die > minimale MTU im Kernel kurz zu ändern, Kernel Kompilieren +Installieren für embedded System gibt es die sourcen (auch wenn nicht für jeden) Warum musst der Kernel überhaupt nicht kompiliert werden, nur um einen Wert zu ändern - eventuell kann das MS ja sogar zur Laufzeit? > sowie auch vieles andere geht da nicht, was geht nicht? > b) sind die Echtszeit-Zusätze > teuer und nicht so performant wie der Preempt-RT-Patch. teuer dafür mit Support. Bei kann man nur hoffen das es geht. > Hinzu kommmen > weitere Unterschiede wie kostenpflichtige Lizenz für das OS (bei MS-Win, > nicht bei Linux) und Updates (auf nächste Kernel-Version bzw. > MS-Win-Version) sowie Stabilität und Resourcenverbrauch. wo ist Windows nicht Stabil? Und das es mehr Recourcen braucht kannst du uns bestimmt auch anhand von ein paar links belegen oder? Verdienst du mit deiner Software Geld? Wenn ja, warum gönnst du dann anderen Leute (MS) nicht das sie auch Geld mit ihrer Software verdienen wollen.
Gast
#4238375
Rolf F. schrieb: > Peter II schrieb: >> Rolf F. schrieb: >>> Dazu braucht man doch nur in die Prozesstabelle sehen; da steht doch >>> welcher Thread läuft und welcher nicht. >>> Ein anderer und noch einfacherer Weg ist mit dem Pseudo-Signal 0 zu >>> testen. >> >> sag ich ja, alles fingerbrech. > > Nö, das ist einfach, performant, wenig Code und außerdem passiert im > Hintergrung unter MS-Win sicherlich nichts besseres. warum sollte sie es gleich machen? Warum stehen überhaupt Thread in der Prozesstabelle - das ist doch nur wieder eine Altlast von Linux die Thread erst später eingeführt haben und vorher alles versucht als Prozesse abzubilden.
Dominik S. schrieb: > Kaj G. schrieb: >> Beckmann > > Beckhoff Ah danke :) Ich war dicht dran ^^
Peter II schrieb: > die es in POSIX nicht gibt und > umständlich nachgebildet werde müssen. > > z.b. auf das ende mehre Threads warten Das halte ich für ein Gerücht.
Gast
#4238461
Bernd K. schrieb: > Peter II schrieb: >> die es in POSIX nicht gibt und >> umständlich nachgebildet werde müssen. >> >> z.b. auf das ende mehre Threads warten > > Das halte ich für ein Gerücht. hast du einen Vorschlag, wie man auf ein ende von mehre Threads warten kann? Unter Windows ist fast alles ein Handle, diese kann man dann beliebig in Funktionen wie WaitForMultipleObjects verwenden. So etwas ist mir für Linux nicht bekannt. Für files und sockets nimmt man select oder poll, bei threads muss man mit join arbeiten. Mutexe muss man wieder anders abfragen.
Peter II schrieb: > hast du einen Vorschlag, wie man auf ein ende von mehre Threads warten > kann? Ich würde in folgende Richtung anfangen zu suchen: http://www.linuxquestions.org/questions/programming-9/how-to-implement-waitformultipleobjects-in-linux-908553/ Was die Thread-Handles in Windows angeht, dann hilft ein Blick in die Quellen der Reimplementierung von Windows (ReactOS) um abzuschätzen was da ablaufen muss um von beliebigen Handles auf etwas zu kommen worauf man warten kann, das sieht mir alles andere als einfach und unkompliziert aus unter der Haube: http://doxygen.reactos.org/d1/d0d/synch_8c_source.html#l00151 http://doxygen.reactos.org/da/d75/obwait_8c_source.html#l00046 Andererseits kann man aber wahrscheinlich den pragmatischen Ansatz mit den Semaphoren auch problemlos auf Windows umsetzen, also würd ich eher das als Basis nehmen (wenn die Anwendung multiplatform sein soll).
Peter II schrieb: > Rolf F. schrieb: >> Daher bleibe ich bei Linux, auch wegen dem Preept_RT-Patch, da es sowas >> nicht für MS-Windows gibt. > > realtime gibt es auch für Windows. Bei Linux lade ich mir einfach z.B. Debian runter, installiere das und mache dann noch ein apt-get install linux-image-rt. Dann konfiguriere ich mir noch eine realtime-Gruppe und packe da alle User rein, die Realtime-Threads erstellen und deren Speicher gegen Auslagerung sperren können sollen, und fertig. Peter II schrieb: > Der letzte Posix Standard ist scheinbar schon wieder 6Jahre her und das > im schnelllebigen Computerzeitalter. Das ist wie Programmieren mit > Hammer und Meisel. Was hat sich denn in den letzten 6 Jahren beim Multithreading so bahnbrechendes getan, daß man eine neue Version der Threading-API bräuchte? Peter II schrieb: >> b) sind die Echtszeit-Zusätze >> teuer und nicht so performant wie der Preempt-RT-Patch. > teuer dafür mit Support. > > Bei kann man nur hoffen das es geht. Da gibt's auch Firmen, die Support leisten. Wenn ich der Meinung bin, ohne auszukommen, kostet's mich allerdings gar nix. Peter II schrieb: > Warum stehen überhaupt Thread in der Prozesstabelle Finde ich sehr praktisch. Vor allem kann man auch jedem Thread einen eigenen Namen geben, so daß man schön sehen kann, wie sich die Threads von mehreren Prozessen auf die einzelnen Cores verteilen. > das ist doch nur wieder eine Altlast von Linux die Thread erst später > eingeführt haben und vorher alles versucht als Prozesse abzubilden. Mag sein, aber was ist das Problem? Bernd K. schrieb: > Peter II schrieb: >> hast du einen Vorschlag, wie man auf ein ende von mehre Threads warten >> kann? > > Ich würde in folgende Richtung anfangen zu suchen: > http://www.linuxquestions.org/questions/programming-9/how-to-implement-waitformultipleobjects-in-linux-908553/ So ähnlich hätte ich das auch gemacht. Ich habe auch ab und zu bestimmte Punkte im Programm, wo alle Threads synchronisiert werden müssen und z.B. gewartet werden muss, bis alle einen bestimmten Punkt erreicht haben, und danach soll es dann erst gemeinsam weitergehen. Das mache ich auch immer mit solchen Semaphoren. Beim Warten auf das Ende würde ich es wohl genauso machen. Das trifft auch in der Regel eher das, was man tun will: Man wartet ja an sich nicht darauf, bis eine Reihe von Threads sich beendet haben, sondern bis sie mit einer bestimmten Aufgabe fertig sind, und das signalisieren sie dann eben per Semaphore. Ich muss allerdings dazu sagen, dass es sich bei mir oft um Programme handelt, die nicht dauernd Threads erzeugen und zerstören, sondern einmal beim Programmstart alle Threads anlegen und die dann bis zum Programm-Ende laufen lassen. Das scheint mir auch bei Realtime-Systemen ein häufig anzutreffender Fall zu sein.
Rolf M. schrieb: > Bei Linux lade ich mir einfach z.B. Debian runter, installiere das und > mache dann noch ein apt-get install linux-image-rt. Dann konfiguriere > ich mir noch eine realtime-Gruppe und packe da alle User rein, die > Realtime-Threads erstellen und deren Speicher gegen Auslagerung sperren > können sollen, und fertig. Das klappt bei mir nicht ganz:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
74 | |
75 | |
76 | |
77 | |
78 | |
79 | |
80 | |
81 | |
82 | |
83 | |
Das Debian ist wohl nach 5 Jahren Dauerbetrieb gealtert. Aber ich bevorzuge die Kernel-Sourcen und Preempt-RT-Patch von kernel.org um selber einen Kernel zu machen.
Erwin M. schrieb: > Das Debian ist wohl nach 5 Jahren Dauerbetrieb gealtert. Ich würde sagen: Nicht nur gealtert, sondern zerkonfiguriert.
Gast
#4240820
Erwin M. schrieb: > »linux-doc-2.6.26-grml64« GRML (http://grml.org) ist ein rescue-Linux, eigentlich für Live-CDs/Booten von USB gedacht. Warum hast du dir deren Kernel fest installiert? Wenn nicht benötigt => Deinstallieren. sollte die Paktetdatenbank in einen besseren Zustand bringen. Erwin M. schrieb: > /etc/kernel/postinst.d/dracut: Zeile 32: dracut: Kommando nicht > gefunden. > run-parts: /etc/kernel/postinst.d/dracut exited with return code 127 dracut wiederum ist der initrd-ramdisk Generator (ursprünglich) von Fedora. Der war bei dir wohl mal installiert, und wurde nicht sauber deinstalliert. ("remove" statt "purge"?) Jedenfalls liegen seine Config-dateien noch herum und verhindern die Kernel-Installation. Komplett deinstallieren, dann sollte das auch wieder passen.
Planlos schrieb: > Komplett deinstallieren, dann sollte das auch wieder passen. Ok, aber es bleibt, mit dem Debian GNU/Linux testing (stretch), noch das Rest-Problem "not found", beim Versuch zu installieren, aber nicht beim search.
Gast
#4241725
Erwin M. schrieb: > Ok, aber es bleibt, mit dem Debian GNU/Linux testing (stretch), noch das > Rest-Problem "not found", beim Versuch zu installieren, aber nicht beim > search. Da wird wohl die /etc/apt/sources.list auf "testing" zeigen, das aber nach 5 Jahren nicht mehr dasselbe ist. Da passiert es dann, dass in der DB zu den verfuegbaren Paketen Pakete drinstehen, die auf dem Server unter testing nicht mehr gefunden werden. 5 Jahre sind auch eine lange Zeit, ich wuerde eine frische Testinstallation installieren, evtl. in einer VM, aber da habe ich keinen Ueberblick, ob sich das mit rt vertraegt. wendelsberg
Ok, ich habe die sources.list so zweimal pro Jahr überarbeitet, und es war wieder mal Zeit. Es läuft wieder mit:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Nun habe ich auch den RT-Kernel. Danke für die Hinweise.
wendelsberg schrieb: > evtl. in einer VM, aber da habe ich keinen Ueberblick, ob sich das mit rt > vertraegt. Kommt drauf an, was man unter "verträgt" versteht. Laufen tut es, aber Echzeitfähigkeit darf man in einer VM nicht erwarten.
Rolf M. schrieb: > wendelsberg schrieb: >> evtl. in einer VM, aber da habe ich keinen Ueberblick, ob sich das mit rt >> vertraegt. > > Kommt drauf an, was man unter "verträgt" versteht. Laufen tut es, aber > Echzeitfähigkeit darf man in einer VM nicht erwarten. Ja, da addieren sich ja die Latenzen (auch Boot-Zeiten, Ausfallzeiten usw.). Und das macht normalerweise keinen Sinn, denn die Echtzeit verwendet man meist für reale Maschinen. Es ist schon genügend Abstraktion Programme im User-Space zu verwenden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.