Hallo Michael!
Vielen Dank für Deinen im ersten Augenblick toll anmutenden Vorstoß, aber auf den zweiten ist der Blick getrübt.
Am 07.03.2013 11:53, schrieb Michael Clemens:
- IRC clients (e.g. irssi)
- jabber clients (e.g. mcabber)
- mail clients (e.g. mutt, pine)
- git
Dafür brauchen wir keine Shell auf einem anderen Server, oder?
- compilers (gcc etc.)
Bye, bye, low load. :) Da legt schon ein Iceweasel-Kompilat mal gerne zwei CPUs für geraume Zeit waagerecht. Dazu kommen noch "Ich will mal gerne cross-compilen für Amiga - mach' mal 'ne Toolchain hin" etc. :)
- screen/tmux
Screen wurde in der Diskussion schon als sinnvoll erwähnt - allerdings weiß ich nicht, ob das alleinig ausreicht.
- OpenVPN service, so fellows can encrypt their connection when they
are on the road
Nicht wirklich - die FSFE, wie von Martin angemerkt, ist dann im ersten Moment verantwortlich für das, was auf der Leitung passiert. Hm, suboptimal.
Ok, mit einer entsprechenden Nutzervereinbarung wäre die FSFE aus dem Schneider, aber was brächte das außer nix als Ärger, den wir personell niemals stemmen könnten? Ich erinnere an die von mir seinerzeit losgetretene Diskussion über einen eigenen Key-Server... That's the way things go.
- web site hosting
- databases (MySQL, postgresql etc.)
Nö. Das macht so dermaßen viel Aufwand, dass ich es nicht auf einem so öffentlich zugänglichen Server betreiben wollte: Apache/PHP/Perl/Python/mod_*/MySQL/PostGreSQL aktualisieren, Lücken durch dämliche Skripte/Websites erkennen, Spam-Versand/CSS/ElseAbuse stoppen, etc. - das ist eine Lebensaufgabe. Oder anders gesagt: Dann lieber mit 100 Servern und Geld damit verdienen :)
- SSH tunneling
Siehe OpenVPN.
- File storage
Wozu genau? Wer bezahlt's? Was liegt da? Im ersten Augenblick: Nö.
- Besides me, I would need two other fellows with skills in Linux/Unix
administration (and maybe in IT security) who will take care of the system
Würd' ich können, aber nicht so machen. :)
Mit fröhlichem Gruß
Robert Kehl