FreeBSD auf dem Desktop - neue Fassungen

  • Ersteller Ersteller holgerw
  • Erstellt am Erstellt am
@CrimsonKing danke für den Link zu der Editor-Übersicht. Wieder was gelernt ...

Und ich sehe gerade: ed, ee, ex und vi liegen alle in /usr/bin, werden also mit dem FreeBSD Basis-System installiert. Finde ich nett von den Entwicklern, hier den Nutzern schon soviel Auswahl zu geben.
 
In /rescue gibt es aber den ee nicht. Also auf singleusermode zurückfallen und dann mit /rescue Mitteln editieren, etwa bei verschlüsseltem System. da kommt man dann an den ee nicht ran.
Ich kenne mich da aus, mit ee Nutzer-Outing. :ugly: Aber ich habe einen vi Kaffeepot, zwar mit Pinguin drauf, aber da ist das Wichtigste für den vi zusammengefasst. Den Kaffee dazu kann man dann ja meist auch gut gebrauchen. :cool:

:wq!
 
Fusselbär schrieb:
Ich kenne mich da aus, mit ee Nutzer-Outing. :ugly: Aber ich habe einen vi Kaffeepot, zwar mit Pinguin drauf, aber da ist das Wichtigste für den vi zusammengefasst. Den Kaffee dazu kann man dann ja meist auch gut gebrauchen.
Zum Vergrößern anklicken....
Oh ja, den habe ich auch mal geschenkt bekommen und ich bin begeisterter Kaffeetrinker :)

Na dann bin ich ja bald vi-Experte :D
 
Man braucht nur 10 Tasten, um mit vi einigermaßen klarzukommen:

Code: 
<Esc> : q ! e m a c s <Enter>

:)
 
Editor-Diskussionen sich fruchtlos, gerade vi gegen Emacs. Also zurück zum Thema. :)
 
Mit einer guten .vimrc ( das Internet ist voll von Beispielen ) und etwas Basiswissen zu
den regular expressions, was ja im Unix-Umfeld zu den selbstverständlichen Basics gehören dürfte und etwas Gewöhnung an die Umschaltung der Modi, hauptsächlich zwischen Eingabe- und Befehlsmodus ist der vim einer der genialsten Editoren!

Edit: Sorry... ich wollte nicht Yamagis OT Ermahnung missachten - hatte ich erst nach dem Abschicken des Beitrages gesehen
 
Hier kommt das versprochene "Original", also die lyx-Datei samt dem Bilderordner, als Archiv. In diese Fassung sind die hier mit "erledigt" Korrekturen schon eingeflossen.

Eine neue PDF-Fassung lade ich erst wieder hoch, wenn einiges Neue dazu gekommen ist.
 

Anhänge

Hallo Holger,

ich habe mir heute morgen Deine excellente Dokumentation genau angeschaut. Sie ist sehr gelungen, auch was die Aufteilung und Gliederung betrifft. Danke dafür.

Dennoch sind mir ein paar kleinere Tippfehler aufgefallen, die der Korrektur bedürfen:

Zwischen Seite 2 und Seite 3 gibt es einen Stilbruch. Ab Seite 3 verwendest Du für mich aus nicht nachvollziehbaren Gründen eine größere Schriftart.

Seite 3

aber für Newbies kann das frustieren.....

besser für NewBies kann das frustrierend sein

Seite 6

Immer wenn ich etwas über XServer gelesen habe wurde die Schreibweise XServer bevorzugt.

Seite 14

sollte es heißen ... das US-Layout

Seite 15

besser Namensvergabe (Du schreibst ja in deutsch)

Seite 18

Tippfehler: geöändert in geändert ändern

Seite 19

derr in der ändern

Seite 25

berdeutet in bedeutet ändern

Pastches in Patches ändern

Seite 34

eignenen in eigenen ändern

Vorschlag:

Ein kleines überschaubares lexikalisches Stichwortverzeichnis für Fachausdrücke fände ich großartig, auch wenn das ein Mehr an Arbeit bedeutet.

