Ubuntu Frust: Kein Full Screen in VirtualBox

Oh man, dass das fuer konfigurationsintensive Programme absolut uneffektiv ist, ist dir noch nicht bewusst, oder?

Das heisst also du lagerst die Entscheidungen an eine Drittsoftware aus? Das waere aber ein Scheunentor-grosses Sicherheitsloch.

praktisch nicht, siehe anderes Posting.

ACK, aber genau das ist doch das Problem was man als erstes loesen muss, wenn man schon ein ach so tolles neues System 'plant'; Das fehlerhafte Software keinen Schaden anrichten kann.

Ja, schon, aber wenn der Benutzer ein Programm ausfuehren will, gibt er der Programmdatei natuerlich die Rechte, und es wird nicht lange dauern bis einer einen Weg gefunden hat, das zu automatisieren, weil es sonst ja unkomfortabel ist.

So, und woher weiss diese Nachfrage, das es ein Virus ist? So eine Abfrage, und den entsprechenden Hinweis gibt es bei den heute ueblichen Virenschutzloesungen auch schon.

Ja, so sieht es wohl aus.

Das ist aber unbrauchbar. Wenn mir meine Daten verloren gehen moechte ich doch nicht das komplette System neu einspielen. Aber das Problem hat dein kompletter Ansatz.

-> Ressourcenhungrigkeit, alle deine Vorschlaege produzieren einen wahnsinnigen overhead, obwohl vieles davon heute auch schon geht, ohne selbigen overhead.

Das passiert aber auch nur windows-usern

Es ist aber im Endeffekt das gleiche, siehe anderes Posting.

Das waere die einfachste Loesung, geht aber ja leider nicht immer.

Ja genau. aber ich moechte das doch bitte dann auch auf mehreren Rechnern nutzen koennen, oder nicht? Dann muessen also alle Rechner untereinander auch noch synchronisiert werden, damit ich die Konfiguration vom Vortag auf Arbeitsstation A am naechsten Tag auf Arbeitsstation B nutzen kann? Naja, Ressourcen (siehe oben)

warum soll das nicht gehen? Funktioniert bei *nix schon lange sehr gut.

Scheint als meinte er das so. Man darf eben nur Programme benutzen die vom Hersteller des Betriebssystems autorisiert sind. *grusel*

Was auch immer du damit sagen moechtest.

So, aber oben hast du geschrieben, das fehlerhafte Software ausgenommen ist. Mag ja sein das du auch Programmieren kannst, und dabei nie Fehler machst, halte ich aber fuer unwahrscheinlich. Die meisten Programmierer sind jedenfalls nicht perfekt, und produzieren nunmal fehlerhafte Software. Du widersprichst dir also selbst.

Das wenn man will, klingt ganz gut. Ich kann also auch auf einer Konsole arbeiten und die Konfigurationen von Hand editieren, und kann mit dem System effektiver arbeiten, weil ich keine meiner Haende staendig zwischen Tastatur und Maus hin- und herbewegen muss?! Perfekt!

Und wie implementiert man das ganze? Theoretische Ideen fuer bessere Systeme gibt es immer viele, aber praktische Loesungen irgendwie nur sehr sehr selten.

Ganz nebenbei gefragt: Bist du auch der Meinung, das man Rechenkapazitaet nutzen sollte, sobald sie zur Verfuegung steht? Das sehen die Entwickler von Vista naemlich wohl auch so. Findest du DRM ne tolle Erfindung (nicht direkt auf Musik bezogen, sondern nur das Prinzip)

Gruss, Karsten

--
In a world without walls and fences,
why do we need Windows and Gates?
Reply to
Karsten Langeloh
Loading thread data ...

Auch die Farbgebung von KDE wird Dir in der Default-Konfig als zu bobnbonartig vorkommen. KDE ist die Konkurrenz zu Gnome. Beides sind Desktop-Manager mit einem Halo an Hilfsprogrammen für die üblichen Desktop-Aufgaben. Das heißt, wenn Du von Gnome auf KDE umsteigst, bekommst Du erstmal einen anderen Fenster-Manager, einen anderen Datei- Manager, einen anderen Paket-Manager, einen anderen Text-Editor, andere Dialoge zur Einstellung der Preferences, ein anderes GUI zur Betrachtung von PDFs undsoweiter. Dass sich dabei ein anderer Look&Feel ergibt, ist eher eine Nebenwirkung.

