Login
Login-Name Passwort


 
Newsletter
0
Von Ethera am Fr, 20. Oktober 2017 um 11:05

Richtig. Ich haette sagen sollen, das Microsoft staendig die Art und Weise aendert wie diese Formate verarbeitet werden und damit die Kompatibilitaet zu LibreOffice leidet.

0
Von ac am Fr, 20. Oktober 2017 um 10:36

Rein formal lässt sich der Logik folgen. In der Praxis muss jeder, der mit anderen Dokumente austauscht, mit docx klarkommen.

0
Von blablabla233 am Fr, 20. Oktober 2017 um 10:34

Sorry aber docx IST opensource (nicht die MS-Implementation aber die definition des formats), einfach unglaublich aufgeblasen. Ein docx ist nix anderes als ein zipfile mit xml drinne.

0
Von Nur ein Leser am Fr, 20. Oktober 2017 um 10:09

Ziemlich offensichtlich ist das Projekt tot.

Die verbliebenen Mitstreiter wollen das aber offenbar nicht wahrhaben, auch hier bei prolinux kommentiert ab und zu jemand, der da offenbar involviert ist. Tenor: "Wir sind das Original, die Lebendigkeit eines Projekts hängt ja nicht von der Anzahl, sondern von der Qualität der Veröffentlichungen ab, OO lebt, LibreOffice hat einfach nur die bessere Pressearbeit."

Ich denke, wenn seit mehreren Jahren immer nur die Version 4.1 mit minimalen Patches versehen wird (und das auch nur ein mal pro Jahr), kann sich jeder seine eigene Meinung zum Zustand des Projekts bilden.

0
Von verfl...WTF.etc. am Fr, 20. Oktober 2017 um 09:55

Ich hoffe es liegt nicht an VMWare, dass man sich eine solche Sprache angewöhnt. Falls doch, werde ich VMWare meiden müssen, denn so will ich nicht werden ...

0
Von Mike11 am Fr, 20. Oktober 2017 um 09:51

Das ist eher die Frage.
Der Text klingt eher wie ein worst-case, oder doch Realität?

0
Von Ethera am Fr, 20. Oktober 2017 um 09:27

Die Sache bei diesen Fehlern ist, dass Microsoft staendig etwas an den Formaten aendert und diese natuerlich nicht open source sind. Das ist also eher ein Microsoft-Office-Problem als ein LibreOffice-Problem. Zumal selbst zwischen verschiedenen Microsoft-Office-Versionen solche Fehler auftreten.
Es empfiehlt sich IMMER die OpenDocument-Formate (z.B. .odt) zu nutzen statt die Microsoft-Formate (z.B. .docx). Die OpenDocument-Formate sind standardisiert, dokumentiert und quelloffen.

Wer die Microsoft-Formate nutzt begibt sich freiwillig in den "vendor lock-in"!

0
Von sbsjsjsjs am Fr, 20. Oktober 2017 um 09:26

Das passt zum Linux Konzept, da werden die Fehler der Programmierer einfach auf den Nutzer umgewälzt. Der Nutzer soll gefälligst lernen das verbuggte Programm "richtig" zu benutzen. Auch wenn er sich dabei verrenken muss.

Die Schuld liegt ganz klar nicht beim Programmierer auch wenn es 1000 andere Portale gibt die es besser können.

Lasst das Token invalide werden oder führt unique hashes für Thread-Child+Name als Prüfung für die Nachrichten der letzten Minute des Threads ein. Da fällt einem doch auf Anhieb vieles ein. Später kann man es immer noch optimieren.

Es ist doch nicht das erste mal, das so etwas passiert. Ich verstehe nicht warum Linuxer kein bisschen Qualitätsbewusstsein besitzen?!

0
Von Atalanttore am Fr, 20. Oktober 2017 um 09:10

Wegen Serverfehler 50x wurde der Beitrag leider doppelt verarbeitet.

1
Von Atalanttore am Fr, 20. Oktober 2017 um 09:08

Wegen Serverfehler 50x wurde der Beitrag leider doppelt verarbeitet.

0
Von Atalanttore am Fr, 20. Oktober 2017 um 09:01

Der Import/Export in Microsoft-Office-Formate funktioniert nach wie vor nicht perfekt. Diesbezüglich habe ich auch schon einige Fehler mit Beispieldokumenten im Bugtracker gemeldet, aber diese werden oft gar nicht bearbeitet, als Fehler der geringsten Schwere eingestuft (und auch nicht bearbeitet) oder mit WORKSFORME abgelehnt.

0
Von io am Fr, 20. Oktober 2017 um 06:30

