Du bist nicht eingeloggt! Möglicherweise kannst du deswegen nicht alles sehen.
  (Noch kein mods.de-Account? / Passwort vergessen?)
Zur Übersichtsseite
Hallo anonymer User.
Bitte logge dich ein
oder registriere dich!
 Moderiert von: mercury, Schalentier


 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« erste « vorherige 1 ... 137 138 139 140 [141] 142 143 144 145 ... 215 nächste » letzte »
erste ungelesene Seite | letzter Beitrag 
hoschi

hoschi
verschmitzt lachen
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]
01.04.2020 23:06:48  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
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!
01.04.2020 23:16:47  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
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]
01.04.2020 23:48:31  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Ach! Swiss hat mich abgelenkt Breites Grinsen
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]
01.04.2020 23:58:03  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Traxer

Mod GSG9
 
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]
02.04.2020 0:22:50  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
 
Zitat von hoschi

Ach! Swiss hat mich abgelenkt Breites Grinsen
Der Aprilscherz von Fefe ist nett! Wollte ich eigentlich schreiben.



Was war denn der Fefe-Aprilscherz?
02.04.2020 0:30:39  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Kein Rant gegen Systemd? Das verunsichert mich!
02.04.2020 0:30:44  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
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?

02.04.2020 0:36:08  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
Zitat von csde_rats

 
Zitat von hoschi

Ach! Swiss hat mich abgelenkt Breites Grinsen
Der Aprilscherz von Fefe ist nett! Wollte ich eigentlich schreiben.



Was war denn der Fefe-Aprilscherz?





Verrate uns doch, wenn du sperren wolltest peinlich/erstaunt
02.04.2020 0:36:19  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
Das steht da in text/plain.
02.04.2020 0:37:19  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Traxer

Mod GSG9
 
Zitat von csde_rats

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?

https://imgflip.com/s/meme/Yo-Dawg-Heard-You.jpg


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
02.04.2020 1:31:44  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
02.04.2020 1:34:14  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Traxer

Mod GSG9
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]
02.04.2020 1:45:48  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
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.
02.04.2020 9:59:02  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
GH@NDI

ghandi2
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 Breites Grinsen
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 02.04.2020 10:03]
02.04.2020 10:02:37  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
 
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.
02.04.2020 10:13:05  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
B0rG*

Gordon
Würde sagen die Frage ist eher, warum es überhaupt ein Debian-Paket gibt.
02.04.2020 10:30:29  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Es gibt schnuckelige Software.












Und dann die Software, die unter Zeitdruck irgendwie zum funktionieren gebracht wurde.
02.04.2020 11:43:49  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
Das ist... naiv. Gitlab ist nicht darauf ausgelegt, "schnuckelig" zu sein, und irgendwo für 2-3 User auf einem Server zu laufen.
02.04.2020 11:55:59  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
 
Zitat von hoschi

Und dann die Software, die unter Zeitdruck irgendwie zum funktionieren gebracht wurde.


Also ungefähr... jede?
02.04.2020 11:58:36  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
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.
02.04.2020 12:19:52  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
GH@NDI

ghandi2
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...
02.04.2020 12:24:19  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
Zitat von SwissBushIndian

Das ist... naiv.



Ich mag aber schnuckelige Dinge!
Viel mehr Dinge sollten schnuckelig sein.
02.04.2020 14:28:54  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
 
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]
02.04.2020 14:40:06  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
GarlandGreene

Mod GIGN
ich hab ne Kombi aus Gogs (eigentlich nur für HTTP) und Redmine. Allerdings ohne fancy CI, einfach nur Git, Projekte und Tickets.
02.04.2020 14:47:43  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021
zsh

bindkey '^r' history-incremental-pattern-search-backward


Ctrl+R kann jetzt Wildcards.
02.04.2020 19:23:48  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Traxer

Mod GSG9
 
Zitat von SwissBushIndian

 
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.


also laut deren install anleitung gibts halt die möglichkeit "omnibus", kubernetes, docker, "from source", azure, GCP und AWS.

für kubernetes und docker könnte ich das verstehen, allerdings auch nur dann, wenn die nicht verstanden haben wie man das eigentlich nutzen sollte. was in dem fall nach der art wäre, dass man sachen schön klein hält, damit man die einzelnen container sauber managen, bewegen und co kann. was in dem monster container halt gar nicht geht.

im fall von azure, GCP und AWS erklärt diese art der installation lediglich eine sache und zwar, warum es da so unglaublich viele leute gibt, die die kisten nicht abgesichert bekommen. ist halt auch eher nicht zu realisieren, wenn du als admin keine kontrolle über die software auf den instanzen hast.

die "omnibus" version ist halt das mit den distri "spezifischen" paketen. die gibt es halt nicht nur für debian, sondern für alle anderen unterstützen systeme ebenfalls. alles arbeiten nach der gleichen art und weise.

"from source" sagt dir dann halt wie du den kram manuell ohne packages, also ohne deren packages zusammenschusterst. der haken ist halt nur, dass genau dafür eben die packages bei distris gedacht sind und sehr spezifisch dafür, dass du da eben kein package version fuckup baust.

 
Zitat von SwissBushIndian

Gitlab ist nicht etwas, was man in ein Deb packt und ein wenig laufen lässt.


komisch finde ich die aussage nun schon, alleine weil es durchaus sehr viel komplexere software gibt, die genau das auf die reihe bekommt.
die schaffen das pakete für distris zu bauen, die ihre abhängigkeiten auflisten, dafür sorgen das der package manager diese auflöst und du danach als admin die aufgabe hast den kram zum laufen zu bringen.