Darin könnten dann Begriffe und Abkürzungen etwas genauer erklärt werden. Für Anfänger und Einsteiger wäre das sehr hilfreich.

Ansonsten haben mir gerade die Kapitel über die individuelle und manuelle Partitioninierung mittels ufs2 und zfs sehr gut gefallen, habe dafür extra meine ada1 platt gemacht, um das noch mals zu üben, weil ich damit ja vor einiger Zeit erfolgreich gescheitert war.;) Hat auch alles gut funktioniert. Gpart ist mir nun etwas vertrauter geworden.

Ich freu mich darauf, wenn das Buch fertig wird. Es wird eine wertvolle Hilfe und sinnvolle Ergänzung für das ofizielle Handbuch sein.:D

Selber werde ich mir wohl mal eine Doku für Minimalinstallation für verschiedene WM vorknöpfen, die ich dann auch der Community bei Interesse und Bedarf zur Verfügung stellen werde.

Leider gibt es auch einen Wermutstropfen in Lyx, es trennt nicht immer sauber.
 
~/.xinitrc
mit folgendem Inhalt angelegt:
Code: 
export LANG=de_DE.UTF-8
exec ck-launch-session startkde

Für diese Config würde ich etwas weiter ausholen, da sie einen extremen Stolperstein für Anfänger bereithält.

Aus der OpenBSD manpage von startx https://man.openbsd.org/startx
Code: 
xrdb -load $HOME/.Xresources
xsetroot -solid gray &
xbiff -geometry -430+5 &
oclock -geometry 75x75-0-0 &
xload -geometry -80-0 &
xterm -geometry +0+60 -ls &
xterm -geometry +0-100 &
xconsole -geometry -0+0 -fn 5x7 &
exec twm
Würde hier ein größeres Beispiel nutzen und anhand dessen erklären, wie weitere Programme exec werden und wo der exec der WM stehen sollte/muss. Ich bin mir sicher, dass diese Config nicht nur für mich einen Stolperstein dargestellt hat.
 
Hallo,

danke für die weiteren Anmerkungen. Die Fehler werde ich korrigieren und die .~/.xinitrc werde ich ausführlicher besprechen.
 
mogbo schrieb:
~/.xinitrc
mit folgendem Inhalt angelegt:
Code: 
export LANG=de_DE.UTF-8
exec ck-launch-session startkde

Für diese Config würde ich etwas weiter ausholen, da sie einen extremen Stolperstein für Anfänger bereithält.

Aus der OpenBSD manpage von startx https://man.openbsd.org/startx
Code: 
groess
xrdb -load $HOME/.Xresources
xsetroot -solid gray &
xbiff -geometry -430+5 &
oclock -geometry 75x75-0-0 &
xload -geometry -80-0 &
xterm -geometry +0+60 -ls &
xterm -geometry +0-100 &
xconsole -geometry -0+0 -fn 5x7 &
exec twm
.
Zum Vergrößern anklicken....

Nun ja, aber das ist dann doch wirklich ein Vorteil der DEs, weil man eben in der .xinitrc
keine XTerminals, Uhren etc. als Hintergrundprozesse vor dem WM starten bzwt. konfiguriert
starten muss.

Bezgl. xterm - ich hab lieber urxvt, aber das ist jetzt ja mal egal - ist es ja nicht damit getan,
die Fenstergroesse in Zeichen und Zeilen mittels dem -geometry-switch anzugeben.
Also fehlen dann noch ein paar Worte zur .Xdefaults, aber halt, die ist ja wohl schon 10 Jahre depricated also .Xresources
... aber so kommt dann halt "Eines zum Anderen"

Gruss walter
 
Vril schrieb:
Nun ja, aber das ist dann doch wirklich ein Vorteil der DEs, weil man eben in der .xinitrc
keine XTerminals, Uhren etc. als Hintergrundprozesse vor dem WM starten bzwt. konfiguriert
starten muss.