KDE und Gnome erfüllen die gleichen Aufgaben auf unterschiedliche Weise und sind dabei ähnlich erfolgreich. Für die Benutzerschnittstelle verfolgen sie unterschiedliche Philosophien. Bei KDE gibt es tentenziell mehr Optionen, Knöpfe und Einstellungen. Letztlich ist es eine persönliche Geschmacksfrage, was einem mehr zusagt.

------

--
Kai-Martin Knaak
http://lilalaser.de/blog
Reply to
Kai-Martin Knaak

"Heiko Nocon" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Zulaessig ist es auf jedem Rechner :-)

Auf einem, der meinem Konzept folgen wuerde, ist es natuerlich zulaessig (ein sicherer Rechner muss sicher gegen alles sein, auch gegen -absichtliche- Fehlbedienung, der Schutz muss ja im Filesystem im Kernel sein) und loescht genau die Namen aus dem Verzeichnis "c:\Dokumente und Einstellungen\MaWin" und darunter die ich loeschen darf, und deren Dateien wenn das der einzige Link auf deren INode war. Meine Dokumente. Nicht die Konfigurationseinstellungen, die Programme, die ich benutzt habe, dort abgelegt haben, nicht Dateien die andere Benutzer dort abgelegt haben (Frechheit, aber ich hab's ihnen offenbar erlaubt) und die fuer mich nur r/o sind. Wegen dem /F waeren aber Dateien, deren gesetztes Dateiattribut r/o von mir geaendert werden duerfte (das sind grob geschaetzt die, bei denen ich manuell r/o gesetzt habe), auch geloescht. Darueberhinaus wuerde es auch Dateinamen loeschen, bei denen die Datei gerade von einem Programm offen gehalten ist, die Datei verscheint, wenn das Programm sie schliesst. Desweiteren wuerde es protokollieren, welche Dateien geloescht worden sind und wo sie waren, damit eine Wiederherstellung moeglich ist, bis im Dateiversionierungssystem dieser Bereich gepurgt wird.

--
Manfred Winterhoff
Reply to
MaWin

OK.

Dann tut es aber nicht das, was du willst. Dein erklärter Wille war ja, alles zu löschen.

Wenn du nun aber 120.000 Programme in Benutzung hattest, diese dir alle aber plötzlich zu doof wurden, weil du das ultimative Tool entdeckt hast, welches die Aufgabe aller dieser Programme ganz allein stemmen kann?

Nach deiner Logik müßtest du dann jedes einzelne dieser 120.000 Programme starten, um ihm zu sagen, daß es 1) sämtliche Konfig-Dateien löschen soll und 2) sich selbst.

Zumutbar?

Ähem. 1) Das Ziel der Aktion mit der Entsorgung der 120.000 Programme war, Platz zu schaffen für das eine neue Übertool. Statt dessen hast du den Platz massiv weiter verknappt, denn Logdateien und und nur scheinbar gelöschte Dateien belegen zusammen mehr Platz als zuvor.

Und, last but not least, wer entscheidet, wann "gepurgt" wird? Was passiert, wenn gepurged wird, bevor du dir sicher bist, daß deine Entscheidung richtig war, das Kommando einzutippen?

Reply to
Heiko Nocon

Mal abgesehen davon, das das Quoting in deiner Antwort milde gesagt besch*** ist, was davon gibt es wie nicht? Ich hab alles was da stand, plus ein paar Extras.

Das Konzept ist sicherlich gut, nur wo definiert man diese Kontrolle? Und die praktische Umsetzung? Womit wir wieder bei der Frage waeren, ob du Programmierer bist?

Braucht es nicht. Zur Ausfuehrungszeit liegt das Programm im Arbeitsspeicher, das lernt man schon im ersten Semester auf jeder ernstzunehmenden Informatikhochschule.

Koennte man unter *nix mit Paketverwaltungssystemen durchaus genau so realisieren.

Doch! (root gilt hier nicht als Benutzer)

Das ist ein brauchbares Konzept. Zugegeben nicht perfekt, aber es geht.

Schonmal mit einem Novell-System und den Rechten da gearbeitet? Ich schon. _Das_ ist die Hoelle, mal davon abgesehen das man sich bei dem System auch komplett selbst aussperren kann :)

Schrieb ich das irgendwo? kann die Stelle nicht finden und mich auch nicht daran erinnern.

Dazu muss aber das Installationsprogramm (Betriebssystemteil?) die Software kennen?!

vernuenftig

