moreentropy

Icecast existed for ages. It's streaming protocol (about the same as the proprietary shoutcast) is basically an endless progressive HTTP download, which means you can simply put a stream URL into an audio tag in HTML and the stream plays in a browser or save a stream using wget/curl.

The protocol is/was directly supported by about any MP3 player software since the end of the 90s, including display of metadata updated (song/show title). One problem with Icecast streams is that content is streamed through a long lasting HTTP request. If the TCP connection breaks there is no way to recover without interrupting playback. Some Antivirus software will think the stream is a downloadable file, so it will withhold data from the browser while trying to download the whole stream. Using HTTPS for Icecast helps to keep most AV software from MITMing the stream.

If you implement A/V streaming to the web today, you most probably would want to use chunked streaming with modern protocols like HLS or DASH. ffmpeg can do this. The encoder will save a live a/v source into small fragments (like 2 seconds) on a webserver that the browser can download, reassemble and play one after the other. If one chunk download fails (because of a network change on the client side), the browser might be able to retry downloading chunks.

Caching/distribution also works using standard HTTP accelerators with chunked streaming while you need to chain multiple Icecast servers if you want to scale Icecast.

Edit and shameless self plug: I wrote an Icecast exporter a few years ago to get nice streaming stats in Prometheus: https://github.com/markuslindenberg/icecast_exporter

> There's no chance this plastic contraption makes a nicer coffee than my espresso machine.

Brewed coffee and espresso are two completely different things.

I just had to deal with a large, handwritten Makefile when trying to package and cross compile something for buildroot.

Turns out it was easier to learn to use cmake and rewrite the relevant parts of the Makefile than fix everything in the Makefile that didn't work in a cross compilation scenario.

I hope they donate to Let's Encrypt.

Video of wttr.in author's short talk about console oriented services at CCC/entropia's GPN18 conference two months ago:

https://media.ccc.de/v/gpn18-164-using-and-creating-console-...

At first I liked it but then I saw the strange ß (german Eszett, ss can be used instead).

From https://en.wikipedia.org/wiki/%C3%9F I understand that that's the Antiqua form while nowadays the Sulzbacher form is used. But I don't know anything serious about typography.

Haven't dealt with live migration, but mounting filesystems should be easy using systemd's unit dependencies.

Just drop a .mount file in /etc/systemd/system and set RequiredBy=systemd-nspawn@something.service and StopWhenUnneeded=true and the filesystem should be mounted before the machine starts and unmounted when the machine is shut down. See the manpages systemd.unit and systemd.mount for details.

Have you tried passing 'debug' instead of 'quiet splash' to the kernel cmdline and doing halt instead of poweroff/reboot? That way you should see what's going on during shutdown.

Well it just works and is extremely simple to use.

I usually debootstrap into /var/lib/machines/something and do "machinectl enable something; machinectl start something", that's it. Then I attach to the machine using "machienctl shell something" and configure networking (host0 interface) inside the domain, that's it.

For drop in configuration systemd-nspawn parses a config file /etc/systemd/nspawn/something.nspawn which usually just contains network configuration on my hosts:

[Network] Bridge=br-int

