View previous topic :: View next topic |
Author |
Message |
magir Tux's lil' helper
Joined: 19 Sep 2002 Posts: 95 Location: Germany
|
Posted: Thu Jun 26, 2003 7:45 pm Post subject: Hey gentoo hat sich gespaltet! |
|
|
Unglaublich, ich finde's schade!
aber macht euch lieber selbst ein Bild davon!
http://www.zynot.org/
Was hält ihr davon?
So ist es halt mit Open-Source, alles bleibt am halbweg liegen!!!
Vielleicht ist es auch gut so! |
|
Back to top |
|
|
ts77 Apprentice
Joined: 23 Mar 2003 Posts: 200 Location: Berlin, Germany
|
Posted: Thu Jun 26, 2003 10:31 pm Post subject: |
|
|
wo ist das problem?
die können doch mit ihrem fork ihrer wege gehen.
nichts bleibt halbweg liegen, gentoo geht weiter (offensichtlich). |
|
Back to top |
|
|
phelan Tux's lil' helper
Joined: 22 Aug 2002 Posts: 110 Location: Zürich, Switzerland
|
Posted: Fri Jun 27, 2003 6:16 am Post subject: |
|
|
Ich denke, dass der Fork vorallem gutes mit sich bringt:
Der Ehrgeiz der Entwickler wird durch die gegenseitige Konkurenz angespornt. Wenn es noch eine zweite Plattform gibt, werden vielleicht mehr Neuerungen ausprobiert, von welchen man sich ja dann die gewünschten rauspicken kann! |
|
Back to top |
|
|
Beforegod Bodhisattva
Joined: 10 Apr 2002 Posts: 1494 Location: Frankfurt/Main
|
Posted: Fri Jun 27, 2003 7:34 am Post subject: |
|
|
Aber dieser Ehrgeiz kann schnell in Fanatismus enden, wenn jeder für "sein Projekt" alles tut und das andere dann nicht mehr akzeptiert usw. Es wird bald so manchem Flame-War dazu geben, aber egal.
Meine Sorge liegt darin, das evt. wirklich gute Neuerungen nicht für das jeweilige andere Projekt zugute kommt.
Aber warten wir mal die ENtwicklung ab. |
|
Back to top |
|
|
bonsaikitten Apprentice
Joined: 01 Jan 2003 Posts: 213 Location: Shanghai, China
|
Posted: Sat Jun 28, 2003 2:46 pm Post subject: |
|
|
Nachdem Gentoo alle interessanten Entwicklungen einfach assimiliert, mache ich mir kaum Sorgen ... sollte der Fork wirklich neue Entwicklungen mit sich bringen, wirds einfach nach Gentoo zurueckportiert. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9559 Location: beyond the rim
|
Posted: Mon Jun 30, 2003 11:29 am Post subject: |
|
|
Das einzige was mir Sorgen machen würde wäre, wenn in grösserem Umfang Resourcen (v.a. Entwickler, aber auch Hardware, User, ...) von Gentoo nach Zynot gehen. Dann müsste man sich allerdings fragen, ob Zynot nicht besser ist als Gentoo. Momentan sieht das zum Glück noch nicht so aus, allerdings sind einige der Ideen von Zynot für portage (bzw. deren neues Paket Management) recht interessant. Mal sehen wie sich das weiterentwickelt. |
|
Back to top |
|
|
JensZ Guru
Joined: 15 Feb 2003 Posts: 339 Location: Freiburg
|
Posted: Mon Jun 30, 2003 6:13 pm Post subject: |
|
|
Hab't ihr euch mal die Gründe für die Aufspaltung durchgelesen?
Ich will mir hier kein Urteil erlauben, aber sollte das wirklich so gelaufen
sein ist es eine Sauerei. Wie dem auch sei, hab ich das Gefühl, das
die Zyklen in denen neue Updates im Portage erscheinen merklich
größer geworden sind (kann natürlich auch sein das ich mich vertue,
oder einfach nur die falschen Packete). Das soll keine Anklage an
die Entwickler sein, es ist ein große Leistung überhaupt ein packet zu
betreuen, zumal die meißten Entwickler mehr als ein Packet betreuen.
Es mag aber ein Indiz dafür sein, das hinter den Kulissen ganz schön
was los ist... |
|
Back to top |
|
|
DieMumiee n00b
Joined: 20 Apr 2003 Posts: 2
|
Posted: Tue Jul 01, 2003 8:28 am Post subject: |
|
|
Am Ende des Artikels ist ein Link zu einem zweiten "Fork". Wobei es sich hierber nur um einen portage fork handelt, wenn überhaupt. Dieser Weggang von Geert Beven hat mich deutlich stärker erschreckt. Die Art wie D.Robbins über portage2 entschieden hat, hat mir überhaupt nicht gefallen. Eine Skriptsprache für so etwas wichtiges wie dem Paketmanager gegenüber einer compilierten Sprache vorzuziehen sollte viel genauer begründet werden.
Ich wäre wirklich froh wenn es ein C++ emerge gäbe, weil es einfach schneller wäre, und die Entwickler den Compiler als weitere Korrekturinstanz hätten. Python bietet eigentlich nur den Vorteil dass es leichter zu lernen ist, und die üblichen Nachteile einer Skriptsprache. Dass in C++ viele Dinge von Grund auf entwickelt werden müssten die in Python schon vorhanden sind sollte die Entwickler bei der Größe der Community eigentlich nicht abschrecken. Ich nehme an dass D.Robbins C++ abgelehnt hat weil er selbst am portage programmieren möchte, und damit nicht umgehen kann.
Aber sollte das zum Aufgabenbereich eines Projektleiters gehören? |
|
Back to top |
|
|
MasterOfMagic l33t
Joined: 20 Aug 2002 Posts: 677 Location: Vienna, Austria
|
Posted: Tue Jul 01, 2003 10:48 am Post subject: |
|
|
ja das stört mich auch irgendwie. ich muss bei gentoo ja python am rechner haben, damit ich überhaupt was installieren kann. hätte man diese sachen (wenn schon in einer interpretersprache) nicht auch gleich in bash realisieren können oder hab ich da jetzt was übersehen. ich meine ne shell hat so ziemlich jeder auf seinem linuxrechner aber python ist ja nun nicht unbedingt das was man unbedingt auf seinem rechner haben will.
mfg
masterofmagic _________________ Gentoo 1.4
Kernel 2.4.24
KDE 3.1.5 |
|
Back to top |
|
|
Beforegod Bodhisattva
Joined: 10 Apr 2002 Posts: 1494 Location: Frankfurt/Main
|
Posted: Tue Jul 01, 2003 11:33 am Post subject: |
|
|
Dei Gründe warum es diese Spaltung gibt sind heiss diskutiert und leider sind auch viele Unwahrheiten dazu gekommen. Leider kenne ich nicht die Wahrheit (wie viele andere auch nicht), aber ich bin der Meinung das man sich darüber nicht das Maul zerfetzen muss (tschuldigt diesen ordinären Ton). Wenn es jemanden nicht gefällt wie das System verwaltet wird, bitteschön... entweder selber was machen, oder bei dem Zweit Projekt (das sein Hauptaugenmerk auf kleine Systeme legt!) mitwirken.
Und wenn die Entwickler (oder D. Robbins) der Meinung ist das Python einfach besser ist für emerge (ob es nun stimmt oder nicht!) dann ist das als Projektleiter nunmal sein letztes Wort.
Es gibt genug alternative zu Gentoo und von meiner Seite kann ich weder über Python klagen, noch über die Politik die D. Robbins vertritt bzw. durchführt. |
|
Back to top |
|
|
haceye Apprentice
Joined: 22 May 2003 Posts: 187 Location: Stuttgart, Germany
|
Posted: Tue Jul 01, 2003 12:06 pm Post subject: |
|
|
Hi,
Ich sehe das auch nicht so schwarz. Ich denke eher, dass durch die Konkurrenz (wenn überhaupt, beide verfolgen ja in gewisser Weise auch andere Ziele...) beide Distributionen besser werden.
Zu Python: Ich persönlich sehe da auch keinen Nachteil. Der einzigste Vorteil von C++ besteht meiner Meinung nach darin, dass Portage wirklich schneller wäre, aber für Python spricht, dass es leichter zu erlernen ist, meisst viel weniger Code erfordert, da es praktisch für alles schon Module/Funktionen/... gibt.
Ausserdem ist Portage als Python Script leicht erweiterbar. Ein "import portage" genügt, und man kann ganz schnell eigene, auf Portage aufbauende Scripte schreiben.
Finde es allerdings auch etwas komisch, dass keine genauen Gründe dafür genannt wurden.
Ich mag auf jeden Fall gentoo (und damit Portage) so wie es ist.
David _________________ faster 'emerge -s'? emerge esearch |
|
Back to top |
|
|
kopfarzt Apprentice
Joined: 05 Apr 2003 Posts: 170 Location: Vienna, Austria
|
Posted: Tue Jul 01, 2003 12:47 pm Post subject: |
|
|
Ich glaube eigentlich nicht, dass eine Scriptsprache in diesem Fall viel langsamer als C++ ist. Schliesslich handelt es sich nicht um rechenintensive Tasks mit astronomischen Schleifen (wie etwa bei einem Raytracer) sondern um logische Tasks. Es wird vermutlich viel mit Listen, Dictionaries und Strings gearbeitet und eine Menge Textfiles geparsed, was innerhalb von Python sowieso "native" (also hochoptimiert in C) abläuft. Man erspart sich das gesamte Speichermanagement wo man bekanntlich einiges an Fehlern produzieren kann, sowohl Leaks, als auch suboptimale Nutzung usw. Wer nicht glaubt, daß eine Scriptsprache hier genauso schnell, wenn nicht oft sogar schneller ist (in der Praxis), soll mal nach Benchmarkvergleichen zwischen C++ und z.B. Java suchen (da gabs mal welche am Netz).
Aber neben der Geschwindigkeit ist meiner Meinung nach ein wichtiger Punkt für Python bzw. eine Scriptsprache die Plattformunabhängigkeit, da die meisten Python Module auf jeder Plattform gleich aussehen.
Das ganze in Shell zu programmieren wäre wahrscheinlich machbar, aber halte ich persönlich für extrem mühsam und unübersichtlich (z.B. Datenstrukturen, Kapselung?).
Ich finde die Entscheidung für eine Scriptsprache richtig und bin auch froh, daß es sich um Python handelt, weil das einfach eine klare und schöne Sprache ist. Mit einer der Gründe warum ich Gentoo so nett finde.
kopfarzt |
|
Back to top |
|
|
haceye Apprentice
Joined: 22 May 2003 Posts: 187 Location: Stuttgart, Germany
|
Posted: Tue Jul 01, 2003 12:59 pm Post subject: |
|
|
Hi,
Stimme vollkommen mit dir überein.
Ich glaube auch, dass Portage oft nicht wegen Python langsam ist, sondern weil z.B. der Portage-Tree, bzw. der /var/db/pkg-Tree als Verzeichnissbaum angeordnet ist. Mit einer Datenbank im Hintergrund würde das bestimmt auch etwas schneller laufen, aber mir gefällt es so viel besser, da es übersichtlicher ist, und man auch gut damit arbeiten kann (man braucht nicht SQL o.ä. zu lernen).
kopfarzt wrote: | Wer nicht glaubt, daß eine Scriptsprache hier genauso schnell, wenn nicht oft sogar schneller ist (in der Praxis), soll mal nach Benchmarkvergleichen zwischen C++ und z.B. Java suchen (da gabs mal welche am Netz). |
Hmmm... Java ist doch keine Scriptsprache?!
ciao David _________________ faster 'emerge -s'? emerge esearch |
|
Back to top |
|
|
JensZ Guru
Joined: 15 Feb 2003 Posts: 339 Location: Freiburg
|
Posted: Tue Jul 01, 2003 8:33 pm Post subject: |
|
|
vielleicht gibt's in der neuen Distri ja ne Lösung die besser ist, mal sehen
was die so auf die Beine stellen, wenn's besser ist kann man das ja in
Gentoo assimiliere ... |
|
Back to top |
|
|
kopfarzt Apprentice
Joined: 05 Apr 2003 Posts: 170 Location: Vienna, Austria
|
Posted: Sun Jul 06, 2003 7:00 pm Post subject: |
|
|
haceye wrote: |
Hmmm... Java ist doch keine Scriptsprache?!
|
*grins* was ist denn eine Scriptsprache?! Habe mich in diesem Fall der hier verwendeten Nomenklatur angepaßt. Python ist (wie Java auch) eine interpretierte Byte-Code Sprache. *.pyc entspricht *.class also auch hier echt vergleichbar.
kopfarzt
PS: mich würde allerdings interessieren, ob der Begriff Scriptsprache vielleicht doch noch eine tiefere Bedeutung hat oder einfach für alle interpretierten Sprachen gilt, oder etwa nur für die, die keinen Byte-Code erzeugen...? |
|
Back to top |
|
|
haceye Apprentice
Joined: 22 May 2003 Posts: 187 Location: Stuttgart, Germany
|
Posted: Sun Jul 06, 2003 7:22 pm Post subject: |
|
|
Hi,
Naja, der Unterschied besteht meiner Meinung nach darin, dass Java kompiliert werden muss, und Python nicht. Das ist bei Python nur eine Option, gibts bei Perl z.B. auch.
Deiner Definition nach wäre dann ja C# auch eine Scriptsprache.
ciao David _________________ faster 'emerge -s'? emerge esearch |
|
Back to top |
|
|
beejay Retired Dev
Joined: 03 Oct 2002 Posts: 924 Location: Flensungen (das liegt neben Merlau)
|
Posted: Mon Jul 07, 2003 5:32 am Post subject: |
|
|
Das Problem liegt daran, dass Portage bis zu 300 MB (!) an Metadaten mitverwalten muss. Metadaten sind die ganzen Datenabfälle, die beim Auflösen von Abhängigkeiten benötigt werden bzw. entstehen. Diese müssen jedesmal neu berechnet werden, woraus ein Aufwand von vielen kleinen Zugriffen entsteht, die zusammengenommen aber riesig gross sind.
Zumindest durch einen Kern in C (oder C++, denn der Portage-Code hat ja Klassen implementiert) könnte sich einiges an Geschwindigkeit herausholen lassen. Sinnvoller wäre es aber, die Metadaten anders zu verwalten - wie schon erwähnt z.B. über eine Datenbank. Dann würde sich aber wieder die Frage stellen: "Ich brauche eine installierte Skriptsprache und eine Datenbank für mein Paketsystem - was ist das?". Jede erdenkbare Datenbank hat selbst auch noch Abhängigkeiten, und eine Datenbankmaschine in Python zu entwickeln würde das ganze zwar eleganter machen, es aber genau so schnell halten. Es wäre im Endeffekt genauso, als bräuchte man eine eigene Tankstelle und eine Garage, nur um einen Rasenmäher besitzen zu können - schlechtes Beispiel, aber ich denke es verdeutlicht gut den Sachverhalt.
Mit gutem C/C++-Code könnte man dieses Manko schon ausräumen. _________________ Dort wo schwarzer Rauch aufsteigt, sich alsbald ein Fehler zeigt.
www.paludis-sucks.org | www.gentoo.de | www.gentoo-ev.org | www.gentoo.org |
|
Back to top |
|
|
Pietschy Apprentice
Joined: 25 Jul 2002 Posts: 237
|
Posted: Mon Jul 07, 2003 8:03 pm Post subject: |
|
|
Da ich nichts vom programmieren verstehe (ich meine selbst meine scripte sind mies) nehme ich das mal so hin.
Die Datenbank klingt trotzdem gut, es gibt doch sicher einmöglichkeit sowas als zusatzfeature das sinnvoll aber nicht undbedingt notwendig ist in gentoo einzubauen, so wie ccache.
Ronny
Nachtrag: Ups ist das oT |
|
Back to top |
|
|
haceye Apprentice
Joined: 22 May 2003 Posts: 187 Location: Stuttgart, Germany
|
Posted: Mon Jul 07, 2003 8:27 pm Post subject: |
|
|
Hi
Naja, das mal "so schnell" als Zusatzfeature zu implementieren geht glaube ich nicht. Um das dann sinnvoll zu nutzen müsste man z.B. die ebuilds in eine Tabelle schreiben, und unterschiedliche Felder wie HOMEPAGE, DESCRIPTION, ... usw. haben. Komplexere Sachen wie (R)DEPEND müssten evtl. schon wieder in eine neue Tabelle. Ich weiß nicht wie das mit dem ganzen Caches usw. aussieht.
Allerdings meine ich schonmal etw. ähnliches im "Portage & Programming" Forum gesehen zu haben. Vielleicht wird ja doch noch was draus.
Mir ist Portage - so wie es ist - schnell genug.
Ach und wo wir gerade beim Thema (oder eigentlich nicht) sind, hier eine kleine Portage-Erweiterung von mir. Und zwar handelt es sich dabei um ein schnelleres emerge search (Eine der Aufgaben, bei der Portage wirklich sehr langsam ist).
Mein Script hat fast die gleiche ausgabe wie emerge search (bis auf "Size of downloaded files" und ein paar Kleinigkeiten), ist aber auf meinem Rechner zw. 40 und 1000 mal schneller.
Ok, das funktioniert natürlich nur mit einem kleinen Trick... Und zwar einem Index. (Ähnliches Prinzip wie bei locate (updatedb))
wer sich das ganze mal anschauen will, kann sich die drei Scripte hier zusammenkopieren:
eupdatedb - Shellscript (chmod +x eupdatedb) um das Pythonscript aufzurufen.
Code: | #!/bin/bash
start=`date +"%s"`
python eupdatedb.py > db.py
# compile python file
python -c 'import db'
rm db.py
stop=`date +"%s"`
echo Updated Database in $(($stop - $start)) seconds
|
eupdatedb.py - Pythonscript um den Index zu generieren, Warnung, ganz schlechter Code - bitte nicht lesen
Code: | #!/usr/bin/env python2.2
import portage
from output import red, darkgreen, green, bold
import sys
vartree = portage.vartree()
def version(pkg):
# from emerge
if len(pkg) > 1:
parts = portage.catpkgsplit(pkg)
if parts == None:
return red("[ Not installed ]")
if parts[3] != 'r0':
version = parts[2]+ "-" + parts[3]
else:
version = parts[2]
return version
else:
return ""
print "db = {"
for pkg in portage.portdb.cp_all():
masked = ""
pkgv = portage.portdb.xmatch("bestmatch-visible", pkg)
if not pkgv:
pkgv = portage.best(portage.portdb.xmatch("match-all", pkg))
masked = red(" [ Masked ]")
try:
if len(pkgv) > 1:
homepage, description = portage.portdb.aux_get(pkgv, ["HOMEPAGE", "DESCRIPTION"])
else:
homepage, description = ["", ""]
except KeyError:
homepage, description = ["", ""]
str = green("*") + " " + bold(pkg) + masked + "\n"
str += " " + darkgreen("Latest version available: ") + version(pkgv) + "\n"
str += " " + darkgreen("Latest version installed: ") + version(vartree.dep_bestmatch(pkg)) + "\n"
str += " " + darkgreen("Homepage: ") + homepage + "\n"
str += " " + darkgreen("Description: ") + description + "\n"
print repr(pkg) + ": " + repr(str) + ","
print "}"
|
esearch - Der Ersatz für emerge search, kleines Pythonscript (chmod +x)
Code: | #!/usr/bin/env python2.2
from db import db
from sys import argv
import re
pattern = re.compile(argv[1], re.IGNORECASE)
for (key, str) in db.items():
if pattern.search(key):
print str
|
Und so wird das ganze benutzt:
Code: |
shark@gentoo esearch $ # Alle Dateien zusammenbasteln und in einem Ordner speichern
shark@gentoo esearch $ chmod +x esearch
shark@gentoo esearch $ chmod +x eupdatedb
shark@gentoo esearch $ ./eupdatedb
Updated Database in 16 seconds
shark@gentoo esearch $ esearch kdebase
* kde-base/kdebase
Latest version available: 3.1.2
Latest version installed: 3.1.2
Homepage: http://www.kde.org/
Description: KDE base packages: the desktop, panel, window manager, konqueror...
|
ciao David _________________ faster 'emerge -s'? emerge esearch |
|
Back to top |
|
|
magir Tux's lil' helper
Joined: 19 Sep 2002 Posts: 95 Location: Germany
|
Posted: Mon Jul 07, 2003 8:31 pm Post subject: |
|
|
Da kann ich nur zurstimmen.
Datenbank ist nicht nur cool, ist auch sehr funktional und schnell.
Deswegen wird auch nächstes Windows auf einer DB stat file-system basieren. Ich meine, das File-System ist dann eine grosse DBMS.
Datenbank ist leicht zu pflegen und leicht erweiterbar. Außerdem bekommt man viel Funktionalität, so zu sagen, umsonst, sprich Abhängigkeiten wäre zum beispiel eine einfache "referenielle intergrität". Man könnte aber komplete gentoo-configuration in einer DB unterbrigen. Stellt euch nur eine Tabelle mit USE-Flags vor. Ist es nicht cool immer alle USE-Flags auf einen Blick zu haben!? Man könnte diese dann noch mit Zeitstempel versehen und schon kann man einfach für jede Version richtige USE-Flags rauskriegen. Sollche Beispiele kann man sehr weit fortsetzen... So was benötigt natürlich guter Planung, wäre aber zukunftsweisend!!! Was meint Ihr? |
|
Back to top |
|
|
Pietschy Apprentice
Joined: 25 Jul 2002 Posts: 237
|
Posted: Mon Jul 07, 2003 9:11 pm Post subject: |
|
|
jaja so isser der haceye
Redet mir meine DB madig und bringt mir gleichzeit ein Geschenk
Genau sowas habe ich gesucht eine schnelle Suche, dankeschön.
Und da wir gerade so schön off Topic sind, beejay ist es möglich auf gentoo.de eine script Datenbank (schonwieder dieses Wort) einzurichten, wo alle möglichen "werke" eingestellt werden könnten. Ich habe schon sehr viel gute scripte hier im Forum in vergessenheit geraten sehen, auf getnoo.de wären sie immer schnell verfügbar und könnte sich zu wahren fundgrube entwickeln.
Ronny |
|
Back to top |
|
|
beejay Retired Dev
Joined: 03 Oct 2002 Posts: 924 Location: Flensungen (das liegt neben Merlau)
|
Posted: Tue Jul 08, 2003 4:46 am Post subject: |
|
|
Pietschy wrote: | jaja so isser der haceye
Und da wir gerade so schön off Topic sind, beejay ist es möglich auf gentoo.de eine script Datenbank (schonwieder dieses Wort) einzurichten, wo alle möglichen "werke" eingestellt werden könnten. Ich habe schon sehr viel gute scripte hier im Forum in vergessenheit geraten sehen, auf getnoo.de wären sie immer schnell verfügbar und könnte sich zu wahren fundgrube entwickeln.
Ronny |
Ich werde das mal abklären, sollte aber kein Problem sein - vorerst aber nur als Text, nicht zum Download (das sollte sich aber u.U. auch verwirklichen lassen) _________________ Dort wo schwarzer Rauch aufsteigt, sich alsbald ein Fehler zeigt.
www.paludis-sucks.org | www.gentoo.de | www.gentoo-ev.org | www.gentoo.org |
|
Back to top |
|
|
JensZ Guru
Joined: 15 Feb 2003 Posts: 339 Location: Freiburg
|
Posted: Tue Jul 08, 2003 2:56 pm Post subject: |
|
|
Naja eine Datenbank ist immer so eine Sache, wer schonmal ne rpm
distri hatte der's die Datenbank zerschossen hat weiß was ich meine.
Wär halt zu überlegen, was man wie löst, grundsätzlich ist ne Datenbank
zwar am besten, aber ich denke keiner will in den rpm like Sumpf
absacken. Und das gesammt Emerge auf C++ umzustellen halt ich für
eine sehr gute Idee, da dürfte noch einige Geschwindigkeitsvorteile
möglich ein. Außerdem wäre es dann leichter verschiedene UI's zu bauen. |
|
Back to top |
|
|
lonF Apprentice
Joined: 04 Apr 2003 Posts: 193 Location: Ostfildern
|
Posted: Tue Jul 08, 2003 3:52 pm Post subject: UI's und RPMdb Prob |
|
|
das RPMdb prob kenne ich zur genüge daher find ich eine db nicht so toll.
Hat aber wie gesagt alles Vor- und Nachteile.
Interessant ist das mit den UI's. Stellt sich nur die Frage will das überhaupt jemand. Ich ziehe die Shell vor hab mit UI's (hauptsächlich unter RedHat) schon manches böses erwachen gehabt. Hab immer wieder alles von Hand gemacht. Und bin damit immer besser gefahren.
Bin nun auch kein Profi was programmieren angeht. Aber ich denke mit Regulären Ausdrücken wie Sie in jeder vernünftigen "Scriptsprache" existieren, hat man wesentlich schneller TextFiles geparsed. Oder???
Wenn ich falsch liege korrigiert mich. |
|
Back to top |
|
|
Pietschy Apprentice
Joined: 25 Jul 2002 Posts: 237
|
Posted: Tue Jul 08, 2003 7:22 pm Post subject: |
|
|
Ok das für und wieder einer Datenbank, kann wohl in einer sehr langen diskussion enden (hab aber auch noch keine Ehrfahrungen mit einer abgeschossenen rpmDB, (jahrelang SuSE )).
Ich denke aber das es im Portage einiges an geschwindigkeit zu verbessern gibt, zB das Script 5 Posts oben drüber. Hey man ich liebe es.
Und im Grunde ist es nichts weiter als eine Abbild des Portagebaum in einer Datenbank. (wenn ich mich nicht verlesen habe (habe ich schon erwähnt, das mein scriptisch nicht so toll ist?))
Emerge auf C++ umstellen, ist glaube ich nicht das was die Entwickler im Sinn haben.
Ronny |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|