Lug-dd

lug-dd@mailman.schlittermann.de

10859 discussions

Suche isolierte Build-Umgebung für [Ubuntu|Fedora] Linux
by Matthias Petermann 16 May '11

16 May '11

Guten Morgen LUG, womit helft ihr Euch, wenn ihr eine Software aus den Sourcen bauen wollt, nicht aber Eure bestehende Installation unter Umgehung des Paketmanagers beschädigen wollt? Gibt es für solche Zwecke unter Ubuntu bzw. Fedora sowas wie ein vorkonfiguriertes chroot? Hintergrund: ich möchte OpenGroupware inkl. Abhängigkeiten neu bauen - möglichst mit einem Mindestmaß an expliziter Konfiguration an den Makefiles etc. der jeweiligen Pakete. Vielleicht hat ja jemand eine gute Idee? Viele Grüße, Matthias

6 5

Inkscape: geschweifte Klammern
by Fabian Hänsel 13 May '11

13 May '11

Hallo, für ein paar Grafiken benötige ich große geschweifte Klammern (die umspannen auch mal 3/4 Seitenbreite). Mein Ansatz: Ein } als Text einfügen und dann entsprechend strecken (und drehen). Das ganze hat zwei Nachteile: (1) wenn die Klammer proportional skaliert wird, dann wird sie sehr breit (zuuu breit) (2) wenn sie nicht-proportional skaliert wird, dann leiden die Proportionen, wodurch die Klammer hässlich wird (und dann wird immer noch der in Skalierungs- richtung liegende Teil zu breit) Hat jemand eine Idee, wie man das besser machen kann? Ich verwende Inkscape. Viele Grüße Fabian

3 5

Nochmal: Biete Mitfahrgelegenheit zum LinuxTag am 14.05.2011
by Stefan Schmitt 12 May '11

12 May '11

Hi Liste! Ich hab's zwar vor ein paar Wochen schon mal gepostet, aber vielleicht ist mein Beitrag in einer anderen Diskussion untergegangen... :-) Ich fahre am Samstag früh nach Berlin zum LinuxTag 2011. Wer Zeit, Lust und Laune hat, kann sich gerne noch einklinken und mitfahren. Details sowie Vereinbarung eines Treffpunktes (Vorschlag: Elbepark) bitte mit Handynummer (zwecks Kontaktaufnahme) an meine Mailadresse - aber bitte bis spätestens morgen Abend!!! CU Stefan

1 0

PostgreSQL
by Marcus Obst 11 May '11

11 May '11

Hallo Liste! Ich glaube mich zu erinnern, dass es hier einige gibt, die sich mit Datenbanken und im speziellen sogar mit PostgreSQL ziemlich gut auskennen. Wir verwenden hier in Chemnitz seit einiger Zeit eine Postgres-Datenbank um unsere Messdaten zu speichern. Eigentlich halte ich die Anforderungen für sehr moderat, dennoch bin ich mit der ,,Gesamtsituation'' bisher etwas unzufrieden. Ich versuch mal kurz zu skizzieren was wir machen (wollen) und wo es im Moment klemmt. Die Datenbank besteht im Prinzip aus einer Tabelle die pro Datensatz eine ID, einen Zeitstempel, einen Blob sowie noch drei String Felder enthält. Da wir die PostGIS-Erweiterung benutzten ist auch noch eine Feld mit Koordinaten vorgesehen. In dem Blob-Feld fügen wir Binärdaten der Größe 100 Byte - 300kb ein, das ist aber ständig variable. Insgesamt ist perspektivisch mit eine Datenvolumen von ca. 1 Terrabyte zu rechnen, also eigentlich nix aufregendes. Wenn ich einen Satz Messdaten importiere sind das ca. 20GB-Daten, die auf 500.000 Datensätze verteilt sind. Die Datenbank läuft auf einem Windows-Server in der 32-Bit Version. Client-seitig verwenden wir c# mit dotConnect von devart. Jetzt zu den Problemen: 1) Der Import der Daten gestaltet sich aus meiner Sicht ziemlich langsam. Der Importer schafft im Moment lediglich eine Datenrate von 8 MB/s wenn er in die Datenbank schreibt. Beschaffen könnte er die Daten theoretisch mit 50M/s. 2) Ganz blauäugig dachte ich mir, dass man um das INSERT der 500.000 Datensätze, die ja alle logisch zu einem Messdatensatz gehören, mit einer Transaktion klammern kann. Wenn ich das mache, bekomme ich nach ca. 5GB importierten Daten eine Exception, die mir mitteilt, dass auf Serverseite irgendwelcher Speicher alle wäre? Wenn ich weniger Daten importiere gibt es keine Exception. Dafür bekomme ich beim finalen Commit der Transaktion ein Timeout. 3) Das löschen von Messdaten (wider 500.000 Zeilen) mit einer Query ala DELTE FROM measurements WHERE session_id = 34 dauert ewig und kommt meist Client-seitig mit einem Timeout zurück. Hat jemand vielleicht einen Ansatzpunkt? Vielen Dank! Marcus

