Zumindest Nutzer von deb- und rpm-basierenden Distributionen können sich die Kompiliererei auch gleich sparen: http://de.libreoffice.org/download/?nodetect
soll ich mir diese Arbeit machen? Es mag sein, dass es Exotensysteme gibt, für die es keine fertigen Pakete gibt. Für Linux, Mac und Windows gibt es fertige Pakete. Außerdem dürften die wenigsten Anweder eines Officepaketes mit mehr als der Programminstallation klar kommen. Das geht zu mindest mir mal so.
Du scheinst das nicht verstanden zu haben. Um ein vollwertiger Com- puterbenutzer zu sein muss man auch Quellcode kompilieren können. Ohne diesen Fähigkeits- nachweis wirst Du weder in einem Linuxforum noch auf irgendwelchen Mailinglisten ernst genommen.
Scherz beiseite: Der Autor wollte es wohl einfach mal ausprobieren und hat einen möglichen Grund auch im Artikel erwähnt: Wenn Mann oder Frau zum Quellcode oder allgemein zur Verbesserung beiträgen möchte, kann er/sie das tun und sieht also auch, dass seine Änderungen immer noch bauen.
Aber der Normalbenutzer, wo ich mich auch dazu zähle wird das wohl eher gar nicht tun.
Es gibt keine zentrale Stelle die für Dich das "Vertrauen" übernimmt. Signiere den Schlüssel als vertrauenswürdig ab, dann bekommst Du auch keine Warnung mehr.
Dazu muss man PGP verstehen. Welchen Schlüsseln man vertraut, definiert man selbst. Und ich habe keinem der Schlüssel, mit denen der LO-Schlüssel signiert ist, mein Vertrauen ausgesprochen.
Die Chance, dass eine Signatur dabei ist, der man vertraut, wäre höher, wenn die Zahl der Signaturen höher wäre.
Von Stephanopoulus am Mo, 25. Februar 2013 um 21:34 #
Danke für den Super-Artikel! Das ist sehr interessant. LibreOffice ist ein super Projekt. Es ist sehr sinnvoll, dieses Projekt neuen Leuten zugänglich zu machen. Vielen Dank
Man kann make ordentlich Beine machen, da meist Multicore-Systeme compilieren. Mit
make -j _x_
wobei _x_ mit einer Zahl gleich oder etwas größer der Core-Anzahl zu ersetzen ist, kann man die Compilezeit extrem verringern. Hier ein Beispiel einer Kernel-Übersetzung (3.8.0) auf einer 16-Core-Maschine:
Dabei war ein Core durch andere Prozesse zu ca. 100% ausgelastet. Dadurch sind Schwankungen um einige Sekunden möglich. Außerdem gibt es eine "Sockelzeit", da der Build-Prozess auch einige Teile enthält, die nicht ein reines make sind und sich nicht parallelisieren lassen. Wenn die Thread-Zahl wesentlich über der Core-Zahl liegt, gibt es wieder eine Verschlechterung der Performance durch den Overhead der Prozessverwaltung.
Naja, da hätte man aber ein bisschen recherchieren können - so bleibt der Informationsgehalt doch sehr dünn...
Zumindest Nutzer von deb- und rpm-basierenden Distributionen können sich die Kompiliererei auch gleich sparen: http://de.libreoffice.org/download/?nodetect
Ist nur für x86 und x86_64...
Tja! Du kompilierst dann halt.
soll ich mir diese Arbeit machen? Es mag sein, dass es Exotensysteme gibt, für die es keine fertigen Pakete gibt.
Für Linux, Mac und Windows gibt es fertige Pakete. Außerdem dürften die wenigsten Anweder eines Officepaketes mit mehr als der Programminstallation klar kommen. Das geht zu mindest mir mal so.
Hi Thomas,
Du scheinst das nicht verstanden
zu haben. Um ein vollwertiger Com-
puterbenutzer zu sein muss
man auch Quellcode kompilieren
können. Ohne diesen Fähigkeits-
nachweis wirst Du weder in einem
Linuxforum noch auf irgendwelchen
Mailinglisten ernst genommen.
Scherz beiseite: Der Autor wollte es
wohl einfach mal ausprobieren und
hat einen möglichen Grund auch im
Artikel erwähnt: Wenn Mann oder
Frau zum Quellcode oder allgemein
zur Verbesserung beiträgen möchte,
kann er/sie das tun und sieht also
auch, dass seine Änderungen immer
noch bauen.
Aber der Normalbenutzer, wo ich
mich auch dazu zähle wird das wohl
eher gar nicht tun.
Grüße,
fx
Ich mach das immer so:
emerge libreoffice
und dann Kaffee tringen - fertig !
Hast Du aber ne grosse Kaffetasse, oder bist du einfach nur langsam?
Ich bin ein Genießer !
Ich mache immer ein emerge libreoffice-bin, aus den Sourcen bauen dauert mir zu lange. Im Artikel steht eine Stunde, bei mir dauert das Stunden.
mfg
So n Stress. Bei der Distri meiner Wahl muss ich gar nix machen. Es sit automatisch dabei ;o)
Genau... Ist einfach so auf die Platte gebeamt... Musste nie installiert werden...
BTW: Mein "emerge libreoffice" dauert knapp unter einer Stunde...
in der Stunde installiere ich die Distri meiner Wahl wenns drauf ankommt zweimal ;o)
...was man bei manchen Distris wohl auch machen muss... Immerhin haste dann 2 mal in der Stunde die Gelegenheit Unity loszuwerden
Ich hab meine gentoos teilweise vor Jahren installiert und möchte die Vorteile einer Rolling-Release-Distri nicht mehr missen.
Gibt es eigentlich irgendwelche Archive, bei denen diese dämliche Warnung nicht auftaucht??
Wozu dann das ganze Bohei um Signaturen und Trust-Netze, wenn nicht mal Libre Office vertrauenswürdig sein soll?
PGP != PKI
Es gibt keine zentrale Stelle die für Dich das "Vertrauen" übernimmt.
Signiere den Schlüssel als vertrauenswürdig ab, dann bekommst Du auch keine Warnung mehr.
Gruß Ohne Namen weil zu faul sich zu registrieren
Was "gültige" Zertifikate wert sind, kannst du ganz aktuell hier nachlesen:
http://www.heise.de/security/meldung/Zertifizierter-Online-Banking-Trojaner-1808261.html
Wünsche noch viel Spaß mit deinem Schlangenöl.
Dazu muss man PGP verstehen. Welchen Schlüsseln man vertraut, definiert man selbst. Und ich habe keinem der Schlüssel, mit denen der LO-Schlüssel signiert ist, mein Vertrauen ausgesprochen.
Die Chance, dass eine Signatur dabei ist, der man vertraut, wäre höher, wenn die Zahl der Signaturen höher wäre.
Danke für den Super-Artikel!
Das ist sehr interessant.
LibreOffice ist ein super Projekt.
Es ist sehr sinnvoll, dieses Projekt neuen Leuten zugänglich zu machen.
Vielen Dank
Hat einer von Euch das auch mal direkt aus GIT geholt?
Andere doofe Frage, wenn man nun entwickelt, muss man dann immer alles bauen oder nur die Komponente, wo man was geändert hat?
Man kann make ordentlich Beine machen, da meist Multicore-Systeme compilieren. Mit
make -j _x_
wobei _x_ mit einer Zahl gleich oder etwas größer der Core-Anzahl zu ersetzen ist, kann man die Compilezeit extrem verringern. Hier ein Beispiel einer Kernel-Übersetzung (3.8.0) auf einer 16-Core-Maschine:
_x_ .. Build-Zeit in Sekunden
ohne .. 2535
8 .. 420
16 .. 283
18 .. 290
20 .. 286
30 .. 291
Dabei war ein Core durch andere Prozesse zu ca. 100% ausgelastet. Dadurch sind Schwankungen um einige Sekunden möglich. Außerdem gibt es eine "Sockelzeit", da der Build-Prozess auch einige Teile enthält, die nicht ein reines make sind und sich nicht parallelisieren lassen.
Wenn die Thread-Zahl wesentlich über der Core-Zahl liegt, gibt es wieder eine Verschlechterung der Performance durch den Overhead der Prozessverwaltung.
Neugier pur: 16 core Maschine, was ist denn das für ein Teil.
~> grep processor /proc/cpuinfo | wc -l
80
:-D
Sollte kein Protzen sein
... Ist halt ein Server ProLiant DL580 G5 mit vier Quadcores.