|
|
|
|
|
|
Ach komm. Das ist doch eine Falle!
// edit
Ich kaufe ein "e"
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 01.04.2020 23:08]
|
|
|
|
|
|
|
|
|
|
Eigentlich wärs ja sinnvoll die Kräfte zu bündeln. Aber wo kämen wir denn da hin. Muh Choices! Year of the Linux fragmented Desktop Clusterfuck!
|
|
|
|
|
|
|
|
|
|
|
Wunder Punkt. Wie viele Forks von Archlinux gibt es mittlerweile?
Bei GNOME läuft gerade wieder die Diskussion an ob und wie hinderlich die zahlreichen Distributionen sind um ein verlässliche Plattform zu bilden. Nur hat das immer den Tenor die Distributionen sind doof und
Paketmaintrainer sollen weg. Und dann wir haben alle noch ein Problem mehr! Die können das eben nicht selbst.
Vielleicht der Urfehler des GNU Projektes, nicht eine komplettes System selbst zu liefern. Die Maintainer der Distributionen sind das Fundament der Lösung um zwei oder drei Basisvarianten zu schaffen. Die Wissen wie man
Installer macht, Paketverwaltung und Support macht.
Und die ganze Forks und Patches hat sich GNOME selbst zuzuschreiben, weil man gute Bedienbarkeit damit verwechselt hat wenige Optionen anzubieten. Die bringen immer das alte Beispiel mit den drei Widgets für die Uhr,
das hat aber nichts damit zu tun das man das Verhalten bei geschlossenem Display nicht in GNOME ändern kann. KDE hat ja auch Forks und irgendwie mehrere Webbrowser.
Habe dann geschrieben, dass sie bitte zusammen arbeiten sollen und nicht etwas Eigenes machen sollen. Systemd und FlatPak sind erste Schritte. Und bei GNU hat man schmerzlich gelernt, dass ein Fork von GCC nicht
hilfreich war. Ich hoffe 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 01.04.2020 23:52]
|
|
|
|
|
|
|
|
|
Ach! Swiss hat mich abgelenkt 
Der Aprilscherz von Fefe ist nett! Wollte ich eigentlich schreiben.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 01.04.2020 23:58]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Vielleicht der Urfehler des GNU Projektes, nicht eine komplettes System selbst zu liefern.
| |
ich sag dazu jetzt nur folgendes:
"frische" gitlab install, die ganzen daemons laufen zusätzlich auch lokal oder auf servern daneben.
| |
| Code: |
systemd-+-agetty
+-bundle-+-13*[bundle---3*[{bundle}]]
| +-2*[{bundle}]
+-cron
+-dbus-daemon
+-2*[dhclient]
+-gitaly-+-2*[ruby---38*[{ruby}]]
| +-24*[{gitaly}]
+-nullmailer-send
+-rsyslogd---3*[{rsyslogd}]
+-runsvdir-+-runsv-+-redis-server---3*[{redis-server}]
| | +-svlogd
| +-runsv-+-gitaly-wrapper---11*[{gitaly-wrapper}]
| | +-svlogd
| +-runsv-+-postgres---24*[postgres]
| | +-svlogd
| +-runsv-+-gitlab-unicorn----sleep
| | +-svlogd
| +-runsv-+-bundle---35*[{bundle}]
| | +-svlogd
| +-runsv-+-gitlab-workhors---10*[{gitlab-workhors}]
| | +-svlogd
| +-runsv-+-nginx---9*[nginx]
| | +-svlogd
| +-runsv-+-gitlab-logrotat---sleep
| | +-svlogd
| +-runsv-+-node_exporter---19*[{node_exporter}]
| | +-svlogd
| +-runsv-+-gitlab-exporter---6*[{gitlab-exporter}]
| | +-svlogd
| +-runsv-+-redis_exporter---8*[{redis_exporter}]
| | +-svlogd
| +-runsv-+-prometheus---20*[{prometheus}]
| | +-svlogd
| +-runsv-+-alertmanager---16*[{alertmanager}]
| | +-svlogd
| +-runsv-+-postgres_export---7*[{postgres_export}]
| | +-svlogd
| +-runsv-+-grafana-server---14*[{grafana-server}]
| +-svlogd
+-smartd
+-sshd---sshd---sshd---bash---su---bash---pstree
+-systemd---(sd-pam)
+-systemd-journal
+-systemd-logind
+-systemd-timesyn---{systemd-timesyn}
+-systemd-udevd
|
|
ich bin geneigt ein "apt purge" auszuführen.
/e
das forum kann nach wie vor kein utf8.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Traxer am 02.04.2020 0:24]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Ach! Swiss hat mich abgelenkt
Der Aprilscherz von Fefe ist nett! Wollte ich eigentlich schreiben.
| |
Was war denn der Fefe-Aprilscherz?
|
|
|
|
|
|
|
|
|
|
|
|
Kein Rant gegen Systemd? Das verunsichert mich!
|
|
|
|
|
|
|
|
|
|
|
Ist da dieses runsv ein Service-Supervisor, der unter dem systemd-Service-Supervisor läuft, der unter einem Container läuft, der unter einem systemd-Service-Supervisor läuft?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | Zitat von hoschi
Ach! Swiss hat mich abgelenkt
Der Aprilscherz von Fefe ist nett! Wollte ich eigentlich schreiben.
| |
Was war denn der Fefe-Aprilscherz?
| |
Verrate uns doch, wenn du sperren wolltest 
|
|
|
|
|
|
|
|
|
|
|
|
Das steht da in text/plain.
|
|
|
|
|
|
|
|
|
|
|
das schönste daran ist ja eigentlich das hier:
| |
| Code: |
root@phoenix:/opt/gitlab# ls -la
total 3264
drwxr-xr-x 10 root root 212 Apr 1 21:59 .
drwxr-xr-x 3 root root 20 Apr 1 21:52 ..
drwxr-xr-x 2 root root 152 Apr 1 21:52 bin
-rw-r--r-- 1 root root 238262 Mar 31 15:42 dependency_licenses.json
drwxr-xr-x 18 root root 215 Apr 1 21:58 embedded
drwxr-xr-x 11 root root 262 Apr 1 22:00 etc
drwxr-xr-x 2 root root 279 Apr 1 22:00 init
-rw-r--r-- 1 root root 3019479 Mar 31 15:42 LICENSE
drwxr-xr-x 2 root root 24576 Apr 1 21:52 LICENSES
drwxr-xr-x 2 root root 279 Apr 1 22:00 service
drwxr-xr-x 17 root root 279 Apr 1 22:00 sv
drwxr-xr-x 3 root root 21 Apr 1 21:59 var
-rw-r--r-- 1 root root 28755 Mar 31 15:43 version-manifest.json
-rw-r--r-- 1 root root 13216 Mar 31 15:43 version-manifest.txt
root@phoenix:/opt/gitlab# ls -la embedded/
total 36
drwxr-xr-x 18 root root 215 Apr 1 21:58 .
drwxr-xr-x 10 root root 212 Apr 1 21:59 ..
drwxr-xr-x 3 root root 12288 Apr 1 21:58 bin
drwxr-xr-x 2 root root 333 Apr 1 21:52 conf
drwxr-xr-x 20 root root 4096 Apr 1 21:58 cookbooks
drwxr-xr-x 2 root root 201 Apr 1 21:59 etc
drwxr-xr-x 2 root root 40 Apr 1 21:52 html
drwxr-xr-x 13 root root 8192 Apr 1 21:52 lib
drwxr-xr-x 3 root root 138 Apr 1 21:52 libexec
drwxr-xr-x 2 root root 6 Mar 31 15:43 logs
drwx------ 2 root root 43 Apr 1 21:58 nodes
drwxr-xr-x 5 root root 37 Apr 1 21:52 postgresql
drwxr-xr-x 2 root root 4096 Apr 1 21:52 sbin
drwxr-xr-x 3 root root 35 Apr 1 21:52 selinux
drwxr-xr-x 10 root root 165 Apr 1 21:52 service
drwxr-xr-x 13 root root 179 Apr 1 21:52 share
drwxr-xr-x 4 root root 141 Apr 1 21:52 ssl
drwxr-xr-x 3 root root 21 Apr 1 21:52 var
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ich wollte auch noch kurz eben erwähnen, dass das nen knapp 860 MB grosses .deb file ist.
das ganze wirkt für mich ein wenig nach "wir packen einfach mal das, was sonst in nem container läuft in das debian paket".
| |
| Code: |
Package: gitlab-ee
Version: 12.9.2-ee.0
Priority: extra
Section: misc
Maintainer: GitLab, Inc. <support@gitlab.com>
Installed-Size: 2,301 MB
Depends: openssh-server
Conflicts: gitlab-ce, gitlab
Replaces: gitlab-ce, gitlab
Homepage: [URL]https://about.gitlab.com/[/URL]
Download-Size: 859 MB
APT-Manual-Installed: yes
APT-Sources: [URL]https://packages.gitlab.com/gitlab/gitlab-ee/debian[/URL] buster/main amd64 Packages
Description: GitLab Enterprise Edition (including NGINX, Postgres, Redis)
|
|
...
ich würde also vorschläge zu einer vernünftigen alternative annehmen. präferiert ohne oracle zeugs und abhängigkeiten.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Traxer am 02.04.2020 1:47]
|
|
|
|
|
|
|
|
|
|
Gitlab ist ein richtiges Biest. Aber es läuft. Wenn auch nicht mit der kleinsten Hetzner cloud Instanz, wie ich betrübt feststellen musste. 2 cores und 4gb ram ist wohl minimum.
|
|
|
|
|
|
|
|
|
|
|
Bin ebenfalls pro GitLab! Wir haben auch eine instanz on premise. Für die Infrastruktur-Leute nicht ganz einfach. Für die Entwickler aber ein Segen! 
// Wobei eigentlich die Jenkins Infrstruktur mit Uralt Windows Agents viel schlimmer zu maintainen ist
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 02.04.2020 10:03]
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
das ganze wirkt für mich ein wenig nach "wir packen einfach mal das, was sonst in nem container läuft in das debian paket".
| |
Was hast du denn erwartet? So wie gitlab normalerweise deployt wird ist das doch wirklich keine Überraschung.
|
|
|
|
|
|
|
|
|
|
|
|
Würde sagen die Frage ist eher, warum es überhaupt ein Debian-Paket gibt.
|
|
|
|
|
|
|
|
|
|
|
Es gibt schnuckelige Software.
Und dann die Software, die unter Zeitdruck irgendwie zum funktionieren gebracht wurde.
|
|
|
|
|
|
|
|
|
|
|
|
Das ist... naiv. Gitlab ist nicht darauf ausgelegt, "schnuckelig" zu sein, und irgendwo für 2-3 User auf einem Server zu laufen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Und dann die Software, die unter Zeitdruck irgendwie zum funktionieren gebracht wurde.
| |
Also ungefähr... jede?
|
|
|
|
|
|
|
|
|
|
|
|
Wobei das in diesem Fall höchstens fürs Debianpaket gilt. Gitlab ist nicht etwas, was man in ein Deb packt und ein wenig laufen lässt. Das war nie der Sinn und wird es auch nicht werden. Ja, dann ist das wahrscheinlich
nicht so genial, dass man das Paket anbietet. Aber wenn man sowas sucht, dann ist Gitlab wahrscheinlich nicht die richtige Wahl.
|
|
|
|
|
|
|
|
|
|
|
Kommt vermutlich auch auf den UseCase an. Wenn man nur ein bessere WebUI möchte, ist es halt völliger Overkill.
Wenn man einen echten gehosteten Git service will dann ist die realität halt kompliziert. Allein das man via SSH-URLs mit seinem PublicKey ins Repo pushen kann, ist halt auf einem Bestandsystem mit SSH und UserAccounts
nicht so einfach mit dem Konzept von GitLab verheiratbar.
Ich nutze auf meinem Server privat das deutlich schlankere Gogs. Aber auch das bingt nen eigenen SSH-Server im Container mit um genau diese Usecases abdecken zu können.
Und da reden wir jetzt noch nichtmal von der CI bei der sich Runner melden können, Heartbeats verwaltet werden und Runner dann auf deinem System container spawnen sollen um die Arbeit auszuführen...
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Das ist... naiv.
| |
Ich mag aber schnuckelige Dinge!
Viel mehr Dinge sollten schnuckelig sein.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
ich würde also vorschläge zu einer vernünftigen alternative annehmen. präferiert ohne oracle zeugs und abhängigkeiten.
| |
sourcehut, gogs, trac? Fossil?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 02.04.2020 14:40]
|
|
|
|
|
|
|
|
|
|
ich hab ne Kombi aus Gogs (eigentlich nur für HTTP) und Redmine. Allerdings ohne fancy CI, einfach nur Git, Projekte und Tickets.
|
|
|
|
|
|
|
|
|
|
|
zsh
bindkey '^r' history-incremental-pattern-search-backward
Ctrl+R kann jetzt Wildcards.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
