This is not true, many are moving to OFTC. But the obvious answer is, Libera is run by the ex-freenode staffers, and runs on the same software. (Unlike OFTC)
So Libera is basically Freenode's spiritual successor with a different name.
> XMPP & Matrix bridge together fairly well these days.
I want to test this claim. After an hour of google searching I'm none the wiser:
1. Can I bridge private messages, or just MUCs? I use XMPP only to keep in contact with friends that use XMPP. I would love to integrate them into a single client, but afaict it does not appear possible.
2. Do I have to run my own XMPP bridge, or is there some automatic integration service I'm completely missing? For comparison, the experience of bridging a matrix room to IRC was as easy as clicking "add new bridge" in the Element UI.
Well, one question we could ask is why basically every single popular open source multimedia project (FFmpeg, x264, MPC-HC/madVR, mpv, avisynth/VapourSynth, MVtools/SVP, heck even LAME, .....) is made mostly by european authors? Some projects are almost 100% european, some are partially european with some russian and other non-american countries thrown in.
The only projects I can actually think of that are based in the US and made by american authors are those by xiph.org, and they only get away with it because their entire business model is developing royalty free alternatives to MPEG codecs.
Even if multimedia patents might not affect big corporations much, they definitely seem to strongly affect the open source community. I imagine if we had similar dystopian laws here in the EU, our best and most beloved multimedia software would plain not exist.
SMPlayer can barely even be considered an mpv front-end and I hope nobody who uses it will ever make an mpv bug report again. It's a gigantic pile of hacks from the MPlayer age, and it “interfaces” with mpv using the most horrible method possible (embedding the mpv window and sending keystrokes to it)
Nobody is trying to argue that 4:2:0 video looks objectively superior to 4:4:4 video if given a free choice. Obviously, full chroma information will always be better, such as is the case for something like a PC monitor vs a TV with subsampling.
The problem is that 4:4:4 chroma requires more bits to compress, so when you're designing a video/image codec, you have to ask yourself whether the difference in bitrate between 4:2:0 and 4:4:4 is worth the difference in quality, and the answer seems to be “no”.
This means that when you're serving, say, a 5 Mbps youtube video where the bitrate is already fixed, 4:2:0 is going to give you more bits to put into useful stuff (e.g. luma plane) instead of having to waste them on mostly-redundant chroma information.
I'm not actually sure. In retrospect, I'm not sure what ‘DCT without quantizing’ really means, since the output of the cosines are probably real numbers? I guess the interpretation would be quantized to however many steps to reproduce the original result when inverted (and rounded).
In lossless JPEG it seems they omitted the DCT primarily for this reason: It not being a lossless operation to begin with, if you actually want to store the result. What other lossless codecs often do is store a lossy version such as that produced by a DCT, alongside a compressed residual stream coding the difference (error).
In either case, it's important to note the distinction between reordering and compressing; reordering tricks like DCT can reorder entropy without affecting the number of bits required to store them, but the simple fact of having reordered data can make the resultant stream much easier to predict.
For example, compare an input signal like this one:
FF 00 FF 01 FF 02 FF 03 FF 04 ...
By applying a reordering transformation to move all of the low and high bytes together, you turn it into
FF FF FF FF FF .. 00 01 02 03 04 ..
which is much more easily compressed. As for whether that's the case for (some suitable definition of) lossless DCT, I'm not sure.
> what i think of as undershooting or overshooting is relative to the range... and besides that, what is wrong with clamping? its how computer graphics has always had to deal with these things... limited range simply doesn't exist in that context, and it doesn't harm anything.
As far as I understand it, limited range was historically used so you could use efficient fixed-function integer math for your processing filters without needing to worry about overflow or underflow inside the processing chain. You can't just “clamp back” a signal after an overflow happens.
Of course, it's pretty much irrelevant in 2016 when floating point processing is the norm and TVs come with their own operating systems, so these days it just exists for backwards compatibility with the existing stuff - which is a property that video standards have tried to preserve as much as possible since the early beginnings of television.
> Chroma subsampling isn't going anywhere. You'll usually get subjectively better quality with 4:2:0 chroma compared to 4:4:4 at the same bitrate. And this means you can't have everything in RGB, so all the colorspace conversion complexity can't be ignored.
What's more, YCbCr is more efficiently compressed than RGB even if you don't subsample, for the same reason that a DCT saves bits even if you don't quantize: Linearly dependent or redundant information is moved into fewer components, in this case most of the information moves into the Y channel with the Cb and Cr both being very flat in comparison. (Just look at a typical YCbCr image reinterpreted as grayscale to see what I meant)
This comment is pretty much what I was going for. I've reworded it to make it clearer.
The issue you can run into in practice is stuff like softsubbed signs, which can clash and look out of place with the native video if you render them at full res. There's also a related issue, which is that if you're using something like motion interpolation (e.g. “smoothmotion”, “fluidmotion” etc. or even stuff like MVTools/SVP), softsubbed signs will not match the video during pans etc., making them stutter and look very out-of-place - the only way to fix that is to render them on top of the video before applying the relevant motion interpolation algorithms.
Personally I've always wished for a world in which subtitles are split into two files, one for dialogue and for signs, with an ability to distinguish between the two. (Heck, I think softsubbed signs should just be separate transparent video streams that are overlayed on top of the native picture, allowing you to essentially hardsub signs while still being capable of disabling them)
Also, sometimes, rendering at full resolution is prohibitively expensive, e.g. watching heavily softsubbed 720p content on a 4K screen.
In the car analogy, the car crashing is the equivalent of the programmer introducing a bug.
The adversary is out of the picture here - you want to write your kernel in a way that makes accidental bugs hard/harmless. (i.e. prevent “random crashes”)
“A TCP weakness in Linux systems allows ...”
vs
“A TCP weakness allows ... on Linux systems”
Technically, it's not just Linux that's affected - it's the TCP protocol itself. The “on Linux systems” part is sort of redundant, and only serves to point out that other operating systems are unaffected as they don't implement that part of the RFC.
There's always the option of running certbot in certonly mode - in fact, that's what I do for the majority of my setups (mostly because certbot doesn't support nginx).
On second thought, block devices are sort of sketchy for this use case - but FUSE still seems like a perfectly natural way to export networked storage.
I'd expect a backup hierarchy to just be a directory of read-only snapshots of my files - I mean, this is how I organize backups locally either way (e.g. /snapshot/YYYY-MM-DD/etc/whatever.conf).
The advantage of using a standard API like filesystems and FUSE is that you can use it easily and from the terminal without needing to deal with bloated GUIs and JVMs that are no doubt hard to install, hard to use and hard to rely on.
A JVM is also a pretty hefty requirement to have on a machine. (I personally avoid installing it all costs, mostly because everything that targets JVM seems to be crud to begin with)
Those patches are for running the nvidia kernel driver in a PaX-enabled kernel. It doesn't help you protect the actual libGL.so, which my concern was about.
(Indeed, I have to use those patches otherwise the nvidia kernel module wouldn't compile)
My biggest problem with GPU drivers is that they stick out like a sore thumb on a hardened system. All the protection and isolation in the world won't help you when you have a stock-compiled, PaX-disabled blob loaded into your binary that communicates directly with the kernel.
For this reason and this reason alone, I am forced to basically limit OpenGL access to X.org and mpv.
I wonder if these numbers would change if one included sexting. I have a feeling that a growing portion of both relationships and sexual activities are being held over the internet.
Wait, wouldn't that be standard? I've never used online backup, but I would naively assume that Linux would just have a block device or FUSE driver for these things.
I think a better way to look at it is not the chance of total data loss, but the expected running cost over time. Even with just RAID6 it's hard to imagine a scenario in which you would be unable to replace one of the failed drives and resilver before getting two further failures, so the naive reliability calculations are extremely biased.
So if we assume that we can safely operate at some fixed level of redundancy (say 3 copies) across all hard drive vendors, the only question is (how many drives you need to replace per year) × (the price of those drives).
So Libera is basically Freenode's spiritual successor with a different name.