6 11

Treffen heute => Torwirtschaft
by Heiko Schlittermann 11 May '11

11 May '11

Hallo, eben hatte mich noch mal der GAG18 angerufen, die Lage dort hat sich noch mehr verschlechtert. Vorgestern kam ja schon der Vorschlag, in die Torwirtschaft auszuweichen. Das Wetter scheint noch eine weiterer Befürworter zu sein. Also habe ich jetzt eigenmächtig festgelegt, dem Vorschlag von Christian Perle zu folgen: Das heutige Treffen der Linux-User-Group Dresden findet 20.00 in der Torwirtschaft im Großen Garten (Westliches Ende der Hauptallee, dann der Biergarten südlich der Hauptallee). Wer mit den Kategorie Westen, Süden, Hauptalle und Großer Garten nichts anfangen kann: http://maps.google.de/maps?ie=UTF8&q=torwirtschaft+dresden&fb=1&gl=de&hq=to… http://tinyurl.com/67oltcn oder alternativ den Anhang scannen ☺ Die Leute vom GAG18 werden noch ein Redirect-Schild aufhängen, für die, die das hier nicht lesen. -- Heiko :: dresden : linux : SCHLITTERMANN.de GPG Key 48D0359B : 3061 CFBF 2D88 F034 E8D2 7E92 EE4E AC98 48D0 359B

1 0

Abkehr von der FOSS-Strategie des Auswärtigen Amts
by micu 11 May '11

11 May '11

Hallo miteinander, zur Rückmigration des Auswärtigen Amts (zu Windows XP!) ein Update: Bei Netzpolitik.org sind Leaks (ist ja irgendwie ein Hype zur Zeit :D) dazu eingetroffen: > Vergangene Woche bloggte bereits Joerg-Olaf Schaefers bei uns über > die Antwort der Bundesregierung (PDF) auf Fragen der SPD-Fraktion > zum Strategiewechsel. > > Daraufhin fanden wir in unserem Briefkasten verschiedene Datensätze, > die etwas Einblick in die Hintergründe liefern http://www.netzpolitik.org/2011/interne-dokumente-des-auswartigen-amtes-zur… Die IT-Strategie von FDP und Westerwelle für das Auswärtige Amt kann man demnach wie folgt zusammenfassen: "Wir migrieren zurück zu Windows, verschwenden Millionen an Steuergeldern und setzen auf einen Verlust an Freiheit in der Informationsgesellschaft [1], weil alle (sogar McKinsey) uns dazu geraten haben, dies nicht zu tun und bei GNU/Linux zu bleiben." VG micu ============================== [1] http://www.micuintus.de/2010/10/27/die-gesellschaftliche-bedeutung-freier-s… -- GnuPG: https://www1.inf.tu-dresden.de/~s3418892/micuintus.asc Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80 <<</>> http://www.micuintus.de

3 3

Re: PostgreSQL
by Holger Dietze 11 May '11

11 May '11

Hallo Marcus, "Marcus Obst" <marcus.obst(a)etit.tu-chemnitz.de> >On 10.05.2011 15:04, Heiko Schlittermann wrote: > >> Ich habe nun nicht *diese* Ahnung von PostgreSQL, aber wenn ich mir die >> Doku ansehe, dann steht da was zu "large objects", "lo_import" usw. > >Ja, hab ich auch gesehen, allerdings ist das dann ein ,,extra'' API. Ich >müsste also den Code einigermaßen umschreiben, so stelle ich mir das >aber irgendwie nicht vor. > large objects: "partially obsolete" :-) (Doku zu PostgreSQL 9.0) >> Das scheint die Objects nicht in der Tabelle zu vergraben, sondern >> "extern" und es ist beim Einfüllen der Daten herausfordernder (die >> müssten als Stream kommen(?)). > >Hab ich auch so verstanden > >> Vielleicht ist ja dieses bytea nicht das, was Du brauchst. > >Vielleicht nicht, aber es ist das was ich wöllte :) bytea ist schon das, was Du willst. Vermutlich macht das Insert zuviel Bloedsinn. [Beispiel in etwa fuer Perl DBI) Fuer Bulk-Inserts ist es guenstig, zuerst das Statement mit Platzhaltern zu parsen $sth = $dbh->prepare (q[INSERT INTO tabelle (id, beschreibung, bild) values (?, ?, ?)]); und dann fuer jeden Datensatz das vorbereitete Statement mit den speziellen Werten aufzurufen: foreach (@werte) { $sth->execute ($_->{id}, $_->{beschreibung}, $_->{bilddaten}); } Das spart a) das staendige Neuparsen der Anweisung und die Erstellung des Ausfuehrungsplans, und b) die Konvertierung der Binaerdaten in "Escaped ASCII" weil das Protokoll fuer diesen Fall eine Rohdatenuebertragung vorsieht. COPY waere vielleicht schneller (wenn man die Binaerdaten schnell genug eingepackt bekommt). > >Mysql hätte es bestimmt gekonnt... wzbw. (was zu beweisen waere) PostgreSQL kann es, Du hast eben noch nicht alles rausgekitzelt. BTW, Raid-5 ist fuer Datenbanken nicht so der Bringer. Besser ist Raid-1 oder davon abgeleitete Varianten. Holger ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