Bezgl. xterm - ich hab lieber urxvt, aber das ist jetzt ja mal egal - ist es ja nicht damit getan,
die Fenstergroesse in Zeichen und Zeilen mittels dem -geometry-switch anzugeben.
Also fehlen dann noch ein paar Worte zur .Xdefaults, aber halt, die ist ja wohl schon 10 Jahre depricated also .Xresources
... aber so kommt dann halt "Eines zum Anderen"
Zum Vergrößern anklicken....
Das war das Beispiel aus der manpage, stell dir halt vor da wäre eine conky-Zeile oder ähnliches
 
Hallo @Vril hallo @mogbo

in meinem Beispiel geht es um slim, mit dessen Hilfe ich plasma5 starte (wird wohl bald durch sddm ersetzt) und der braucht eine - wenn auch minimale - .xinitrc. Daher gehe ich an der Stelle nicht weiter auf die .xinitrc ein

Aber an anderer Stelle werde ich auf die .xinitrc mal detailierter eingehen, weil ich nun auch überlege, als minimalistische Alternative zu kde / mate / gnome / xfce mal eine Kombination von openbox und tint2 oder ähnlichem vorzustellen. @Vril das ist Deine Schuld :D Ich bin zwar nach wie vor nicht so ein Anhänger solcher Ansätze auf dem Desktop (aber es geht ja bei der Doku nicht darum, was mir besonders toll gefällt unter Ausschluss von Alternativen). In diesem Zusammenhang kommen mir übrigens auch einige Projekte von @marcel entgegen (dsbmd, dsbmc, dsbmixer), die sich ja zu unterschiedlichen DEs und minimalistischen XServer-Installationen neutral verhalten, und somit auch unter fluxbox oder openbox einigen Komfort bringen.
 
holgerw schrieb:
mal eine Kombination von openbox und tint2 oder ähnlichem
Zum Vergrößern anklicken....
ACHTUNG: hoher Suchtfaktor! Vielleicht möchtest du danach nie mehr wieder was von KDE wissen ;)
Sieh dir vielleicht das Ubuntu-Wiki zu Desktop an. Das ist ein guter Startpunkt und man sollte das nicht belächeln. Man kommt von selbst niemals auf alle möglichen Gedanken und Kombinationen und wir haben ja schon gesehen, dass jeder seine eigene Vorstellung von einem "perfekten" Desktop hat. Ein KDE ist regelrecht einfach: installier es, nimm es und gut. OpenBox (oder andere WM) brauchen mehr und bei jedem Mehr gibt es viele Möglichkeiten.
 
Hallo Holger,

ein solches Mammutprojekt allein zu wuppen, ist, wie ich aus eigener Erfahrung weiß, ziemlich anstrengend und zeitaufwendig.

Deshalb möchte ich mal einen Vorschlag unterbreiten, auch wenn der möglicherweise ein kleines Erdbeben auslösen wird.

Holger, kannst Du Dir vorstellen, Dein Projekt zu sozialisieren, zu vergesellschaften?

Kannst Du Dir vorstellen, das daraus ein Gemeinschaftsprojekt der Communitymitglieder wird?

Die Vorteile lägen auf der Hand. Wir haben hier eine Menge Profis, die aus Ihrem Spezialgebiet etwas beitragen könnten. Isoliertes Wissen sind verschwendete Resourcen. Besser wäre es, diese Kompetenzen in einem Projekt zu bündeln.

Spontan denke ich an juedan, der ja ein Kapitel über Festplattenverschlüsselung beisteuern könnte.

Selber würde ich mich einbringen und ein Kapitel über Minimalinstallationen unter der Verwendung verschiedener Windowmanger schreiben. Hiermit habe ich fundierte Kenntnisse und Erfahrungen, die ich gewinnbringend beisteuern könnte.

Wir haben ein sehr gutes FreeBSD Handbuch. Nicole deckt auch einen Großteil über FreeBSD auf dem Desktop ab. Warum das Rad immer wieder neu erfinden?