Zum technischen Teil kann ich gerade nichts sagen. Aber ich muß gerade mal was loswerden: Ist das das Standarddesign?? :huh: :shock: Ist mein voller Ernst, die Bilder erinnern mich an eine Aura (Gesichtsfeldverzerrung) im Vorfeld einer Migräne. Entschuldigung, aber ich hab NOCH NIE dermaßen häßliche Hintergrundbilder gesehen. Dagegen war das Debian-Weltraumraketen-Design von 2010 (?) echt geschmackvoll.

0
Von flipster am Fr, 20. Oktober 2017 um 05:03

warum es nicht eine breitere Anwendung (sei es Desktop oder Distro) genießt.
weil HUD shice is! ^^

0
Von Gitstompha am Fr, 20. Oktober 2017 um 02:14

Klar löst Warten das Problem. Macht es für mich schon seit Jahren auf Pro-Linux. Nicht ein einziger Mehrfachpost. Nur manchmal dauert es einfach etwas länger, auch mehrere Minuten. Be patient! Youngling! :D

0
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 23:52

WTF - Logisch dass alles was du an Daten wegbekommst den shrink effizienter macht, erzähl mir was neues, ich fahre hier je nach use case production VM's die nur ein paar hundert MB gross sind

Zerofree oder nullen macht im Kontext deines "wuuu da könnten noch wo Blöcke mit Daten sein" keinerlei Unterschied, auch nicht im Kontext ehemals belegter 4k Block mit physischen Restdaten

der einzige Unterschied zu dd ist dass die disk temporär nicht auf die volle Größe anwächst und das war es dann auch schon

0
Von Martin Steigerwald am Do, 19. Oktober 2017 um 23:43

Dürfte auch für reines KVM mit qcow2 gelten. Und das geht auch mit VMs in RBD-Geräten in einem Ceph.

In der VM:

fstrim -av

Fertig :).

So einfach kann das gehen.

Und so einfach dürfen das auch Virtualbox und VMware bitte irgendwann mal hinbekommen. Dafür ist Trimming ja da.

0
Von XYZ am Do, 19. Oktober 2017 um 23:40

> Ich arbeite jetzt 15 Jahren in der Branche

Dann sollte man aber solche Fragen wie das unmounten von / oder in ro re-mounten im Zusammenhang mit zerodisk nicht stellen bzw. nicht *mehr* stellen.

0
Von XYZ am Do, 19. Oktober 2017 um 23:37

... du kapierst es nicht!

Es war ein Beispiel! Ein "Erklärungsansatz", damit der normale Mensch kapiert was auf der Festplatte noch so an Daten "herumgeistern" können oder könnten.

Nur weil du gelernt hast in den VMWare Produkten einen Button zu drücken, was dir deine VM verkleinert, so heisst es noch lange nicht, dass man sie nicht noch "kleiner" bekäme, wenn man etwas mehr Sorgfalt pflegt.

0
Von XYZ am Do, 19. Oktober 2017 um 23:34

Schon einmal darüber nachgedacht, dass ein anderer Leser meinen Beitrag für durchaus interessant halten könnte ?

Es gibt noch mehr Leute, die die Kommentare lesen und vielleicht das eine oder andere Interessante hieraus ableiten möchten.

Der Beitrag setzt nämlich genau an Punkt 2) dieses Artikels an.

In diesem Kontext sollte man sich ggf. nochmal mit Sparse Files auseinandersetzen bevor man zu Methoden wie dd greift... Wäre aber wieder ein anderes Thema. Ich möchte damit jetzt nicht Leute überfordern, die nicht wissen wie man eine VM / in ro mountet, um dann mit zerodisk drauf zuzugreifen...

Ich schlage vor, du akzeptierst einfach mal einen Userbeitrag in den Kommentaren als gegeben. Für dich mag das alles ok sein... Ein anderer User mag sicherlich noch etwas davon gebrauchen können.

Soll heissen: Wir beide sind hier nicht alleine auf Pro-Linux.de

0
Von Verfluchtnochmal am Do, 19. Oktober 2017 um 23:24

Und wenn du Sourcecode auf der produktiv VM kompiliert hast bist du sowieso ein Trottel, die hat gar niemals einen Compiler zu sehen und demzufolge auch keine sources, dafür gibt es Build Maschinen und Paketverwaltungen

Ich arbeite jetzt 15 Jahren in der Branche aber auf die saudumme Idee Sourcecode oder compiler mit mit einer produktiv Maschine in Berührung zu bringen ist hier noch keiner gekommen


 
Pro-Linux
Traut euch!
Neue Nachrichten