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?
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.
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
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.
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.
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.
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 .
:
Bearbeitet durch User
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.
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
Peter II schrieb: > seit systemd eingeführt wurden ist, muss man auch deswegen neu booten. Wäre mir neu. Quelle?
> 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.
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.
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.
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...
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.
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
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 | Over 350 Unix utilities such as vi, ksh, csh, ls, cat, awk, grep, kill, etc. |
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.
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 | > Over 350 Unix utilities such as vi, ksh, csh, ls, cat, awk, grep, kill, |
2 | > etc. |
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 | Windows Services for Unix and Subsystem for Unix-based Applications provide |
2 | header files and libraries that make it easier to recompile or port Unix |
3 | applications for use on Windows; they do not make Unix binaries compatible |
4 | with Windows binaries. |
So wie es aussieht ist die letzte Version aber die Version 3.5 von 2004
1 | This was the final release of SFU and the only release to be distributed |
2 | free of charge. It was released January 2004 and included both English and |
3 | Japanese versions for Windows 2000, Windows XP Professional, and Windows |
4 | Server 2003 (original release only[a]) on x86 platforms with Internet |
5 | Explorer 5.0+. It included Interix subsystem release 3.5 (build version 8.0) |
6 | adding internationalization support (at least for the English version which |
7 | did not have such until now) and POSIX threading. |
8 | ... |
9 | Microsoft does not intend to produce any further standalone versions of |
10 | SFU, opting instead for the integrated SUA. As of February 6, 2014 v3.5 is |
11 | still downloadable.[5] General support will continue until 2011; extended |
12 | support until 2014. |
Damit sollte auch die Frage nach POSIX Threads beantwortet sein :)
1 | As of 2011 SFU contains: |
2 | GCC 3.3 compiler, includes and libraries (through an MS libc) |
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.
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...
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.
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.
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.
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.
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.
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).
:
Bearbeitet durch User
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 | # aptitude install linux-image-rt-amd64 |
2 | Die folgenden NEUEN Pakete werden zusätzlich installiert: |
3 | linux-image-4.0.0-2-rt-amd64{a} linux-image-rt-amd64
|
4 | Die folgenden teilweise installierten Pakete werden konfiguriert: |
5 | linux-image-4.0.0-2-amd64 linux-image-amd64 |
6 | 0 Pakete aktualisiert, 2 zusätzlich installiert, 0 werden entfernt und 20 nicht aktualisiert. |
7 | 34,9 MB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 173 MB zusätzlich belegt sein. |
8 | Möchten Sie fortsetzen? [Y/n/?] Y |
9 | Feh http://ftp.de.debian.org/debian/ testing/main linux-image-4.0.0-2-rt-amd64 amd64 4.0.8-2 |
10 | 404 Not Found |
11 | Feh http://mirrors.kernel.org/debian/ testing/main linux-image-4.0.0-2-rt-amd64 amd64 4.0.8-2 |
12 | 404 Not Found |
13 | Feh http://mirrors.kernel.org/debian/ testing/main linux-image-rt-amd64 amd64 4.0+65 |
14 | 404 Not Found |
15 | 0% [Arbeite]dpkg: Warnung: Parsen der Datei »/var/lib/dpkg/status«, nahe Zeile 8332 Paket »linux-doc-2.6.26-grml64«: |
16 | Fehler in Zeichenkette »grml.08« für Feld »Version«: Versionsnummer beginnt nicht mit einer Ziffer |
17 | linux-image-3.16.0-4-amd64 (3.16.7-ckt11-1+deb8u2) wird eingerichtet ... |
18 | /etc/kernel/postinst.d/apt-auto-removal: |
19 | dpkg-query: Warnung: Parsen der Datei »/var/lib/dpkg/status«, nahe Zeile 8332 Paket »linux-doc-2.6.26-grml64«: |
20 | Fehler in Zeichenkette »grml.08« für Feld »Version«: Versionsnummer beginnt nicht mit einer Ziffer |
21 | /etc/kernel/postinst.d/dracut: Zeile 32: dracut: Kommando nicht gefunden. |
22 | run-parts: /etc/kernel/postinst.d/dracut exited with return code 127 |
23 | Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.16.0-4-amd64.postinst line 634. |
24 | dpkg: Fehler beim Bearbeiten des Paketes linux-image-3.16.0-4-amd64 (--configure): |
25 | Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück |
26 | linux-image-4.0.0-2-amd64 (4.0.8-2) wird eingerichtet ... |
27 | vmlinuz(/boot/vmlinuz-4.0.0-2-amd64 |
28 | ) points to /boot/vmlinuz-4.0.0-2-amd64 |
29 | (/boot/vmlinuz-4.0.0-2-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-4.0.0-2-amd64.postinst line 263. |
30 | The link /initrd.img is a dangling linkto /boot/initrd.img-4.0.0-2-amd64 |
31 | /etc/kernel/postinst.d/apt-auto-removal: |
32 | dpkg-query: Warnung: Parsen der Datei »/var/lib/dpkg/status«, nahe Zeile 8332 Paket »linux-doc-2.6.26-grml64«: |
33 | Fehler in Zeichenkette »grml.08« für Feld »Version«: Versionsnummer beginnt nicht mit einer Ziffer |
34 | /etc/kernel/postinst.d/dracut: Zeile 32: dracut: Kommando nicht gefunden. |
35 | run-parts: /etc/kernel/postinst.d/dracut exited with return code 127 |
36 | Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-4.0.0-2-amd64.postinst line 634. |
37 | dpkg: Fehler beim Bearbeiten des Paketes linux-image-4.0.0-2-amd64 (--configure): |
38 | Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück |
39 | dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-image-amd64: |
40 | linux-image-amd64 hängt ab von linux-image-4.0.0-2-amd64; aber: |
41 | Paket linux-image-4.0.0-2-amd64 ist noch nicht konfiguriert. |
42 | dpkg: Fehler beim Bearbeiten des Paketes linux-image-amd64 (--configure): |
43 | Abhängigkeitsprobleme - verbleibt unkonfiguriert |
44 | Fehler traten auf beim Bearbeiten von: |
45 | linux-image-3.16.0-4-amd64 |
46 | linux-image-4.0.0-2-amd64 |
47 | linux-image-amd64 |
48 | E: Herunterladen von http://mirrors.kernel.org/debian/pool/main/l/linux/linux-image-4.0.0-2-rt-amd64_4.0.8-2_amd64.deb fehlgeschlagen: 404 Not Found |
49 | E: Sub-process /usr/bin/dpkg returned an error code (1) |
50 | Failed to perform requested operation on package. Trying to recover: |
51 | dpkg: Warnung: Parsen der Datei »/var/lib/dpkg/status«, nahe Zeile 8332 Paket »linux-doc-2.6.26-grml64«: |
52 | Fehler in Zeichenkette »grml.08« für Feld »Version«: Versionsnummer beginnt nicht mit einer Ziffer |
53 | linux-image-4.0.0-2-amd64 (4.0.8-2) wird eingerichtet ... |
54 | vmlinuz(/boot/vmlinuz-4.0.0-2-amd64 |
55 | ) points to /boot/vmlinuz-4.0.0-2-amd64 |
56 | (/boot/vmlinuz-4.0.0-2-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-4.0.0-2-amd64.postinst line 263. |
57 | The link /initrd.img is a dangling linkto /boot/initrd.img-4.0.0-2-amd64 |
58 | /etc/kernel/postinst.d/apt-auto-removal: |
59 | dpkg-query: Warnung: Parsen der Datei »/var/lib/dpkg/status«, nahe Zeile 8332 Paket »linux-doc-2.6.26-grml64«: |
60 | Fehler in Zeichenkette »grml.08« für Feld »Version«: Versionsnummer beginnt nicht mit einer Ziffer |
61 | /etc/kernel/postinst.d/dracut: Zeile 32: dracut: Kommando nicht gefunden. |
62 | run-parts: /etc/kernel/postinst.d/dracut exited with return code 127 |
63 | Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-4.0.0-2-amd64.postinst line 634. |
64 | dpkg: Fehler beim Bearbeiten des Paketes linux-image-4.0.0-2-amd64 (--configure): |
65 | Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück |
66 | dpkg: Abhängigkeitsprobleme verhindern Konfiguration von linux-image-amd64: |
67 | linux-image-amd64 hängt ab von linux-image-4.0.0-2-amd64; aber: |
68 | Paket linux-image-4.0.0-2-amd64 ist noch nicht konfiguriert. |
69 | dpkg: Fehler beim Bearbeiten des Paketes linux-image-amd64 (--configure): |
70 | Abhängigkeitsprobleme - verbleibt unkonfiguriert |
71 | linux-image-3.16.0-4-amd64 (3.16.7-ckt11-1+deb8u2) wird eingerichtet ... |
72 | /etc/kernel/postinst.d/apt-auto-removal: |
73 | dpkg-query: Warnung: Parsen der Datei »/var/lib/dpkg/status«, nahe Zeile 8332 Paket »linux-doc-2.6.26-grml64«: |
74 | Fehler in Zeichenkette »grml.08« für Feld »Version«: Versionsnummer beginnt nicht mit einer Ziffer |
75 | /etc/kernel/postinst.d/dracut: Zeile 32: dracut: Kommando nicht gefunden. |
76 | run-parts: /etc/kernel/postinst.d/dracut exited with return code 127 |
77 | Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.16.0-4-amd64.postinst line 634. |
78 | dpkg: Fehler beim Bearbeiten des Paketes linux-image-3.16.0-4-amd64 (--configure): |
79 | Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück |
80 | Fehler traten auf beim Bearbeiten von: |
81 | linux-image-4.0.0-2-amd64 |
82 | linux-image-amd64 |
83 | linux-image-3.16.0-4-amd64 |
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.
:
Bearbeitet durch User
Erwin M. schrieb: > Das Debian ist wohl nach 5 Jahren Dauerbetrieb gealtert. Ich würde sagen: Nicht nur gealtert, sondern zerkonfiguriert.
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.
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 | deb http://httpredir.debian.org/debian stretch main contrib non-free |
2 | deb-src http://httpredir.debian.org/debian stretch main contrib non-free |
3 | |
4 | deb http://httpredir.debian.org/debian stretch-updates main contrib non-free |
5 | deb-src http://httpredir.debian.org/debian stretch-updates main contrib non-free |
6 | |
7 | deb http://security.debian.org/ stretch/updates main contrib non-free |
8 | deb-src http://security.debian.org/ stretch/updates main contrib non-free |
Nun habe ich auch den RT-Kernel. Danke für die Hinweise.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.