Ein gemeinschaftliches Projekt sollte anders sein und Wissenslücken stopfen, die es noch gibt.

Dem Leser sollte ein Grundlagenwissen präsentiert werden, mittels dessen er selbst eine freie Entscheidung treffen kann, ob er UFS2 oder ZFS verwendet, nur um ein Beispiel zu bringen.

Dabei geht es nicht darum, Ideologien zu schüren und weitere Religionskriege zu entfachen, sondern die Vorteile der einen oder anderen Technik transparent zu machen, um sich ein eigenes Bild zu machen.

Das ganze Projekt wäre identitätsstiftend und würde das Wir-Gefühl und damit das Gemeinschaftsgefühl unseres Forums stärken.

Wie denkst Du darüber?

Es wäre doch lohnenswert, sich zumindest mal Gedanken darüber zu machen. Gleichzeitig wäre die Last auf mehreren Schultern verteilt. Über entsprechende Aufgabenverteilung würden sich die Communitymitglieder sicher schon einigen. Alles eine Frage der Organisation.

Grüße

Ralph
 
Zuletzt bearbeitet von einem Moderator:
Hallo @ralli

Dein Vorschlag bezieht sich meines Erachtens auf etwas, das es schon gibt: Das BSD-Wiki.

Ich möchte Dir gerne weiteres dazu per Unterhaltung mitteilen, damit dieser Thread nicht wieder in eine ganz andere Richtung läuft:)
 
Hallo Holger, es war nur eine Idee. Das Du Dein Projekt nicht halbherzig aufgibst, wo Du viel Arbeit und Herzblut rein gesteckt hast, das war mit schon klar. Viele Artikel in unserem Wiki sind über 10 Jahre alt und nicht mehr aktuell. Da könnte man auch ansetzen und sich einbringen.:D Das gilt auch für mich selbst.
 
BSD Wiki?

Das Problem beim BSD Wiki ist einfach, dass viele Dinge schlicht veraltet sind -
und einen Anfaenger eher in die Falle laufen lassen, als dass sie helfen - weil ein
Anfaenger die Qualitaet und Aktualitaet noch gar nicht einschaetzen kann.

Ein VIM-HowTo aus 2007 wird z.B. auch in 10 Jahren noch hilfreich sein ...
ein Samba-HowTo aus 2007 ist heute schon ein Fall fuer den Papierkorb

:-)
 
Der Vorteil eines Wikis ist hingegen, dass so etwas schnell korrigiert werden kann, sofern Account vorhanden.
 
Und man kann veraltete Artikel einfach als solche markieren, wenn einem sowas auffällt. Muss ja nicht gleich korrigiert werden, die Arbeit will man sich vielleicht nicht gleich machen, weil man gerade keine Zeit hat.

Aber wir schweifen schon wieder ab! Zurück zum Thema.
 
derOliver schrieb:
Und man kann veraltete Artikel einfach als solche markieren, wenn einem sowas auffällt. Muss ja nicht gleich korrigiert werden, die Arbeit will man sich vielleicht nicht gleich machen, weil man gerade keine Zeit hat.

Aber wir schweifen schon wieder ab! Zurück zum Thema.
Zum Vergrößern anklicken....

Und..
Hast Du schon veraltete Artikel gefunden und markiert?
 
Hallo,

um Spekulationen vorzubeugen - "[...]macht er noch was an der Doku oder wird da doch nix draus[...]":

Ich arbeite weiter dran, es hat sich allerdings eine neue Situation ergeben, und zwar die, dass daraus nun ein Projekt von zwei Leuten geworden ist.
Die zweite Autorenschaft bekannt zu geben ist nun Sache desjenigen, der dazu gekommen ist, nur soviel:
Es wird der Qualität sehr gut tun, weil es sich dabei um einen sehr erfahrenen FreeBSD-Nutzer handelt.

Viele Grüße,
Holger
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben