BSD - Mehrere Fragen

[azerty]

Da die Installation nun abgeschlossen war habe ich die HDD sofort (ohne Reboot) in das Notebook zurückgebaut, damit die finale Einrichtung bzw. Erstellung diverser Keys und Gerätedateien, die bei OpenBSD beim ersten Booten generiert werden, auf dem Notebook abläuft.

Du hast doch den Rechner nur runtergefahren und dann die Platte ausgebaut, oder? Das liest sich ein wenig so, als würdest du die laufende Platte im Betrieb ausbauen. Etwas das afaik erst ab SATA gehen soll.

Jawohl, einfach halt eingegeben und das Subnotebook herungefahren, danach ohne in irgendeiner Form zu rebooten die Festplatte abgesteckt und ins Notebook zurückverfrachtet. Kurz: OpenBSD hat seinen ersten selbstständigen Boot von HDD im Subnotebook getätigt.

[azerty]

Kleines Update:

Ich hab weiter an der System Konfiguration herumgeschraubt, einen Benutzer mit sudo-Rechten eingerichtet und einige kleinere nützliche Entdeckungen inkl. Anspassungen in den /etc Konfigurations-Dateien gemacht.

Desweiteren entdeckt dass man im Gegesatz zu GNU/Linux keinen eigenen gpm Daemon benötigt um die Maus bzw. den Trackpoint in der Shell zu aktivieren, das ganze ist schon standardmässig enthalten im Bildschirm/Maus/Tastatur-Treiber wscons bzw. einem Sub-Treiber von Letzterem: wsmoused.

Besondere Neuigkeit für mich:
Durch den im Grundsystem fehlenden Nano, habe ich mich innerhalb kürzester Zeit an den Vi gewöhnt - Geniales Ding!
Mittlerweile benötige ich den Nano nicht mehr, die grundlegenden Vi-Kommandos habe ich schon im Kopf, mal schauen wie es dann in einigen Wochen aussieht..

[Meillo]

Mittlerweile benötige ich den Nano nicht mehr, die grundlegenden Vi-Kommandos habe ich schon im Kopf, mal schauen wie es dann in einigen Wochen aussieht..

... weiter so!

[azerty]

Ich mal wieder...

Falls jemand ein minimales BSD (aus der FreeBSD-Ecke) ausprobieren möchte, hat er mit miniBSD die Gelegenheit dazu. Eine Partition mit 15 MB dürfte weitaus reichen.

Falls jemand noch ein weitere minimal kleines* BSD system kennt, das vielleicht sogar als Live-CD nutzbar ist, bitte hier posten.

*Bedingung: Nicht mehr als 200 MB Größe

[Kotzkroete]

Kein BSD, aber v7x86 ist auch sehr klein: http://www.nordier.com/v7x86/index.html
UNIXv7 für Intel ist bestimmt sehr lustig

[azerty]

@ peschmae

Habe gerade eben OpenBSD-4.3 auf meinem Subnotebook per USB-FDD (floppyC43.fs) installiert.
Allerdings hapert es mal wieder an der korrekten menu.lst. Ich bekomme immer Folgendes:

Error 23: Error while parsing number

Koenntest du mir einen Eintrag posten der auf die 3. Partition der 1. HDD verweißt (deutsch: /dev/sda3) und dabei den Chainloader verwendet, so dass OpenBSD mit seinem eigenen Bootloader starten kann?

Habe selber schon einige Sachen ausprobiert, aber irgendwie finde ich meinen (Denk-)Fehler nicht.


EDIT:
LOL, das Problem hat sich erledigt.
Im Eintrag "root (hd0,2)" war die 0 mit einem O vertauscht.

[peschmae]

Ich benutze mittlerweile Grub2, könnte dir also eh nicht präzise konkret weiterhelfen

Leider geht da das direktladen nicht wirklich; also um den Chainloader kommt man bis auf weiteres nicht rum.

MfG Peschmä

[azerty]

Ist der denn schon stable bzw. als Paket (in Testing) installierbar ohne Probleme zu verursachen?

[Six]