6 6

Re: PostgreSQL
by Holger Dietze 10 May '11

10 May '11

Hallo Marcus, Von: "Marcus Obst" <marcus.obst(a)etit.tu-chemnitz.de> > >> Ach ja: wenn Du kannst, verwende COPY anstelle INSERT, wenn es >> Bulk-Inserts sind. Ist um Größenordnungen schneller. > >Geht leider nicht. > >Ich hab jetzt nochmal ein bisschen weiter nachgeforscht. Das Problem >scheint der BLOB zu seien. Wir speichern u.a. unkomprimierte Bilder ab, >diese haben dann pro Eintrag eine Größe von ca. 300k. Sobald ich diese >Einfügen will bricht die import Performance von 40MB/s auf 5MB/s ein. > >Lasse ich die Bilder weg, geht alles wunderbar. > Dann lege die TOAST-Tabelle auf eine getrennte Festplatte. Moeglicherweise schluckt auch das Komprimieren der Bilddaten Rechenleistung. Holger ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

4 6

Re: PostgreSQL
by Holger Dietze 10 May '11

10 May '11

Hallo Marcus, -----Ursprüngliche Nachricht----- Von: "Marcus Obst" <marcus.obst(a)etit.tu-chemnitz.de> Gesendet: 10.05.2011 14:49:28 An: "Linux-User-Group Dresden" <lug-dd(a)mailman.schlittermann.de> Betreff: Re: PostgreSQL >On 10.05.2011 13:55, Marcus Obst wrote: > >> Ich glaube das Problem grenzt sich wirklich auf die Binärdaten ein. Ich >> verwende im Moment dafür den Datentyp *bytea*. Nach allem was ich >> gelesen und glaube verstanden zu haben, ist das am Ende nix weiter als >> ,,escaptes'' ASCII, sprich sowohl Client also auch Server müssen >> irgendetwas konvertieren. > >So, ich hab jetzt nochmal eine Postgres-Datenbank unter Linux aufgesetzt. > >Hier ändert sich ebenfalls nix, außer dass ich das Tun des Servers etwas >besser beobachten kann. > >Sobald ich Daten Größer 30kb in die Tabelle mit dem Type bytea schreibe >wird alles langsam. Serverseitig belegt der postgres-Daemon dann eine >komplette CPU. spricht fuer die Komprimierung beim Abspeichern. > >Demzufolge scheint also die Behandlung von bytea nur mit der >CPU-Leistung zu skalieren. > >Schade eigentlich. > > apt-get remove postgresql nicht so vorschnell. ALTER TABLE tabelle ALTER COLUMN spalte SET STORAGE EXTERNAL; http://www.postgresql.org/docs/9.0/interactive/storage-toast.html Die Bilder liegen doch schon in einem Format vor, was intern komprimiert ist? Holger ___________________________________________________________ Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die Toolbar eingebaut! http://produkte.web.de/go/toolbar

2 1

LUG-TReffen Mittwoch
by GAG 18 10 May '11

10 May '11

Hallo Pinguin-Freunde, wir haben ein kleines Problem: Morgen ist Nachtwanderung und mit Band abbauen und Klub aufräumen werden wir es wohl nicht bis Mittwoch abend geschafft haben. Jetzt meine Frage: wäre es für euch möglich das Treffen kurzfristig zu verschieben. vieleicht um eine Woche? Sorry das ich mich erst so spät melde aber ich gebe zu ich hatte es vergessen... Falls das nicht funktioniert dann sagt bitte schnellst möglich bescheid, dann bekommen wir das schon irgendwie hin, wird nur stressig. Gebt mir bitte auf jeden Fall eine Antwort. Teuflische Grüße! Tobi Kellerklub GAG 18 e.V. Telefon 471 90 85 Telefax 472 43 63 http://www.gag18.de

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Lug-dd