Ok, das ist zugegebenermassen mit heutigen Systemen schwierig ohne jedem Programm einen eigenen Benutzer zu geben. Nur wie willst du das realisieren?

Das kann man heute schon sehr gut verhindern. Das kann sogar Win**

Den smilie hast du aber schon gesehen?

Und wie macht man das besser? Systeme die bei fehlerhaften Konfigurationen, die letzte gueltige oder eine vordefinierte Standardkonfiguration laden, gibt es heute auch schon.

welche Zeile?

Mhh .. welcher Stand? Ich editiere alle meine Konfigurationsdateien von Hand, denn ich moechte Wissen was die Software tut (noch ein Grund fuer

*nix, unter Win** geht sowas ja nicht). Es ist nunmal Fakt, das man mit einer Tastatur fast immer schneller arbeiten kann als mit der Maus.

Computer waren noch nie Omakompatibel. Rechner anschalten, Text in Word/OO.orgWriter tippen, drucken, Rechner ausschalten, geht auch heute, egal was fuer ein OS da drauf ist. Aber sobald man etwas intensiver mit den Geraeten arbeiten moechte, muss man eben auch ein bisschen dazulernen. Das ist aber bei allem so, erstaunlicherweise wird aber bei Computern immer darueber gemeckert.

Wie ich vorhin schon schrieb, deine Ansaetze und Konzepte sind ja ganz nett, aber die Umsetzung? Die Rechtevergabe verlagerst du nur von den Benutzeraccounts auf die Software, das ist machbar, aber die Komplexitaet, wird nicht weniger als wenn jeder Software einen eigenen Benutzeraccount haette, sieht nur anders aus. Aber ich glaube da denkst du nicht abstrakt genug.

Gruss, Karsten

--
In a world without walls and fences,
why do we need Windows and Gates?
Reply to
Karsten Langeloh

Aha, also wieder ein 'Es gibt nur einen, meinen Weg die Konfig zu aendern'? Hoert sich schwer nach Windows an und ist genauso mistig zu handhaben. Scripten kann man solche Dialoge nicht und, zumindest bei Windows, sind auch Backups dank Registry eher schwer.

Woher weiss das Installationsprogramm das? Wer erstellt diese Zuordnungen?

Eine aehnliche Frage stellt dir heute schon XP oder MacOS... Haelt das die Leute davon ab einfach immer 'Ja' zu klicken? Nein!

Aha... Und wie mache ich dann partielle Restores? Es kommt immer mal wieder vor, dass ein Benutzer oder sogar der Admin die falsche Datei loescht oder mal eine Platte die nicht das System enthaelt den Geist aufgibt. Dann willst du nur die betroffenen Daten vom Backup und nicht wirklich einen kompletten Restore.

Mein Konzept funktioniert einwandfrei, der Sinn davon ist _meine_ Daten und Anwendungen zu sichern, _nicht_ die des Systems oder anderer Anwender. Global installierte Programme landen hier nicht auf dem Backup, die kommen bei einem Reinstall sowieso wieder. Im Falles eines Crash wird das OS von CD/Internet neu aufgesetzt, das erwaehnte backup.tar ausgepackt und alle meine benutzerspezifischen Daten, Programme und Konfigurationen sind wieder vorhanden.

Ein Programm muss immer mit einer UID laufen damit der Kernel weiss was es darf. Das kann die UID des aufrufenden Users sein oder eine andere (s-Bit). Wenn dir danach ist, kannst du einem Programm einen eigenen 'User' vergeben und es dann per s-Bit darauf festnageln. Es bleibt eine UID, auch bei deiner Idee. Aber wenn du willst... Fuer den Restore eines Backups braucht man dann eben eine Programm-ID die alles schreiben darf. Sobald sowas existiert werden sich Programme finden die sich diese ID aneignen.

Aeh, nein, es ist schon schlimm genug den realen Schreibtisch aufraeumen zu muessen... Beim Computer mag ich es lieber wenn ich mir den fuer mich idealen Desktop aufgebaut habe und der beim Login genauso wieder erscheint. Also sozusagen automatisches Aufraeumen durch Restart.

Diese Beschreibung erinnert mich dunkel an 'Smalltalk'... Hatte leider einige Nachteile.

Nein, braucht man nicht, konsistent reicht. Mit Journaling ist das machbar.