diese art von installer, den die da in das .deb gequetscht haben umgeht das komplette konzept eines package managers.

wo wäre jetzt das problem die pakete mit deren kram zu erzeugen, also dem backend services, dem web frontend, etc und diese dann als pakete anzubieten?
damit hätte ich dann als admin die möglichkeit z.b. sachen zu verwenden, die vielleicht auf anderen maschinen laufen.
ich hab hier z.b. nen server, der ausschliesslich datenbank server ist. ich hab auch schon installationen (generell) gehabt, wo ich mehrere "nur" redis maschinen gehabt habe. oder so sachen, wo der mail server nicht auf der gleichen gurke laufen muss... hab mir sagen lassen, dass das halt auch normal ist, das sowas nicht in nem internen netz läuft, so aus sicherheit und so.


 
Zitat von SwissBushIndian

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.


ok, dass würde dann also bedeuten, dass ich gitlab nicht für sachen aus der professionellen welt verwenden kann und es auch nicht dafür gedacht ist, weil dort würde ich ja z.b. so sachen wie eigene redis rechner, eigene datenbank systeme, separate statistik (grafana, prometheus) server und co haben.

ernsthaft, dass teil bringt sein eigenes logrotate mit, genau so wie drei verschiedene versionen von postgresql, eine eigene bash(!) version, diverse standard GNU tools, die auf jedem unterstützen system vorhanden sind, nen volles image magick, ne libgd und noch vieles andere, was ich als admin komplett nicht mehr warten kann, aber potentiell von aussen erreichbar ist.

das ist aktuell so die variante von "wir haben keine ahnung wie man linux nutzt, aber wir machen das jetzt so wie unter windows".

selbst microsoft macht da mit dem dotnet core zeugs nen besseren job.


 
Zitat von B0rG*

Würde sagen die Frage ist eher, warum es überhaupt ein Debian-Paket gibt.


das ist eine sehr gute frage.


das was mich bei der sache auf die palme bringt ist, dass die software vermutlich sogar gut wäre, aber ich kann und will es nicht verantworten sowas aufzusetzten, wenn ich über das teil genau nichts an kontrolle habe.

mal ganz abgesehen davon, dass ich nichtmal irgendwo bei der ganzen sache gefragt wurde, wohin sich das teil installieren soll.
es liegt jetzt unter /opt, was es halt verzeichnis vorher gar nicht gab. laut LSB wäre das halt auch das falsche verzeichnis. zumindest für die daten aus dem system.

ich muss die software so oder so wieder deinstallieren, weil anscheinend kann man die nicht einfach verschieben. das ganze hat sich damit auf nen 32 gig DOM modul installiert. was für die eigentliche software vermutlich nicht so problematisch wäre, wenn die nicht zu viel schreibt, aber ich kann halt die nutzdaten nicht auf das raid auslagern, weil dann crasht das ganze.

nebenbei, wenn ich hab das gerade mal grob nachgeschaut, wenn man den ganzen doppelt und dreifachen kram, den der omnibus da mitbringt entfernen würde und einfach das zeugs nutzen würde, was so oder so auf dem system vorhanden ist, dann wäre das ganze paket nach installation 1.5 GB (!) kleiner, vor installation ca. 600 MB kleiner.
02.04.2020 23:23:56  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
Ja ne:

 
Zitat von SwissBushIndian

Ja, dann ist das wahrscheinlich nicht so genial, dass man das Paket anbietet.



Und ja, wir haben dafür eigene Builds gebaut.

¤: Ich meine, ich will ja nichtmal Gitlab verteidigen, ich finds technisch auch nichts besonderes. Aber du wählst Omnibus, wo explizit in der Doku das hier steht:

Omnibus GitLab is a way to package different services and tools required to run GitLab, so that most users can install it without laborious configuration.

Und bist dann überrascht, dass es eben genau das macht. Ich finde ja Rants gut, aber der hier ist gesucht.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 03.04.2020 8:50]
03.04.2020 8:45:53  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
audax

AUP audax 03.12.2007
Mein Rechner steht in einem (schönen) Kellerraum. Ich möchte remote auf den Rechner, damit ich auch mal mit dem Laptop im Wohnzimmer oder auf dem Balkon sitzen zum Arbeiten, damit ich etwas mehr Licht habe. Mein Laptop ist ein MacBook Pro, der Rechner läuft auf Linux.

Was benutzt man 2020 dafür? Hauptsächlich läuft 2-5 mal IntelliJ Idea, ein paar Terminals und Slack und ich möchte gerne relativ einfach zwischen Desktop und Laptop wechseln können. Bei den ganzen Remote-Desktop Lösungen blicke ich nicht mehr durch. VNC und SSH-X-Forwarding scheinen mir aber keine Lösungen für dieses Jahrzehnt zu sein Breites Grinsen
03.04.2020 9:40:16  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
mYstral

Arctic
...
 
Zitat von csde_rats

zsh

bindkey '^r' history-incremental-pattern-search-backward


Ctrl+R kann jetzt Wildcards.


This. Changes. Everything.

Mal ehrlich, wie findet man sowas heraus? Scheint ja nirgendwo konkret dokumentiert zu sein?
03.04.2020 10:20:15  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« erste « vorherige 1 ... 137 138 139 140 [141] 142 143 144 145 ... 215 nächste » letzte »

mods.de - Forum » Linux » 

Hop to:  

Thread-Tags:
gnu  linux 
| tech | impressum