|
|
|
|
|
|
|
Warum so kompliziert Matlab nutzen? 
|
|
|
|
|
|
|
|
|
|
|
Ich muss mal mit den Leuten noch reden, ob man die Abgabe auch in C oder so machen darf. Die Aussage bisher war: "Wir machen das in Matlab, weil man da Plots machen kann und wenn sie das erst in C implementieren müssten, wäre das ja wohl kompliziert". Ja klar. Datei schreiben und dann Gnuplot oder so gibt's ja nicht. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Schalentier
| | Zitat von [SFoR]-RedEagle
Ich bin mir nicht absolut sicher, aber ich glaube nicht, dass die Inliner-Heuristik das mit einbezieht. | |
Doch, tut er. Solche Deklarationen bekommen auch ganz besondere Linkage-Eigenschaften. Solche Methoden bekommen automatisch eine eigene Unit, die dann von mehreren Übersetzungseinheitne parallel compiliert werden kann und beim Linken wieder zusammengeführt werden (und dann alle gleich groß sein müssen, sonst ist was schiefgegangen) Da der Compiler hier den Methodenkörper kennt und weiß, dass er eindeutig sein muss, kann er intraprozedurale Compile-Time-Optimisierung anwenden. Das lässt er sich nicht zweimal sagen, es sei denn man verbietet es ihm.
Generell hat das Wort "inline" in g++ eine andere Bedeutung als in C. In C meint man damit wirklich, dass man die Methode gerne geinlinet hätte. In C++ bezieht es sich vielmehr auf obengenanntes Verhalten und kann dazu benutzt werden Funktionen mitsamt Implementation in Headern zu definieren. Das gleiche geschieht implizit auch mit Templates und eben eingebetteten Methodenkörpern.
In C++ profitiert man allgemein davon, dass hier implizit geinlinet wird, vor allem im Umgang mit Templates. Bei diversen Konstrukten werden aus Abstraktionsgründen häufig Methoden weitergereicht (und Copy-Konstruktoren, etc...). Da werden teilweise unglaublich komplexe Konstrukture vom Compiler zusammengezogen und knapper Assembler-Code erzeugt, der, wenn anderweitig explizit in Call-Anweisungen umgesetzt, schrecklich komplex und unnötig wären. Wenn man also Funktionskörper in Header packt, dann macht man das aus purer Absicht (sollte man, nicht aus purer Faulheit). Im Übrigen generiert der Compiler immer (ausser wenn die Methode ausserhalb der derzeitigen Übersetzungseinheit sichtbar ist) noch eine out-of-line-Implementation, denn das inlinen macht er nur optional. Wenn der gcc beschließt, dass es sich nicht lohnt, macht er einen ganz gewöhnlichen Aufruf daraus.
¤: Wie Traxer auch schon angemerkt hat, wenn man was in Headern will, ist es äquivalent dazu, ein "inline" dazuzupacken und die Implementation unterhalb zu machen. Ist einfach eine Frage der Übersichtlichkeit, welchen Weg man wählt. Das ist ein Nachteil an C++, es überlässt dem Programmierer die ganzen schweren Stilentscheidungen. 
| |
Okay. So viel wollte ich nicht gleich wissen
Ich wusste zumindest, dass "inline" bei normalen Funktionen vom Compiler auf Effizenz ueberprueft wird und dann je nach Situation tatsaechlich "inline" verwendet wird, oder nicht. Leider ist mein Buch bei den Klassen dann nicht weiter auf "inline" eingegangen, das ich ausserhalb einer Klasse definierte Elementfunktionen/Methoden auch inlinen kann mit "inline" wird leider nicht erwaehnt, oder noch nicht
Darf ich so zusammenfassen?
"Inline" lohnt sich eigentlich immer, der Heuristik des Compilers bewertet dann von selbst, ob das so klug war oder nicht. Notfalls wird "inline" halt wieder aufgehoben. Ob man jetzt eine Memberfunktion/Methode direkt in der Klasse definiert ist halt einfach meine Stilentscheidung.
Ach ja, wenn Schale schon so ausholt.
Seit GCC4 soll die "inline Heuristik" (ich nenne es jetzt so) wesentlich besser sein, zumindest wenn man "make menuconfig" beim Linux-Kernel glauben schenkt. Ich glaube unter "Hacking" ist da eine Option dafuer, die ich seit einiger Zeit auch aktiviert habe.
<edit> Wir waren ja schon bei der X11- und Tastaturdiskussion.
In letzter Zeit war ich ja nicht immer ganz Fefes Meinung, aber heute hat er recht. Wie war das HAL ist Mist? Richtig. Und DBUS auch? Finde ich auch. Nur laesst er PolicyKit aus, das Krebsgeschwuer schlechthin. Halt, ich habe Pulseaudio vergessen. Wobei ich das Gejammer bei Pulseaudio nicht verstehe, im Gegensatz zu PolicyKit kann man das einfach weglassen.
UDEV mag ich aber, ist ja auch kein Layer, sondern ein ganze Devicesystem.
Was mich wundert ist, dass irgendwie jetzt erst viele bemerken dass X11 sich inzwischen ueberhaupt nicht mehr um fehlende Inputdevices kuemmert. Das ist doch schon laenger so. Ueberhaupt finde ich, dass sich die Lage bessert: FAM ist tot (Gamin), HAL ist tot (ganz ueberfluessig) und PolicyKit hustet sicher schon
Anderseits. An der Theorie dass es irgend jemand gibt der bloede Layer und Daemonen fuer GNU entwirft koennte was dran sein?
|
|
[Dieser Beitrag wurde 8 mal editiert; zum letzten Mal von ./hoschi am 20.04.2010 22:06]
|
|
|
|
|
|
|
|
|
| | Zitat von RichterSkala
Ich muss mal mit den Leuten noch reden, ob man die Abgabe auch in C oder so machen darf. Die Aussage bisher war: "Wir machen das in Matlab, weil man da Plots machen kann und wenn sie das erst in C implementieren müssten, wäre das ja wohl kompliziert". Ja klar. Datei schreiben und dann Gnuplot oder so gibt's ja nicht.
| |
Warum nicht Octave nehmen?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von ./hoschi
Halt, ich habe Pulseaudio vergessen. Wobei ich das Gejammer bei Pulseaudio nicht verstehe, im Gegensatz zu PolicyKit kann man das einfach weglassen. | |
Ich find Pulseaudio immernoch toll. Solange es halt optional ist.
Ich habs mir (nachdem die Ubuntujungs es vor einiger Zeit mal kaputtgefixt haben) vor ein paar Wochen nochmal installiert. Und was soll ich sagen? Es funktioniert einfach.
Ich benutzt es eigentlich quasi nur, um Sound vom Laptop aufs Mediacenter umzuleiten. Ich kann sogar während ein Video läuft problemlos umschalten wo was ausgegeben werden soll, ich kann für jedes Programm einzeln die Lautstärke einstellen etc. Für mich optimal.
Alles natürlich unter dem Grundgedanken es optional zu machen. Da ich hier mit meinem Aufbau warscheinlich eher zu einer Randgruppe gehöre, hat das mMn in der Ubuntu-Standardinstallation natürlich nix verloren.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von ./hoschi
<edit> Wir waren ja schon bei der X11- und Tastaturdiskussion.
In letzter Zeit war ich ja nicht immer ganz Fefes Meinung, aber heute hat er recht. | |
Ich hab selber nie was dafür gecodet, insofern kann ich ihm soweit nur zustimmen, dass Bluetooth mit Dbus die allerreinste Pest ist. Dass er die Kiste resetten muss, find ich affig: Alt+SysRq+R, Strg+Alt+F1 und fertig. Zumindest ging das bei mir bisher immer einwandfrei, wenn ich nicht grad 'ne Kernelpanic hatte.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von ShinyDoofy am 20.04.2010 23:00]
|
|
|
|
|
|
|
|
|
Nur weil die Implementation hakelig ist, muss man nicht gleich alles verteufeln. Insofern kann ich Fefe überhaupt nicht zustimmen. Der Kernel hat einen Überblick über alle Devices, aber Userspace soll für alle Eventualitäten ein trölf-Millionen-großes /dev vorhalten? So ein Schwachsinn.
Ein Problem ist, dass Teile davon maßgeblich von Gnome-Entwicklern und Redhat-Leuten getragen wurde, Leute die keine Ahnung von Kompatibilitätskriterien haben und das ganze ist in einem Kompatibilitätschaos geendet und nur Distros kannten die magisch passenden Komponenten. Auch Gentoo ist wiederholt in die Falle getreten und es gab nur zwischendurch Phasen, wo alles reibungslos lief.
Das Hauptproblem ist, dass alles noch dabei ist sich zu etablieren und einfach unreif war (und dennoch gepusht wurde). Auch das wird sich mit der Zeit geben.
udev auf jeden Fall ist seit einiger Zeit sehr stabil und ein riesiger Fortschritt gegenüber dem, was man früher hatte. Es synchronisiert das Interface zwischen Kernel und Userspace und vereinheitlicht Hotplug. Auch ein systemweites Messaging-System (dbus) spielt hierbei eine entscheidende Rolle. Weg mit wilden Skripten die sich gegenseitig aufrufen und katastrophales Locking haben. Neues Geräte rein -> Datenbank wird nachgeschlagen um was es sich handelt -> Device nach bestem wissen angelegt -> ggf. Device konfiguriert, Firmware geladen -> Message über neues Device rumgeschickt -> ggf. Dienste informiert / gestartet. Das Problem ist, bis sich das ganze eingespielt hat, wie die genaue Hierarchie stattfindet.
Das Problem mit HAL war, dass einfach drauf losprogrammiert wurde. udev hat viele der Funktionen systematisch übernommen mit der Zeit während HAL mit Funktionen überfrachtet wurde, so dass ein Zuständigkeitschaos entstand. Gerade, als es anfing zu funktionieren, wurde es wieder in die Tonne getreten (wobei ich das persönlich etwas übertrieben finde, Teile der Idee fand ich gut). Im Moment ist leider alles etwas im Flux, und wie kann's anders sein, funktioniert nur mit den magisch richtigen Paketen so halbwegs.
Auch das wird sich legen. Nur weil so ein riesen Chaos herrscht, kann man noch lange nicht behaupten, dass alles Blödsinn sei und man es nicht braucht. Das ist ein typische Standpunkt von Trollen, die Notwendigkeiten und das Gesamtbild nicht erkennen und sich nur wegen ihren persönlichen Ansichten über alles aufregen. Sicherlich, die Probleme sind da, aber das heißt noch lange nicht, dass man sich ein Urteil über Dinge bilden sollte, über die man keinen vollständigen Überblick hat.
Ich bin mal für geduldig abwarten, die Dinge werden sich irgendwann von selbst einpendeln.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Schalentier
Ich bin mal für geduldig abwarten, die Dinge werden sich irgendwann von selbst einpendeln.
| |
pendelt sich dann auch irgendwann dieses nur noch aus, teilweise nicht richtig funktionierenden, plugins bestehende x zeugs weg?
|
|
|
|
|
|
|
|
|
|
|
|
LVM baut aus mehreren PVs in einer VG einen JBOD-Verbund, oder? Ich hab keine Möglichkeit, wie bei einem Raid auf mehreren Volumes parallel zu schreiben, oder?
|
|
|
|
|
|
|
|
|
|
|
|
Man kann Volumes RAID0-artig über mehrere PVs stripen. Weitereführende Möglichkeiten gibt es derzeit meines Wissens nach nicht, obwohl der zugrundeliegende Device-Mapper weitere RAID-Targets hat. (RAID1 wird von LVM meines Wissens nach nur für pvmove verwendet)
|
|
|
|
|
|
|
|
|
|
|
|
ah, das wär schon ziemlich ideal. Ich würd unser SAP-Testsystem gern mal damit ausstatten und schauen, ob das dahinter liegende SAN performanter ist, wenn ich es über zwei NICs ansteuere (ESX-Server mit 4 iSCSI-NICs, Round Robin und 4 HP Lefthand-Knoten dahinter).
|
|
|
|
|
|
|
|
|
|
|
Gibt es eine möglichkeit eine Anwendung Fullscreen zu starten ohne das eine Windowsmanager läuft?
Hintergrund: Ich habe hier Linux PCs die unter dem Benutzer "Windows" eine Windows VM starten. Nun möchte ich gerne aus "der Benutzer soll nix kaputt machen können"-Gründen auf einen WM verzichten. Daher starte ich Vmware (mit passenden Parametern) über ein passen GDM *.desktop Datei.
Allerdings wird das ding nicht "Bildschirmgroß" gestartet und der Vollbildmodus für die VM geht auch nicht.
|
|
|
|
|
|
|
|
|
|
|
| | | One can also use X11 without a window manager. Typically, one writes a session script which starts an "xterm" at a "-geometry" location. One then starts other X11 clients by giving their "-geometry" explicitly, because there is no window manager | |
|
|
|
|
|
|
|
|
|
|
|
Hm...dann müsste ich die Displaygrößen immer wissen. Das ist auch doof.
Lösung bisher:
metacity &
vmware -q -X /pfad/zu/vm
Läuft halt Metacity im Hintergrund...so ganz dramatisch ist das nicht.
|
|
|
|
|
|
|
|
|
|
|
Die Displaygroesse koenntest du aus xdpyinfo ziehen, aber vllt. gibt es auch noch einen besseren Weg.
E: xwininfo -root | grep geometry
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [SFoR]-RedEagle am 21.04.2010 19:22]
|
|
|
|
|
|
|
|
|
|
Du kannst auch z.B. fluxbox mit einer leeren Menudatei und ohne Windowdecoration, Toolbar und Tastaturkuerzel betreiben.
|
|
|
|
|
|
|
|
|
|
|
Wie gesagt, mit Metacity gehts. vmware ist dann offenbar in der Lage sich selbst in Fullscreen zu setzen und die X-Session beendet sich artig wenn sich vmware schließt.
Jetzt brauche ich nur noch eine Möglichkeit unter GDM für einen bestimmten User (und nur für diesen) immer eine Seitzung zu erzwingen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Weil sich da auch andere User als der "Windows" Benutzer einloggen wollen. Und weil ich so wenig wie möglich verändern und basteln möchte, weil ich das alles dokumentieren muss. Je näher an einer Ubuntu Standardinstallation, desto weniger arbeit.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achsel-des-Bösen am 21.04.2010 20:23]
|
|
|
|
|
|
|
|
|
|
slim + .xinitrc macht bei mir genau das
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Teh Ortus
Alles natürlich unter dem Grundgedanken es optional zu machen.
| |
Fast immer eine gute Loesung
| | Zitat von ShinyDoofy
Ich hab selber nie was dafür gecodet, insofern kann ich ihm soweit nur zustimmen, dass Bluetooth mit Dbus die allerreinste Pest ist. Dass er die Kiste resetten muss, find ich affig: Alt+SysRq+R, Strg+Alt+F1 und fertig. Zumindest ging das bei mir bisher immer einwandfrei, wenn ich nicht grad 'ne Kernelpanic hatte.
| |
SysRq ist toll, REISUB mag doch jeder 
Nur muesst ich dazu auf dem Macbook die Tasten umkonfigurieren, die SysRq-Taste hat der Steve weggelassen. Ich bin nur zu faul dazu.
Hauptgrund:
Ich kann mich nicht erinnern, dass in den letzten zwei Jahren mein Linux auf dem Macbook auch nur eine Kernel-Panic hatte. Spaetestens seit KMS das Umschalten zwischen Terminal und X11 sauber erledigt kann man nicht mal mit wildem "Suspent to RAM" das System in Not bringen. Zumindest ich nicht.
Was wieder zu HAL/DBUS und Schale fuehrt, wenn beides nur schlecht waere saehe das anders aus.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von ./hoschi am 21.04.2010 23:14]
|
|
|
|
|
|
|
|
|
| | Zitat von ./hoschi
(...)
SysRq ist toll, REISUB mag doch jeder
Nur muesst ich dazu auf dem Macbook die Tasten umkonfigurieren, die SysRq-Taste hat der Steve weggelassen. Ich bin nur zu faul dazu.
(...)
| |
Sah wahrscheinlich nicht stylish aus.
|
|
|
|
|
|
|
|
|
|
|
Japp. Dafuer gibt es die Auswurftaste 
eject sage ich da nur.
<edit>
Die koennte ich ja als SysRq mappen. Aber was soll ich tun, das System laeuft ja schoen stabil
Ueberhaupt. Ein guter Grund die Programmierer von GNU/Linux mal zu loben.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von ./hoschi am 21.04.2010 23:17]
|
|
|
|
|
|
|
|
|
Wieso? Weil fefe grad Greg K-H wegen dem Programmpfad in udev basht? 
|
|
|
|
|
|
|
|
|
|
|
|
Wie kann ich denn ne andere Taste auf SysReq mappen? Mein Netbook hat sowas nämlich auch nicht.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von ./hoschi
Japp. Dafuer gibt es die Auswurftaste
eject sage ich da nur. | |
Eject aus dem Fenster?
Schlimm ist es eigentlich, dass die These über das Stockholmsyndrom bei Applefanbois wirklich wahr ist. Als Reaktion auf dieses Bild gab's neulich tatsächlich sinngemäß nur zu hören, dass das von der guten Qualität des Kabels und der robusten Verarbeitung zeuge, dass man sich damit auch erhängen könne...
Gibt's eigentlich praktikable "Gegenmaßnahmen", um den Leuten wenigstens wieder ein bisschen Verstand einzuverleiben? Man muss sie doch aus dieser Misere befreihen können 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Meinungsverstärker™.
/e: Zwischenposter.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von statixx am 21.04.2010 23:46]
|
|
|
|
|
|
|
|
|
Lahmarsch. 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.21 - sudo make me a sandwich! ) |
