Von Windows 7 fan am Di, 15. Dezember 2009 um 13:53 #
Warum macht man es nicht endlich wie beim guten Windows indem man .exe dateien anbietet ? da muss man nur einmal klicken, das ist doch echt am aller einfachsten.
Du hast die Paketverwaltung nicht verstanden! Windows hat sowas gar nicht, insofern kann man es nicht vergleichen. P.S. schon mal auf eine *.deb Datei geklickt?
Das Problem ist, das das im Gegensatz zur Exe bei Windows in 5 Jahren mit dem selben rpm aufgrund von fehlenden Abhängigkeitn nicht mehr funktionieren wird. (Wenn nicht gleich Inkompartibilitäten in den Pfaden oder rpm auftreten)
Diese Möglichkeit hast du unter Linux auch. Du kannst alle Librarys entwerder statisch linken, oder sie dynamisch Linken und das ganze unter /opt ablegen. Alternativ kannst du auch gegen LSB librarys dynamisch linken und gegen alles andere statisch.
Pakte bauen welche auf (fast) allen Distributionen laufen, und über Jahre hinweg funktionieren ist auch unter Linux möglich. Im fall von OSS Software wird das aber in der Regel nicht gemacht, da es der ineffizientere weg ist, und es nicht notwendig ist weil neuere Versionen der Distribution sowieso wieder Pakete mitliefern.
> Eben, nur welche Software liefert ihre dlls nicht gleich mit... Und mir hat bis heute noch keiner den Vorteil daran nennen können, die DLLs können sie dann doch gleich mit reinlinken, wenn eh jeder sein eigenen hat.
>Und mir hat bis heute noch keiner den Vorteil daran nennen können, die DLLs können sie dann doch gleich mit reinlinken, wenn eh jeder sein eigenen hat. Das Zauberwort lautet Modularisierung.
Das die typisch verwendete DLLs selbst mitliefern ist ein großer Nachteil, denn wer aktualisiert denn diese, wenn es mal eine Sicherheitslücke in der gegebenen Version gibt?
Hast du schonmal so ne DLL mit Sicherheitslücke genommen und durch eine neue ersetzt? Tatsache ist doch, daß das kein Windows Anwender macht.
D.h. wenn's für die Anwendung nicht irgendwann nen Patch gibt, der das repariert, dann hat man für Zig Jahre ne Anwendung mit einer DLL die ne Sicherheitslücke hat.
So etwas passiert dir unter Linux in der Regel nicht, da hier die Systembibliotheken einzeln upgedatet werden und dennoch noch zu den alten Binarys der gleichen Distributionsversion passen.
Von vicbrother am Di, 15. Dezember 2009 um 15:19 #
War es unter NextStep/Mac nicht so, dass die Programme ein Icon waren welches man auch einfach auf einen anderen Datenträger verschieben konnte und dann das ganze Programm schön verpackt gesichert hatte?
Von Paketmanagementfan am Di, 15. Dezember 2009 um 17:08 #
Weil du dann auf den Hersteller der Exe-Datei vertrauen musst, dass die Deinstallation vernuenftig laeuft. (Schonmal ein zugemuelltes Windowssystem ausgemistet?) Bei Paketen ist der Witz, zumindest so lange sie ohne Skripte auskommen, dass du sie problemlos wieder deinstallieren kannst, ohne irgendwelche Spuren.
Abgesehen davon hast du so unter Linux in der Regel eine echte One-Click-Installation.
Ich selbst benutze sie auch für Hobby-Sachen. Man hat einfach den Komfort von C# oder Java (von der Sprache her) ohne auf ein natives Kompilat zu verzichten zu müssen. Gibt halt keine ausgefeilten IDEs à la Eclipse, NetBeans oder Visual Studio, auch wenn es einige Projekte diesbezüglich gibt. Derzeit fährt man am besten mit dem Texteditor seiner Wahl oder mit gedit + Vala-Plugin.
Welchen Komfort von Java meinst Du da genau? Der muss mir bisher immer entgangen sein
Ich habe größere Projekte sowohl in Java als auch in .Net (VB.Net und C#) geschrieben und in der Zwischenzeit ziehe ich Java C# vor. Die Java Klassenbibliothek ist einfach besser als die .Net Klassenbibliothek, Java bietet mir um multithreaded zu Programmieren (in .Net gibts nichtmal ne BlockingQueue), Swing ist viel, viel besser als Windows.Forms und meiner Meinung nach auch noch besser als WPF. Die JVM optimiert besser, kann bald Stack Allocation, der Garbage First Kollektor ist besser als das, was .Net zu bieten hat. C# ist meiner Meinung nach mit lauter unnützen Zeug überladen und mit Scala gibts eine Sprache für die JVM, die C# einfach nur alt aussehen läßt.
Swing ist viel, viel besser als Windows.Forms und meiner Meinung nach auch noch besser als WPF >> Ich glaube du hast dir WPF nicht angeschaut oder nicht verstanden. Einfach nur lächerlich. C# ist meiner Meinung nach mit lauter unnützen Zeug überladen >> With great power comes great responsibility, mehr gibts dazu nicht zu sagen. Die Java Klassenbibliothek ist einfach besser als die .Net Klassenbibliothek >> Beispiele? Java bietet mir um multithreaded zu Programmieren (in .Net gibts nichtmal ne BlockingQueue), >> Aha, wahnsinns argument.Ne BlockingQueeu ist auch ein monster zum implementieren oder?? Achja, apropo multi-threading -> Mit ParallelFX spricht sicher noch viel mehr für Java, oder?
Ich glaube du hast dir WPF nicht angeschaut oder nicht verstanden. Einfach nur lächerlich.
Ich hab mit WPF einen Editor (>30000) Zeilen Code geschrieben. WPF hat einige nette Konzepte, aber MVC fehlt praktisch komplett. In Swing kann ich problemlos 100000 Items in ein Listview oder ein Treeview stecken und die GUI ist immer noch schnell. Mit WPF kann man das völlig vergessen. Mit WPF ist es auch nicht möglich, einfach Linien oder Bezier-Pfade in ein Bitmap zu rendern, sondern es wird jedesmal ein Scene-Graph aufgebaut, was für manche Anwendungen (z.B. in einem Telemetrie-System Plots mehrmals pro Sekunde neu zu zeichnen) nicht akzeptabel ist. WPF ist nicht schlecht, aber wegen der genannten Einschränkungen würde ich Swing im Moment vorziehen.
With great power comes great responsibility, mehr gibts dazu nicht zu sagen.
Dann lieber C++, das hat wenigstens Mehrfachvererbung, die C++ Templates sind den C# Templates meilenweit überlegen usw.
Ne BlockingQueeu ist auch ein monster zum implementieren oder
Ne Priority-Blocking Queue in fehlt in .Net auch. Es ist in .Net nicht möglich, über alle managed threads zu iterieren (vergiß die Process-Klasse, die gibt dir nur die unmanaged threads), es gibt kein memory mapped IO, es gibt keine Softreferences, bzw. sie funktionieren nicht. Mag ja sein, daß du das alles selber programmieren kannst (was ich allerdings nicht glaube), aber warum sollte man, wenn Java das alles mitbringt?
Achja, apropo multi-threading -> Mit ParallelFX spricht sicher noch viel mehr für Java, oder?
Wenn das dieses .Net Actor Framework ist, daß ich mir mal angesehen habe, kann ich nur sagen daß das ganze in Scala elegant gelöst wurde, ohne jede Menge neue Keywords einzuführen und die Sprache aufzublähen. Java ist sicher nicht perfekt, aber die Alternative ist nicht C# sondern Scala, die JVM ist schon ziemlich gut.
Ich selbst benutze sie auch für Hobby-Sachen. Man hat einfach den Komfort von C# oder Java (von der Sprache her) ohne auf ein natives Kompilat zu verzichten zu müssen.
Einer der großen Vorteile von Java und C# ist der Garbage Collector, den Vala nicht hat. Ein anderer Vorteil von Java oder C# sind die guten IDEs und daß man die Sprachen leicht debuggen kann. Die Vorteile sind mit Vala auch weg. Außerdem ist C# meiner Meinung nach total überfrachtet und übermäßig komplex, keine Ahnung warum Vala unbedingt C# als Vorbild nehmen mußte. Scala z.B. ist eine wirklich schöne Sprache, dagegen schaut C# ziemlich alt aus.
Von vicbrother am Di, 15. Dezember 2009 um 16:17 #
Vala ist eine Sprache die für die GNOME-Entwicklung geschaffen wurde und C++ zu umgehen versucht. Erinnere dich bitte an die vielen lustigen Beiträge wie toll C und böse C++ sei in den entsprechenden News. Wer C++ nutzt, der setzt i.d.R. auf Qt...
Die meisten wirklich komplexen Applikationen werden immer noch in C++ geschrieben, weil es für solche Applikationen immer noch keinen wirklich sinnvollen Ersatz gibt.
Also gibt es C++ für Anwendungen die die Welt nicht braucht? Meintest du das wirklich?
Ich meinte daß es für komplexe, performance-kritische Anwendungen praktisch immer noch keine Alternative zu C++ gibt. So ziemlich alle modernen Game-Engines dürften in C++ geschrieben sein. C++ ist nicht schlecht, es gibt nur zuviele Leute, die es nicht verstehen und vermurksten Code damit produzieren. Aber für Leute die C++ wirklich verstehen, ist es eine sehr mächtige, produktive Sprache, die Dinge erlaubt, die man mit anderen Sprachen nicht ohne weiteres machen kann.
Einer der großen Vorteile von Java und C# ist der Garbage Collector, den Vala nicht hat
Garbage-Collectoren haben auch Nachteile. Sie schlagen oft irgendwann zu, wenn es nicht erwartet wird und lassen Anwendungen teilweise "sluggish" erscheinen, geben Speicher erst spät wieder frei und sind für Echtzeit-Anwendungen nicht geeignet. Vala macht halt automatische Referenzzählung, wo man halt den kleinen Preis zahlen muss, dass man manchmal auf zyklische Referenzen achten muss, was aber kein Problem ist, wenn man sich das Design seiner Klassen anschaut.
Ein anderer Vorteil von Java oder C# sind die guten IDEs und daß man die Sprachen leicht debuggen kann.
Vala-Code kann man auch debuggen, mit dem normalen GDB oder einem Frontend dafür. Wenn man mit -g kompiliert kann man durch den Vala-Code (nicht den C-Code) steppen.
Scala z.B. ist eine wirklich schöne Sprache, dagegen schaut C# ziemlich alt aus.
Scala ist gut. Aber teilweise auch überfrachtet. Ich sag nur XML-Literale. Hat meiner meinung nach in einer Sprachsyntax nix zu suchen. XML ist bald out, derzeit ist JSON angesagt. Sowas gehört nicht in die Syntax.
Garbage-Collectoren haben auch Nachteile. Sie schlagen oft irgendwann zu, wenn es nicht erwartet wird und lassen Anwendungen teilweise "sluggish" erscheinen, geben Speicher erst spät wieder frei und sind für Echtzeit-Anwendungen nicht geeignet.
Für harte Echtzeitanwendungen ist der G1 vielleicht immer noch nicht geeignet (genauswo wenig wie Linux ohne RT Kernel), aber für Desktop-Anwendungen sollte das gut genug sein.
Vala macht halt automatische Referenzzählung, wo man halt den kleinen Preis zahlen muss, dass man manchmal auf zyklische Referenzen achten muss, was aber kein Problem ist, wenn man sich das Design seiner Klassen anschaut.
Referenz Counting kann ich in C++ und Objective-C seit Jahren haben.
Ich sag nur XML-Literale
Sicher ist Scala nicht perfekt. Aber immer noch deutlich besser als C#.
Referenz Counting kann ich in C++ und Objective-C seit Jahren haben.
Sagt ja auch niemand was dagegen. Wobei es in C++ schon sehr umständlich ist um jeden Typ dauernd std::shared_ptr<> (oder wie das heißt) und Co zu schreiben.
Von vicbrother am Di, 15. Dezember 2009 um 15:31 #
Der Wikipedia-Artikel schreckt eher ab:
Zwei Studenten schreiben eine Sprache - und wie wird die Weiterentwicklung gesichert?
Die Codebeispiele: Wow, zum Glück hat meine Grafikkarte >16 Mio Farben, sonst wäre der Highlighteffekt im Editor dahin -Aber warum braucht ein "Hello World" jetzt 6 Klammern und ein Semikolon? Python zeigt wie es wesentlich einfacher geht. Und wie groß ist das Programm im Endeffekt?
Ich kann Miranda, C, C++, Java, Pascal, Oberon, Python - wieso ist Vala nun besser? Das leuchtet mir noch noch nicht ein.
Der Hauptvorteil von Vala ist am Ende das man "reines" C erhält, aber mit einem Komfort der in etwa bei Java liegt, mit den schon genannten Nachteilen.
Für Libs ist das eine schöne sache, wie im verlinkten Originalartikel schon steht kann das z.B. (das von mir sehr geschätzte) Python nicht bieten.
Jedes Tool halt für seinen Zweck. Für Libs die man mit möglichst vielen Sprachen nutzen können soll ist Vala eine gute Idee. Aber ich glaube nicht das damit wirklich alles gemacht werden sollte.
Zwei Studenten schreiben eine Sprache - und wie wird die Weiterentwicklung gesichert?
So wie bei vielen anderen Open-Source-Sprachen auch. Durch die Entwickler und beitragende Community. Python wird ja auch nicht gerade von einem ISO-Gremíum entwickelt.
Aber warum braucht ein "Hello World" jetzt 6 Klammern und ein Semikolon? Python zeigt wie es wesentlich einfacher geht.
Dass du eine Haupteintritts-Funktion schreiben musst fällt bei einem großen Projekt nicht mehr ins Gewicht. Und wenn du auf Semikolon und freies Format verzichten willst gibt es Genie für dich.
Und wie groß ist das Programm im Endeffekt?
8345 Byte. Für ein native Binary normal. Da dürfte der halt noch der normale initiale ELF-Overhead dabei sein.
Miranda, C, C++, Java, Pascal, Oberon, Python
Miranda kenn ich nicht. Vorteile zu C: Syntax-Unterstützung für OOP und anderer Syntax-Sugar Vorteile zu C++: Einfachere Syntax, direkte C-ABI-Kompatibilität, Closures, Typ-Inferenz Vorteile zu Java: keine Runtime-Umgebung, Closures, Properties, Delegates, Typ-Inferenz Oberon kenn ich nicht. Pascal: C-ABI-Kompatibilität, sonst weiß ich nicht was Delphi / Object Pascal mittlerweile kann Python: keine Runtime-Umgebung, produziert C-Bibliotheken, die von anderen Sprachen gebunden werden können
Natürlich gibt es im Vergleich zu jeder Sprache auch Nachteile, wie bei allem.
Ich programmiere in Pascal mit FPC, und alle Anwendungen sind, wenn man es will, 100% C-ABI kompatibel. Einen Vorteil von Vala gegenüber Pascal sehe ich im deutlich leichtgewichtigeren Syntax und in der Möglichkeit wie in C an jeder Stelle variablen zu deklarieren.
Ah, hattest du ja geschrieben... Ein Vorteil an Pascal ist die klare Syntax und die Cross-Plattform-Fähigkeiten durch Abstraktion der entsprechenden Funktionen. Außerdem entfällt die verwendung von Pointern, wenn man sie nicht nutzen will, muss man es nicht zwangsläufig. Mit Delphi/Lazarus existieren auch gute IDEs für Pascal und man kann performante Webanwendungen schreiben.
Vorteile zu Java: keine Runtime-Umgebung, Closures, Properties, Delegates, Typ-Inferenz
Java hat zwar keine Closures, aber anonyme innere Klassen können auf als final deklarierte Variablen des umgebenden Contexts zugreifen, was sehr nahe an Closures kommt. Daß man nur auf final Variablen des umgebenden Contexts zugreifen kann, finde ich sinnvoll.
Delegates lassen sich mit Interfaces und anonymen inneren Klassen verwirklichen. Ist nicht ganz so elegant wie delegates, Netbeans und Co. fügen aber den ganzen Boilerplate-Code eh automatisch ein.
Properties sind meiner Meinung nach ziemlicher Unfug. In C# z.B. lassen sich Properties nicht als ref typen an Funktionen übergeben. Wenn schon Properties, dann sollen sie überall wie Felder funktionieren und nicht manchmal.
Type Inference wäre zwar nett. Naja, Scala hat Type Inference.
Wenn schon Properties, dann sollen sie überall wie Felder funktionieren und nicht manchmal. ==> Wirklich ein Wahnsinns-Argument gegen properties, oh mein .... *Augen-roll und weg*
Wenn schon Properties, dann sollen sie überall wie Felder funktionieren und nicht manchmal. ==> Wirklich ein Wahnsinns-Argument gegen properties, oh mein .... *Augen-roll und weg*
Das ist ein gutes Argument. In Scala z.B. sind Operatoren ganz normale Funktionen. In C# sind Operatoren statisch, daher lassen sich nicht überladen. In Scala läßt sich eine Funktion ohne Parameter mit einem Rückgabewert wie ein Feld des gleichen Typs benutzen, in C# geht das mit Properties manchmal, manchmal nicht. In Scala sind Funktionen einfach Objekte, in C# gibt es delegates, die eine Sonderstellung haben. Scala ist konsistent und elegant (ein paar Schwächen hat es natürlich auch), C# ist großer Haufen nicht-orthogonaler Features, daß allmählich zu einem zweiten C++ zu mutieren, ohne allerdings so mächtig wie C++ zu sein,
Von vicbrother am Di, 15. Dezember 2009 um 22:38 #
Danke tangram für deine Darstellung.
Ich habe ein wenig Bauchschmerzen damit, dass eine Metasprache genutzt wird, um in einer Sprache wie C zu programmieren. Das hört sich nach einer neuen Fehlerquelle an
Was mich wundert ist dass es zwar GNU-, KDE-, GNOME-, LXDE-, CD-, DVD-, XFCE-, E17-Distributionen gibt, aber noch keine Distribution, die sich auf eine einheitliche Sprachbasis konzentriert. Perl-Anwendungen gehören m.E. verboten, ebenso OCAML, HASKELL und andere obskure Sprachen Sollte das XO2 nicht rein auf Python und C basieren, damit die Kinder den Code analysieren können? Da trauere ich Oberon wirklich hinterher.
Prinzipiell könnte man bei Vala ja auch einfach den C-Code distributieren. Insofern passt Dein Beispiel nicht ganz. Davon abgesehen fände ich eine Gtk+-Anwendung mit Vala eher unproblematischer als das Gleiche in C.
> Perl-Anwendungen gehören m.E. verboten Du willst also alles, was du nicht verstehst, verbieten?
> Sollte das XO2 nicht rein auf Python und C basieren, damit die Kinder den Code analysieren können? Dann bettet man in C eben Assembler ein. Ist ja erlaubt und macht den Code sicher lesbarer.
Von vicbrother am Mi, 16. Dezember 2009 um 09:46 #
Du willst also alles, was du nicht verstehst, verbieten?
Verbieten direkt nicht, aber die Verwendung von Perl sollte unter Strafe gestellt werden
Perl ist keine Sprache die im Verdacht steht besonders gut lesbar zu sein. Selbst die kleinen Zehnzeiler können unlesbar sein. Lesbarkeit ist aber ein Kriterium für das Verständnis des Codes und damit auch für die Beherrschbarkeit. Beherrschbarkeit ist für Software aber ein Sicherheitsmerkmal.
Von mir aus kann es eine Distribution geben die nur auf Perl setzt. Aber die werde ich mir sicherlich nicht antun. Lieber eine Python-Distribution
Ich möchte allerdings auch noch auf spannedes Problem hinweisen: Es gibt eine Reihe von Firewalldistributionen, die mit Perl, Python u.a. Interpretern ausgestattet sind. Das macht es Angreifern nach der Kompromittation sehr einfach eigene Skripte auszuführen.
Von Flying Circus am Mi, 16. Dezember 2009 um 10:18 #
Kompromittation
Ist das was Ansteckendes? *g*
Was das Problem angeht, daß ein Angreifer Skripte ausführen kann ... wenn die Kiste kompromittiert ist, ist es mir wurst, ob er dafür Perl nimmt, Bash oder sonstigen Mist. Und wenn er ein Werkzeug nicht hat, lädt er's eben nach.
Objektorientierte Metasprache, die es erlaubt GObjects zu verwenden, als wäre es eine moderne objektorienterte Sprache.
Vala übersetzt in reines C. So kann man Objektorientierung nutzen ohne auf C++/C#/Java/Python.../... zuzugreifen, hat eine allgemeine Syntax, und geht auch nicht zu weit von C weg.
Von blumenwiese am Di, 15. Dezember 2009 um 14:53 #
Vom "Syntax-Sugar-Grad" her würde ich Vala grob zwischen Java und C# einordnen. Etwas mehr als Java (Closures, Properties, Delegates, Typ-Inferenz) und etwas weniger als C# (kein LINQ, kein Operator-Überladen). Und es hat ein paar Goodies, die keins von beiden bietet (z.B. String-Templates). Auf der Homepage gibt es neben einem allgemeinen Tutorial auch zwei Tutorials, die jeweils auf C#- und Java-Programmierer zugeschnitten sind und viele Code-Beispiele.
Von Der, der immer mit seinem dick am Di, 15. Dezember 2009 um 15:12 #
Anmerkung: Ruby und Pike sind Schwestersprachen für Python, für Leute, die mehr auf die klassische Klammersetzung und so stehen. Außerdem ist Pike in der Referenzimplementierung schneller. (beinahe wie Lua)
Ok, Roxen ist kein Framework, sondern ein Serverprogramm.... DANN HALT NICHT. Aber Teile vo Opera Mini sind damit gemacht worden. ...zumindest laut der engl. Wikipedia....
Von Julian Andres Klode am Di, 15. Dezember 2009 um 14:50 #
Erst mal muss ich sagen, dass ich noch nie einen Artikel mit meinem Namen drin gelesen habe. Nun aber ein paar Punkte bezüglich des Artikels:
> Das erstmals Ende August vorgestellte Projekt will [...] sich durch eine gesteigerte Geschwindigkeit auszeichnen Prinzipiell gesehen kann es schneller sein, muss es aber nicht, es ist prinzipiell nur ein Nebeneffekt der Wahl von SQLite 3, und nicht das Ziel.
> Ferner enthält die Lösung ein Kommandozeilenprogramm mit dem Namen »capt«. Ja, ich habe nur irgendwie Angst das man es mit cupt verwechseln könnte. Ein Vorteil des Namens wäre aber, dass man eine GTK+ Version dann gapt nennen könnte.
> Wie der Entwickler nun bekannt gab, soll APT2 bereits im Dezember in einer ersten Version veröffentlicht werden Ich meinte nur, dass ich den lokalen Code in das öffentliche Repository pushe ("it will be published" bezog sich auf den code aus "the internal branch has seen a lot of new code"). Die interne Branch ist jetzt aber an sich auch online und trägt den freudigen Namen "temp"; da einige sich das schon mal anschauen wollten. Ein Release vor Weihnachten wäre insofern auch dumm, da ich ja die Weihnachtsferien nutzen kann, weiter zu programmieren.
> Die aktuelle [Vala] Version enthält einen Fehler, der es unmöglich macht, APT2 zu compilieren. Um genau zu sein, haben die Veröffentlichen Vala Versionen die Angewohnheit, die Kopie eines Arrays welches mit null endet, nicht mit null enden zu lassen, weil die Kopie ein Element zu klein war.
Von lord-carlos am Di, 15. Dezember 2009 um 16:37 #
Na wenn du hier bist kann ich ja gleich mal ein paar fragen stellen. Bei apt unter debian testing dauert es immer so lange Programme zu installieren weil das hier so lange dauert: (Lese Datenbank ... XX%) Gerade bei kleinen Programm nimmt das Herunterladen und Entpacken nur ein Bruchteil der zeit ein wie das Lesen der Datenbank. Wird das bei apt2 anders/besser/schneller sein?
Mal angenommen man installiert Zwei von einander unabhaenige Programme, koennte er nicht schon das erste Installieren waerend das Zweite noch runterlaedt?
Von Julian Andres Klode am Di, 15. Dezember 2009 um 19:05 #
> Bei apt unter debian testing dauert es immer so lange Programme zu installieren weil das hier so lange dauert: > (Lese Datenbank ... XX%)
Das ist dpkg's Baustelle, und die Arbeiten scheinbar dran.
> Mal angenommen man installiert Zwei von einander unabhaenige Programme, koennte er nicht schon das erste Installieren waerend das Zweite noch runterlaedt?
Theoretisch wäre das machbar, aber es ist mir ein bisschen zu unordentlich.
Von Christopher Roy Bratusek am Di, 15. Dezember 2009 um 19:50 #
>> Das ist dpkg's Baustelle, und die Arbeiten scheinbar dran.
Ich benutze die neueste in SID bzw Experimental (heißt/hieß Experimental jetzt eigentlich SCUD, oder nicht?) und seit einigen Wochen dauert das nicht mal mehr halb so lange.
> Theoretisch wäre das machbar, aber es ist mir ein bisschen zu unordentlich. Naja, apt muss doch ohnehin bereits die Installationsreihenfolge der voneinander abhängigen Pakete berücksichtigen. Es spräche ja erstmal prinzipiell nichts dagegen, diese auch beim eigentlichen Download heranzuziehen und, sobald möglich, heruntergeladene Pakete zu installieren, wenn ihre Abhängigkeiten bereits aktualisiert wurden. Gerade bei aufwändigeren postinst-Prozessen, die nicht sonderlich I/O-lastig sind, wäre da eine ordentliche Beschleunigung drin.
Von Julian Andres Klode am Mi, 16. Dezember 2009 um 13:57 #
Na ja, wir werden sehen. Aber ich denke nicht, dass das wirklich sinnvoll ist; zumal die Anzahl der dpkg Aufrufe ziemlich anstiege. Außerdem ist es Programmiertechnisch komplexer.
Ah, cool! Gut, dass Du das alles nochmal erklärt hast. Dann schaffst Du es ja sicher noch, apt2 in Ubuntu 10.04 und das nächste Debian-Release reinzubekommen!
Was wird denn jetzt neu an APT2? "Nur" die Unterstützung für RPM-Pakete und ein paar Drehungen an der Geschwindigkeitsschraube? Oder kommt da mehr (hab eigentlich keine Idee, was man sonst noch machen könnte, APT ist bereits klasse)?
Von Julian Andres Klode am Mi, 16. Dezember 2009 um 13:11 #
> Was wird denn jetzt neu an APT2? "Nur" die Unterstützung für RPM-Pakete und ein paar Drehungen an der Geschwindigkeitsschraube? Oder kommt da mehr (hab eigentlich keine Idee, was man sonst noch machen könnte, APT ist bereits klasse)?
Möglichkeiten:
Besseres Auflösen von Abhängigkeiten
Fehler in Konfigurationsdateien nicht ignorieren (APT ist ziemlich kaputt hier)
Einfachere Bedienung, kombiniert in einem Programm (sowie bei cupt)
Einfacher zu warten.
Grundsätzlich zu beachtende Regeln:
Führen mehrere Wege zum Ziel, so wähle den, der langfristig am einfachsten ist.
Löse die Probleme dort wo sie entstehen, anstatt sie zu umgehen.
Wenn du etwas tust, sag warum und wie du es tust.
Viele kleine Dinge sind besser als wenige große Dinge.
wird APT2 eigentlich etwas an der Art wie Updates für Programme ausgeliefert werden ändern? Also in die Richtung dass zum Beispiel nur mehr die veränderten Dateien bei einem Updates eines Programms heruntergeladen werden müssen und nicht mehr das komplette Programmpaket wie es AFAIK bis jetzt der Fall ist? Ich dachte Fedora (oder war es eine andere Distribution?) hat in deren Paketmanager ein ähnliches Feature, dieses finde ich durchaus interessant.
Nein ich habe nicht gegoogelt, würde mich dennoch kurz und knapp interessieren.
OpenSuse bietet dieses Feature ebenfalls schon recht lange an. Es macht sich vor allem bei "großen" Aktualisierungen wie OpenOffice-Updates bezahlt. Die OpenSuse-Server verbrauchen in so einem Fall nur einen Bruchteil der Brandbreite, die z.B. Debian- oder Ubuntuserver "verbraten". Ein Beispiel aus OpenSuse 11.0: OpenOffice_org-2.4.0.14-1.4.i586.rpm: 49056 KB OpenOffice_org-2.4.0.14-1.2_1.4.i586.delta.rpm: 982 KB siehe ftp://ftp.gwdg.de/pub/opensuse/update/11.0/rpm/i586/
P.S. schon mal auf eine *.deb Datei geklickt?
einfach textdatei mittels notepad erstellen, nichts reinschreiben, abspeichern, umbenennen in exe
also wenn des nix is 
;-)
Pakte bauen welche auf (fast) allen Distributionen laufen, und über Jahre hinweg funktionieren ist auch unter Linux möglich. Im fall von OSS Software wird das aber in der Regel nicht gemacht, da es der ineffizientere weg ist, und es nicht notwendig ist weil neuere Versionen der Distribution sowieso wieder Pakete mitliefern.
Open Source Software Software?
*scrn*
Und mir hat bis heute noch keiner den Vorteil daran nennen können, die DLLs können sie dann doch gleich mit reinlinken, wenn eh jeder sein eigenen hat.
Das Zauberwort lautet Modularisierung.
Wiederverwenden? Sinn ist das Sicherstellen der Lauffähigkeit der ausgelieferten Software.
denn wer aktualisiert denn diese, wenn es mal eine Sicherheitslücke in der gegebenen Version gibt?
Hast du schonmal so ne DLL mit Sicherheitslücke genommen und durch eine neue ersetzt?
Tatsache ist doch, daß das kein Windows Anwender macht.
D.h. wenn's für die Anwendung nicht irgendwann nen Patch gibt, der das repariert, dann hat
man für Zig Jahre ne Anwendung mit einer DLL die ne Sicherheitslücke hat.
So etwas passiert dir unter Linux in der Regel nicht, da hier die Systembibliotheken einzeln upgedatet werden
und dennoch noch zu den alten Binarys der gleichen Distributionsversion passen.
Und bei Haiku ist es noch so.
Zu Next/Mac kann ich nichts sagen.
Abgesehen davon hast du so unter Linux in der Regel eine echte One-Click-Installation.
__________________^^^^^
ja nee is klar
Ich selbst benutze sie auch für Hobby-Sachen. Man hat einfach den Komfort von C# oder Java (von der Sprache her) ohne auf ein natives Kompilat zu verzichten zu müssen. Gibt halt keine ausgefeilten IDEs à la Eclipse, NetBeans oder Visual Studio, auch wenn es einige Projekte diesbezüglich gibt. Derzeit fährt man am besten mit dem Texteditor seiner Wahl oder mit gedit + Vala-Plugin.
Ich würde Java streichen und C# stehen lassen, so wird nen Schuh draus.
Ich habe größere Projekte sowohl in Java als auch in .Net (VB.Net und C#) geschrieben und in der Zwischenzeit ziehe ich Java C# vor. Die Java Klassenbibliothek ist einfach besser als die .Net Klassenbibliothek, Java bietet mir um multithreaded zu Programmieren (in .Net gibts nichtmal ne BlockingQueue), Swing ist viel, viel besser als Windows.Forms und meiner Meinung nach auch noch besser als WPF. Die JVM optimiert besser, kann bald Stack Allocation, der Garbage First Kollektor ist besser als das, was .Net zu bieten hat. C# ist meiner Meinung nach mit lauter unnützen Zeug überladen und mit Scala gibts eine Sprache für die JVM, die C# einfach nur alt aussehen läßt.
C# ist meiner Meinung nach mit lauter unnützen Zeug überladen >> With great power comes great responsibility, mehr gibts dazu nicht zu sagen.
Die Java Klassenbibliothek ist einfach besser als die .Net Klassenbibliothek >> Beispiele?
Java bietet mir um multithreaded zu Programmieren (in .Net gibts nichtmal ne BlockingQueue), >> Aha, wahnsinns argument.Ne BlockingQueeu ist auch ein monster zum implementieren oder?? Achja, apropo multi-threading -> Mit ParallelFX spricht sicher noch viel mehr für Java, oder?
Ich hab mit WPF einen Editor (>30000) Zeilen Code geschrieben. WPF hat einige nette Konzepte, aber MVC fehlt praktisch komplett. In Swing kann ich problemlos 100000 Items in ein Listview oder ein Treeview stecken und die GUI ist immer noch schnell. Mit WPF kann man das völlig vergessen. Mit WPF ist es auch nicht möglich, einfach Linien oder Bezier-Pfade in ein Bitmap zu rendern, sondern es wird jedesmal ein Scene-Graph aufgebaut, was für manche Anwendungen (z.B. in einem Telemetrie-System Plots mehrmals pro Sekunde neu zu zeichnen) nicht akzeptabel ist. WPF ist nicht schlecht, aber wegen der genannten Einschränkungen würde ich Swing im Moment vorziehen.
With great power comes great responsibility, mehr gibts dazu nicht zu sagen.
Dann lieber C++, das hat wenigstens Mehrfachvererbung, die C++ Templates sind den C# Templates meilenweit überlegen usw.
Ne BlockingQueeu ist auch ein monster zum implementieren oder
Ne Priority-Blocking Queue in fehlt in .Net auch. Es ist in .Net nicht möglich, über alle managed threads zu iterieren (vergiß die Process-Klasse, die gibt dir nur die unmanaged threads), es gibt kein memory mapped IO, es gibt keine Softreferences, bzw. sie funktionieren nicht. Mag ja sein, daß du das alles selber programmieren kannst (was ich allerdings nicht glaube), aber warum sollte man, wenn Java das alles mitbringt?
Achja, apropo multi-threading -> Mit ParallelFX spricht sicher noch viel mehr für Java, oder?
Wenn das dieses .Net Actor Framework ist, daß ich mir mal angesehen habe, kann ich nur sagen daß das ganze in Scala elegant gelöst wurde, ohne jede Menge neue Keywords einzuführen und die Sprache aufzublähen. Java ist sicher nicht perfekt, aber die Alternative ist nicht C# sondern Scala, die JVM ist schon ziemlich gut.
Einer der großen Vorteile von Java und C# ist der Garbage Collector, den Vala nicht hat. Ein anderer Vorteil von Java oder C# sind die guten IDEs und daß man die Sprachen leicht debuggen kann. Die Vorteile sind mit Vala auch weg. Außerdem ist C# meiner Meinung nach total überfrachtet und übermäßig komplex, keine Ahnung warum Vala unbedingt C# als Vorbild nehmen mußte. Scala z.B. ist eine wirklich schöne Sprache, dagegen schaut C# ziemlich alt aus.
Wenn ich das will, kann ich auch C++ nehmen.
Wer C++ nutzt, der setzt i.d.R. auf Qt...
Die meisten wirklich komplexen Applikationen werden immer noch in C++ geschrieben, weil es für solche Applikationen immer noch keinen wirklich sinnvollen Ersatz gibt.
Ich meinte daß es für komplexe, performance-kritische Anwendungen praktisch immer noch keine Alternative zu C++ gibt. So ziemlich alle modernen Game-Engines dürften in C++ geschrieben sein. C++ ist nicht schlecht, es gibt nur zuviele Leute, die es nicht verstehen und vermurksten Code damit produzieren. Aber für Leute die C++ wirklich verstehen, ist es eine sehr mächtige, produktive Sprache, die Dinge erlaubt, die man mit anderen Sprachen nicht ohne weiteres machen kann.
> praktisch immer noch keine Alternative zu C++ gibt.
Ada, Eiffel. Der Grad der Verbreitung korrelliert gern mal mit Qualität, allerdings negativ.
Wenn es auf umfangreiche Bibliothekssammlungen oder hochoptimierte Compiler nicht ankommt,
dann ist D durchaus ein geeigneter Ersatz.
Garbage-Collectoren haben auch Nachteile. Sie schlagen oft irgendwann zu, wenn es nicht erwartet wird und lassen Anwendungen teilweise "sluggish" erscheinen, geben Speicher erst spät wieder frei und sind für Echtzeit-Anwendungen nicht geeignet. Vala macht halt automatische Referenzzählung, wo man halt den kleinen Preis zahlen muss, dass man manchmal auf zyklische Referenzen achten muss, was aber kein Problem ist, wenn man sich das Design seiner Klassen anschaut.
Ein anderer Vorteil von Java oder C# sind die guten IDEs und daß man die Sprachen leicht debuggen kann.
Vala-Code kann man auch debuggen, mit dem normalen GDB oder einem Frontend dafür. Wenn man mit -g kompiliert kann man durch den Vala-Code (nicht den C-Code) steppen.
Scala z.B. ist eine wirklich schöne Sprache, dagegen schaut C# ziemlich alt aus.
Scala ist gut. Aber teilweise auch überfrachtet. Ich sag nur XML-Literale. Hat meiner meinung nach in einer Sprachsyntax nix zu suchen. XML ist bald out, derzeit ist JSON angesagt. Sowas gehört nicht in die Syntax.
http://developers.sun.com/learning/javaoneonline/
j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase
Für harte Echtzeitanwendungen ist der G1 vielleicht immer noch nicht geeignet (genauswo wenig wie Linux ohne RT Kernel), aber für Desktop-Anwendungen sollte das gut genug sein.
Vala macht halt automatische Referenzzählung, wo man halt den kleinen Preis zahlen muss, dass man manchmal auf zyklische Referenzen achten muss, was aber kein Problem ist, wenn man sich das Design seiner Klassen anschaut.
Referenz Counting kann ich in C++ und Objective-C seit Jahren haben.
Ich sag nur XML-Literale
Sicher ist Scala nicht perfekt. Aber immer noch deutlich besser als C#.
Sagt ja auch niemand was dagegen. Wobei es in C++ schon sehr umständlich ist um jeden Typ dauernd std::shared_ptr<> (oder wie das heißt) und Co zu schreiben.
lg
Erik
Zwei Studenten schreiben eine Sprache - und wie wird die Weiterentwicklung gesichert?
Die Codebeispiele: Wow, zum Glück hat meine Grafikkarte >16 Mio Farben, sonst wäre der Highlighteffekt im Editor dahin
-Aber warum braucht ein "Hello World" jetzt 6 Klammern und ein Semikolon? Python zeigt wie es wesentlich einfacher geht. Und wie groß ist das Programm im Endeffekt?
Ich kann Miranda, C, C++, Java, Pascal, Oberon, Python - wieso ist Vala nun besser? Das leuchtet mir noch noch nicht ein.
Für Libs ist das eine schöne sache, wie im verlinkten Originalartikel schon steht kann das z.B. (das von mir sehr geschätzte) Python nicht bieten.
Jedes Tool halt für seinen Zweck. Für Libs die man mit möglichst vielen Sprachen nutzen können soll ist Vala eine gute Idee. Aber ich glaube nicht das damit wirklich alles gemacht werden sollte.
So wie bei vielen anderen Open-Source-Sprachen auch. Durch die Entwickler und beitragende Community. Python wird ja auch nicht gerade von einem ISO-Gremíum entwickelt.
Aber warum braucht ein "Hello World" jetzt 6 Klammern und ein Semikolon? Python zeigt wie es wesentlich einfacher geht.
Dass du eine Haupteintritts-Funktion schreiben musst fällt bei einem großen Projekt nicht mehr ins Gewicht. Und wenn du auf Semikolon und freies Format verzichten willst gibt es Genie für dich.
Und wie groß ist das Programm im Endeffekt?
8345 Byte. Für ein native Binary normal. Da dürfte der halt noch der normale initiale ELF-Overhead dabei sein.
Miranda, C, C++, Java, Pascal, Oberon, Python
Miranda kenn ich nicht.
Vorteile zu C: Syntax-Unterstützung für OOP und anderer Syntax-Sugar
Vorteile zu C++: Einfachere Syntax, direkte C-ABI-Kompatibilität, Closures, Typ-Inferenz
Vorteile zu Java: keine Runtime-Umgebung, Closures, Properties, Delegates, Typ-Inferenz
Oberon kenn ich nicht.
Pascal: C-ABI-Kompatibilität, sonst weiß ich nicht was Delphi / Object Pascal mittlerweile kann
Python: keine Runtime-Umgebung, produziert C-Bibliotheken, die von anderen Sprachen gebunden werden können
Natürlich gibt es im Vergleich zu jeder Sprache auch Nachteile, wie bei allem.
Einen Vorteil von Vala gegenüber Pascal sehe ich im deutlich leichtgewichtigeren Syntax und in der Möglichkeit wie in C an jeder Stelle variablen zu deklarieren.
Außerdem entfällt die verwendung von Pointern, wenn man sie nicht nutzen will, muss man es nicht zwangsläufig.
Mit Delphi/Lazarus existieren auch gute IDEs für Pascal und man kann performante Webanwendungen schreiben.
Java hat zwar keine Closures, aber anonyme innere Klassen können auf als final deklarierte Variablen des umgebenden Contexts zugreifen, was sehr nahe an Closures kommt. Daß man nur auf final Variablen des umgebenden Contexts zugreifen kann, finde ich sinnvoll.
Delegates lassen sich mit Interfaces und anonymen inneren Klassen verwirklichen. Ist nicht ganz so elegant wie delegates, Netbeans und Co. fügen aber den ganzen Boilerplate-Code eh automatisch ein.
Properties sind meiner Meinung nach ziemlicher Unfug. In C# z.B. lassen sich Properties nicht als ref typen an Funktionen übergeben. Wenn schon Properties, dann sollen sie überall wie Felder funktionieren und nicht manchmal.
Type Inference wäre zwar nett. Naja, Scala hat Type Inference.
Das ist ein gutes Argument. In Scala z.B. sind Operatoren ganz normale Funktionen. In C# sind Operatoren statisch, daher lassen sich nicht überladen. In Scala läßt sich eine Funktion ohne Parameter mit einem Rückgabewert wie ein Feld des gleichen Typs benutzen, in C# geht das mit Properties manchmal, manchmal nicht. In Scala sind Funktionen einfach Objekte, in C# gibt es delegates, die eine Sonderstellung haben. Scala ist konsistent und elegant (ein paar Schwächen hat es natürlich auch), C# ist großer Haufen nicht-orthogonaler Features, daß allmählich zu einem zweiten C++ zu mutieren, ohne allerdings so mächtig wie C++ zu sein,
Für ne Skriptsprache nicht schlecht.
Sorry, mein Fehler. Programmieren und posten gleichzeitig ist keine gute Idee...
Ich habe ein wenig Bauchschmerzen damit, dass eine Metasprache genutzt wird, um in einer Sprache wie C zu programmieren. Das hört sich nach einer neuen Fehlerquelle an
Was mich wundert ist dass es zwar GNU-, KDE-, GNOME-, LXDE-, CD-, DVD-, XFCE-, E17-Distributionen gibt, aber noch keine Distribution, die sich auf eine einheitliche Sprachbasis konzentriert. Perl-Anwendungen gehören m.E. verboten, ebenso OCAML, HASKELL und andere obskure Sprachen
Sollte das XO2 nicht rein auf Python und C basieren, damit die Kinder den Code analysieren können? Da trauere ich Oberon wirklich hinterher.
lg
Erik
+!
Du willst also alles, was du nicht verstehst, verbieten?
> Sollte das XO2 nicht rein auf Python und C basieren, damit die Kinder den Code analysieren können?
Dann bettet man in C eben Assembler ein. Ist ja erlaubt und macht den Code sicher lesbarer.
Verbieten direkt nicht, aber die Verwendung von Perl sollte unter Strafe gestellt werden
Perl ist keine Sprache die im Verdacht steht besonders gut lesbar zu sein. Selbst die kleinen Zehnzeiler können unlesbar sein. Lesbarkeit ist aber ein Kriterium für das Verständnis des Codes und damit auch für die Beherrschbarkeit. Beherrschbarkeit ist für Software aber ein Sicherheitsmerkmal.
Von mir aus kann es eine Distribution geben die nur auf Perl setzt. Aber die werde ich mir sicherlich nicht antun. Lieber eine Python-Distribution
Ich möchte allerdings auch noch auf spannedes Problem hinweisen:
Es gibt eine Reihe von Firewalldistributionen, die mit Perl, Python u.a. Interpretern ausgestattet sind. Das macht es Angreifern nach der Kompromittation sehr einfach eigene Skripte auszuführen.
Ist das was Ansteckendes? *g*
Was das Problem angeht, daß ein Angreifer Skripte ausführen kann ... wenn die Kiste kompromittiert ist, ist es mir wurst, ob er dafür Perl nimmt, Bash oder sonstigen Mist. Und wenn er ein Werkzeug nicht hat, lädt er's eben nach.
Außerdem kann man mit D auch nen Kernel schreiben, denn D ist für die Systemprogrammierung sehr gut geeignet.
Vala übersetzt in reines C. So kann man Objektorientierung nutzen ohne auf C++/C#/Java/Python.../... zuzugreifen, hat eine allgemeine Syntax, und geht auch nicht zu weit von C weg.
DANN HALT NICHT.
Aber Teile vo Opera Mini sind damit gemacht worden. ...zumindest laut der engl. Wikipedia....
> Das erstmals Ende August vorgestellte Projekt will [...] sich durch eine gesteigerte Geschwindigkeit auszeichnen
Prinzipiell gesehen kann es schneller sein, muss es aber nicht, es ist prinzipiell nur ein Nebeneffekt der Wahl von SQLite 3, und nicht das Ziel.
> Ferner enthält die Lösung ein Kommandozeilenprogramm mit dem Namen »capt«.
Ja, ich habe nur irgendwie Angst das man es mit cupt verwechseln könnte. Ein Vorteil des Namens wäre aber, dass man eine GTK+ Version dann gapt nennen könnte.
> Wie der Entwickler nun bekannt gab, soll APT2 bereits im Dezember in einer ersten Version veröffentlicht werden
Ich meinte nur, dass ich den lokalen Code in das öffentliche Repository pushe ("it will be published" bezog sich auf den code aus "the internal branch has seen a lot of new code"). Die interne Branch ist jetzt aber an sich auch online und trägt den freudigen Namen "temp"; da einige sich das schon mal anschauen wollten. Ein Release vor Weihnachten wäre insofern auch dumm, da ich ja die Weihnachtsferien nutzen kann, weiter zu programmieren.
> Die aktuelle [Vala] Version enthält einen Fehler, der es unmöglich macht, APT2 zu compilieren.
Um genau zu sein, haben die Veröffentlichen Vala Versionen die Angewohnheit, die Kopie eines Arrays welches mit null endet, nicht mit null enden zu lassen, weil die Kopie ein Element zu klein war.
Bei apt unter debian testing dauert es immer so lange Programme zu installieren weil das hier so lange dauert:
(Lese Datenbank ... XX%)
Gerade bei kleinen Programm nimmt das Herunterladen und Entpacken nur ein Bruchteil der zeit ein wie das Lesen der Datenbank.
Wird das bei apt2 anders/besser/schneller sein?
Mal angenommen man installiert Zwei von einander unabhaenige Programme, koennte er nicht schon das erste Installieren waerend das Zweite noch runterlaedt?
Mfg
lord-carlos
> (Lese Datenbank ... XX%)
Das ist dpkg's Baustelle, und die Arbeiten scheinbar dran.
> Mal angenommen man installiert Zwei von einander unabhaenige Programme, koennte er nicht schon das erste Installieren waerend das Zweite noch runterlaedt?
Theoretisch wäre das machbar, aber es ist mir ein bisschen zu unordentlich.
Ich benutze die neueste in SID bzw Experimental (heißt/hieß Experimental jetzt eigentlich SCUD, oder nicht?) und seit einigen Wochen dauert das nicht mal mehr halb so lange.
Naja, apt muss doch ohnehin bereits die Installationsreihenfolge der voneinander abhängigen Pakete berücksichtigen. Es spräche ja erstmal prinzipiell nichts dagegen, diese auch beim eigentlichen Download heranzuziehen und, sobald möglich, heruntergeladene Pakete zu installieren, wenn ihre Abhängigkeiten bereits aktualisiert wurden. Gerade bei aufwändigeren postinst-Prozessen, die nicht sonderlich I/O-lastig sind, wäre da eine ordentliche Beschleunigung drin.
lg
Erik
ich glaub es ist zuspät:
"Paketmanager Apt2 wird zu Weihnachten fertig"
meldet golem.de
http://www.golem.de/0912/71903.html
lg
Erik
Grueße
Ignatz
Möglichkeiten:
Grundsätzlich zu beachtende Regeln:
Wer die Liste versteht darf sich freuen
Ich dachte Fedora (oder war es eine andere Distribution?) hat in deren Paketmanager ein ähnliches Feature, dieses finde ich durchaus interessant.
Nein ich habe nicht gegoogelt, würde mich dennoch kurz und knapp interessieren.
Es macht sich vor allem bei "großen" Aktualisierungen wie OpenOffice-Updates bezahlt. Die OpenSuse-Server verbrauchen in so einem Fall nur einen Bruchteil der Brandbreite, die z.B. Debian- oder Ubuntuserver "verbraten".
Ein Beispiel aus OpenSuse 11.0:
OpenOffice_org-2.4.0.14-1.4.i586.rpm: 49056 KB
OpenOffice_org-2.4.0.14-1.2_1.4.i586.delta.rpm: 982 KB
siehe ftp://ftp.gwdg.de/pub/opensuse/update/11.0/rpm/i586/
Wenn sie das für viele Pakete mchen, "verbraten" sie dafür wesentlich mehr Plattenplatz.