Dann koennen diese Anwendungen immer nur im Kontext des Users laufen und niemals mehr Rechte als dieser User haben. Alles andere wuerde Eingriffe in das OS erlauben. Also koennen sie nicht global installiert werden sondern nur in den Directories auf die der User Schreibrechte hat (und das sind garantiert keine System-Directories). Sollten sie mehr Rechte al der User haben koennen hat sie der User auch gleich... Einfach ein kleines Programm schreiben welches diese Rechte bekommt und dir eine Shell startet in der alle aufgerufenen Programme nicht mit den Rechten des Users sondern denen des Programmes laufen. Mit Priviledge Escalation kann man viel Spass haben.

Gerrit

Reply to
Gerrit Heitsch

"Karsten Langeloh" schrieb im Newsbeitrag news: snipped-for-privacy@druidh.slaplab.org...

Konfigurationsintensiv darf ein Programm sein, viele Windows Programme erlauben Aenderung der Farbe jeden Pixels, Schriftart und wasweissich, aber wenn ein Benutzer vor Benutzung erst mal stundenlang irgendwo ihm weitestgehende unbekannte Fragen beantworten soll und Informationen einholen muss, ist am Programm was falsch.

Nicht Drittsoftware. Installation ist ein Kern des Betriebssystems, sogar kerniger als dieses selbst, denn nur das Betriebssysteninatallationsprogramm (von der CD) darf das Betriebsystem veraendern (und ist dann als Teil davon auf der Platte). Ein Update davon erfordert signierte Updatemodule. Mit dem Installationsprogramm darf man weitere Programme installieren, unter anderem ein weiteres Installationsprogramm vom Fremdanbieter, nennen wir es InstallShield. InstallShield kann dann Programme installieren, es darf die auch im System eintragen und durch Betriebssystemaufrufe z.B. Icons plazieren, und die Programme selbst duerfen natuerlich das Betriebssystem verwenden und z.B. Drucken, aber InstallShield kann nicht das Betriebssystem aendern, es darf nur die Programme aendern, die es selbst installiert hat.

Ein hierarchisches Konzept ist halt recht einfach und solide sicher.

Und ? Was willst du mir damit sagen? Halte den Kern klein? Keine Sorge, mach ich.

Wenn Rechte nur an Benutzer und nicht an Programme gekoppelt werden, hast du das Problem, dass ein Betriebssystemcall dann ein chmod machen darf, wenn der Benutzer ein chmod machen darf, weil es nicht zu differenzieren ist. War man klug genug, Rechte nach Programmrechten und Benutzerechten zu differenzieren, kann man verhindern, dass Programme chmods machen, wenn der Benutzer sie keine chmods machen lassen will.

Ich sagte schon, ich wuerde diese Stelle mit einem Virenchecker belegen und einer Rueckfrage, wenn die Aenderung nicht plausibel ist. Plausibel sind Aenderungen von Installationsprogrammen, denn die erlauben zwar, dass nun ein neues Programm ausfuehrbar ist, aber das Programm ist hierarisch untergeordnet, es kann nichts von dem kaputtmachen, das schon vor seiner Existenz installiert war.

Es ist was gaenzlich unproblematisches, wenn Rechte hierarchisch angeordnet sind und an Programme vergeben werden. Das alte Konzeot von *nix taugt nix, mit dem geht das natuerlich nicht. Ein Recht, alles kaputt.

Weil ein Virenchecker drueber lief, sagte ich aber schon.

Nur muessen Virenchecker heute alle Dateien zu jeder Zeit pruefen, und nicht nur an einer zentralen selten verwendeten Stelle.

Zirkelschluss? Ein kompletter Ansatz ist komplett ? Ja, ist er. Daher betonte ich ausdrucklich die Moeglichkeit, gezielt Teile einzulesen. Hast du offenbar ueberlesen.

Nope. Im Gegenteil, sehr effizient gegenueber allen heute verwendeten Methoden. Sie sind so effizient, dass ein Update einer Datei, welches die nur teilweise aendert, auch nur zu sektorweisem Neuschreiben und Belegen fuehrt, und trotzdem den alten Dateistand speichert. Es ist ein transaktionales versionierendes Dateisystem vorgesehen, welches kaum langsamer ist als aktuelle, und nur auf der Hardwareanforderung aufsetzt, dass eine Festplatte einen uebermittelten Sektor entweder scheibt, oder er beim Lesen (nach Stromausfall) ein bad sector ist.

Es sei denn, das Programm befindet sich auf einem Server, wie es bei solchen Umgebungen wohl ueblich waere.

Wesentlich weniger, als derzeit.

