|
|
|
|
|
|
|
| | Zitat von TheRealHawk
Wenn man keine Kalender, Kontakte und alles andere was ein sinnvoller Client haben sollte braucht, ok.
| |
Gebt mal Evolution wieder eine Chance, es funktioniert hier mit Exchange(!) richtig gut. Ich vermisse nur noch eine gute Integration der Kalender anderer Mitarbeiter (funktioniert, aber GUI dazu ist eher eine verstrecktes Easter-Egg).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von kRush*
In meinem Debian jessie tauchen unter etlichen Prozessen plötzlich zig
(deleted)/tmp/rst16743.000257a3
im lsof output auf, die Zahlen sind dabei recht zufällig irgendwie fortlaufend.. wasn da los?
| |
Wenn sie als (deleted) gelistet sind, sind sie doch glaube noch da. Wenn du also irgendwo in /proc/$pid/fd/$deskriptor den passenden Filedescriptor findest, kannst du das file noch ansehen. Wenn ich mich jetzt nicht vertue.
Vielleicht hilft das ja, um der Sache auf die Spur zu kommen. 
|
|
|
|
|
|
|
|
|
|
|
|
MS hat sich mit den letzten Exchange-Versionen ja auch Mühe gegeben, offene Standards zu implementieren die dann auch von beliebigen Clients verwendet werden können. Outlook hat zwar immer noch ein paar kleine Funktionen, die die Exchange-API nicht bietet, aber das wird sich hoffentlich in den nächsten Versionen auch erledigen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
| | Zitat von kRush*
In meinem Debian jessie tauchen unter etlichen Prozessen plötzlich zig
(deleted)/tmp/rst16743.000257a3
im lsof output auf, die Zahlen sind dabei recht zufällig irgendwie fortlaufend.. wasn da los?
| |
Wenn sie als (deleted) gelistet sind, sind sie doch glaube noch da. Wenn du also irgendwo in /proc/$pid/fd/$deskriptor den passenden Filedescriptor findest, kannst du das file noch ansehen. Wenn ich mich jetzt nicht vertue.
Vielleicht hilft das ja, um der Sache auf die Spur zu kommen.
| |
Würde es wenn ich die Kiste nicht schon neu gestartet hätte, aber danke, ich merks mir fürs nächste Mal (wenn es noch eins gibt, der Mist fliegt jetzt endgültig raus).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
MS hat sich mit den letzten Exchange-Versionen ja auch Mühe gegeben, offene Standards zu implementieren die dann auch von beliebigen Clients verwendet werden können. Outlook hat zwar immer noch ein paar kleine Funktionen, die die Exchange-API nicht bietet, aber das wird sich hoffentlich in den nächsten Versionen auch erledigen.
| |
Ja. Etwas traurig war, das Evolution bereits frueher recht gut mit Exchange reden konnte und der letzte Umbau auf "evolution-ews" wieder ganz von Vorne anfangen musste. Den Umbau haben wir wohl der EU zu verdanken, uebrigens ganz im positiven Sinne. Den inzwischen laeuft es seit vier Jahren besser als zuvor. Schade ist eigentlich nur, dass hier erst etwas nach Jahren passiert ist und letztendlich auf Druck anderer Unternehmen und nicht der Oeffentlichkeit. Tatsaechlich muss man die Neelie Kroes danken. SAMBA hat davon auch profitiert. Das haette alles viel frueher passieren koennen, aber es ist passiert! Spezielle Google umgeht dass jetzt relativ clever, mit Android und der Cloud.
Zu Muenchen, ich habe bis jetzt mal vor allem auf einzelne Kommentare bei Heise geachtet. Ich habe hier nicht die Zeit alles mit Links zu belegen und der Link ist auch kein Beweis:
- Es gibt drei, eigentlich sogar vier, IT-Verwaltungen in Muenchen. Ganz klar das Hauptproblem.
- Microsoft Windows und bestimmte Programme wurde nie abgeloest. Ein generelles Problem, wenn man ein anderes System benuetzt muss man wirklich auf native Programme umstellen oder Windows umgehen.
- Der Personalrat hat offenbar verlangt, dass es so gut wie keine Aenderungen an der Software geben darf (keinen Button verschieben, sonst erfordert das Schulungen). Das ist eine Upgradeverweigerung mit Zwang zur Schulung.
- Die IT konnte, oder wollte, die Software nicht aktuell halten. Es erscheint so, als ob die noch mit ~ Debian 6 und OpenOffice arbeiten. Was der Softwarestand etwa von Vista waere.
- Der neue OB hat Microsofts Zentrale nach Muenchen geholt, was eine Mischung aus Gewerbesteuereinnahmen und persoenlichen Seilschaften ist.
Ich persoenlich kann nur sagen, dass man unbedingt vollstaendig Migrieren muss. Niemals darf man WINE einsetzen oder den Leute mit virtuellen Maschinen oder Terminal-Servern kommen, dass ist langsam, instabil und sehr wartungsaufwendig. Und dann tut man sich im Umkehrschluss unglaublich schwer, die Software aktuell zu halten.
Wichtige Anwendungen muessen nativ portiert werden. Viel Aufwand, viel Ertrag. Das ist besonders schwierig, da viele sogenannte Fachanwendung historisch gewachsender Giftmuell sein duerfte. Falls man Glueck hat gibt es fuer weniger stark schwergewichtige Anwendungen schon eine Weboberflaechen, was es heute leichter macht als frueher. Hauptproblem sind dabei halt zusammengefrickelte sogenannte Fachanwendungen, bei denen die jetztigen Entwickler die Anforderungen gar nicht mehr kennt. Speziell Hardware kann dabei toedlich sein, aber auch hier kann man mit schlauen Loesungen arbeiten (ich habe mit den Kartenlesern inzwischen ziemlich viele kreative Loesungen entwickelt). Falls die eID-Anwendung fuer den elektronischen Personalausweis einen Fingerabdruck benoetigt, kann man sich aller Treiberprobleme entledigen indem das Lesegeraet direkt per Netzwerk den Abdruck als Scan ablegt oder per Email zusendet. Das ist obendrein eine Portierung auf alle Plattformen und sehr viel flexibler. Viele Probleme koennte man durch zentrale Entwicklung durch den Bund loesen und Geld sparen. Und als Zulieferer darf man nicht immer den billigstens Anbieter waehlen und muss die technische Realisierung hinterfragen. Ich lehne die elektronischen Funktionen des ePA ab, erinnere mich aber wie wir im Heise-Forum das letzte "Gefrickel" von T-Systems auseinandergenommen haben, sie haben Java und .NET in einer Anwendung verwurschtel. Ein wunder dass das laeuft! Der ePA wird ohne quelloffene Library in C unter MIT/BSD/LGPL keinen Erfolg haben. Aber die Politiker geben immer wieder neue "Apps" in Auftrag, weil die alten Mist sind, schon faszinierend.
Und was die angebliche Forderung vom Personalrat angeht:
Als Entwickler ist es unsere Aufgabe fuer den Endanwender (!= Profianwender, welche flexible Shellprogramme will) fertige, bequeme und weitestgehende automatische arbeitende Loesungen zu entwickeln. Das ist die Aufgabe von Software, das Leben leichter machen! Das schreibt sich leicht und ist in der Praxis wirklich schwierg. Fuer mich, weil ich Kartenterminals mit einer Webanwendung verbinde.
Und in dem Zug darf und muss man Software umbauen duerfen, bei der Sparkasse haben wir bei der Umstellungen von 3270-Emulation auf Webanwendung Schulungen ueber drei Tage erhalten. Umgekehrt darf und muss man von Angestellten die Faehigkeit zur Bedienung von Computern erwarten. Es gab eine Releasemail von der Sparkassen-Informatik, die man selbst abrufen konnte und eine fuer die Anwender von der eigenen IT und damit konnte nahezu jeder sich an neuen Versionen anpassen, ansonsten gibt es immer Mitarbeiter die anderen Helfen koennen und duerfen.
Wir haben hier jetzt wieder die ultimative Situation, wir sollen mit eine neuen Webanwendung eine alte ersetzen (die wirklich ersetzt werden muss) und dann gleich folgende Forderungen vom Kunden: Die URL darf sich nicht aendern (und damit meinen die nicht nur die Domain!), die Oberflaeche muss genauso aussehen (also die unbequeme Bedienung portieren) und wir sollen gar nicht auf Kompatiblitaet zu den Webbrowsern achten, wir sollen einen eigenen Webbrowser installieren mit Homepage und den als "Anwendung" beschoenigen. Man kann es sich und den Menschen da draussen wirklich schwer machen. Die URL-Story unterminiert die Idee einer Stufenweise Migration natuerlich 
Native Awendungen und webbasierte Loesungen
Zum Beispiel Word durch LibreOffice zu ersetzen ist vollkommen richtig, dass ist deren staendiger Begleiter in jeder Verwaltung. Da kann man keine rueckelige Websoftware verwenden, die bei Wartungsarbeiten am Proxy nicht geht. Ich habe das mal in der Sparkasse erlebt, es ist langsam, unbequem und hat in meinem Hirn die Hand/Augen-Koordination unterbrochen (Kopfschmerzen). Man darf erwarten, dass die Zeichen zeitgleich auf dem Bildschirm auftauchen, gerade mit dem Zehn-Finger-System*! Andersherum, die An- und Abmeldung eines PKW muss jetzt nicht unbedingt in Lichtgeschwindigkeit erfolgen, nur zuegig und zuverlaessig. Da kann eine Webanwendung schon eine gewinnbringende Idee sein.
Womoeglich hat Microsoft ja sogar Glueck in Muenchen, falls die IT vereinheitlich wird, koennen sie einen einfachen Erfolg erzielen und den fuer sich verbuchen. Dabei ist der ganze Migrationsschmerz mit Window >= 8 und Office-Ribbon an Muenchen vorbeigezogen ist, bisher, jetzt darf man sich eben auf Windows 10 mit permanenten Upgrades einstellen. Da duerfte so manche Fachanwendung ihre Probleme entwickeln. Letztend Endes war es ein Geniestreich die Deutschlandzentrale ein paar Meter zu verlegen und dem OB damit Gewerbesteuereinnahmen zu verschaffen, wenn das Wort faellt schaltet sich bei einem Kommunalpolitiker verstaendlicher Weise das Gehirn aus.
Interessant ist, von Florida (Largo) (XFCE, bloggt oefters bei planet.gnome.org), ueber Spanien und Frankreich, bis Niedersachen (12.000+ mit KDE) kann man mit Linux arbeiten. Das setzt dann halt eine gute IT voraus 
Wer bis jetzt durchgehalten hat hier der Plot-Twist:
Ob erwaehntes Schreiben mit zehn Fingern wird wunderschoen, wenn sogar die Zeichen sanft fliessend auf den Bilschirm gezeichnet werden. Microsoft hat das irgendwie erkannt und es zumindest in den nativen Office-Anwendung eingebaut. Das ist wirklich mal eine schoene Sache fuer den Anwender, muss ich Microsoft ehrlich zugestehen.
Wuensche mir das gleiche Feature generell fuer Gtk und Qt
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 17.02.2017 13:17]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
| | Zitat von TheRealHawk
Wenn man keine Kalender, Kontakte und alles andere was ein sinnvoller Client haben sollte braucht, ok.
| |
Gebt mal Evolution wieder eine Chance, es funktioniert hier mit Exchange(!) richtig gut. Ich vermisse nur noch eine gute Integration der Kalender anderer Mitarbeiter (funktioniert, aber GUI dazu ist eher eine verstrecktes Easter-Egg).
| |
evolution geht bei uns in der firma laufend kaputt. immer ist irgendwas... (und support bei problemen bekommste da ja nicht)
ich geh da meinem mittelweg indem 99% der zeit ich eh nur die "emailfunktion" nutz und das über imap/thunderbird abfrühstück.
für das bischen termin/raumbelegung was ich hab gibts ne rdesktop-session die in sekundenschnelle auf ist.
kenn allerdings auch leute die da gerne das ganze KDE zeugs benutzen. ich denke das wäre meine einstiegsstelle bevor ich das monster aus der hölle rauslass (evolution).
|
|
|
|
|
|
|
|
|
|
|
KDE hatte eben ewig keinen Support for Exchange, aber die bauen jetzt etwas ein. Weiss aber echt nicht was da kaputt gehen soll, die Windowsadmins bei uns nehmen keine Ruecksicht auf irgendwas und es geht trotzdem. Wobei fluchende Outlooknutzer durchaus existieren 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 17.02.2017 16:59]
|
|
|
|
|
|
|
|
|
Die PIM-Suite von KDE war doch schon immer ziemlich gut.
Brauch ich halt nicht. Vong Job her gibt es OpenXchange, das läuft komplett im Browser und ist da nicht schlimm genug bzw. nutze ich nicht intensiv genug, als dass ich mich mit nativer Integration beschäftigen würde. (Tatsächlich würde ich da jetzt mal als eine der gelungeren JS-Anwendungen bezeichnen -- hat nichtmal einen Ladebalken!)
Apropos, ich hatte jetzt die Ehre PowerPoint Online zu benutzen, und abgesehen davon, dass es doch recht beeindruckend ist, dass die da nen recht vollständigen PPT-Editor in JS haben, ist das auch wieder eine klischeehafte JS-Anwendung: Lädt ewig, viel CPU-Verbrauch und sogar der Ladespinner ruckelt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 17.02.2017 17:23]
|
|
|
|
|
|
|
|
|
OX läuft bei mailbox.org und funktionierte einfach mal gar nicht. Nachdem Zarafa den Outlook Support abgekündigt hat sind wir bei Kerio gelandet. Die fliegen irgendwie oft unter dem Radar und tauchen in Vergleichen gar nicht erst auf, funktioniert aber OOTB einfach annähernd perfekt und es gibt native Debian Pakete. Funktioniert auf jeden Fall besser als alles was ich bisher gesehen hab (inkl. Exchange).
Das eigentliche Problem sind aber halt die Clients. Outlook ist gut, em Client ist super (ich mag das Look & Feel von Outlook aber immer noch lieber), Thunderbird funktioniert nur als reiner Mailclient.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TheRealHawk am 17.02.2017 20:19]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TRH: Ich hab den Mail-Teil von OX glaube ich noch nie benutzt, weil mein GPG-Key nicht aufm OX liegt. Anscheinend gibt es aber eine Integration da, er fragt nach nem Key...
Der Rest, wie gesagt.
Für Mail benutze ich Thunderbird und Enigmail oder wie das hieß, was eine super Kombination ist. GPG-Nutzung auf das absolute Minimum reduziert.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 17.02.2017 22:36]
|
|
|
|
|
|
|
|
|
|
Travis' Kapazitäten auf OSX sind jetzt so stark ausgelastet, dass Travis bis ins Wochenende braucht, um die Builds im Backlog abzuarbeiten.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
TRH: Ich hab den Mail-Teil von OX glaube ich noch nie benutzt, weil mein GPG-Key nicht aufm OX liegt. Anscheinend gibt es aber eine Integration da, er fragt nach nem Key...
| |
Bei OX legt man seinen private Key auf den Server. Ich finde das etwas bedenklich.
|
|
|
|
|
|
|
|
|
|
|
Danke. Koennte Windowsanwender in meiner Firma geben, die sich das vielleicht mal ansehen
Ich habe Kollegen unter Windows kein Outlook nutzen, obwohl Lizenz da, weil es bei deren Mailbox auf Grund der Groesse versagt und Thunderbird nutzen (Kalender und so interessieren die nicht).
|
|
|
|
|
|
|
|
|
|
Buildsystem
|
Ich entschuldige mich hiermit fuer die nachfolgende Opfer der fundmentalistischen Kriege, die folgen koennen. Aber - meine Sourcen brauchen Kompilierung! Mir geht es um C/C++, diverse Traumata mit Maven und Java sind also nicht von belang.
Ich habe bisher mit handgeschriebenen Makefiles gearbeitet. Das macht sehr viel Aufwand, aber der Build ist zuverlaessig, schnell und nachvollziehbar. Man tippt $make [optionalerwunsch] ein und bekommt genau das gewuenschte Resultat auf jeder Plattform. Den ganzen Umfang von gnu-make nutze ich bis heute nicht.
Ich habe mich jetzt durch 380 Seiten Praesentation zu den gnu-autotools durchgearbeitet, es scheint auch alles zu koennen was ich will. Nur erinnert mich alles bedenklich ganz stark an groff, regex, sed und Textsatzsysteme und es kommen noch 200 Seiten fuer i18n und spezielle Sachen. Ein Indikator der mir beunruhigt ist die grosse Anzahl der Konfigurationsdateien, automatisch generierten Konfigurationsdateien und die ganzen verschiedenen Programme die im Hintergrund arbeiten.
Ich schaue mir jetzt gleich Meson an. Das scheint ja der neue heisse Sch**ss im Buildtoolland zu sein? Habe aus Interesse ein Beispielprojektin mit gnome-builder angelegt, da sehe ich nur ein Bruchteil der Dateien. Ich will hier nur nicht einem hippen Trend hinterherlaufen. Sicher gibt es auch verfechter von CMake? Was setzt ihr ein? Wieso?
|
|
|
|
|
|
|
|
|
|
|
|
Wer Exchange im Hintergrund nutzt, hat doch normalerweise ne Archivlösung im Einsatz. Entweder die, die Exchange seit einiger Zeit selber mitbringt oder so ein Kram wie Enterprise Vault, was wir seit ca. 10 Jahren einsetzen. Meine Mailbox hat so 150 MB, obwohl ich seit einem Jahrzehnt keine relevanten Mails mehr gelöscht hab. Keine blöden Umzüge von Mails, wenn Mitarbeiter ausscheiden (Archiv wird einfach an den Nachfolger weitergegeben und ist dann automatisch für den sicht- und suchbar), feste Compliance-Vorgaben durch Journalarchivierung und Outlook macht auch keinen Ärger. Grad bei Banken hätte ich sowas erwartet...
|
|
|
|
|
|
|
|
|
|
|
|
In der Firma haben wir CMake. Es funktioniert gut, glaube ich. Auf jeden Fall wird es von CLion unterstützt, was für mich ein großes Kriterium ist. Ich habe aber peinlich wenig Ahnung von Buildsystemen und sollte mich wirklich mal 1-2 Tage reinfuchsen.
|
|
|
|
|
|
|
|
|
|
|
qbs oder cmake
Alles andere ist arg meh und selbst cmake baut öfter mal Mist. qbs, ich kann's nur immer wieder sagen, hat mir noch nie einen einzigen fehlerhaften Build gemacht und war bisher immer schneller als CMake und Co.
qbs hat imho nur drei-vier Nachteile:
1. etwas gewöhnungsbedürftige Syntax (wenn man kein QML kennt)
2. man musas Compiler manuell einstellen (bzw. --detect manuell ausführen).
3. Bibliotheken, an die man nicht per pkg-config rankommt, werden eher kein fertiges Snippet haben
4. Doku ist nicht so übersichtlich
Große Pro-Punkte von CMake sind:
- Gibt für fast alles irgendwo nen Snippet
- Sehr flexibel
- CLion
- Die Doku ist vollständig (aber auch nicht so übersichtlich) und StackOverflow ist voll mit cmake.
- Die Chance, dass "make -j20" klappt ist bei CMake etwas besser als bei dem anderen Zeugs.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 18.02.2017 13:20]
|
|
|
|
|
|
|
|
|
| | Zitat von Danzelot
Es funktioniert gut, glaube ich.
| |
| | Zitat von Danzelot
Ich habe aber peinlich wenig Ahnung von Buildsystemen und sollte mich wirklich mal 1-2 Tage reinfuchsen.
| |
Ich bin gerade auf Level Tag 2 und soeben durch die 556 Seiten durch
Wobei ich bei gettext nur noch druebergelesen habe.
@Garland:
Ich meine mich in Outlook (frueher) an ein Archiv zu erinnern. Oder war es in Lotus Notes? Aber ich bin schon ewig nicht mehr bei der Spardose.
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 18.02.2017 16:07]
|
|
|
|
|
|
|
|
|
CMake ist cool und wie ich finde eigentlich auch garnicht so schlimm zu schreiben, im Bezug auf die Syntax. Ich empfehle zum Einstieg (nach irgendeinem Tutorial) das Buildsystem von irgendeinem größeren Open-Source Projekt durchzulesen, dann lernt man schnell, wie man mit Problemen umgeht. Ich fand neovim eine gute Quelle .
|
|
|
|
|
|
|
|
|
|
|
+1 für CMake. Immer nen Tab damit offen lassen.
Im Vergleich zu nackten Makefiles geht das ganz gut von der Hand und läuft noch dazu mit allen gängigen Platformen.
|
|
|
|
|
|
|
|
|
|
|
Direkt mal die Variablenliste gebookmarked 
|
|
|
|
|
|
|
|
|
|
|
|
Paketbauers Freund: cmake -LAH
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Lügenfile
|
Ich schaue mir gerade meson und moechte das hinterher mit cmake vergleichen. Dabei ist mir folgendes aufgefallen:
| |
| Code: |
$ mkdir build && cd build && CFLAGS="-O3 -s" meson --buildtype=plain ..
The Meson build system
Version: 0.38.1
Source dir: /home/peter/exploremeson
Build dir: /home/peter/exploremeson/build
Build type: native build
Project name: tutorial
Native c compiler: cc (gcc 6.3.1)
Appending CFLAGS from environment: '-O3 -s'
Build machine cpu family: x86_64
Build machine cpu: x86_64
Build targets in project: 1
[peter@lap-lnx-pew build]$ ninja
[2/2] Linking target demo
[peter@lap-lnx-pew build]$ file demo
demo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9f0f0c31e0f9615e2718c80115043167cdb2f4c3, stripped, with debug_info
|
|
Warum so kompliziert? Wegen "with debug_info" ganz am Ende! Mir aufgefallen, das jede Executable die ich mit meson & ninja baue debug_infos enthaelt! Also habe ich "buildtype=plain" (das ist fuer die Maintainer der Distributionen) gesetzt und meine eigenen Flags uebergeben. Nur erscheint trotzdem with debug_info. Also habe ich auf Stackoverflow gepostet. Ergebnis war, dass ich mir gleich darauf auf Github den Source von file angesehen habe (ich habe von Anfang an file verdaechtigt). File hat einen Bug
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 21.02.2017 21:41]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Geht doch noch. Ich hab vor kurzem das Kernel-Repo mit tig angeguckt, kurz runterscrollen und man kann die Commit-Messages nicht mehr sehen. Zumindest nich auf 1920px Breite.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KeePassX (Version 1) scheint die einzige KeePass-Variante/-Fork zu sein, die Autotype (STRG+V) in i3 hinbekommt. Nicht mal KeePassX2 macht das noch 
KeePass selbst geht nicht, KeePassXC geht nicht. Ich will aber Unterstützung des neuen Formats (kdbx) 
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |
