Dresden hat soeben auch Ausgangsbeschränkungen verhängt. Mal sehen, wann der Wind es weiter treibt
Beiträge von timkoop
-
-
Kann mir mal bitte jemand das Passwort für meine private CA verraten?
-
Jaja. Schöngerede, sonst nichts.
Wenn man ohne triftigen Grund von der Polizei draußen erwischt wird, muss man mit angeblich empfindlichen Geldstrafen rechnen.
Eben. Das Zulassen eines triftigen Grundes spricht für eine Beschränkung und gegen eine Sperre.
-
-
bei netcup werden die Mails nur nicht verschlüsselt archiviert. Posteo bietet dies ja an.
Was genau bringt dir die verschlüsselte Archivierung, wenn die Mails ungeschützt im Posteingang oder Unterordnern liegen?
-
Versendet Amazon.co.uk auch über Amazon.de? Habe heute Vormittag auf ersterem Portal bestellt und gerade die Versandmitteilung mit einer normalen/nationalen Amazon-DHL-Sendungsnummer erhalten...
-
Wer seine eigene Instanz aufbauen möchte, kann das Jitsi-Image auf einem netcup Root-Server oder VPS über das SCP ausspielen. Für kleinere Teams bis zu 15 Mitgliedern reichen bereits kleinere Instanzen wie die Produkte VPS 1000 oder RS 1000. Für Teams mit bis zu 30 Mitgliedern empfehlen wir jeweils den VPS 2000 oder RS 2000, alles darüber sollte auf den RS 4000 bzw. RS 8000 setzen.
-
Leider (derzeit) nicht, läuft auf einem RS 2000 und der hat bekanntlich genug Ressourcen... Habe dann mit ein paar anderen Kommilitonen ein "Meeting" und kann Mal schauen, wie es sich im Vergleich zum Idle verhält
geekmonkey Also. Ist jetzt nur eine "Momentaufnahme". Der Docker-Stack besteht aus 4 Containern (Jitsi Video Bridge, Web, Jicofo und Prosody). Im Idle ziehen alle zusammen 400-500 MB RAM.
Mit 3 Teilnehmern, [wobei einer den Bildschirm mit Full HD geteilt hat,] ist die Video Bridge von 217 MB auf 385 MB gestiegen und Jicofo 172 MB -> 250 MB. Web und Prosody kann man nahezu vernachlässigen. In Summe also knapp 700 MB bei drei Teilnehmern. Ich denke, das lässt sich recht linear hochrechnen; wobei es bei mir keinen Unterschied gemacht hat, ob ich Video streame oder nicht.
-
Kannst du mir was zum Ressourcen Verbrauch sagen?
Leider (derzeit) nicht, läuft auf einem RS 2000 und der hat bekanntlich genug Ressourcen... Habe dann mit ein paar anderen Kommilitonen ein "Meeting" und kann Mal schauen, wie es sich im Vergleich zum Idle verhält
-
Schau dir mal Jitsi an!
-
Preisfrage (höhö): Festplatten lieber jetzt (online) kaufen oder wenn sich die ganze Situation irgendwann beruhigt hat?
-
Was nutzt ihr als Software?
-
Heute die erste Online-Vorlesung. Die haben anscheinend Stresstest mit 5 Teilnehmern gemacht, mehr konnten nämlich nicht joinen... Nach 20 Minuten haben die es endlich mal in den Griff bekommen und der Prof fliegt nur aller 10 Minuten raus und kann uns nicht hören
-
Eine bezahlbare und brauchbare Webcam auf Amazon zu finden ist derzeit gar nicht so leicht Zumindest, wenn man sie in absehbarer Zeit haben möchte
-
Das Originalpaket enthält "trailing zero bytes", um die Gesamtgröße auf 4MB zu bringen.
Tatsache. Auffüllen mittels dd if=/dev/zero bs=1 count=NUMBER >> rootfs.cpio.gz um auf die gleiche Größe zu kommen. Anschließend damit booten und sich freuen. Du Held
-
Ein tail -n 3 hätte auch gereicht... Ursache/Lösung
-
Ich wurde gerade darauf hingewiesen, dass mein Massenspeicher fast voll ist... Habe dann mal geschaut, was so viel braucht
Und ja, logrotate ist aktiviert Ich überlege derzeit noch, wie ich herausfinde, was dort drinnen so viel spammt
-
Das kann mehrere Ursachen haben (vgl. https://unix.stackexchange.com/q/414655/238272). Wenn man jetzt noch wüsste, welche Distribution das ist (über die letzten drei Seiten dieses Themas nicht eruierbar) und mit welchen Befehlen/warum genau das initramfs neu gebaut werden soll…
PS: Wenn gzip wirklich "hängt" (eher unnormal), würde ich das einmal auf einer anderen/stärkeren Maschine ausführen. Alternativ, wenn genügend Platz da ist, wird man aber auch nicht gezwungen, das initramfs zu komprimieren.
Das ganze ist ein NAS, standardmäßig mit modifiziertem Android. SOC ist der RTD1295 mit 1GB RAM. Drauf soll ein Debian, dafür auch das initramfs/rootfs. Hier sind das funktionierende Archiv (aus einschlägigen russischen Foren) und meins, welches den Fehler wirft. Verändert habe ich nichts, also nur entpackt und wieder gepackt:
Codegunzip rootfs.cpio.gz mkdir out cd out cpio -id < ../rootfs.cpio find . | cpio -o -H newc > ../rootfs.cpio gzip rootfs.cpio
Das Ergebnis ist ein Kernel-Panic mit zuvor genanntem Fehler. Bootloader, bootargs, ... sollten nicht das Problem sein, da das System ja mit dem "fertigen" initramfs (mit 0% Komprimierung) bootet.
-
Nein.
https://www.kernel.org/doc/Documentation/xz.txt
https://wiki.gentoo.org/wiki/Genkernel
kernel, initramfs und die Module dürfen schon seit Jahren mit xz und ähnlichem komprimiert sein.
Dachte ich auch, aber der Kernel (4.1.17) bootet nur mit cpio in gz. Anderweitig wirft er not syncing: VFS: Unable to mount root fs on unknown-block(0,0) und ist tot.
-
timkoop und was ist mit zip ...? das kennt -0 als 'store only'
Der Kernel/Bootloader/whatever akzeptiert sein initramfs nur als cpio in einem gzip-Archiv... Alle funktionierenden (aus dem Internet) haben 0% Kompressionsrate. Wenn ich eins erstelle (bzw. ein funktionierendes bearbeite), dann bekommt der Kernel eine Panikattacke. Der einzige Unterschied zwischen meinem und dem fertigen ist die Kompressionsrate; sonst ist alles identisch...