Ohne transaktionales Dateisysetem kann es nicht funktionieren, es kann immer in einem Moment abbrechen, wo inkonsistente Informationen vorliegen.

FUD.

Ausgenommen wovon ? Fehlerhafte Software funktioniert nicht. Aber das geschilderte Konzept sorgt zu 100% dafuer, dass fehlerhafte Software keine andere Software beschaedigen kann. Zwar waere es peinlich, wenn das Betriebssystem fehlerhaft ist, aber daher gliedert man das in kleine Bereiche, und hofft z.B. die Rechteverwaltung ohne Fehler hinzubekommen. Damit man das nicht uumgehen kann, muss man Rechte fuer Resourcen auf Ebene der Systemcalls bereits implementiert haben. Rechte sind ganz tief unten, knapp ueber der Hardware

Ja.

Wenn es ein von dir selbst geschriebenes Programm ist welches die Konfiguration benutzt.

Die Konfiguration von Peters Onlinebankingsystem kannst du nicht mit vi aendern.

Lass die Hand einfach auf der Maas. Denk dran, dass 10% der Bevoelkerung nicht schreiben und lesen kann, die wollen wir doch als Computernutzer nicht verprellen.

Das schlimme ist, das die praktischen Loesungen von Dorftrottel geamcht werden, die nicht mal ein tragfaehiges theoretisches Konzept haben.

Bla.

Bla.

DRM ist bei einem sicheren Betriebssystem nichts was hinzuprogrammiert werden muss (wie Microsoft bei Vista) sondern im Kern drin. Ich bin jedoch mit Leserechten freizuegig. Wer nicht gelesen werden will, kann Leserechte fuer andere abklemmen, damit waere DRM in der ganzen Prozesskette von der DVD bis zum Bildschirmtreiber implementiert.

--
Manfred Winterhoff
Reply to
MaWin

Das Problem kann als geloest betrachtet werden. Stichwort 'SunRay', da wandert deine Session sogar on the fly zwischen den am gleichen Cluster haengenden SunRays ohne ausloggen mit. Chipkarte ziehen, woanders reinstecken und weitermachen. Habe ich auf der Arbeit, gewoehnt man sich schnell dran. Den Server gibt es nicht nur fuer Solaris.

Journaling sollte man haben, aber sonst kann ich kein Problem erkennen.

Gerrit

Reply to
Gerrit Heitsch

Hier funktionierte es... Gnome hat naemlich ein paar Probleme mit dem Session-Management die KDE nicht hat. Gnome kann sich die Position eines 'xterm' nicht merken womit sie beim Einloggen zwar starten aber dann alle an einem Fleck uebereinander liegen. KDE bekommt es hin.

Ja, ich benutze immer noch xterm statt den Nachbauten. Letztere sind naemlich teilweise deutlich langsamer oder nicht 100% kompatibel.

Gerrit

Reply to
Gerrit Heitsch

Wenn er Gnome nicht deinstalliert kann er die ganzen Gnome-Programme weiterverwenden. Ich benutze KDE und trotzdem Synaptic fuer die Pakete.

Editor? Du meinst bei KDE liegt ein anderer 'vi' bei? SCNR... :)

Gerrit

Reply to
Gerrit Heitsch

Nö, so einen Unsinn lernt man nur in Klippschulen, wo man noch niemals etwas von virtuellem Speicher gehört hat.

Es ist nicht nötig, daß ein Programm im Speicher liegt, um es ausführen zu können. Es genügt im Extremfall, wenn die aktuell ausgeführte Anweisung im Speicher liegt. Typischerweise wird aber ein OS die Sachen nicht auf Anweisungsebene, sondern auf der Ebene von Speicherseiten verwalten. Da genügt es dann halt, wenn die eine oder zwei Speicherseiten im RAM sind, die die aktuelle Anweisung enhält/enthalten.

Reply to
Heiko Nocon

Ok, da sind wir uns einig. Die Frage ist nur, was ist dann an deinem Konzept besser?

Schoen, wer macht das, und wo wird das definiert, der Overhead ist bei der Fuelle an Software gigantisch.

Autsch! genau das ist der Grund warum heute schon Software stirbt. Sie ist nicht anpassbar an die speziellen Beduerfnisse. Das duerfte ein ziemlich sicheres (*lol*) Todesurteil fuer das Konzept sein.

Welches aber auch neue Probleme mit sich bringt. Wie schon im anderen Posting geschrieben, verlagerst du das Problem nur, loest es aber nicht.

