Das ist doch wie Weihnachten!
-
Warum heißt es eigentlich immer "Linux ist das Entwickler OS"? Außer zwei gut konfigurierbaren Editoren sitzen sie ja komplett im Trockenen.
MfG SideWinder
-
SideWinder schrieb:
Warum heißt es eigentlich immer "Linux ist das Entwickler OS"? Außer zwei gut konfigurierbaren Editoren sitzen sie ja komplett im Trockenen.
MfG SideWinder
Da sieht man wieder, dass einige MS-Fanatiker kein Plan haben.
Ja, man kann unter jedem OS entwickeln.
Was die editoren angeht: Selbst wenn ich per apt-cache search nach editoren suche, stoße ich auf mehr...
-
Debian-Fan schrieb:
vista schrieb:
Debian-Fan schrieb:
ps: Linux/unix ist/sind das/die Entwickler os!
kannst du das irgendwie belegen?
Ehm ja. Der Sourcecode ist offen, sodass man als neugieriger Entwickler/Schnüffler im source rumtrieben/austoben/dazulernen kann. Außerdem kanns jeder verändern wie er will. Falls ich nich mehr weiß wie funktion <irgendwas> ging, brauch ich meist nur "man <irgendwas>" aufzurufen und hab eine sehr lange und präzise beschreibung.
quelloffene programme kannst du auch auf closed-source systemen betrachten, ändern, davon lernen etc.
'man <irgendwas>' ist so ziemlich die spartanischste möglichkeit, durch eine dokumentation zu browsen. textmodusbasierte man-pages waren vielleicht in den 60'er jahren revolutionär, aber heute würde ich sowas nicht mehr benutzen wollen.
ich hatte dich so verstanden, daß linux als entwicklersystem im sinne von 'arbeitsgerät bzw. umgebung' für das erstellen von software das beste wäre und das ist definitiv falsch.
-
vista schrieb:
Debian-Fan schrieb:
vista schrieb:
Debian-Fan schrieb:
ps: Linux/unix ist/sind das/die Entwickler os!
kannst du das irgendwie belegen?
Ehm ja. Der Sourcecode ist offen, sodass man als neugieriger Entwickler/Schnüffler im source rumtrieben/austoben/dazulernen kann. Außerdem kanns jeder verändern wie er will. Falls ich nich mehr weiß wie funktion <irgendwas> ging, brauch ich meist nur "man <irgendwas>" aufzurufen und hab eine sehr lange und präzise beschreibung.
quelloffene programme kannst du auch auf closed-source systemen betrachten, ändern, davon lernen etc.
'man <irgendwas>' ist so ziemlich die spartanischste möglichkeit, durch eine dokumentation zu browsen. textmodusbasierte man-pages waren vielleicht in den 60'er jahren revolutionär, aber heute würde ich sowas nicht mehr benutzen wollen.
ich hatte dich so verstanden, daß linux als entwicklersystem im sinne von 'arbeitsgerät bzw. umgebung' für das erstellen von software das beste wäre und das ist definitiv falsch.lol? Unter windows gibts GARKEINE Möglichkeit sowas nachzuschauen. Jaja, jetzt kommt gleich MSDN, diese muss man sich aber eh dazuinstallieren.
Und seien wir mal ehrlich: Am liebsten wäre es MS, dass niemand auf der Welt coden würde außer MS selbst.
-
vista schrieb:
ich hatte dich so verstanden, daß linux als entwicklersystem im sinne von 'arbeitsgerät bzw. umgebung' für das erstellen von software das beste wäre und das ist definitiv falsch.
kannst du das irgendwie belegen?
-
borg schrieb:
vista schrieb:
ich hatte dich so verstanden, daß linux als entwicklersystem im sinne von 'arbeitsgerät bzw. umgebung' für das erstellen von software das beste wäre und das ist definitiv falsch.
kannst du das irgendwie belegen?
die verfügbarkeit von ausgereiften entwicklungstools aus einem guss für nicht-x86 plattformen ist unter windows um ein vielfaches grösser.
unter linux müsste man sich dafür, falls es den/die passenden GCC/binutils gibt, irgendwas zusammenstückeln. wenn man glück hat, bekommt man's mit eclipse und CDT zum laufen aber spätestens das debuggen (remote debugging mit GDB/Insight etc.) ist eine einzige katastrophe.
ein freund von mir z.b. entwickelt für coldfire prozessoren mit embedded linux. die entwicklungsmaschine ist ein windows-pc. das geht völlig problemlos und stressfrei...
-
minhen schrieb:
Oder wie erklärst du dir sonst, dass "Anfänger-Distributionen" wie z.B. Ubuntu - welche mit Sicherheit mit die größte Verbreitung haben - wunderbar ohne Kompilierungszwang auskommen?
Ohne Kompilierungszwang gehts zwar, aber bis dann endlich mal alles läuft...
Zuerst lädt man sich den Treiber von der ATI-Seite runter und installiert ihn (ich weiß leider nicht mehr genau wie das ging, ist schon ein Jahr her). Funktioniert auch alles soweit, allerdings ist die Bildschirmfrequenz auch immer noch 60 Hz. Gut, sollte so einfach gehen wie unter Windows, Menü dafür gefunden, aber auch nachdem man 80 Hz oder was auch immer ausgewählt hat, ist die Frequenz immer noch bei 60 Hz.
Total genervt googelt man erstmal los und findet nach einer knappen Stunde ein Forum in dem beschrieben wird, dass man irgendeine komische Text-Datei öffnen und editieren muss... Ok, das sollte ja noch gehen, allerdings hat man keine Rechte um die Datei zu speichern
. Nach weiteren 20 Minuten googeln lernt man den Sudo-Befehl für die Konsole kennen. Natürlich muss man dann alles über die Konsole machen, kriegt schließlich den Monitor auf die normalen 100 Hz hoch.Dann will man neue Software installieren (ist ja angeblich dank dem Paketsystem sehr einfach), die gesucht ist aber nicht dabei und sich die source zu installieren und mit ./configure und co zu installieren/ selbst zu kompilieren hat man keine Lust, also sucht man weiter, bis man rausfindet, dass man irgendwelche neuen Paketquellen registrieren muss, bis dann endlich mal alles funktioniert.
Soweit zu meiner Erfahrung unter Ubuntu.
Ich sage NICHT, dass man unter Windows keine ähnlichen Probleme haben kann, z.b. mit fehlenden Treibern oder dem einstellen der Bildschirmfrequenz (tatsächlich hatte ich damit auch unter Windows Probleme, was aber am ATI-Treiber lag).
Aber dass man
- Zum ändern der Bildschirmfrequenz eine Textdatei editieren muss
- Zum editieren der Textdatei die Konsole und den sudo-Befehl kennen muss
- Software selbst kompilieren oder über ./configure... installieren muss anstatt einen netten graphischen Installer zu haben
ist einfach nervig und (meiner Meinung nach) unnötig.
Ja, ich weiß dass man das bestimmt alles hätte anders machen können/sollen/müssen oder es doch ganz normal ist, seitenweise Befehle in die Konsole zu hacken, um irgendwelche simplen Dinge zum laufen zu kriegen, aber es ist MEINE MEINUNG, dass das nicht so sein SOLLTE.
Felix
P.S.: Ich habe nichts gegen andere Betriebssysteme, mit MacOS bin ich sogar sehr zufrieden
-
Die Installation von Windows ist doch auch nicht problemlos. Ganz zu schweigen von der Tatsache, dass der Otto-Normalverbraucher weder Windows noch Linux installieren kann.
Also meine Erfahrung mit Windows-Installationen (wobei ich noch keine Erfahrung habe mit Witzda), ist auch nicht sonderlich toll. Es ist mir auch schon mehrfach passiert, das Hardware nicht erkannt wurde (was beim Festplatten-Controller eben ein bisserl blöd is) und Windows mich dann bat irgend eine Treiberdiskette(!) einzulegen... Linux lies sich übrigens in allen ausprobierten Versionen problemlos installieren, weil bei Linux eben so exotische Treiber dabei sind.
Auch die NVidia- oder ATI-Treiber installiert man heute ja nur noch mit einem Mausklick (siehe zB easyubuntu). Ich kenne Leute, die keine Ahnung von Computern haben und es geschafft haben Ubuntu selbst zu installieren (auf Laptop-Hardware(!!) und sogar WLAN ging sofort...).
Klar hat Linux Treiber für einige Hardware nicht. Da muss man eben vorher gucken. Ist ja auch das gleiche wenn man Windows hat oder MacOSX (ich hab zB einen USB-Stick, der aus irgend einem Grund nicht mit OS X arbeiten will, obwohl er von Windows und Linux ohne Probleme erkannt wird. Daher finde ich jetzt eher den USB-Stick scheiße, als OS X...). Leider hat man mit Linux eben nicht die Leichtigkeit einfach "innen **Markt" zu gehen und dort das erste Produkt rauszugreifen. Aber das wird sich eh ändern. So Firmen wie Dell etc fangen ja langsam an Linux auch auf dem Desktop-Markt einen Platz einzuräumen.
Bei Ubuntu zB finde ich einige Konfigurationswerkzeuge ein wenig schwach und ich glaube eine "Virtuelle Ubuntu Tour" und "Interaktive Hilfe" wäre für Anfänger sinnvoll. Aber das wird mit der Zeit kommen...
@vista
Naja, wenn er gerne Windows benutzt (ich finde die Benutzung grauenhaft und unkomfortabel. Aber ich will ja niemandem meine Meinung aufzwingen). Aber das schlimmste ist doch _für_ Windows zu entwickeln...(zB Windows aka das Betriebsysstem was DLLs nicht hinbekommt oder Windows aka das Betriebssystem was kaputtes Unicode hat :D)
-
DEvent schrieb:
Andy2006, was soll dein Blödssin hier? Immer redest du vom Otto-Normal-DA-User. Aber dann kommen Sachen wie:
- Partitionierung
- neue Festplatte
- Multi-BootAuch ein Otto-Normal-Da-User muss irgendwann mal den Begriff Parition gebrauchen, spätestens wenn er sein System zerschossen hat und neu installieren will.
Und unter Windoof ist das allemal einfacher zu verstehen als unter Linux.Auch ein Otto-Normal-Da-user wird sich vielleicht mal eine neue Platte in den PC dazu bauen, oder auch einen Brenner, unter Windoof ist das kein Thema, rein damit (richtig gejumpert) und fertig. Unter Linux habe ich das so noch nie gemacht, allerdings habe ich noch nicht verstanden wozu etwas gemounted werden muss. Wenn es da its ist es da, wenn nicht dann nicht, basta.
Das Multi-Boot war natürlich auf mich bezogen.
Dass die Hardwarehersteller nicht für 1000de Linux Versionen Treiber proggen ist wohl auch klar. Wieder so ein Fehler in meinen Augen dass es tatsächlich so viele Distries gibt. Einem Umsteiger wird die Sache in der Hinsicht nicht leicht gemacht, und Treiber würde es sicher auch geben wenn die Nachfrage bestehen würde, was allerdings daran scheitert weil sich wol viele nicht da ran trauen, an das Linux-System.
-
rüdiger schrieb:
@vista
Naja, wenn er gerne Windows benutzt (ich finde die Benutzung grauenhaft und unkomfortabel.es ist auch eine frage von produktivität. wenn sich jemand unter linux wohler fühlt bzw. damit besser klar kommt, kann man ihn schlecht von den vorteilen gewisser windows-tools überzeugen. die erfahrung muss er selbst machen.
mich stören unter linux solche kleinigkeiten wie z.b. dass es kein einheitliches 'clipboard' gibt.rüdiger schrieb:
Aber ich will ja niemandem meine Meinung aufzwingen). Aber das schlimmste ist doch _für_ Windows zu entwickeln...
welche negativen erfahrungen hast du gemacht?
rüdiger schrieb:
(zB Windows aka das Betriebsysstem was DLLs nicht hinbekommt...
was heisst 'nicht hinbekommt'
-
vista schrieb:
die verfügbarkeit von ausgereiften entwicklungstools aus einem guss für nicht-x86 plattformen ist unter windows um ein vielfaches grösser.
das widerspricht ja auch dem konzept kleine unabhängige, aber miteinander verbindbare werkzeuge zu haben.
ich brauche einen editor, der muss syntax highlighting können, dann brauch ich noch nen debugger, der soll debuggen, nen compiler der soll.. ich will kein tool das alles auf einmal macht und auch noch kaffee kochen kann, welches ich aber nicht mehr gebrauchen kann wenn ich eine kleinigkeit an der spezifikation ändere. wenn ich die plattform ändere soll sich gefälligst nur der compiler ändern und wenn ich die programmiersprache ändere möchte ich doch bitte den gleichen editor verwenden können usw.und ich bin mir sicher du hast tools wie gdb/valgrind und co noch nie intensiv verwendet, hauptsache behaupten es ist eine "einzige katastrophe".
-
fred zumachen
-
borg schrieb:
vista schrieb:
die verfügbarkeit von ausgereiften entwicklungstools aus einem guss für nicht-x86 plattformen ist unter windows um ein vielfaches grösser.
das widerspricht ja auch dem konzept kleine unabhängige, aber miteinander verbindbare werkzeuge zu haben.
ein konzept ist nur dann gut, wenn es mir hilft und nicht wenn es mich behindert.
borg schrieb:
ich brauche einen editor, der muss syntax highlighting können, dann brauch ich noch nen debugger, der soll debuggen, nen compiler der soll.. ich will kein tool das alles auf einmal macht...
das ist auch nicht so.
die von mir angesprochenen komplettlösungen sind eine sammlung sorgfältig aufeinander abgestimmter programme, die aus einer komfortablen IDE heraus ausgeführt werden können. du kannst die tools auch einzeln von der kommandozeile ausführen, aber das tut fast niemand. ...und so eine toolchain funktioniert 'out-of-the-box', ohne grosse konfigurationsorgien.borg schrieb:
und ich bin mir sicher du hast tools wie gdb/valgrind und co noch nie intensiv verwendet, hauptsache behaupten es ist eine "einzige katastrophe".
valgrind nicht, aber GDB/Insight für NEC V850 musste ich mal benutzen. an die umständliche bedienung hätte ich mich ja noch gewöhnen können, aber der schrott war total buggy und absolut unbrauchbar.
das gleiche erlebnis mit GDB für ARM/AT91SAM7: verbuggt bis zum geht-nicht mehr.
glücklicherweise gibt's ja noch die kommerzielle IAR embedded workbench, damit lief alles wie geschmiert. es liegen doch welten zwischen brauchbarer software und dem GNU-mist.
mag natürlich sein, dass GDB unter linux/x86 gut funktioniert, das kann ich nicht beurteilen.
-
Andy2006 schrieb:
DEvent schrieb:
Andy2006, was soll dein Blödssin hier? Immer redest du vom Otto-Normal-DA-User. Aber dann kommen Sachen wie:
- Partitionierung
- neue Festplatte
- Multi-BootAuch ein Otto-Normal-Da-User muss irgendwann mal den Begriff Parition gebrauchen, spätestens wenn er sein System zerschossen hat und neu installieren will.
Und unter Windoof ist das allemal einfacher zu verstehen als unter Linux.Otoo-Normal-Da-User wird auch nie im Leben auf die Idee kommen ein anderes Betriebssystem zu installieren, als das vorinstallierte. Daher ist es ja besonders schlimm, wie Microsoft mit verbrecherischen Methoden sein Monopol ausnutzt.
Auch ein Otto-Normal-Da-user wird sich vielleicht mal eine neue Platte in den PC dazu bauen, oder auch einen Brenner, unter Windoof ist das kein Thema, rein damit (richtig gejumpert) und fertig.
Ach und unter Linux ist das ein Problem?
Unter Linux habe ich das so noch nie gemacht, allerdings habe ich noch nicht verstanden wozu etwas gemounted werden muss. Wenn es da its ist es da, wenn nicht dann nicht, basta.
gemountet wird auch unter Windows...
Das Multi-Boot war natürlich auf mich bezogen.
Dass die Hardwarehersteller nicht für 1000de Linux Versionen Treiber proggen ist wohl auch klar. Wieder so ein Fehler in meinen Augen dass es tatsächlich so viele Distries gibt.Natürlich fällt es einem leicht über ein System zu flamen, wenn man doch so offensichtlich keine Ahnung hat. Treiber sind nicht Distributionsabhängig... Aber vermutlich hast du das Konzept von Distributionen gar nicht verstanden...
-
Phoemuex schrieb:
Dann will man neue Software installieren (ist ja angeblich dank dem Paketsystem sehr einfach), die gesucht ist aber nicht dabei und sich die source zu installieren und mit ./configure und co zu installieren/ selbst zu kompilieren hat man keine Lust, also sucht man weiter, bis man rausfindet, dass man irgendwelche neuen Paketquellen registrieren muss, bis dann endlich mal alles funktioniert.
Wo es Ubuntu-Paketquellen hat gibt es normalerweise auch .deb - Installer oder?
Deine Windows-exe wird ja auch nicht von Windows-Update automatisch aktualisiert, da finde ich die möglichkeit Paketquellen hinzuzufügen sehr freundlich, gerade bei WINE ist das auch für jeden DAU verständlich beschrieben
-
vista schrieb:
mich stören unter linux solche kleinigkeiten wie z.b. dass es kein einheitliches 'clipboard' gibt.
Klar gibt es das. So ungefähr mindestens seit 20 Jahren...
rüdiger schrieb:
Aber ich will ja niemandem meine Meinung aufzwingen). Aber das schlimmste ist doch _für_ Windows zu entwickeln...
welche negativen erfahrungen hast du gemacht?
zB die genannten: DLLs, Unicode
Außerdem Skalierbarkeit und das schlimmste ist wohl die WinAPI (Wer denkt sich bitte eine derartig beschissene API aus? Sicher ist die POSIX-API nicht die tollste. Aber im Vergleich zur WinAPI...)
rüdiger schrieb:
(zB Windows aka das Betriebsysstem was DLLs nicht hinbekommt...
was heisst 'nicht hinbekommt'
Gut, als C-Programmierer fällt einem das sicher nicht so sehr auf. Aber für C++ sind DLLs im Prinzip unbrauchbar. Es gibt keine einheitliche ABI. Ganz gewöhnliche Sachen wie Speicherverwaltung und Exceptions gehen total in die Hose. Für Plugins sind DLLs auch nur eingeschränkt verwendbar, da man einer DLL keine globalen Symbole zur Verfügung stellen kann etc.
-
zB die genannten: DLLs, Unicode
Bist du dir auch ganz sicher hier nicht in der Vergangenheit zu leben?
MfG SideWinder
-
rüdiger schrieb:
vista schrieb:
mich stören unter linux solche kleinigkeiten wie z.b. dass es kein einheitliches 'clipboard' gibt.
Klar gibt es das. So ungefähr mindestens seit 20 Jahren...
dann scheinen viele linux-anwendungen das clipboard nicht oder auf ungewöhnliche art zu benutzen?
rüdiger schrieb:
rüdiger schrieb:
Aber ich will ja niemandem meine Meinung aufzwingen). Aber das schlimmste ist doch _für_ Windows zu entwickeln...
welche negativen erfahrungen hast du gemacht?
Außerdem Skalierbarkeit und das schlimmste ist wohl die WinAPI (Wer denkt sich bitte eine derartig beschissene API aus? Sicher ist die POSIX-API nicht die tollste. Aber im Vergleich zur WinAPI...)
ja, winapi ist recht unübersichtlich, aber es gibt eine übersichtliche dokumentation dafür. ich finde das macht es wieder wett.
rüdiger schrieb:
rüdiger schrieb:
(zB Windows aka das Betriebsysstem was DLLs nicht hinbekommt...
was heisst 'nicht hinbekommt'
...Aber für C++ sind DLLs im Prinzip unbrauchbar.
das kann ich nicht nachvollziehen
wenn dem so wäre, wer verursacht das problem? sind es die DLLs oder ist es C++?rüdiger schrieb:
Ganz gewöhnliche Sachen wie Speicherverwaltung und Exceptions gehen total in die Hose.
das stimmt nicht.
windows hat ein im betriebssystem integriertes exception handling und die speicherverwaltung funktioniert auch tadellos. alles davon lässt sich selbstverständlich in DLL's nutzen.rüdiger schrieb:
Für Plugins sind DLLs auch nur eingeschränkt verwendbar, da man einer DLL keine globalen Symbole zur Verfügung stellen kann etc.
auch das ist falsch.
du kannst in einer DLL globale objekte anlegen, die prozessweit gültigkeit haben, und solche, auf die systemweit zugegriffen werden kann (dafür wird automatisch shared memory benutzt, ohne dass man viel programmieren muss).
-
vista schrieb:
rüdiger schrieb:
vista schrieb:
mich stören unter linux solche kleinigkeiten wie z.b. dass es kein einheitliches 'clipboard' gibt.
Klar gibt es das. So ungefähr mindestens seit 20 Jahren...
dann scheinen viele linux-anwendungen das clipboard nicht oder auf ungewöhnliche art zu benutzen?
Nö. Bisher hatte ich damit auch noch nie ein Problem.
ja, winapi ist recht unübersichtlich, aber es gibt eine übersichtliche dokumentation dafür. ich finde das macht es wieder wett.
Aber es sind doch einige Teile der API einfach kaputt. So wie diese High-Performance-A/IO-API, bei der man keinen Timeout für Verbindungen angeben kann, so dass jemand einfach nur fleißig Verbindungen öffnen muss und der Server ist gedost etc. (Gut, das Problem ist jetzt sehr spezifisch. Windows für Server einzusetzen ist ja eh wahnsinnig)
[quote="rüdiger"]
das kann ich nicht nachvollziehen
wenn dem so wäre, wer verursacht das problem? sind es die DLLs oder ist es C++?Wenn man betrachtet, wie gut dynamische Libs unter Linux mit C++ klappen, müssen es wohl die DLLs sein.
rüdiger schrieb:
Ganz gewöhnliche Sachen wie Speicherverwaltung und Exceptions gehen total in die Hose.
das stimmt nicht.
windows hat ein im betriebssystem integriertes exception handling und die speicherverwaltung funktioniert auch tadellos. alles davon lässt sich selbstverständlich in DLL's nutzen.Kann sein, dass ich da nicht mehr up-to-date bin. Habe nur in Erinnerung, dass es Probleme gibt, wenn man Speicher in der Hauptanwendung anlegt und in der DLL freigibt bzw. andersrum.
auch das ist falsch.
du kannst in einer DLL globale objekte anlegen, die prozessweit gültigkeit haben, und solche, auf die systemweit zugegriffen werden kann (dafür wird automatisch shared memory benutzt, ohne dass man viel programmieren muss).Ich meine das andersrum: Die DLL greift auf die Symbole der Hauptanwendung zu.
-
rüdiger schrieb:
Aber es sind doch einige Teile der API einfach kaputt. So wie diese High-Performance-A/IO-API, bei der man keinen Timeout für Verbindungen angeben kann, so dass jemand einfach nur fleißig Verbindungen öffnen muss und der Server ist gedost etc.
man kann doch die anzahl der verbindungen begrenzen oder verbindungen nach einer bestimmten zeit abbrechen. dafür bietet windows einiges an möglichkeiten. wenn eine API sowas nicht von sich aus anbietet, muss man es eben selbst programmieren, das sollte kein hindernis sein.
rüdiger schrieb:
(Gut, das Problem ist jetzt sehr spezifisch. Windows für Server einzusetzen ist ja eh wahnsinnig)
manche tun es mit erfolg.
was stört dich daran?
vielleicht, dass windows-server eine grafische oberfläche haben, die man nicht abschalten kann?rüdiger schrieb:
das kann ich nicht nachvollziehen
wenn dem so wäre, wer verursacht das problem? sind es die DLLs oder ist es C++?Wenn man betrachtet, wie gut dynamische Libs unter Linux mit C++ klappen, müssen es wohl die DLLs sein.
windows-DLLs können beim laden C++ konstruktoren aufrufen und beim entladen die destruktoren. was fehlt dir?
rüdiger schrieb:
auch das ist falsch.
du kannst in einer DLL globale objekte anlegen, die prozessweit gültigkeit haben, und solche, auf die systemweit zugegriffen werden kann (dafür wird automatisch shared memory benutzt, ohne dass man viel programmieren muss).Ich meine das andersrum: Die DLL greift auf die Symbole der Hauptanwendung zu.
eine windows-DLL ist nach dem laden bestandteil des prozesses. der prozess kann auf jedes byte der DLL zugreifen und andersherum geht es auch völlig problemlos. ich nehme an, du hast dich nur nicht genügend mit dem thema auseinandergesetzt...