Systemd-nspawn enables and user namespacing by default and chowns the machines's root filesystem on first start. If that's not desired (Things like Samba fileservers don't work well with user namespacing) just disable it in the .nspawn file:

[Exec] PrivateUsers=no

Everything you need to know is in the manpages systemd-nspawn and systemd.nspawn. I usually install systemd from stretch-backports because running a fairly recent systemd version helps as it still gets new features, but I never had problems with stability.

I've had way more headache with badly written and plain faulty init scripts than with systemd, including systemd-networkd, systemd-timesyncd, systemd-resolved and systemd-nspawn, which I used to replace a lot of LXC, LXD and openvz setups.

I think most systemd criticism misses the point and revolves too much around usage semantics.

Systemd allows actual resource management on a level that simply didn't exist with traditional init [1]. Yes we can argue about implementation, but the necessity of better resource management in more dense and shared environments can't just be ignored, especially when building a shared VM hosting platform like the author is talking about.

[1] http://0pointer.de/blog/projects/resources.html

You can't have overlapping AllowedIPs for peers on the same interface. Wireguard has to decide which encryption/decryption keys to use based on the AllowedIPs.

For your use case you need two wg Interfaces on each host (w/ different ListenPort and AllowedIPs=0.0.0.0/0) and a routing daemon (like bird).

Don't know about High Sierra issues but Linphone (http://www.linphone.org/) usually works very well. Jitsi Desktop (https://desktop.jitsi.org/) is a decent SIP softphone too but it's really ugly. Both are cross platform and open source, don't know about commercial software.

I wouldn't recommend native SIP softphones anymore, it's a pain to configure and run securely. The best cross platform media stack is the WebRTC functionality in modern browsers, and it usually just works perfectly with a VoIP provider or PBX that has a WebRTC frontend.

Never tried, sorry.

See here: http://nginx.org/en/docs/stream/ngx_stream_ssl_preread_modul...

I honestly don't know, I never made serious performance tests. The external exporter can make use of every variable that nginx is able to use in a log_format. I guess the internal Lua scripting has access to even more data.

Performance wise I assume the external exporter has less impact on Nginx' operation because it doesn't keep shared state or run code inside Nginx at all (see https://github.com/knyar/nginx-lua-prometheus#caveats), all Ngnix does is push out log records over syslog/UDP. If the exporter should overload that doesn't concern Nginx at all, what happens is that observations get dropped.

I'm pretty much in love with Nginx' simplicity and capabilities as a swiss army knife for all kinds of HTTP magic.

I had some doubts about Nginx' direction and feature development, but most really great features (like stream proxy with SNI support) make their way into the open source release. Built in monitoring sucks though. There are options for better monitoring your requests with Prometheus.

This project implements prometheus metrics using Lua scripting inside Nginx:

https://github.com/knyar/nginx-lua-prometheus

This project is indended as a sidecar service to nginx and receives access logs and timings using syslog protocol (Nginx has a native syslog over UDP capabilities) so no scripting inside Nginx is necessary:

https://github.com/markuslindenberg/nginx_request_exporter

(I'm the author of this exporter)

> I can't recommend more the 33c3 talk "Software Defined Emissions," which tells you a ton more than this clickbait hack journalism could ever.

https://media.ccc.de/v/33c3-7904-software_defined_emissions

> Apparently The Mirror was not ready for the sudden influx of readers...

Spiegel online is huge, that extra bit of traffic shouldn't bother them, see http://www.alexa.com/siteinfo/spiegel.de

Right now the site is down supposedly because of a power outage in a data center. Can't remember the last time spiegel online was offline, the outage is so high profile that #spiegelonline is trending in .de

Right now Spiegel is resorting to publishing on https://www.facebook.com/spiegelonline/

A language where it's natural to think about and properly handle every error condition.

Yubico Authenticator for Desktop:

https://www.yubico.com/support/knowledge-base/categories/art...

If you're on Ubuntu you can use the package yubioath-desktop from this PPA:

https://launchpad.net/~yubico/+archive/ubuntu/stable

Have a look at the Nitrokey, it's completely Open Source: https://www.nitrokey.com/

TOTP with Yubikeys is great. You just need the Yubico Authenticator app to access the TOTPs. Works fine on phone using NFC as well as on my (Linux) desktop using USB. New phone? Install YK Authenticator, tap the YK and use your TOTPs.

US International keyboards have a AltGr key instead of right Alt and a € symbol on the 5 key. Afaik there are no other differences.

I use restic[1] to make encrypted backups to S3 (self hosted minio service in my case).

I can't praise restic enough. It's fast, secure, easy to use and set up (golang) and the developer(s) are awesome!

[1] https://restic.github.io/

Ack. Sadly, enterprise procurement is all about avoiding blame in case something goes wrong. Another issue is contributing to open source projects. I know a case where a customer's in house developer had to wait two months to contribute a few lines patch to a open source project because legal objected. They never dealt with that situation before.

The thing about docker is that the containers are thin provisioned, you can run as many containers based on 8GB images if you have the spare 8GB for the base image. Still, bloat is to be avoided so Alpine as a base image is a great idea.

The headline is misleading, it's not the routers (EdgeOS) but the airMAX wireless sytems (airOS) affected.

Add SoundCloud's Prometheus w/ Grafana.

People are learning and using it just fine. Yes, it looks a bit different but that's about it. Everything works just the same except building properly routed networks is a lot easier with IPv6.