Nein, es ist ein Zustand. Probleme wird es immer geben, mit dem aktuellen Zustand sind wir denke ich alle nicht 100% zufrieden, aber man kann damit arbeiten, und man kann auch an Verbesserungen arbeiten, aber Perfekt wird es nie werden. Vielleicht loest sich das Problem sobald Rechner selbststaendig denken koennen, und das in einem vordefinierten Rahmen auch duerfen, achja der Rahmen, das selbe Problem!

Stimmt, wuerde es bei dir aber auch, nur an anderer Stelle.

Stimmt, aber dynamisch ist, und man wenn man will tun und lassen kann was man will (die Sinnhaftigkeit sei mal dahingestellt, aber ich bin ein selbststaendig und frei denkendes Individuum und moechte gefaelligst selbst entscheiden was ich auf meinem Rechner tun kann)

Das bezweifel ich auch nicht, um Verbesserungen zu machen, muss man sich ja ansehen was schlecht, und was weniger schlecht ist, logisch.

Das seh ich schon, nur kann ich momentan damit leben (nicht das ich es nicht auch gerne anders haette). Das es immer jemanden gibt, der damit nicht leben kann, ist voellig klar. Aber Perfekt geht momentan einfach nicht, denn auch dein System hat schwaechen.

Autsch! Diese Aussage solltest du nochmal ueberdenken. Gut vielleicht programmierst du in haskell, und kannst deine Programme Problemlos beweisen, aber bei so etwas komplexen wie einem Betriebssystem von beweisbar zu sprechen ... ganz duennes Eis ... Ich beschaeftige mich schon seit laengerer Zeit mit Betriebssystemen, insbesondere Echtzeit, aber halt auch mit linux, entsprechende theoretische Grundlagen, gabs in der Vorlesung.

Das sollte man auch erwarten koennen. Das hat M$ auch ziemlich verpfuscht seit Win2000

Wo darf ich das unterschreiben? :) Die haben doch genug damit zu tun die vorhandenen Fehler oberflaechlich zu beheben, und ihren Releaseplan fuer die naechste Version einzuhalten. Das die existierenden Systeme unzulaenglichkeiten haben, habe ich ja auch nie bestritten.

So, nu geh ich erstmal kochen :)

Gruss, Karsten

--
In a world without walls and fences,
why do we need Windows and Gates?
Reply to
Karsten Langeloh

"Gerrit Heitsch" schrieb im Newsbeitrag news:gekrt1$i6b$ snipped-for-privacy@news.bawue.net...

Nein. Es gibt nur einen Bereich von dem heraus man die Konfiguration aendern kann, naemlich das Programm, sein Installprogramm und ihm uebergeordnete programme wie das Betriebsystem (dessen Aufrufe man sicher verwendet, um Konfigurationen programm-, arbeitsplatz- und benutzerbezogen ablegen zu koennen). Natuerlich kann das Installprogramm die Konfiguration ohne Dialog schreiben. Natuerlich kann das Programm skriptbar sein. Aber ebenso natuerlich kann es dir beim rumpfuschen in Oma Hertwigs INI auf die Finger hauen.

Es sind die Benutzerzuordnungen, die sagen, dass B der Chef von A ist, und A ihm erlaubt, Programme fuer ihn zu installieren und deinstallieren. Das ergab sich schon so, weil B sowieso das Programm fuer alle Benutzer zugaenglich installiert hat :-)

Nein. Du hast es nicht versatdnen. Vista und MacOS stellt die Frage immer. Nicht nur an Momenten, wo dir ein Virus untergeschoben wird. Und unter Vista und MacOS ist nach einem Ja der Virus im System frei, und kann nicht nur sich selbst loeschen, sondern alle anderen Programme auch.

Sagte ich schon: In dem du sagst, dass du nur was bestimmtes wiederherstellen willst. Das kannst du (nur), wenn du die Rechte dazu hast. Also DEINE Dokumente, oder die Programme fuer die DU installations- berechtigt bist, oder die Konfig-Dateien, die Programme haben fuer die du installationsberechtigt bist. Das Betriebssystem kannst du nur ersetzen, wenn du es auch installiert hast, und nur mit dem Installprogramm des Betriebssystems, nicht mit irgendeinem Loeschprogramm.

Bei bestehenden Systemen: Ja. Klar. Leicht. Bei sinnvollen Systemenen: Eigene Dokumente, aber die liegen dann im Papierkorb.

