|
|
|
|
|
|
|
| | Zitat von csde_rats
Stock Archlinux Kernel aus dem Repo, ich kenne die Config nich... 
| |
schau dir die config halt an: cat /boot/config-$(uname -r)
|
|
|
|
|
|
|
|
|
|
|
Ich hab nur ne /proc/config.gz
~> zcat /proc/config.gz | grep HZ
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_RCU_FAST_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_MACHZ_WDT=m
~> zcat /proc/config.gz | grep CFQ
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
CONFIG_DEFAULT_CFQ=y
~> zcat /proc/config.gz | grep EMPT
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
|
|
|
|
|
|
|
|
|
|
i3pystatus jetzt auch mit... reddit und bitcoin Support...
Das nimmt ja Formen an hier 
/e: Bei der Länge des Changelogs wird mal wieder ein Release fällig.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 18.07.2014 20:53]
|
|
|
|
|
|
|
|
|
zomg, denkt doch wer an die Kinder! Nehmt zgrep
Das Problem mit I/O->Stau habe ich mit einer 840pro im x201 von Lenovo auch. Und ja früher war das schon besser.
Die Primepower ging 2007 außer Dienst, jetzt wird ihr Nachfolger durch einen Nachfolger ersetzt und wir brauchen den Platz. Das Monstrum hat neben den 4HE Server/Festplattenkorb auch noch eine USV mit dabei, die kann vor dem Transport natürlich entfernt werden.
|
|
|
|
|
|
|
|
|
|
|
Nutzt jemand den Filesync von Owncloud? Ist das schnell, auch für viele/große Files?
Ich nutze gerade BTSync. Das ist superschnell, besonders weil ich immer mindestens 4 Clients online hab. Aber das ist Closed Source und relativ buggy. Da ich ne Owncloud laufen haben wäre das die erste Alternative, die ich mir jetzt ansehen wollte.
/e: Mhh, das ist ja scheisse langsam. Aber wieso? Weder eine der Leitungen noch einer der Rechner ist ausgelastet..
PHP!!!11
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von theromi am 19.07.2014 15:24]
|
|
|
|
|
|
|
|
|
|
Ich wollte gerad schreiben, das allein der Versuch mit OwnCloud eine Zeitverschwendung ist, weil bedingt durch PHP nichtmal eine Chance bestehen kann.Dein Edit zeigt, dass dir dies Erkenntnis auch wieder eingefallen ist :-)
|
|
|
|
|
|
|
|
|
|
|
Seafile anstatt Owncloud.
http://seafile.com/
Python + C. Hab ich seit längerer Zeit produktiv am Laufen und bin sehr zufrieden. Performance ist sehr gut.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von audax
Seafile anstatt Owncloud.
http://seafile.com/
Python + C. Hab ich seit längerer Zeit produktiv am Laufen und bin sehr zufrieden. Performance ist sehr gut.
| |
seit diesem fest eincodierten salz bei seafile trau ich dem ehrlichgesagt eher weniger...
klar, ka wie es da bei owncloud aussieht, ich hoffe einfach dass mal jemand anderes sich die arbeit macht und sich die dinger anschaut 
|
|
|
|
|
|
|
|
|
|
|
Na gut, aber da hatte Owncloud doch erheblich heftigere Probleme als nen festen Salt.
http://www.cvedetails.com/vulnerability-list/vendor_id-11929/Owncloud.html
Aber gut, ich will dich ja nicht versuchen, zu überreden. Ich habe jedenfals mit Owncloud nur Probleme gehabt und fahre mit Radicale für CalDav und CardDav sowieso Seafile für Dateien erheblich besser. Bei anderen Leuten scheint aber ja Owncloud mit guter Performance und problemlos zu laufen. Du brauchst bestimmt nur nen schnelleren Server.
|
|
|
|
|
|
|
|
|
Warnung systemd-215
|
Bitte unbedingt die Mkinitcpio von selbst kompilierten Kernel(n) nach dem Upgrade auf Systemd >= 215 neu bauen, bevor man neu startet. Oder wenigstens einmal den Defaultkernel von Archlinux hochbooten lassen!
https://bugs.archlinux.org/task/41097
Der Fix fuer Systemd 215-2 zieht wahrscheinlich zu spaet oder nicht, wenn man nicht den Defaultkernel verwendet.
|
|
|
|
|
|
|
|
|
|
|
Irgendwas war gerade in Hetzners Netzwerk los. Erst melden zwei Hosts (per cssh) gleichzeitig, dass sie nach draußen kein rsync dürfen (Connection reset), danach geht's plötzlich ohne jegliche Änderung wieder.
Neu gelernt: Wenn die gegenüberliegende Seite die anzunehmende Verbindung abweist, meldet telnet "Permission denied". Das soll man erst mal rausfinden 
|
|
|
|
|
|
|
|
|
|
|
Ich habe mich gerade durchgesetzt und beschlossen, dass wir zukünftig Git statt Subversion verwenden wenn es keinen konkreten Showstopper gibt. Kann man die Repositories nahtlos und vollständig migrieren und gibt es irgendwas das Subversion kann aber Git nicht?
PS: und benutzt zufällig jemand TortoiseGit und kann sagen ob das mittlerweile ausgereift ist?
|
|
|
|
|
|
|
|
|
|
|
|
Ich hasse git unter Windows irgendwie. Immer nur Probleme mit dieser doofen gui.
|
|
|
|
|
|
|
|
|
|
|
|
Wäre auch nicht so sehr das Problem, regulär werden die Entwickler den integrierten Git-Support von PhpStorm verwenden und in maximal drei Monaten soll eh alles über TeamCity CI laufen.
|
|
|
|
|
|
|
|
|
|
|
|
Was sind die Vorteile von git im Admin-Umfeld?
|
|
|
|
|
|
|
|
|
|
|
Wir haben hier auch von SVN zu GIT umgestellt. Kleines Entwicklerteam mit 8 Progammierern. Man muss sich schon ein wenig umstellen. Vor Allem sollten alle Entwickler mit der Philosphie von dezentralem vs. zentralem Versionamangement vertraut gemacht werden. Zudem sind evtl. hier und da Anpassungen an bestehende Lösungen notwendig, die sich der Revisionsnummer aus SVN bedienen. So haben wir z.B. Probleme mit Windows-Installern bei denen bisher die SVN Revisionsnummer einfach als minor Version mit reingepackt wurde. Das geht mit Git commit hashes nicht mehr.
Und dieses TortoiseGIT unter Windows zerlegt regelmäßig bei den anderen hier Arbeitskopien. Wer also bisher den "SVN macht nichts kaputt, das geht schon schief"-Ansatz verfolgt hat, kann da mit TortoiseGIT und den falschen Haken in der UI böse Überraschungen erleben. Dadurch schaffen es einige auch immer wieder erfolgreich die Änderungen eines anderen ungewollt zu reverten, weil irgendwo beim Pullen und Mergen was schief ging, übersehen wurde.
Ansonsten eigentlich ganz cool. Insbesondere wenn man sich den Luxus erlaubt und sich intern ein GitLab aufsetzt. Oder eben gleich GitHub nutzt, wenn man keine Probleme damit hat, dass der Code dort liegt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gitlab ist eigentlich relativ freundlich, das hat man ziemlich schnell gemacht. Und ist auch bequem.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
PS: und benutzt zufällig jemand TortoiseGit und kann sagen ob das mittlerweile ausgereift ist?
| |
Wenn es mal eingerichtet ist, ok. Bei uns gibt es immer wieder Probleme mit Windows+ssh+TortoiseGit. Hat ansonsten noch mehr Macken - aber ich glaube, unter Win gibt es nicht wirklich Alternativen, oder?
|
|
|
|
|
|
|
|
|
|
|
|
VS unterstützt git, und das ziemlich gut. Ist dann halt einfach die Voraussetzung, dass man auch mit VS arbeitet.
|
|
|
|
|
|
|
|
|
|
|
|
VS aber auch nur in den aktuellen Versionen. Da reicht dann aber die VS shell.
|
|
|
|
|
|
|
|
|
|
|
Jo das sollte man dazu sagen. Ich habe zum Glück das Privileg privat und im Geschäft Dreamspark mit allem drum und dran* zu haben Powershell ginge übrigens auch, gibt da ein gutes git "Plugin".
¤: *Und keine vollbehinderte Updatepolitik.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von SwissBushIndian am 21.07.2014 11:56]
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Wir haben hier auch von SVN zu GIT umgestellt. Kleines Entwicklerteam...
| |
Eben deswegen frage ich ja, wo die Vorteile für Systemadministration lägen. Wenn nicht diverse Leute als Hauptbeschäftigung Codezeilen ändern, sondern hauptsächlich Configpakete gruppiert und automatisch abrufbar sein sollen, hat man dann auch irgendwelchen dezentralen Vorteile?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 21.07.2014 11:57]
|
|
|
|
|
|
|
|
|
Seit einigen Tagen schaffe ich es nicht mehr unsere Windowsshares zu mounten.
| |
| Code: |
yt:~$ sudo mount --verbose /mnt/archiv
Credential formatted incorrectly: (null)
mount.cifs kernel mount options: ip=10.0.0.2,unc=\\10.0.0.2\Archiv,iocharset=utf8,file_mode=0660,dir_mode=0770,uid=1510,gid=100,user=yt,pass=********
|
|
Jemand schon mal ähnliches gehabt?
/edit
Auf anderen Maschinen bekomme ich mit der selben /etc/fstab andere Fehlermeldungen ...
| |
| Code: |
mount error(112): Host is down
|
|
oder
| |
| Code: |
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
|
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von YT am 21.07.2014 12:21]
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
| | Zitat von GH@NDI
Wir haben hier auch von SVN zu GIT umgestellt. Kleines Entwicklerteam...
| |
Eben deswegen frage ich ja, wo die Vorteile für Systemadministration lägen. Wenn nicht diverse Leute als Hauptbeschäftigung Codezeilen ändern, sondern hauptsächlich Configpakete gruppiert und automatisch abrufbar sein sollen, hat man dann auch irgendwelchen dezentralen Vorteile?
| |
Vermutlich keine signifikanten. Aber auch keine echten Nachteile. Wenn man die Historie der Dateien eh nicht braucht, kann man sich Versionskontrolle sowieso sparen.
|
|
|
|
|
|
|
|
|
|
|
Ich kann nur global für uns sprechen, nach den Erkenntnissen aus Entwicklerkonferenzen und monatlichen Releases stellt es sich momentan so dar, dass
a) wir uns bei Releases einen Haufen Zeit sparen würden den wir jetzt mit dem Mergen und der damit einhergehenden Behebung von Konflikten verbringen, was auch nach einem Upgrade auf Subversion 1.8 immer noch ein allgegenwärtiges Problem ist;
b) die Performance nach ein paar oberflächlichen Tests wesentlich besser ist, besonders wenn einige aufwändigere Hooks anspringen - das ist mit 1.8 etwas besser geworden aber immer noch träger zwischen Faktor 2 und 10 (obwohl ich nach dem Upgrade schon die Repos komplett gedumpt, geplättet, einiges aus den Dumps rausgefiltert, alles neu eingerichtet, die Hooks neu geschrieben und die Dumps wieder eingespielt habe);
c) unsere Tools besseren nativen Support für Git als für Subversion haben, mit dem Upgrade auf 1.8 mussten wir z.B. erstmal eine ganze Weile warten weil PhpStorm damit nicht umgehen konnte;
d) wir z.B. GitLab einsetzen möchten und jetzt schon u.a. viel mit npm, bower, composer, satis usw. arbeiten die auch eher gitzentrisch sind;
e) unser neuester Entwicklerzugang neben mir sitzt und sich eigentlich ständig nur über Subversion aufregt
Eigentlich ist alles um uns herum schon Git, nur unsere lokale Entwicklungsumgebung nicht, und das auch nur weil sich bisher keiner damit auseinandersetzen wollte. Jetzt haben wir aber schon mehrere Entwickler die sich eh gut bis sehr gut damit auskennen und bevor wir noch mehr Leute einstellen die sich in Subversion einarbeiten und um das "alte" System eine CI-Umgebung herum bauen machen wir lieber rechtzeitig einen sauberen Cut. Ich glaube der DVCS Approach entspricht auch eher der Denkweise unserer Entwickler und der Natur unserer beiden großen Projekte.
Ein ehemaliger Kollege hat in seiner Firma gerade von einer Mischung aus VSS (), TFVC und Subversion auf Git umgestellt und ist einigermaßen begeistert, mit dem werd ich mich nochmal zusammensetzen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Rufus
| | Zitat von GH@NDI
Wir haben hier auch von SVN zu GIT umgestellt. Kleines Entwicklerteam...
| |
Eben deswegen frage ich ja, wo die Vorteile für Systemadministration lägen. Wenn nicht diverse Leute als Hauptbeschäftigung Codezeilen ändern, sondern hauptsächlich Configpakete gruppiert und automatisch abrufbar sein sollen, hat man dann auch irgendwelchen dezentralen Vorteile?
| |
Für den SysAdmin gibts so gesehen keinen Vorteil durch GIT. Eher die Ersparnis irgendwelche mod_dav SVN Geschichten in Apache-Konfigs am laufen zu halten
Allerdings braucht man halt dafür dann etwas versiertere Entwickler, die eben mit PublicKey und SSH-Keys was anfangen können. Was bei Windows-Leuten schon eine überraschend hohe Hürde sein kann. Wobei das auch ziemlich verkackt ist, mit TortoiseGit und PuttyAgent und dem ganzen krams...Sicher fühlt sich das nach der Einrichtung nicht mehr an
Was sonst konkrete Vorteile angeht: Ein Kollege macht viel im Zug wenn er zwischen zuhause und Kunde pendelt. Für den ist git natürlich ein Heilsbringer.
Ansonsten ist das bei uns glaube ich wie in den meisten anderen Teams auch: Ein Stück weit wird der dezentrale Ansatz so verbogen das es am Ende doch wieder recht zentral ist. Zumindest pullen/pushen wir uns nicht gegenseitig direkt in die Repos sondern gehen über den Gitlab Server (den es für faule auch als fertiges VM-Image zum saugen und starte gibt )
//Was man allerdings auch sagen muss: Submodules sind merklich schon ein ziemliches gefrickel im Vergleich zu Externals in SVN. Wir haben ein Projekt das OpenSSL und Boost nutzt. Haben wir also brav beide GITs als submodule eingebunden...ein sauberer rekursiver Checkout tauert ne gute Stunde und latscht dir halt den Dependency-Tree quer durch alle OpenSource-Projekte durch
Obendrein ist das dann auch der Moment in dem man die Abhängigkeit von GitHub extrem spürt. Ist das Down oder grade langsam, bist du ziemlich gefickt...
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 21.07.2014 15:00]
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Ist das Down oder grade langsam, bist du ziemlich gefickt...
| |
Wie ich es hasse von zuhause aus hasse mit IBM Jazz zu arbeiten. Das macht mich jedesmal ein wenig sauer und ich hätte gerne wenigstens lokal git...
¤: Aber für Git zentral einen Server zu haben halte ich nicht so falsch. Das Problem was ich mit Jazz habe ist halt einfach, dass ALLE Funktionalitäten den Server brauchen. Das macht mich immer leicht mett 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 21.07.2014 15:33]
|
|
|
|
|
|
|
|
|
|
Komplett ohne Zentralität kommt ja git sowieso nicht aus. Bzw. git eigentlich schon, nur die damit entwickelten Produkte i.d.R. nicht. Und wenn es am Ende nur ein Herr Torvalds ist, der sich die Pull-Requests rauspickt.
|
|
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.30 gute Gründe für systemd ) |
