Kann ebenfalls nur zustimmen, nachdem ich innerhalb der letzten zwei Monate einige meiner Gentoo-Systeme auf FreeBSD migriert habe.
Das Einzige, was mich noch stört, ist das ständige cd'n innerhalb /usr/ports. Für KDE/QT gibt's ein schönes Frontend, was die Sache sehr erleichtert, aber leider habe ich nichts entsprechendes auf GTK-Basis gefunden - gibt es sowas nicht oder habe ich nur falsch gesucht? Sowas wie Porthole für Gentoo wäre mir sehr recht, dürfte im Notfall eigentlich auch nicht so schwer zu portieren sein, imho.
Von Daniel Seuffert am Fr, 20. April 2007 um 18:01 #
Hallo, hier im Schnelldurchlauf:
1. Es gibt eine ganze Reihe schöner Port-frontends für KDE/Qt, mir fallen zumindest 3 ein (desktopbsd-tools, kports und barry).
2. Wenn es unbedingt GTK-Basis sein muß: http://www.freshports.org/ports-mgmt/bpm/ Ich habe es noch nie benutzt, kann dazu also nichts aus eigener Erfahrung berichten.
3. Für eine Auswahl aller Ports-Managementtools: http://www.freshports.org/ports-mgmt/
4. Ob das vergleichbar zu Porthole ist weiß ich nicht, da ich es nicht kenne.
Hallo Daniel und erstmal danke für die kurze Übersicht :)
GTK muss es nicht unbedingt sein, nur sagt mir QT leider gar nicht zu - ausser bei Opera - insofern fallen die ganzen KDE-Sachen erstmal raus.
portsman scheint interessant zu sein, reine Shell-Applikation auf ncurses-Basis, was mir auch nicht ungelegen kommt. bpm und pbrowser hatte ich schon einmal getestet, allerdings waren diese ziemlich unstabil.
Infos zu Porthole finden sich hier -> http://porthole.sourceforge.net/ Portage stammt ja von den Ports ab und ist immer noch ziemlich ähnlich, insofern wäre wahrscheinlich nicht soviel Arbeit dran zu tun, mal schauen, was sich da machen lässt.
Von Daniel Seuffert am Fr, 20. April 2007 um 19:05 #
Hallo ph,
keine Ursache.
Wenn du es ncurses-basierend haben möchtest, dann fällt mir persönlich eigentlich nur http://www.freshports.org/ports-mgmt/pkgfe/ ein auf Anhieb. Das ist zumindest sehr ausgereift, vom Leistungsumfang her fehlen mir persönlich da ein paar Sachen, aber es taugt imho für Leute, die nicht (nur) mit portupgrade und Co. arbeiten möchten.
Ich fände es sehr gut, wenn es mehr Auswahl geben würde auch in Richtung von etwas wie Porthole. Aber ob dies so einfach zu portieren ist wage ich doch zu bezweifeln, weil ebuilds/Portage und Ports doch eine ziemlich unterschiedliche Sache sind. Aber das kannst du nur genau wissen, wenn du dich daran versuchst. Ich kann dazu nur eines sagen: Go for it and have fun! :-)
Wenn man sowas wie BSD laufen hat, dann muss man nicht auch noch GTK Programme laufen lassen, wenn es nicht unbedingt sein muss. Ich glaube daran, dass gut designte Software sich am besten mit gut designter Software verträgt. Wenn man die Schmuddelkinder zulässt, dann kommt eben was anderes als BSD bei raus. Ist auch okay, aber wenn man BSD nutzt, will man das halt nicht.
Das stimmt natürlich. Jetzt, da GTK eine erträgliche Nutzerbasis und Akzeptanz erreicht hat, ist es natürlich wieder total schlecht (Millionen Fliegen können sich nicht irren). Schade, dass es nicht mehr das alternative Hacker-Toolkit ist, was gegen das vielbenutzte und gut dokumentierte (wirkt sich statussenkend aus) Qt positioniert wurde. Vielleicht ist es Zeit, ein neues und vor allem wieder elitäres Toolkit zu erschaffen, für das es weder Dokumentation noch Anwendungen gibt, um endlich wieder asketisch vor dem Gerät zu sitzen und rum zu basteln. Schön in Lisp programmieren und natürlich mit ircii im IRC unterwegs sein (BitchX wird ja viel zu viel benutzt). Vielleicht solltest Du auf Plan9 umsteigen, das ist wirklich toll designt und geizt mit verbreiteten Toolkits, deren alleinige Verwendung ja bereits auf die Skills des Programmautors schliessen lässt.
Beschäftige dich mal einwenig mit Softwaretechnik (nicht "Programmieren"). Das was die meisten "Entwickler" zu hause an ihrem Computer abliefern hat nichts, aber rein gar nichts mit professionellen Software Engineering zu tun. Man schaue sich nur mal auf Freshmeat oder Sourceforge um, 95% absoluter Müll. Mir ist ein sauber entwickelt System um einiges lieber als dieses Release-Pushing, Entwicklungszyklen von 6 Monaten sind einfach lächerlich. Wer aus heutige Sicht Applikationen die nicht hardwarenah oder höchstperformant sind, auf Basis von C und einem nicht originären objektorientierten Werkzeug, sondern mit Hilfswerkzeugen aus der GLib entwickelt kann ich nicht wirklich ernst nehmen. Als Fundament auf eine prozedurale Hochsprache, anstatt auf ObjektOrientierung oder gar komponentenbasierter Systeme zu setzen ist nicht nachvollziehbar. Würde Java seinen Kompatibilitätsballast abwerfen dann wäre es das Werkzeug erster Wahl.
Schon klar - ich wollte ja nur den Vorredner etwas aufgreifen. Ich bin selber Softwareentwickler und kenne die aus professioneller Sicht nicht nachvollziehbaren Entscheidungen (etwa ieee80211: Jetzt haben wir genügend funktionierende Treiber, die zwar Workarounds benötigen, aber funktionieren. Es ist also Zeit, das Dingen wieder aus dem Kernel zu entfernen, sich was völlig neues auszudenken und das natürlich ohne Kompabilitätshindernisse zur alten API). Allerdings sollte man C nicht per se verteufeln, wenn es um GUI geht - wie es läuft, zeigt Apple mit Objective C
"What is professionalism, anyway? I suppose everybody has his own definition, and maybe the choice of word isn't so good. I'd like to think that a professional approaches his work from a more global perspective, from the standpoint of the project rather than from his personal standpoint. This includes accepting or even making decisions which go against his personal convictions. By this definition, free software is not very professional. People write software to scratch their own itch. When updating software, they don't care much about maintaining compatibility, and frequently features disappear, not because nobody wants them, but because no developer wants them. The standard solution for this problem is for somebody who wants a feature to pay a developer to maintain it."
Das sprach Unix Guru Greg Lehey. Worthülsen schaffen keinen Profi und wer das von sich selbst behauptet hat eigentlich in der qualitativen Zunft nichts zu suchen, weil er nicht mehr lernen möchte. Die Arroganz hemmt da schon gewaltig.
Von Hans-Joachim Daniels am So, 22. April 2007 um 20:15 #
Hm, was soll ich da sagen? In der Firma haben wir einen ungefähr viermonatlichen Releasezyklus und unseren Makroaufsatz auf COBOL eine Hochsprache zu nennen wäre auch übertrieben. Und trotzdem sind wir über 100 Mitarbeiter und wachsen weiter.
Releasezyklen hängen von Projekt ab. Hier gings es um GTK, also einem Framework, das als Fundament für viele andere Projekte dienen muss. Hier ist die Architektur und das Design von entscheidender Wichtigkeit, daher sollte die Entwicklungszeit entsprechend lang sein. Statt die Entwicklung auf moderne Technologien zu lenken, setzt man auf ein altes Pferd, während MS mit C# und .NET erstarken und viele $ in FuE dafür stecken.
Auf BSD sollte man überhaupt keine grafischen Sachen laufen lassen, da in der Regel zu buggy. Ich hab lange bei dem wohl größten FreeBSD Nutzer "Y" gearbeitet. Ich hatte nie nen richtig stabilen Desktop (KDE) und hab mehrere FreeBSD Releases hintermir. Wenn ich das mit z.B. KDE auf Gentoo Vergleiche sind da Welten dazwischen. Ich muss aber auch sagen, dass sie im normal Betrieb, nur als Server ohne GUI, bombenstabil liefen. Ich hatte mehrere DB/Web Server die Uptimes von 600 Tagen und mehr hatten.
Sorry, Vertipper in meinem post. Ich meinte 600 Tage uptime für einen BSD-Server sind ja wohl vollkommen normal und unter 1.00 Tagen erwähnt man das gar nicht erst.
Doch! Das ich mich auch anschließe.
http://de.wikipedia.org/wiki/Die_Bremer_Stadtmusikanten
Das Einzige, was mich noch stört, ist das ständige cd'n innerhalb /usr/ports. Für KDE/QT gibt's ein schönes Frontend, was die Sache sehr erleichtert, aber leider habe ich nichts entsprechendes auf GTK-Basis gefunden - gibt es sowas nicht oder habe ich nur falsch gesucht? Sowas wie Porthole für Gentoo wäre mir sehr recht, dürfte im Notfall eigentlich auch nicht so schwer zu portieren sein, imho.
cheers,
ph
1. Es gibt eine ganze Reihe schöner Port-frontends für KDE/Qt, mir fallen zumindest 3 ein (desktopbsd-tools, kports und barry).
2. Wenn es unbedingt GTK-Basis sein muß: http://www.freshports.org/ports-mgmt/bpm/
Ich habe es noch nie benutzt, kann dazu also nichts aus eigener Erfahrung berichten.
3. Für eine Auswahl aller Ports-Managementtools: http://www.freshports.org/ports-mgmt/
4. Ob das vergleichbar zu Porthole ist weiß ich nicht, da ich es nicht kenne.
HTH, Daniel
GTK muss es nicht unbedingt sein, nur sagt mir QT leider gar nicht zu - ausser bei Opera
- insofern fallen die ganzen KDE-Sachen erstmal raus.
portsman scheint interessant zu sein, reine Shell-Applikation auf ncurses-Basis, was mir auch nicht ungelegen kommt. bpm und pbrowser hatte ich schon einmal getestet, allerdings waren diese ziemlich unstabil.
Infos zu Porthole finden sich hier -> http://porthole.sourceforge.net/
Portage stammt ja von den Ports ab und ist immer noch ziemlich ähnlich, insofern wäre wahrscheinlich nicht soviel Arbeit dran zu tun, mal schauen, was sich da machen lässt.
thx nochmal,
ph
keine Ursache.
Wenn du es ncurses-basierend haben möchtest, dann fällt mir persönlich eigentlich nur
http://www.freshports.org/ports-mgmt/pkgfe/ ein auf Anhieb. Das ist zumindest sehr
ausgereift, vom Leistungsumfang her fehlen mir persönlich da ein paar Sachen, aber
es taugt imho für Leute, die nicht (nur) mit portupgrade und Co. arbeiten möchten.
Ich fände es sehr gut, wenn es mehr Auswahl geben würde auch in Richtung von etwas
wie Porthole. Aber ob dies so einfach zu portieren ist wage ich doch zu bezweifeln,
weil ebuilds/Portage und Ports doch eine ziemlich unterschiedliche Sache sind.
Aber das kannst du nur genau wissen, wenn du dich daran versuchst. Ich kann dazu
nur eines sagen: Go for it and have fun! :-)
Grüße, Daniel
Vielleicht ist es Zeit, ein neues und vor allem wieder elitäres Toolkit zu erschaffen, für das es weder Dokumentation noch Anwendungen gibt, um endlich wieder asketisch vor dem Gerät zu sitzen und rum zu basteln.
Schön in Lisp programmieren und natürlich mit ircii im IRC unterwegs sein (BitchX wird ja viel zu viel benutzt).
Vielleicht solltest Du auf Plan9 umsteigen, das ist wirklich toll designt und geizt mit verbreiteten Toolkits, deren alleinige Verwendung ja bereits auf die Skills des Programmautors schliessen lässt.
Mir ist ein sauber entwickelt System um einiges lieber als dieses Release-Pushing, Entwicklungszyklen von 6 Monaten sind einfach lächerlich. Wer aus heutige Sicht Applikationen die nicht hardwarenah oder höchstperformant sind, auf Basis von C und einem nicht originären objektorientierten Werkzeug, sondern mit Hilfswerkzeugen aus der GLib entwickelt kann ich nicht wirklich ernst nehmen.
Als Fundament auf eine prozedurale Hochsprache, anstatt auf ObjektOrientierung oder gar komponentenbasierter Systeme zu setzen ist nicht nachvollziehbar.
Würde Java seinen Kompatibilitätsballast abwerfen dann wäre es das Werkzeug erster Wahl.
"What is professionalism, anyway? I suppose everybody has his own definition, and maybe the choice of word isn't so good. I'd like to think that a professional approaches his work from a more global perspective, from the standpoint of the project rather than from his personal standpoint. This includes accepting or even making decisions which go against his personal convictions. By this definition, free software is not very professional. People write software to scratch their own itch. When updating software, they don't care much about maintaining compatibility, and frequently features disappear, not because nobody wants them, but because no developer wants them. The standard solution for this problem is for somebody who wants a feature to pay a developer to maintain it."
Das sprach Unix Guru Greg Lehey. Worthülsen schaffen keinen Profi und wer das von sich selbst behauptet hat eigentlich in der qualitativen Zunft nichts zu suchen, weil er nicht mehr lernen möchte. Die Arroganz hemmt da schon gewaltig.
Statt die Entwicklung auf moderne Technologien zu lenken, setzt man auf ein altes Pferd, während MS mit C# und .NET erstarken und viele $ in FuE dafür stecken.
Ich hab lange bei dem wohl größten FreeBSD Nutzer "Y" gearbeitet.
Ich hatte nie nen richtig stabilen Desktop (KDE) und hab mehrere FreeBSD Releases hintermir.
Wenn ich das mit z.B. KDE auf Gentoo Vergleiche sind da Welten dazwischen. Ich muss aber auch sagen, dass sie im normal Betrieb, nur als Server ohne GUI, bombenstabil liefen. Ich hatte mehrere DB/Web Server die Uptimes von 600 Tagen und mehr hatten.