daher empfehle ich zum Backup immer alles zu lesen, von allen Benutzern, auch Dateien die gerade offen sind und modifiziert werden, dazu braucht es aber ein transaktionales Dateisystem, damit man einen konsistenten Stand (2.11.08 19:41:21) speichern kann.

Ja.

Ja. Im Prinzip richtig. Natuerlich implementiert man das so aehnlich, man erfindet ja ncht alles neu. Allerdings ist der User ein Konglomerat aus Programm und User und aendert sich, wenn ein Call von einem Programm in ein anderes geht.

Bei dumm implementierten Systemen ist das sicher moeglich.

Bei dir: Schon. Bei besseren Systemen: Keineswegs, das waere ja eine Riesen-Sicherheritsluecke.

Nein. Journaling allein heisst nicht stromausfallssicher.

Korrekt. Ebenso wie der User haben seine selbstgeschriebenen Programme nicht das Recht z.B. Dateien des Betriebssystems zu zernepfen.

Oh diese veraltete, eingeschraenkte Sicht. Hier ist dein Brett vor'm Kopf deutlich erkennbar.

Du hast hierarchische Programmrechte nicht verstanden, kein Stueck davon. Mag mein Fehler sein, weil ich hier nicht ganze Diplomarbeiten ausbreite, aber wenigstens meinen Ausfuehrungen mitdenken haettest du koennen.

--
Manfred Winterhoff
Reply to
MaWin

In anderen Worten, das funktioniert nur mit closed source beim OS. Will man das nicht faellt deine Idee flach weil sich jeder ein passendes Modul signieren kann. Wobei man closed Source aus anderen Gruenden u.U. nicht will.

Wie kombinierst du diese Idee und die Idee der shared libraries? Sind letztere Teil des OS oder der Anwendung? Wer darf Updates machen? Wie ist die Versionierung geloest?

Der kennt auch nicht alle, je nach Updatezustand...

Macht nichts, das bekommt man mit Journaling erschlagen und das Flag fuer 'Update erfolgreich' wird als letztes gesetzt. Ist es da, dann passt alles, wenn nein ist das Update nicht komplett. Ja, es gibt eine kleine Wahrscheinlichkeit, dass es nach erfolgreichem Update aber vor dem Setzen des Flags gescheppert hat, aber auch dann passiert nichts ausser dem Update nochmal von vorne.

Gerrit

Reply to
Gerrit Heitsch

gksu und gksudo _sind_ GUI-Versionen.

sudo ist dafür da, _einen_ Befehl mit Root-Rechten durchzuführen. su ist dafür gedacht, in der jeweiligen Shell permanent Root-Rechte zu bekommen. Genaugenommen ist es etwas allgemeiner. Man kann mit su und sudo Programme mit den Rechten eines anderen login ausführen. Root ist da nur ein (wichtiger) Spezialfall.

------

--
Kai-Martin Knaak
http://lilalaser.de/blog
Reply to
Kai-Martin Knaak

"Heiko Nocon" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Jupp.

Skriptbar. Oder im Add-/Remove Program Dialog: Klick, shift klick, DEL.

Jupp.

ICH wuerde bei meinen Rechner nie purgen (ich kann z.B. meine eMails bis zur allerersten unter Compuserve noch lesen), spart das Backup rauskramen, sondern hoechstens mal eine neue Platte kaufen.

Vor dem Purge waere ein guter Zeitpunkt, ein Backup anzufertigen. Das koennte einem gleich das purge-Kommando nahelegen :-)

--
Manfred Winterhoff
Reply to
MaWin

"Karsten Langeloh" schrieb im Newsbeitrag news: snipped-for-privacy@druidh.slaplab.org...

Wie ueblich: Wenn man inhaltlich nichts mehr entgegnen kann, maekelt man an der (uebrigens astreinen) Form.

Dann geh noch mal in die Schule.

WENN man ein vernuenftiges Betriebssystem schreibt, kann man paging von Codesegmenten vereinfachen, weil man verworfene Kacheln nicht rausschreiben muss, sondern von ihrem Ursprungsplatz der Datei wieder laden kann. Man braucht zum Programmsatrt noch ncht mal die Datei zu laden, sondern nur in den virtuellen Speicher zu mappen.

Hat man natuerlich erst mal das Konzept vergurkt (so wie es der strunzdoofe David N Cutler bei MS beim Sprung von Win3.11 zu Win32 schaffte, wo DLLs nur zur Adressumrechnung mehrmals geladen werden), dann braucht man nach dem Programmstart die Datei tatsaechlich nicht mehr, denn man wird sie rausswapppen muessen.