Desweiteren entdeckt dass man im Gegesatz zu GNU/Linux keinen eigenen gpm Daemon benötigt um die Maus bzw. den Trackpoint in der Shell zu aktivieren, das ganze ist schon standardmässig enthalten im Bildschirm/Maus/Tastatur-Treiber wscons bzw. einem Sub-Treiber von Letzterem: wsmoused.

Wozu man eine Maus in einem VT braucht, werde ich wohl nie begreifen

Besondere Neuigkeit für mich:
Durch den im Grundsystem fehlenden Nano, habe ich mich innerhalb kürzester Zeit an den Vi gewöhnt - Geniales Ding!
Mittlerweile benötige ich den Nano nicht mehr, die grundlegenden Vi-Kommandos habe ich schon im Kopf, mal schauen wie es dann in einigen Wochen aussieht..

Wurde ja auch mal Zeit!

[yeti]

Wozu man eine Maus in einem VT braucht, werde ich wohl nie begreifen

Cut&Paste ist auch auf ner Console 'ne nette Sache, aber das löst Screen m.E. besser als GPM, denn Screen dehnt das auch auf den Scrollback-Puffer aus und nicht nur auf den angezeigten Bildschirmbereich.

Ob Linux oder BSD, Screen gehört bei mir immer zu den erstinstallierten Programmen...

[peschmae]

Ist der denn schon stable bzw. als Paket (in Testing) installierbar ohne Probleme zu verursachen?

Nee, da gibts etwa alle Woche ein neues Paket in Sid von. Hatte auch schon mal dass das Update plötzlich nicht mehr ging...

Die OS-Erkennung ist schon nicht schlecht - er listet automatisch alles auf (ausser OpenBSD) was bei mir installiert ist. Allerdings nicht in der Reihenfolge die ich will - ein bisschen Anpassbarkeitsarbeit liegt da also noch vor den Debian-Maintainern

MfG Peschmä

[azerty]

Kann mir jemand sagen wo die .profile im Root Ordner nützlich ist und von wem sie ausgelesen wird?

(Gemeint ist in diesem Fall /.profile NICHT /root/.profile)

[azerty]

/me hat mal wieder etwas ganz tolles ausgegraben! Natürlich mit OpenBSD!

OpenRCS

DESCRIPTION
The Revision Control System (RCS) manages multiple revisions of files. RCS automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs, documentation, graphics, papers, and form letters.

The basic user interface is extremely simple. The novice only needs to learn two commands: ci(1) and co(1). ci, short for “check in”, deposits the contents of a file into an archival file called an RCS file. An RCS file contains all revisions of a particular file. co, short for “check out”, retrieves revisions from an RCS file.

Von der offiziellen Homepage:

Description

As Ray Lai stated it:

The OpenRCS project was started as a first step toward OpenCVS which will ultimately become a replacement for CVS, solving inherent flaws in the original CVS implementation. OpenRCS aims to be robust, fast and simple.

Goals

Like OpenSSH, OpenRCS is developed under and for OpenBSD only. Portable OpenRCS is there to allow non-OpenBSD users to use OpenRCS, instead of RCS.

Portability Status

For now, portable OpenRCS has been successfully ported on:

* Linux i386/amd64
* FreeBSD 5.4 i386
* FreeBSD 6.2 i386

Einen guten Einstieg gibt man rcs. Merken sollte man sich rcs(1), ci(1) und co(1).

Auf Ubuntu gibt es auch noch man rcsintro als zusätzliche Starthilfe. (Am Anfang schon erwähnt!)

Ich werde immer wieder von neuem überrascht von diesen unzähligen kleinen aber wertvollen Tools in der Unix Toolchest, insbesondere im OpenBSD BASE!

[Meillo]

RCS hat das Problem, dass es jede Datei für sich verwaltet. Neuere Systeme legen meist ein Repository und dessen Stand zu Grunde. Damit ist es einfacher alle zugehörigen Dateien auf eine bestimmte Version zu bringen. Zudem können Umbenennungen und Codetransfers zwischen Dateien vernünftig representiert werden.

IMO ist RCS durchaus eine Wahl für einzelne Dateien die nur von einem User auf einer Maschine verwaltet werden sollen. Z.B. Dateien unter /etc.

Für Programmierprojekte mit mehreren Usern auf mehreren Rechnern ist ein modernes dezentrales VCS bestimmt die bessere Wahl.

[novalix]

Äähh,
kann es sein, dass die OpenBSDler ne klitzekleine NIH-Neurose haben.
RCS ist alterwürdig, wird aber afaics so gut wie überhaupt nicht mehr verwendet. [1]
Dass CVS durchaus funktionale Begrenzungen aufweist, ist auch keine allzu neue Erkenntnis. Die SVN-Entwickler sollen ja eine ähnliche Hypothese in den Raum geworfen haben.
Wenn man jetzt noch die Fülle an wirklich guten Distributed VCS (git, mercurial, bazaar, darcs, ...) dazu nimmt, stellt sich mir die Frage: Was macht denn dieses OpenRCS so besonders?

Groetjes, niels

[1] Zur Quellcodeverwaltung wurde RCS ohnehin schon lange Zeit nicht mehr ernsthaft verwendet. Einige Leute haben es zur Revisionsverwaltung ihrer Konfigurationsdateien eingesetzt. Allerdings bieten auch hier die "modernen" Tools weitaus bessere Möglichkeiten. Siehe etckeeper.

[azerty]

IMO ist RCS durchaus eine Wahl für einzelne Dateien die nur von einem User auf einer Maschine verwaltet werden sollen. Z.B. Dateien unter /etc.

Genau, für meine vllt. zehn Dateien (Configs, Guides, Kontakte, Bookmarks, ...) reicht es wunderbar aus.

Für Programmierprojekte mit mehreren Usern auf mehreren Rechnern ist ein modernes dezentrales VCS bestimmt die bessere Wahl.

Angenommen ein Projekt wie Suckless würde sich auf einem zentralen öffentlichen Unix-System, ähnlich dem milk, befinden und alle Entwickler würden sich dort per SSH einloggen um direkt auf diesem System zu arbeiten; wäre OpenRCS dann immer noch praktikabel? (Mehrere User, aber nur ein System da sich alles auf dem zentralen System abspielt.)

Ansonsten kann ich dir natürlich nur zustimmen, für mehrere System und mehrere User wird es dann wohl nicht mehr praktikabel. Mercurial ist da dann wieder die bessere Wahl.

[Meillo]

kann es sein, dass die OpenBSDler ne klitzekleine NIH-Neurose haben.

Was bedeutet ``NIH''?

Für Programmierprojekte mit mehreren Usern auf mehreren Rechnern ist ein modernes dezentrales VCS bestimmt die bessere Wahl.

Angenommen ein Projekt wie Suckless würde sich auf einem zentralen öffentlichen Unix-System, ähnlich dem milk, befinden und alle Entwickler würden sich dort per SSH einloggen um direkt auf diesem System zu arbeiten; wäre OpenRCS dann immer noch praktikabel? (Mehrere User, aber nur ein System da sich alles auf dem zentralen System abspielt.)

Clone, pull, und push entsprächen dann scp, vermutlich. Leider gäb's kein automatisches Mergen (AFAIK kann RCS das nicht).

Der große Unterschied Datei-basiert vs. Repository-basiert beliebe. Damit gibt es keine Changesets für ein Release, sondern jede Datei hat ihren eigenen Diff.

Ich glaube bei der Quellcode-Verwaltung tut man sich damit einfach schwer. (Aber du hast schon einen guten Hinweis auf milk gegeben. Wir werden es testen. )

[novalix]

kann es sein, dass die OpenBSDler ne klitzekleine NIH-Neurose haben.

Was bedeutet ``NIH''?

Not Invented Here.
Dieses Syndrom ist nicht per se etwas verwerfliches. In gewissen Grenzen kann es durchaus Sinn ergeben, das Rad neu zu erfinden. Allerdings sehe ich unter den gegebenen Umständen eben gar keine Notwendigkeit RCS zu pimpen. Kommt mir n klein wenig esoterisch vor.
Allerdings habe ich natürlich keine Ahnung, was die OpenBSDler damit bezwecken, noch wie alt dieses Projekt ist.
Andererseits ist es ja kein allzu grosses Geheimnis, dass man bei OpenBSD sich keine Sorge um die Pflege des Lagerdenkens machen muss.

Groetjes, niels