Ich friere gerade den Stand ein in eine vm. Und dann erstmal Pause.

Wechsel doch einfach zu irgendeiner Linux-Distro, da bekommst du dein AppImage, samt Flatpack/Snap und allen anderen überflüssigen Kram genauso gratis dazu, wie du gratis ein FreeBSD bekommst, über welches du ständig meckerst, dass dir dies oder jenes fehlt. Ganz im Ernst?
Ja ganz im Ernst. Während manche wie @pit234a sich das eine wünschen, hätte ich mir halt das andere gewünscht. Wäre FreeBSD von Anfang an Apples Weg gefolgt (App Ordner, der alles enthält und als App deklariert wird) hätte es damals schon einen positiven Vorteil gegenüber Linux.

„Wechsel halt zu Linux…“ ja, bin schon längst zu Apple gewechselt.

Mir könnte das alles hier am A… vorbei gehen aber da ich halt nix bewirken kann (zeitlich und zT fachlich) poste ich hier ab und an provokatives, in der naiven Hoffnung, wenigstens damit jm einen Schubs zu geben.

Edit: meine „Beschwerden“ waren sehr lieb gemeint weil ich FreeBSD an sich lieber mag als Linux und weil ich nicht möchte (!) dass es bedeutungslos wird!!!

Und ich bin froh über jeder OSS Alternative, denn ohne die würden uns Microsoft (was sie jedoch gefühlt tun) und Apple an der Nase rumtanzen.
 
Kommt bitte mal zum Thema zurück. Hier geht es um @Clas NetBSD-Experimente (im positiven Sinne, mir fällt nur gerade kein anderes Wort ein) und nicht zum x-ten Mal um den seit 31 Jahren beliebten Klassiker "FreeBSD stirbt".
 
Wenn es Dir wirklich wichtig wäre, würdest Du versuchen was zu organisieren. Du würdest mal die entsprechenden Leute anschreiben. Würdest evtl. sogar Deine Hilfe anbieten (im Rahmen Deiner Möglichkeiten; kann ja auch so was wie Tester oder Doku-Schreiber sein).
Guter Punkt. Manchmal wünsche ich mir, ich könnte hier und da mal etwas beitragen, so etwas wie eine GUI für Bluetooth ist ja wirklich ein sehr spezieller Wunsch, den wirklich nicht jeder braucht und von daher ist es auch verständlich, dass es bisher keiner gemacht hat und lediglich irgendwo unter "Nice to have" aufgelistet ist. Mal so allgemein gefragt: Wie programmiert man denn eine kleinere GUI für irgendwelche CLI-Funktionen? Was muss man dafür können? C++? Oder fängt man mit GTK bzw. QT an? Gibt es vielleicht irgendein Einsteiger-Tutorial zum Thema?

Kommt bitte mal zum Thema zurück. Hier geht es um @Clas NetBSD-Experimente (im positiven Sinne, mir fällt nur gerade kein anderes Wort ein)
Um zumindest eine Verbindung zum ursprünglichen Thema wiederherzustellen: Vielleicht lässt sich @Clas mal für FreeBSD begeistern und kommt schnell zum Schluss, dass er damit seine Desktopwünsche erfüllen kann? Und dann anfangen, irgendwelche GUIs / Tools zu programmieren, die dann in die Ports kommen...?:D
 
Um zumindest eine Verbindung zum ursprünglichen Thema wiederherzustellen: Vielleicht lässt sich @Clas mal für FreeBSD begeistern und kommt schnell zum Schluss, dass er damit seine Desktopwünsche erfüllen kann? Und dann anfangen, irgendwelche GUIs / Tools zu programmieren, die dann in die Ports kommen...?:D

Ja, ich würde das gerne. Aber leider ist meine Zeit begrenzt, mein Job und halt noch 5 private größere Softwareprojekte wollen erledigt, gewartet und weiterentwickelt werden. Wenns gut läuft dann muss ich noch mind. 17/18 Jahre arbeiten bevor hoffentlich (noch) eine
Rente winkt. Das fühlt sich echt komisch an wenn man das so hinschreibt. Aber was solls, ich bin halt 49 Jahre alt. Kann man ja nichts
dran ändern. :) Und man muss halt sehen wo man bleibt und sollte möglichst irgendwelche Dauernachtschichten unterlassen. Ich wünsche mir für alle BSDs eine gute Zukunft mit hoffentlich mehr jungen Leuten die bei den BSDs in Zukunft mitmachen.

Ich versuche z.B. bei meinen Nichten und Neffen immer mal wieder Werbung dafür zu machen z.B. bei solchen Projekten wie FreeBSD mitzumachen oder sich generell mehr mit Technik usw. auseinander zu setzen. Ohne Erfolg leider. Dort gibt es Berufswünsche, man fällt
vom Glauben ab. ich sagen nur "Influencer" z.B. durch Weltgeschichte fliegen und von einen Strand zum nächsten zu hoppen, ein paar Fotos hochladen und dafür ein riesiges Einkommen erzielen und ansonsten Party machen. Ich weiß ich schweife ab. Aber wir leben echt in ein verkehrten bzw. auf den Kopf stehenden Welt.

So und wo ich gerade von Nachtschichten geschrieben habe. Es ist 00:13 morgens und ich muss auch dringend ins Bett.
Aber bevor ich in die Falle steige. Mich würde echte eine soziologische Erhebung der Menschen interessieren die hier bei den
BSDForen so mitmachen und aktiv sind. Insbesondere das Alter. Durchschnittsalter usw. Na ja, ich vermute mal eher an oder
über 40 und nicht so an die 25.

Viele Grüße,

Clas
 
ich sagen nur "Influencer" z.B. durch Weltgeschichte fliegen und von einen Strand zum nächsten zu hoppen, ein paar Fotos hochladen und dafür ein riesiges Einkommen erzielen und ansonsten Party machen
Ja leider normal. Höre ich mir immer wieder von verschiedenen Leuten an.

Ein sehr junger Praktikant war voll auf Linux und konnte den BSDs wenig abgewinnen, eine junge Studentin nutzte Solaris. Bis heute niemanden persönlich kennengelernt, der BSD nutzt oder schätzt.
Vielleicht lässt sich @Clas mal für FreeBSD begeistern und kommt schnell zum Schluss, dass er damit seine Desktopwünsche erfüllen kann? Und dann anfangen, irgendwelche GUIs / Tools zu programmieren, die dann in die Ports kommen...?
Das hattest du doch schon vormals geschrieben und ich ähnliches (>GhostBSD).
Aber leider ist meine Zeit begrenzt,
Das ist es eben! Irgendwann ist man nicht mehr 13 und hat noch alles vor sich.
Irgendwann merkt man, wie wertvoll Zeit ist!
Irgendwann ist die Zeit zu wertvoll, um Emergie zu verschwenden, einen funktionellen Desktop zu basteln, wo es genug Alternativen gibt und - sorry - scheiss drauf ob drunter n Linux/BSD/Systemd oder weiß der Geier was läuft, Hauptsache es funktioniert.
Das Wort zum Wochenendstart.

Ein schönes WE
 
So und wo ich gerade von Nachtschichten geschrieben habe. Es ist 00:13 morgens und ich muss auch dringend ins Bett.
Dann hoffe ich mal, du hast gut gepennt. :)
Mich würde echte eine soziologische Erhebung der Menschen interessieren die hier bei den
BSDForen so mitmachen und aktiv sind. Insbesondere das Alter. Durchschnittsalter usw. Na ja, ich vermute mal eher an oder
über 40 und nicht so an die 25.
Also, was mich betrifft, ich werde im September 45, wenn nichts Unvorhergesehenes dazwischen kommt. ;)
Ein sehr junger Praktikant war voll auf Linux und konnte den BSDs wenig abgewinnen, eine junge Studentin nutzte Solaris.
... welches seit 2018 nicht mehr weiterentwickelt wird, sofern ich nichts verpasst habe. ;)
Irgendwann ist man nicht mehr 13 und hat noch alles vor sich.
Irgendwann merkt man, wie wertvoll Zeit ist!
Irgendwann ist die Zeit zu wertvoll, um Emergie zu verschwenden, einen funktionellen Desktop zu basteln, wo es genug Alternativen gibt und - sorry - scheiss drauf ob drunter n Linux/BSD/Systemd oder weiß der Geier was läuft, Hauptsache es funktioniert.
Dem möchte ich hinzufügen, dass ein System, wenn es einmal fertig eingerichtet ist, doch einfach läuft. Man braucht nicht mehr viel machen und nimmt im Alltag kaum wahr, was für eine Systemsoftware letztendlich unter der Haube seine Arbeit verrichtet. Wenn mal irgendwo etwas schiefgeht (Upgrade, etc.) hat man unter FreeBSD das äußerst leistungsfähige ZFS mit seinen komfortablen Schnappschüssen, mit denen man mit nur wenigen Handgriffen auf den Stand vor dem Unglück zurückkehren kann. Paketabhängigkeiten werden selbstverständlich automatisch aufgelöst, an ausführlicher Dokumentation mangelt es ebenfalls nicht, mir persönlich genügt das (ja, ich weiß, dass dir das nicht genügt XD). Wie das unter NetBSD aussieht, weiß ich nicht (ich glaube sogar, dass es auch dort eine Unterstützung für ZFS gibt, kann mich aber auch irren), aber letztendlich gibt es die BSDs seit über 30 Jahren (wenn man es genaunimmt sogar seit 1977, also mehr als 45 Jahren XD) und ich denke, das will schon was heißen. ;)
 
Wie programmiert man denn eine kleinere GUI für irgendwelche CLI-Funktionen? Was muss man dafür können? C++? Oder fängt man mit GTK bzw. QT an? Gibt es vielleicht irgendein Einsteiger-Tutorial zum Thema?
Gehört zwar nicht zum Thread-Thema, aber ich antworte mal trotzdem und hoffe mit blauem Auge davon zu kommen. :-)

Üblicherweise sind ja Kommandozeilentools auch nur Frontends irgendwelcher Funktionen bzw. Softwarebibliotheken. Wenn man ein GUI-Tool schreibt, benutzt man dann die entsprechenden Bibliotheksfunktionen (APIs) direkt und geht üblicherweise nicht über die korrespondierenden Kommandozeilentools.
Das macht aus zwei Gründen Sinn. Erstens hat man halt nicht den Aufruf von Kommandozeilentools, was zeitraubend ist. Man muss auch nicht irgendwelche Ausgaben parsen (was fehleranfällig ist), sondern kriegt den Kram gleich in einem Format, mit dem sich besser weiter arbeiten lässt. Außerdem kriegt man meist mehr Informationen darüber, was dann z.B. auch spezielle Funktionen und Fehlerbehandlung erleichtert.

Aber es ist natürlich nicht verboten mit Hilfe der Kommandozeilentools entsprechende GUI-Tools zu schreiben. Du hast dort einfachen Text der sich auch überall und in jeder Programmiersprache verarbeiten lässt. Im Prinzip kannst Du auf dem Wege sogar GUIs via Shell-Skript erstellen.
Softwarebibliotheken sind dagegen häufig an bestimmte Programmiersprachen gebunden. Es gibt zwar teilweise Bridges (Bindings), die die auch für andere Programmiersprachen verfügbar machen. Aber das ist eben nicht immer und für die selbst benutzte Sprache so.
Über Kommandozeilentools zu gehen ist also irgendwo auch eine sehr niedrigschwellige Variante.

Dann braucht man, wie Du richtig bemerkst, natürlich ein GUI-Toolkit. Qt und Gtk sind sicher die Bekanntesten. Die haben auch Bindings zu allen möglichen Sprachen und man ist da nicht unbedingt auf C++ respektive C festgelegt. Eine weitere Möglichkeit ist wxWidgets. Dann gibts da natürlich noch andere Lösungen. , wie z.B. Tk welche zusammen mit der Programmiersprache Tcl eingesetzt wird und eine Zeitlang sehr beliebt für einfache GUIs war, da Tcl auch eine recht einfache Sprache ist. Daher auch recht beliebt war (ist?).

Womit wir schon mitten in der Thematik sind, welche Programmiersprache am besten eingesetzt wird. Die natürliche Wahl wäre C, da die entsprechenden Bluetooth-Bibliotheken/Kernel-APIs i.d.R. C sind und sich auch Gtk damit benutzen lässt. Allerdings ist C als Sprache nicht besonders Gelegenheitsprogrammiererfreundlich, ums mal vorsichtig auszudrücken. I.d.R. benutzt man dann doch häufig Skriptsprachen wie Python (auch unter Linux gehen Tools wie blueman diesen Weg). Da gibts auch viel Krams zu, womit man sich zu allem möglichen connecten kann. Und falls man doch mal nicht weiter kommt, gibts ne C-Schnittstelle wo man sich dann auch an benötigte C-Bibliotheken ranhängen kann.

Ein Einsteiger-Tutorial im Sinne von "Wie bau ich eine Bluetooth-GUI" wirds vielleicht nicht geben, aber natürliuch zu den jeweiligen Teilaspekten.
Vermutlich macht es ja auch Sinn "from scratch" etwas Neues zu schreiben, sondern etwas Vorhandenes (wie blueman oder was es sonst noch gibt) zu nehmen und für FreeBSD anzupassen.
 
Über Kommandozeilentools zu gehen ist also irgendwo auch eine sehr niedrigschwellige Variante.
Was mir dazu noch eingefallen ist:

Das Output-Parsing-Problem wird teilweise dadurch abgemildert, in dem Kommandozeilen-Tools auch manchmal Ausgabemöglichkeiten jenseits von human-readable-text anbieten. Für die FreeBSD-Tools hat sich da libxo als Variante etabliert. Allerdings findet man diese Möglichkeit längst nicht in allen Tools.

Was die GUI angeht, so gibts z.B. zenity als eine mögliche Lösung. Die verwenden im Backend Gtk3 bzw. irgendwelche GNOME-Libs. In der Manpage von zenity stehen auch ein paar Beispiele, wie man das benutzen kann. Aber beste Info-Quelle ist natürlich deren Handbuch (https://help.gnome.org/users/zenity/stable/).

Und so kann man sich dann auch mit Shell-Scripten einfache GUIs bauen. Hier mal ein simples Beispiel, in dem man die Ausgabe von zfs list hernimmt, um daraus eine grafische Tabelle zu machen:
Bash:
datasets=( `zfs list |grep -v NAME |awk '{print $1}'` )
freespaces=( `zfs list |grep -v AVAIL |awk '{print $3}'` )

for (( i=0; i<${#datasets[*]}; ++i)); do
    dataarray+=( "${datasets[$i]}" "${freespaces[$i]}" )
done

zenity --list --column=Dataset --column=Verfügbar --height 400 --width 600 "${dataarray[@]}"
 
Gehört zwar nicht zum Thread-Thema, aber ich antworte mal trotzdem und hoffe mit blauem Auge davon zu kommen. :-)
metoo
in einem alten KDE gab es dazu mal eine GUI zum Erstellen von GUIs. Habe ich selbst nie genutzt und weiß deshalb kaum etwas darüber. Es war etwa so, dass man ein Fenster zeichnen konnte und darin Abfragen und Schaltflächen verteilen und anschließend irgendwelchen Aktionen zuweisen. Alle Funktionen mussten dann natürlich vorhanden, also erreichbar und ausführbar sein. Wie gesagt, nie benutzt.
Aber vielleicht gibt es ja heute noch so etwas oder sogar etwas sehr viel besseres?

Es ist allerdings ein großer Unterschied, ob ich für mich selbst irgendeine Eingabe vereinfachen und in einer GUI unterbringen will, oder ob ich ein so komplexes Thema wie BT-Konfiguration mit allen möglichen Abfragen und Tests hinbekommen möchte. Kurz gesagt, wenn so eine GUI keinen Unsinn machen und Kugelsicher sein soll, muss man schon ganz schön tief in einer Sache drin sein, um an alle Möglichkeiten zu denken. Also nicht nur im Sinne von möglichem Code, sondern auch hinsichtlich aller technischen Aspekte.

Man verzeihe mir hoffentlich, wenn ich dazu auch noch ein unzulängliches Beispiel anführe.
In meinem alten KFZ baute ich vor einigen Jahren ein neues Radio ein, ein extrem billiges Gerät, das aber Musik von einer SD-Card spielen kann und damit auch schon allen meinen Anforderungen genügt. Unlängst klingelte das Ding plötzlich, als ich an einer Tankstelle war. Vollkommen verunsichert hielt ich zunächst an. Weil ich aber nicht wusste, wie ich den eingehenden Anruf auch annehmen könnte, fuhr ich dann schnell weiter. Denn was passiert war, ist recht eindeutig. Das Radio hat einen offenen BT-Zugang (den ich nie benutzt habe und deshalb auch ignorierte) und da hatte sich das Mobiltelefon eines anderen, vollkommen fremden Menschen verbunden, der eben zufällig innerhalb der Reichweite war.
Ich sage mal, so etwas sollte eigentlich nicht passieren, ist aber vollkommen Konstruktionsbedingt.
Das Radio hat natürlich keine BT-GUI!
Aber damit fängt der Spaß ja an, wenn man eine GUI für ein BT-Gerät im PC schreiben möchte. Das soll ja dann irgendwie sicher sein und das bedeutet, dass ich auch nicht mit einem zufälligerweise offenen Kanal eines Radios verbinden möchte und so weiter.
Ich hoffe, man versteht mich.
Die Komplexität liegt hier meines Erachtens nicht in den schlecht bedienbaren Kommando-Zeilen-Tools, sondern im Thema selbst und das bedeutet dann leider, dass eine GUI dem gerecht werden muss (sollte) und die kann dann nicht ganz so einfach ausfallen, wenn alle möglichen Fälle berücksichtigt werden sollen.
 
Nutzt einfach OpenBSD :D

(Da gibts einfach kein Blauzahn!)

((Ich finde das ist nicht ganz unwichtig ... aber wenn man ehrlich ist, wenn man FreeBSD als Desktop nutzt wird man etwas CLI begeistert sein, also DAS ist vermutlich nicht der hindernissgrund))
 
Ich kenne nur den Qt Creator. Ist aber C++
Für Gtk gibts/gabs(?) Glade.
Auf Qt Creator war ich auch gestoßen, da ich aber MATE und soweit möglich lieber Gtk-Anwendungen nutze, ist Glade wohl eines der Schlagworte, die mir einen Ansatz ermöglichen, um mich mal ein bißchen mit dem Thema zu beschäftigen. Vielen Dank auch für die ausführlichen Ausführungen zum Thema allgemein. Mir war klar, dass das natürlich nicht einfach ist.
Einen Rückschluss kann ich zumindest schon mal ziehen: Python ist wohl nicht so empfehlenswert als GUI, denn offensichtlich können da einige GUI's bei einer Weiterentwicklung von Phython wohl auf der Strecke bleiben, wie z.B. hier:


Dann noch mal eine allgemeine Frage: Offenbar geht die Tendenz in der Softwareentwicklung dahin, dass alles im Webbrowser läuft, damit die Anwender im alltäglichen Gebrauch, die oftmals nicht am Schreibtisch sitzen, sondern mit einem Tablet unterwegs sind, alles eben auf einem Touchscreen erledigen können. Also in diesem Sinne gar keine GUI's mehr. Darüber hinaus erzählte mir ein Chefprogrammierer eines solchen Projekts auch noch, "HTML verwende dafür kein Mensch mehr, sondern nur noch Angular". Also wenn ich das dann richtig verstehe, Angular für das Frontend und node.js oder React für das Backend. Bei solchen Sachen steige ich dann gar nicht mehr durch...
 
Python ist wohl nicht so empfehlenswert als GUI, denn offensichtlich können da einige GUI's bei einer Weiterentwicklung von Phython wohl auf der Strecke bleiben
Das kann passieren. Aber das Problem, also das bestimmte Bibliotheken oder Frameworks nicht mehr richtig weiterentwickelt/gepflegt werden, hast Du ja immer. Da muss man vorher gucken wie etabliert das jeweilige Framework ist, um die Wahrscheinlichkeit das so ein Fall eintritt zu minimieren.
Ich denk mal, sowas wie Gtk wird nicht so schnell weggehen. Auch Bindings von Gtk zu Python wirds immer irgendwie geben.

Bei zenmap war ja auch nicht das primäre Problem, das es kein Gtk mehr gab, sondern das die noch auf Gtk2 gebaut haben und das out-of-support ist. Aber auch das ist ein Problem, mit dem Du immer irgendwie konfrontiert sein wirst.

Offenbar geht die Tendenz in der Softwareentwicklung dahin, dass alles im Webbrowser läuft,
Ja. Da ist was dran. Wobei die klassischen GUI-Toolkits vorerst auch nicht verschwinden werden. Die reagieren teilweise auch darauf. So gibts zum Beispiel für Gtk auch unterschiedliche Backends. Also neben X11 und Wayland, gibts auch broadway. Damit kann man sein Gtk-Programm im Browser laufen lassen.

"HTML verwende dafür kein Mensch mehr, sondern nur noch Angular". Also wenn ich das dann richtig verstehe, Angular für das Frontend und node.js oder React für das Backend. Bei solchen Sachen steige ich dann gar nicht mehr durch...
Also ja. Händisch schreiben tut das nötige HTML, CSS und Javascript dann keiner mehr. Das übernehmen die Frameworks. Die Architektur ist dann grob so, das man einen lokalen Webserver hat (den Part übernimmt dann sowas wie node.js). Da ist dann auch die eigentliche Logik des Programms drin. Dann hat man eine häufig eine embedded Browser Komponente (um nicht auf den installierten Webbrowser angewiesen zu sein) und darin lässt man dann die Javascript-Frameworks laufen, die dann die eigene Applikation darstellen.

Aber was war jetzt noch mal Deine Frage dazu? :-)
 
wenn ich mir die Entwicklung über die Jahre vor Augen halte, die ich nicht intensiv verfolgte, aber als Nutzer von FreeBSD doch nebenbei ein wenig mitbekommen habe, dann wohl eher nicht. Es gibt anscheinend nicht genug Anhänger von NetBSD für tägliche Arbeit, wenn diese in Richtung Desktop geht.

NetBSD ist meines Erachtens nach sogar das BSD, welches am wenigsten geeignet scheint, diesen Weg zu gehen und deshalb frage ich mich auch schon länger, warum du gerade so fixiert darauf bist. Ich vermute mal, dass du mit OpenBSD weiter gekommen wärst und wahrscheinlich viel weiter mit FreeBSD. Mein geheimer Liebling DragonFly-BSD geht zwar immer wieder recht verwinkelte Wege und ich habe im Laufe der Zeit den Eindruck, dass es eher ewig experimentell bleiben wird, als in Richtung Desktop-System jemals "fertig" zu werden, aber selbst damit hättest du wahrscheinlich weiter kommen können, als mit NetBSD. Gerade hier, also bei DF-BSD, wäre vielleicht ein Entwickler-Input auch sinnvoller. Vielleicht schaust du es dir ja zu gegebener Zeit mal an.


Ja für Desktop FreeBSD oder OpenBSD

Aber bei NetBSD für den Desktop ?, Was kann das besser als Free oder Open ?

Ich sehe keine Vorteile bei NetBSD für zB. x86/x64er PCs
 
Also was mir spontan so einfällt, wozu NetBSD nützlich sein könnte, wenn man kein Linux oder FreeBSD will: Ein mpd oder minidlna Server auf einem Raspberry Pi 3 (oder vielleicht auch darunter), der per Audiokabel an die Stereoanlage angeschlossen ist und der von einem Client auf dem Mobiltelefon gesteuert werden kann. Denn NetBSD 10 unterstützt im Gegensatz zu FreeBSD das Wifi- und das Audiomodul auf dem Raspberry.
 
Also alle BSDs sind für den Serverbetrieb gut bis sehr gut geeignet. Aber mir geht es halt um den Desktop. Und aktuell das größte Problem bleibt/ist gerade Chromium basierter Browser womit man halt auch alles machen wenn man in Teams,Zoom,Skype drin ist wie Desktopsharing usw. Man kann versuchen das mit FireFox und UserAgent hinzubekommen. Aber ist halt immer so eine Sache ob es dann funktioniert. Windows wird aus meiner Sicht irgendwann weg sein und dann drängt sich noch mehr und alles in den LinuxKernel. Von daher sind Alternativen wichtig in der Zukunft. Und wenn man NetBSD z.B. so einfach installieren kann/könnte wie Linux Mint. Dann würde das vielleicht auch noch mehr Leute dahin bringen sich für NetBSD zu interessieren. Wenn ich solche Repos finde dann macht mir das doch Hoffnung:


Ich bin gespannt wie es weitergeht bei NetBSD. Mit vernünftigen Browsersupport. Auch an der Performance muss man noch einiges machen um in wirklich akzeptablen Bereich zu kommen. Verglichen mit Linux. Und XFS, NTFS, EXT4 usw. sollten direkt unterstützt werden. Mit sofort man ich habe einen USB-Stick er mit NTFS formatiert wurde und dann direkt lesen können ohne Gefrickel usw. Ich denke dafür müsste sich
die Entwicklungsmannschaft von NetBSD massiv vergrößern. Ich hoffe sehr dass das irgendwann auch passiert.
 
Der Hinweis mit dem Desktop-Installer ist interessant, kannte ich noch nicht. Darin enthalten auch ein Hinweis auf qmediamanager, wohl aber nur für FreeBSD, wenn ich das richtig verstehe? Aber in Anbetracht von bsdisks, welches mit den wichtigsten DE's installiert wird oder auch dsbmc, wohl für FreeBSD nicht wirklich nötig. Für NetBSD wäre das natürlich toll, da man dort m.E. externe Medien nur manuell mounten kann.

Bezüglich Chrome habe ich das hier gefunden, scheint es also doch für NetBSD zu geben?


Wenn ich mir allerdings den TODO Link angucke, dann geht Sound in Chromium wohl nur mit Pulseaudio?
 
Zurück
Oben