Jupp, aber als Benutzer (oder Schadprogramm) umgehen. rm *

ROTFL.

Ja, es geht, und du siehst nicht mal die Probleme, weil ueber beiden Huehneraugen Schuhe sind.

Leider. Sogar NLM schreiben muessen. Dann weiss man, was fuer ein Schott da hinter den Kulissen war.

Nun, die Software muss in einem Format vorliegen, mit dem das Setupprogramm was anfangen kann. Ein einfaches EXE wird es nur chmod'n koennen und ins Startmenue eintragen, ein Archiv immerhin entpacken, ein Paket kann man schon mal nach Abhaengigkeiten untersuchen, ein INF erlaubt dann schon Elemente in die Oberflaeche zu integrieren.

Eine moderne Entwicklungsumgebung sollte das Programm gleich als Installationspaket rausschreiben koennen.

Selbst das reicht nicht, weil Programme andere Routinen aufrufen duerfen.

Ich? Alleine? Nie. Ein ganzes Betriebssystem das gegen MS etc. anstinken kann erfordert deutlich mehr als 100 Mannjahre. Aber ich weiss, wie man's implementieren koennte. Und wenn man weiss, was moeglich ist, weiss man, wie weit die heute davon entfernt sind.

In dem man VI endlich wegschmeisst, Aber ich weiss, ihr unter Linux habt noch nichts besseres. Seit 32 Jahren nur Geschwafel. Aber wie ich hoere, bist du erst seit 10 Jahren dabei "mein erstes *nix hatte ich vor ziemlich genau 10 Jahre" Mein letztes Mal, VI benutzen zu muessen, war 1985.

Stimmt. Scheint dich nicht nachdenklich zu machen. Dann solltest du als Softwareentwickler schnell den Job aufgeben. Denn Schrott gibt es genug.

--
Manfred Winterhoff
Reply to
MaWin

Clemens Waechter meinte:

Ubuntu ist von der Installation her einfacher. Dafür steht man dann als Einsteiger etwas dumm da, wenn es nicht funktioniert.

Bei Debian fängt man mit der Netinstall an. Minimalsystem ohne grafische Oberfläche. Dann macht man sich ein wenig mit dem Paketmanagement und apt-get, apt-cache vertraut und installiert das was man wirklich benötigt. Wenn man im Kopf behält, dass alle wichtigen Scripts und Einstellungen unter /etc stehen und das es eigentlich in /etc/init.d losgeht kann man sich mit ein paar wenigen Befehlen mit dem System auseinandersetzen.

Ich schätze, Jörg würde mit

formatting link
nicht lange brauchen um die wichtigsten Dinge wie Bootvorgang, Userrechte und Installation von Software drauf zu haben.

73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19
Reply to
Thomas 'Tom' Malkus

In article , "MaWin" writes: |> |> Ein *nix hat auch kein taugliches Sicherheitskozept, weil es |> Dateirechte nur fuer Benutzer und nicht fuer Programme kennt.

[ ] Du kennst Gruppen. Übrigens erlaubt das Sicherheitskonzept durchaus auch einzelne User pro Programm... Wird von gewissen Schlüsselanwendungen auch gerne genommen.

Rainer

Reply to
Rainer Buchty

Braucht man eher nicht... Eine Datenbank bekommt man so allerdings nicht gesichert weil die Datei zwar nach aussen konsistent aussieht, es aber intern nicht sein muss. Aber dafuer gibt es passende Programme. Ansonsten braucht man dafuer nur ein Dateisystem welches einen immer lesen laesst, also eben nicht NTFS wo geoeffnete Dateien sich querstellen.

Geht aber nicht anders, sonst wird ein Restore einer Datenplatte mit den Anwendungen, konfigurationen und Daten von hunderten Usern etwas kompliziert. Selbst wenn du das OS als fest ansiehst, die ID unter der das Backupprogramm laeuft muss oberhalb aller User liegen.

Muss es auch nicht sein um den Fall 'Update ganz oder gar nicht' zu implementieren. Ich habe beschrieben wie das machbar ist. Wo meinst du einen Fehler zu sehen?

Das hat du jetzt schon beim typischen *IX. Mein lokaler Kram liegt in $HOME/bin und ist nur von mir verwendbar.

Sie haben dann aber auch nicht das Recht global verwendet zu werden. Alles andere waere eine Sicherheitsluecke.

Gerrit

Reply to
Gerrit Heitsch

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.