[–] 1 point 1 hour ago

aber ob die Deutschen soviel besser sind?

Korrupte, rechte Scheiße in Schwarz, korrupte, rechte Scheiße in Blau und sogar noch Reste von korrupter, rechter Scheiße in Gelb: zusammen mit deutlicher Mehrheit, nach Sitzen im Bereich ⅔.

Also Nein. Die Deutschen sind sogar noch dümmer und dazu noch geschichtsvergessen. Nur halt auch etwas langsamer...

  • source
  • parent
  • context
  • [–] 1 point 1 hour ago

    Dann ist dein Umfeld aber die Minderheit mit Eigenheimen. Ich kenn hier noch diverse Ölheizungen und hab in den letzten paar Jahren noch diverse neue Gasheizungen erlebt, weil das ist billiger für den Vermieter, und dass sich das Mieterpack dumm und dämlich zahlt, ist ja nicht deren Problem.

  • source
  • parent
  • context
  • [–] 3 points 1 hour ago* (1 child)

    It's simply faster. Do you strrictly need a GPU-accelerated terminal? No. Or in your case of not doing much in terminal anyway: not at all.

    But with modern terminals (true color, lots of utf-8 glyphs) on big 4k screens using multiple tabs you can literally see the performance difference (quicker tabbing, faster and smoother scrolling, even just how fast a command that spits out a lot of text –hello debugging– runs through) without needing benchmarks.
    And that's still just text. Watching (previews of) graphics files or even playing videos directly inside your terminal is actually possible with modern feature-rich browsers.

    Also just from a pure efficiency point of view: If it runs more efficient on my GPU that's energy saved, so a few more minutes of battery time on my laptop.

  • source
  • parent
  • context
  • [–] 9 points 12 hours ago* (1 child)

    Aber es ist ja so nett alles via App steuern zu können

    Es ist aber auch nicht zielführend, das als Argument voranzustellen, wenn das Hauptproblem die absolute Dummheit von ungesicherten, nicht mehr regelmäßig gepatchten und mit Standardpasswörtern versehenen Geräten ist.

    Klar, kann man sich fragen, was überhaupt wirklich Fernzugriff braucht. Aber das kommt halt erst viel, viel später, in der detaillierten Sicherheits- und Bedrohungsanalyse, nachdem man das absolute Minimum abgehakt. Aber das schaffen die ja scheinbar schon nicht.

    Das ist in etwa so, als wenn wir die Diskussion über das nicht allzu hochwertige Türschluss starten, während die Tür tatsächlich nicht nur eh offen, sondern auch noch ausgehängt neben dem Türrahmen steht. Der Wunsch Geräte aus der Ferne überwachen zu wollen, ist hier nicht das primäre Problem.

  • source
  • parent
  • context
  • [–] 4 points 12 hours ago* (2 children)

    Aber wurden sie ja hier laut Artikel nicht. Die werden nur zentral überwacht und wenn was schief geht (Zitat:)"fährt ein Techniker hin". Dass sie dann a) überhaupt auch steuerbar im Netz hängen, b) längst ohne weitere Updates und Patches zu erhalten, und diese c) auch nicht mal nötig waren, weil jeder Idiot einfach das ungeänderte Standardpasswort benutzen konnte, ist dann aber einfach nur völliger Irrsinn.

  • source
  • parent
  • context
  • [–] 3 points 12 hours ago

    That might be an argument if you are sane and actually building up renewables and storage.

    But for a government that spends its time sabotaging renewables and blocking storage (in fact the whole definition of energy security and why gas peakers are the only option was written directly by an energy company for their corrupt puppet of a minister) it is just a pretense.

  • source
  • parent
  • context
  • [–] 1 point 12 hours ago* (1 child)

    Danke, aber mein Verständnisproblem liegt wohl eher hier:

    "Der Eilantrag, der auf die Vorwegnahme der Hauptsache gerichtet ist, könne nur dann Erfolg haben, wenn auch ein Hauptsacherechtsbehelf offensichtlich erfolgreich wäre. Dies sei hier aber nicht der Fall, so das VG.

    Zur Begründung verwies die 1. Kammer auf [...]"

    Für mich klingt das nach "keine einstweilige Entscheidung im Eilverfahren, weil dafür der erwartete Ausgang 'offensichtlich' sein muss, was er hier nicht ist, weil [Gegenargumente...]"

    Also ist deine Beschreibung korrekt und es wird "eine gewissen Erfolgswahrscheinlichkeit vorausgesetzt" und somit auch eine relevante Prüfung des gesamten Sachverhalts, oder ist –wie hier das Gericht zitiert wird– ein offensichtlich positiver Ausgang nötig und somit wurden in der Begründung nur Gegenargumente herangezogen, die jenem offensichtlichen Erfolg entgegenstehen?

  • source
  • parent
  • context
  • [–] 2 points 19 hours ago* (3 children)

    Kann ich da als Laie mal eine entsprechend fachkundige Einordnung bekommen?

    Ich lese aus dem Text: Eine positive Entscheidung im Eilverfahren wäre nur möglich, wenn eine Entscheidung im Hauptverfahren offensichtlich erfolgreich ausfallen würde.

    In meinen Augen würde das bedeuten, dass der Fall lediglich zu strittig für eine Entscheidung im Eilverfahren ist (weil eben nicht offensichtlich eindeutig), aber nicht dass –wie in der Überschrift impliziert– eine tatsächliche Entscheidung zu der Frage vorliegt.

  • source
  •  

    As this will -thanks to me being quite clueless- be a very open question I will start with the setup:

    One nginx server on an old Raspi getting ports 80 and 443 routed from the access point and serving several pages as well as some reverse proxies for other sevices.

    So a (very simplified) nginx server-block that looks like this:

    # serve stuff internally (without a hostname) via http
    server {
    	listen 80 default_server;
    	http2 on;
    	server_name _; 
    	location / {
    		proxy_pass http://localhost:5555/;
                    \# that's where all actual stuff is located
    	}
    }
    # reroute http traffic with hostname to https
    server {
    	listen 80;
    	http2 on;
    	server_name server_a.bla;
    	location / {
    		return 301 https://$host$request_uri;
    	}
    }
    server {
    	listen 443 ssl default_server;
    	http2 on;
    	server_name server_a.bla;
       	ssl_certificate     A_fullchain.pem;
        	ssl_certificate_key A_privkey.pem;
    	location / {
    		proxy_pass http://localhost:5555/;
    	}
    }
    #actual content here...
    server {
    	listen 5555;
    	http2 on;
        	root /srv/http;
    	location / {
            	index index.html;
       	} 
        	location = /page1 {
    		return 301 page1.html;
    	}
        	location = /page2 {
    		return 301 page2.html;
    	}
            #reverse proxy for an example webdav server 
    	location /dav/ {
    		proxy_pass        http://localhost:6666/;
    	}
    }
    

    Which works well.

    And intuitively it looked like putting Anubis into the chain should be simple. Just point the proxy_pass (and the required headers) in the "port 443"-section to Anubis and set it to pass along to localhost:5555 again.

    Which really worked just as expected... but only for server_a.bla, server_a.bla/page1 or server_a.bla/page2.

    server_a.bla/dav just hangs and hangs, to then time out, seemingly trying to open server_a.bla:6666/dav.

    So long story short...

    How does proxy_pass actually work that the first setup works, yet the second breaks? How does a call for localhost:6666 (already behind earlier proxy passes in both cases) somehow end up querying the hostname instead?

    And what do I need to configure -or what information/header do I need to pass on- to keep the internal communication intact?

    view more: next ›