|
|
|
|
|
|
|
Ich hab mein Backup umgestellt von Amazon S3 zu Google Cloud Storage. S3 hat mir ganze 800kb/s Upload nach Irland gegegen, Google gibt mir 9mb/s und ist günstiger.
¤dit:
https://munin.daxbau.net/munin/net/daxbau.net/if_eth0.html
Man sieht ganz gut, wann ich auf Google umgestellt habe 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von audax am 25.04.2014 13:14]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
~> Ciphertext soll normalerweise wie Zufällig aussehen. Was aber zufällig ist, lässt sich schwer komprimieren. Lässt sich eine verschlüsselte Platte gut komprimieren, folgt der Umkehrschluss, dass der Ciphertext nicht zufällig ist und daher die Verschlüsselung schwach ist.
| |
du verkennst eine tatsache: zufall sieht nicht wie rauschen aus. ein zufallsgenerator, der in einer langen kette von nullen und einsen mal 500 nullen hintereinander ausspuckt, generiert immernoch zufall. natürlich wünscht man sich eine gleichmäßige verteilung der häufigkeiten und verteilungen, aber letztlich ist es zufall, weil man vorher nicht weiß, was genau rauskommt. also ja, in statistischer betrachtung kann man zufall nicht komprimieren, weil es zu nah am rauschen ist, aber das ist keine generell stabile aussage über verschlüsselung und qualität.
|
|
|
|
|
|
|
|
|
|
|
|
Es ist eine praktische Aussage über Verschlüsslung und Qualität selbiger.
|
|
|
|
|
|
|
|
|
|
|
Ich präsentiere: Tasklet
Super-einfache TODO-Liste ohne Overhead. Einfach nur eine Liste
von Dingen, die man eben zu erledigen hat. Keine
Authentifizierung oder Datenbank oder so, ist dafür gedacht lokal
zu laufen.
"Metadaten" wie Farbe, Noch-zu-erledigen/erledigt werden mit kleinen
Markern direkt eingebetet. "übungsblatt blabla erldigen :blue"
markiert dieses Tasklet (ich mein, jedes Projekt brauch irgendeinen
Hippen Namen oder nicht?! Name ist btw. geklaut von der gleichnamigen
Kernelstruktur) eben blau. "rasenmäher ölwechsel :done" (oder :fixed,
:resolved etc.) ist dann eben erledigt und wird unter der Liste
angezeigt.
Die Dinger werden einfach in einer Textdatei gespeichert ; eine Zeile
ist ein Tasklet. Wird entsprechend escaped, kann man aber auch von
Hand editieren.
Werd das Wochenende bestimmt noch ein bisschen was einbauen (Sachen löschen und per Drag'N'Drop (oder Pfeiltasten oder so) umsortieren wär wohl ganz praktisch), aber im
Grunde kann / soll es nicht viel mehr werden.
Braucht Python und Flask, sonst nix.
Hat kein AJAX. Hatte ich keine Lust drauf. Habs anders gepfuscht
/E: Waaaa dieser URL-Tagbug macht mich wahnsinnig
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von csde_rats am 25.04.2014 17:39]
|
|
|
|
|
|
|
|
|
$ vim ~/todo
|
|
|
|
|
|
|
|
|
|
|
echo 'test -e ~/TODO && cat ~/TODO' >> ~/.zshrc
|
|
|
|
|
|
|
|
|
|
|
Das ist genau das, nur in bunt 
|
|
|
|
|
|
|
|
|
|
|
Is mir bewusst. Aber wirklich tiefenklar ist mir nicht, warum Zufälligkeit ein Maß für gute Verschlüsselung sein soll.
// booah potdroid. Denkt euch den post mal 8 Stunden früher
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rufus am 25.04.2014 20:01]
|
|
|
|
|
|
|
|
|
Das das übliche Ziel ist, dass Ciphertext und Rauschen ca. gleich aussehen, hat verschiedene Gründe.
In keiner bestimmten Reihenfolge Dinge wie: Plausible Deniability (vgl TrueCrypt u.ä.), Ciphertext indistinguishability, Data hiding/Steganographie, Malleability (chosen-ciphertext angriffe) und natürlich die diversen Formen von Leakage (z.B. Wenn dein Ciphertext Strukturen aufweist, die plaintextabhängig sind, und die Rückrechnung von der Ciphertext-Struktur zum Plaintext einfacher als das Brechen der Verschlüsselung selbst ist -> versagt. Da ist ECB halt das Lehrbuchbeispiel für).
Ein Vorteil von einem Algo/Cryptosystem, wo dein Ciphertext nicht unterscheidbar ist von Rauschen, dass du dir keine Sorgen mehr machen musst, dass ein Angreifer Ciphertexte untereinander unterscheiden kann. Das steht auch oben in der Liste, ich wollts nur betont haben. Das macht den Umgang damit gemütlciher... gewissermaßen.
/e: Am Ende von dem verlinkten Wikipedia-Artikel findest du einige weiterführende Stichwörter sehe ich gerade.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 25.04.2014 21:27]
|
|
|
|
|
|
|
|
|
Mal wieder Web-VNC-Hass
| | | The clipboard is now shared across connections. While integration with the client-side clipboard is still impossible, copy/paste between connections is seamless. | |
Ich versteh' echt nicht, warum das bitte so schwer sein soll. Ich kann normalerweise in jedes stinkige Formularfeld Copy und Paste machen, aber in ne funkige HTML5-Webconsole nicht?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die haben erstmal ServerTokens gesetzt, nachdem es wohl Dresche wegen der veralteten Versionen gab.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Ich präsentiere: Tasklet
Super-einfache TODO-Liste ohne Overhead. Einfach nur eine Liste
von Dingen, die man eben zu erledigen hat. Keine
Authentifizierung oder Datenbank oder so, ist dafür gedacht lokal
zu laufen.
"Metadaten" wie Farbe, Noch-zu-erledigen/erledigt werden mit kleinen
Markern direkt eingebetet. "übungsblatt blabla erldigen :blue"
markiert dieses Tasklet (ich mein, jedes Projekt brauch irgendeinen
Hippen Namen oder nicht?! Name ist btw. geklaut von der gleichnamigen
Kernelstruktur) eben blau. "rasenmäher ölwechsel :done" (oder :fixed,
:resolved etc.) ist dann eben erledigt und wird unter der Liste
angezeigt.
Die Dinger werden einfach in einer Textdatei gespeichert ; eine Zeile
ist ein Tasklet. Wird entsprechend escaped, kann man aber auch von
Hand editieren.
Werd das Wochenende bestimmt noch ein bisschen was einbauen (Sachen löschen und per Drag'N'Drop (oder Pfeiltasten oder so) umsortieren wär wohl ganz praktisch), aber im
Grunde kann / soll es nicht viel mehr werden.
Braucht Python und Flask, sonst nix.
Hat kein AJAX. Hatte ich keine Lust drauf. Habs anders gepfuscht
http://i.imgur.com/eVvdHDg.png
/E: Waaaa dieser URL-Tagbug macht mich wahnsinnig
| |
Die meisten Leute lieben einfache ToDo-Listen, weil ToDo-Listen einfach sein sollten! Aber irgendwie leiden dann alle Anwendungen mit jedem neuen Feature an immer mehr Bloat, liegt wohl in der Natur der Sache . Du kannst das natuerlich so umsetzen wie du moechtest! Hier mal eine Anregung:
Es gibt quasi einen Standard Todo.txt-Format fuer das speichern von ToDo-Listen in Textdateien. Ich empfinde den Syntax der Notation nicht so angenehm und praegnant kurz wie ich das gerne haette, dennoch macht das einen halbwegs ausgereiften Eindruck. Wenn du darauf aufbauen willst ist diese Extension fuer die GNOME-Shell ein gutes Beispiel. Dabei werden eben keine Farben abgespeichert, sondern Prioritaeten wie im Todo.txt-Format vorgeschlagen und anhand dieser Prioritaeten werden die vom Nutzer veraenderbaren Farben verwendet (etwa Rot (A), Orange (B), Gruen (C), usw.). Die Sache mit dem Mapping der Prioritaeten auf Farben finde ich nicht schlecht, ganz unabhaengig vom Format in dem das gespeichert wird. Wenn die Farben dagegen eine losgeloeste Markierung sein sollen, etwa "Privat, Beruf, Schule, Familie" oder "Leicht, Mittel, Schwer, Sehr Schwer" kann man ja diese Werte hernehmen, oder doch wieder die Farben als Attribut mitspeichern.
Alternativen:
So Zeug macht einfach Spass. Aktive Verschleppung!
Transparenz? Durchsichtigkeit? Alphakanal? GNOME-Terminal? VTE!?
https://git.gnome.org/browse/vte/commit/?id=1ec6c43d1aa89620e040f5a8eebe25b6772a35e6
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 27.04.2014 17:57]
|
|
|
|
|
|
|
|
|
Displayport mit der verschissenen Ati-Karte funktioniert einfach nicht. Es geht nicht.
Selbst wenn es kurz läuft, nach wenigen Minuten schmiert wieder alles ab und der Moniter läuft auf 800x600. Ich hasse diese verdammte Ati-Scheiße.
Der catalyst Treiber von amd segfaultet übrigens. Bei Fedora und bei Arch, mit verschiedensten Xorg Versionen. Ich hasse diesen Mist.
Ich glaube, ich bestelle mir demnächst mal ne Nvidia. 
|
|
|
|
|
|
|
|
|
|
|
|
Ich habs schonmal gesagt und sage es wieder: Schade, dass Intel keine Low-End Grafikkarten macht.
|
|
|
|
|
|
|
|
|
|
|
|
Meine erste und letzte ATI war eine 4850. Das hat mir an fglrx gereicht.
|
|
|
|
|
|
|
|
|
|
|
Linux Sucks 2014
Verdammt, Arch Linux ist schon 10 Jahre alt? Ich werd alt.
Hat von euch noch jemand nen Arch von damals am Laufen das er bis heute up to date gehalten hat?
|
|
|
|
|
|
|
|
|
|
|
|
Gnome3 ist toll, jedenfalls mit einigen Extensions. Ich hätte nicht gedacht, dass ich mich doch so schnell damit anfreunden kann.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von audax
Linux Sucks 2014
Verdammt, Arch Linux ist schon 10 Jahre alt? Ich werd alt.
Hat von euch noch jemand nen Arch von damals am Laufen das er bis heute up to date gehalten hat?
| |
Großartiger Talk!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von audax
Gnome3 ist toll, jedenfalls mit einigen Extensions. Ich hätte nicht gedacht, dass ich mich doch so schnell damit anfreunden kann.
| |
Getrollt oder ernst gemeint? Ja. Beides ist moeglich.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Priapos
| | Zitat von audax
Linux Sucks 2014
Verdammt, Arch Linux ist schon 10 Jahre alt? Ich werd alt.
Hat von euch noch jemand nen Arch von damals am Laufen das er bis heute up to date gehalten hat?
| |
Großartiger Talk!
| |
Ahhhh. Irgendwoher kannt ich das doch mit "Linux Sucks!". Gleichmal anschauen!
// edit
# OpenSSL -> LibreSSL = so true
# WebKit -> Blink = so trueeee
# Cinnamon -> GNOME = Hmmm. Haengt davon ab. Aber erstmal true
Schon hat er mich.
// edit
Codenamen! Beefy Miracle war wirklich super (und das Startlogo). Und die Namen von Ubuntu sind wirklich 
// edit
Shut up Fedora!
// edit
Beefy Miracle nochmal
Fall das wer nicht versteht, ja, da kann und konnte man wirklich als Bootlogo verwenden - http://wwoods.fedorapeople.org/hot-dog/
|
|
[Dieser Beitrag wurde 5 mal editiert; zum letzten Mal von hoschi am 29.04.2014 18:46]
|
|
|
|
|
|
|
|
|
| | Zitat von theromi
Arch hab ich nur auf Servern und nie als Desktop benutzt, deshalb ist meine Meinung (auch aus vielen anderen Gründen) unqualifiziert, aber ich finde pacman ist einfach auch die Hölle, was das Interface angeht. -xxhqfml statt Kommandos wie install, remove, purge, update und so weiter haben mir nie geholfen, das System zu verinnerlichen.
Ich lasse mich da gerne eines besseren belehren. Viele unixoide Tools bedienen sich ja so, aber das kann ja kein Argument sein.
http://matt.harzewski.com/images/posts/xkcd-tar-700x224.png
| |
# tar -xzvf file.tar.gz
# und ja, ich Fall mit tar immer noch oft genug hin
Jemand hat hier doch angemerkt, wie kompliziert die Operations-Optionen von Pacman unter Archlinux waeren und die Verdopplung von Optionen wuerden sowieso verwirren. Also erklaere ich das mal, ohne rechtfertigen oder kritisieren zu wollen. Hinweis:
| |
Optionen sind die Dinger mit Bindestrich hinter einem Programmnamen, eine Option kann Parameter wie etwa eine Datei haben. Soweit klar! Pacman bezeichnet jedoch grundlegende Optionen als Operationen und Apt wiederum als Kommandos, erst alles nachfolgende wird in den Manpages als Option bezeichnet. Ich versuche mich an diese Benennung zu halten.
| |
Es ist nicht kompliziert. Pacman verwundert den neuen Anwender dadurch, dass es kein -Install gibt, aber -Qery , -Remove und -Update! Dahinter steckt der Intention, das -Sync sich auf alle Operationen gebenueber den Repositories bezieht. Deswegen wird Sync beim aktualisieren der Repositories, Pakete, Suche und der Installation neuer Pakete verwendet. Die Operation Query fragt dagegen immer gegen die lokalen Paketdaten an. Die Operation Remove ist sowieso klar. Einzig die Operation Update verwirrt, weil es in der Praxis nur zur manuellen Installation und Updaten von lokal vorliegenden Paketen verwendet wird. Wenn man die Manpage anschaut sieht man, das -Update vielleicht mal eine etwas andere Bestimmung vorgesehen war.
Die Verdopplung von Optionen fand ich frueher bei vielen GNU-Programmen, etwa bei lspci, befremdlich. Dabei ist dass der erste Vorteil, es ist eine bestehende Konvention von GNU. Der zweite Vorteil ist, dass man keine weitere Option fuer mehr von dieser Option braucht. Ein gutes Beispiel ist pacman -Qii, anstatt pacman -Qil. Die Option -l waere in letzterm Fall long (vgl. ps -elf), wird aber nachvollziehbar fuer list verwendet.
Wenn man kurz in die Operationen und Optionen von Pacman eintaucht ergibt sich das Konzept dahinter und die Bedienung geht schnell in Fleisch und Blut ueber. Die Funktionalitaet von pacdiff koennte noch durch Pacman angeboten werden, das waere eine Verbesserung. Das Shellskript hinter pacdiff sucht nur nach "*.pacnew" anhand der Datenbank von Pacman oder so.
Im Vergleich dazu gibt es bei Debian mit Apt gleich mehrere sich ergaenzende, ueberschneidende und ersetzende Programme - dpkg, dpkg-reconfigure, apt-get, apt-cache, aptitude - fuer den Endanwender. Also ohne fremde Repostories, manuell gebaute Pakete oder UI-Frontends. Debian bzw. Apt dient als Vergleich, weil es weit verbreitet und zuverlaessig ist.
Naheliegend greifen wir uns mal apt-get als das Standardprogramm heraus, mit den Kommandos update, upgrade, dist-upgrade. Das update gar nicht Update meint, sondern nur einen Sync mit den Repositories ist schon mal sehr verwirrend. Das was man hinter update erwarten wuerde macht dagegen upgrade, und die Erwartungen hinter upgrade wird erst durch dist-upgrade ganz erfuellt. Wie anderen die Verdopplung von Optionen widerstrebt, gefaellt mir nicht die Mischung aus unterschiedlichen Programmen mit Bindestrichen, die trotzdem noch Kommandos wie update erhalten muessen. Trotzdem kann ich damit umgehen, weil es mir ebenso ins Blut uebergegangen ist. Und jetzt kommt erst noch apt-cache dazu und dpkg und aptitude (das sich anders verhaelt als apt-get). Debian hat gerade das grosse Glueck erfahren endlich mit apt ganz viel Programme zusammenfassen zu koennen (Notiz: R.I.P. Java 6!). Dadurch dass es jetzt full-upgrade bei apt heisst, statt dist-upgrade wie bei apt-get schenke ich den Leuten von Debian gerne.
pacman -Syu ~ apt-get update && apt-get dist-upgrade
pacman -Rns package ~ apt-get --purge remove package
pacman -Q ~ dpkg -l
pacman -Qii ~ [Kennt wer einen Ersatz dafuer, also ob und welche Konfigdateien geaendert wurden?]
| | | Viele unixoide Tools bedienen sich ja so, aber das kann ja kein Argument sein. | |
Ich kann mit APT und Pacman umgehen. Mit dem kurzen und klaren Syntax (KISS!) von Pacman fuehle ich mich wohler, gerade weil sich Pacman am ueblichen GNU-Syntax orientiert.
Ausflug:
Ich habe mich letzthin richtig gefreut, dass Debian nach diversen Updates automatisch die passenden Dienste neustarten will. Etwa nach einem Update von OpenSSL eben Apache. Will? Ja "Will". Ist halt doof, wenn er dabei haengen bleibt zwischen Exim, Cups, Apache und noch etwas anderem auf einer Desktopinstallation. Ich habe dann mit SIGINT (Ctrl+C) die Notbremse gezogen, Apt hat danach gemeckert wegen korrumpierter Paketverwaltung, aber hat mich auch mit einem Hinweis in der Ausgabe zum notwendigen Reparaturkommando hingefuehrt.
Pacman kann das wiederum nicht, im doppelten Sinn. Pacman kann das als Feature nicht! Weil das nicht die Aufgabe einer reinen Paketverwaltung ist und weil Pacman ohne selbige Funktionalitaet bei dem Schritt (Neustarten der Daemonen) gar nicht hinfallen kann. Wie jede Software hat Pacman seine Bugs (hoffentlich nicht viele), aber Pacman fuehlt sich klar und verlaesslich an.
Irgendwer wollte noch wissen, wie das Pacman mit dem Pacnew-Files macht?
Ich hatte damals auch irgendwelches Voodoo befuerchtet, es ist logisch und nicht kompliziert. Wenn Anforderungen immer nur so klar definiert waeren
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von hoschi am 29.04.2014 18:08]
|
|
|
|
|
|
|
|
|
| | Zitat von audax
Hat von euch noch jemand nen Arch von damals am Laufen das er bis heute up to date gehalten hat? | |
nä, vor 10 jahren war ich 15 und auf dem gymmi, wo das „technikteam“ die einzigen 3 „nerds“ weit und breit waren, mich allerdings weder mochten, noch ahnung von irgendwas hatten.
dann hat wohl LaTeX für die facharbeit den frickel-samen gelegt.
dann ziemlich gleichzeitig unibeginn, freundin kennenlernen und linux (kubuntu)
dann seit anfang 2012/ende 2011 arch. (holy shit, das ist ja gar nicht lang her!)
|
|
|
|
|
|
|
|
|
|
|
Und so fühlt man sich also alt
Ich hätte irgendwo noch ein Gentoo von 2002/3 rum, das dürfte inzwischen aber eher challenging zu retten sein <:
|
|
|
|
|
|
|
|
|
|
|
Meine ältesten Installationen sind 02/2007 Arch und 01/2008 gentoo. Arch habe ich leider mal mit einer SSD 2012 neu installiert statt es zu kopieren 
Und momentan sieht es so aus als würde ich den Fehler begehen und Zeit in exherbo investieren. Es ist nicht unbedingt effizient, aber schön. Im Einsatz seit Ende 2012, auf dem Laptop.
|
|
|
|
|
|
|
|
|
|
|
Ich hab 2005 mit Gentoo angefangen, dann jahrelang immer zwischen Debian und Ubuntu hinundhergwechselt und zwischendurch auch mal Arch probiert, aber hat mir damals nicht gefallen weil ich einfach zu Debian-gewöhnt war.
Mittlerweile hab ich Arch mal wieder ne Chance gegeben und ich muss sagen, es gefällt mir immer besser.
/e: Achja, Fedora hab ich mir auch mal ganz kurz gegeben aber ich fand RPM schon immer grausig. Schon wenn ich nicht-privat an irgendwelchen RHEL oder Suse-Maschinen rummachen musste. :x
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Und so fühlt man sich also alt
Ich hätte irgendwo noch ein Gentoo von 2002/3 rum, das dürfte inzwischen aber eher challenging zu retten sein <:
| |
Hhmmm, ich habe mit einer SuSE Box angefangen. Version 5 oder 6 war meine erste, glaube ich. Das war so 1995/96/97(?).
/edit 5 war 1997, 6 1998 - dann habe ich eher 97/98 angefangen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von YT am 29.04.2014 20:03]
|
|
|
|
|
|
|
|
|
|
Also angefangen hab ich 99 mit SuSe, dann bald mal über Red Hat zu Debian gekommen.
|
|
|
|
|
|
|
|
|
|
|
Ich merke gerade wie ungemein praktisch dmenu mit einem vernünftigen Skript ist um häufig benötigte Befehle (samt Arguments) auszuführen.
Spoiler - markieren, um zu lesen:
Seit dem nvidia/systemd bug z.B. systemctl suspend
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
# tar -xzvf file.tar.gz
# und ja, ich Fall mit tar immer noch oft genug hin
| |
Im Gegensatz zu pacman kann man bei tar die ganze Alltags-Parameterreihe sprechen: "Xtract (Zipped) File", "Compress(&Zip) File". Und da ist auch kostenlos das Wissen dabei, dass und wieso das "f" ans Ende muss. "v" und "j" muss man sich halt so merken. Zwei Byte ins Hirn ist vertretbar, allein deswegen entsteht hoffentlich kein epischer running gag über ach so schlimme Syntax. Und bei pacman hört das Mitsprechen in der Regel nach dem Großbuchstaben auf.
| | Zitat von hoschi
Das update gar nicht Update meint, sondern nur einen Sync mit den Repositories ist schon mal sehr verwirrend. | |
Im Gegenteil. Verwirrend ist es, dabei überhaupt von syncen zu sprechen. Ein sync impliziert immer, dass es auch in die andere Richtung gehen könnte. "update" ist nicht schlechter als "sync" sondern genauso ungünstig.
| | Zitat von hoschi
Das was man hinter update erwarten wuerde macht dagegen upgrade
| |
Das eigentliche Problem ist, dass eben die entscheidenden, bedeutungsklarstellenden Worte wie "mirror" oder "package" weggelassen werden. Andererseits finde ich "update ist dies, upgrade ist das" nicht schwerer zu merken als die pacman-Codes jenseits der Großbuchstaben.
Also Vorschlag zur Güte. Sprechbar und eindeutig:
| |
| Code: |
$ geilomanager
-ULM --updateLocalMirrors
-UIP --upgradeInstalledPackages
-USV --upgradeSystemVersion
|
|
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Rufus am 29.04.2014 21:12]
|
|
|
|
|
|
| Thema: 100 gute Gründe für Linux ( v0.30 gute Gründe für systemd ) |
