haasn

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.

Sounds exactly like my experience trying to reintegrate into society.

This is what you get for using Slack. Meanwhile, IRC still works fine.

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)

I believe you are misunderstanding the issue.

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”)

I still think the title is misleading. Compare:

“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)

That implies running Windows, though.

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.

How can that not be the case?

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).

> Which are ...?

I'm not an expert, but I wonder if this means you could restrict GPU access to the master process only (for the sake of hardware-accelerated compositing) without needing to expose it to the website-facing process (due to the security vulnerabilities in GPU drivers).

While I don't think the URL shortening matters too much, there's still another important attribute of using these shortlinks that manifests itself on youtube: They also omit irrelevant metadata like URL parameters that were specific to your session or the way you arrived at the site.

For example, youtube will often include extra garbage parameters for stuff like playlists - which the youtu.be shorturls omit, making them perfect for sharing videos.

This feature already exists and you don't need a button for it. It's part of HTML metadata, specifically the <link rel="shortlink"> tag.

You could either provide some sort of button to your browser to place this into the clipboard, or use an extension like pentadactyl to add a keyboard shortcut for it. (It's simply “y” by default - so copying URLs works like yanking in vim)

I always copy/paste the URL when I want to share a website. That's what the URL is meant for. Heck, it's easier to copy the URL (using the keyboard) than it is to use the mouse to click on some button.

Sharing buttons are a nuisance more than anything. at best, I'd say they're a tool to enable spying on users and should be categorically blocked (as standard uBlock₀ filter rules let you do with a single click).

This is my biggest worry too. It's easy to turn on ASLR and PIE and SSP and whatnot and still have tons of obvious bugs in your actual business logic.

I'm sort of worried that these automated metrics are too easy to game, and that all it will teach companies do is to use different compiler settings without actually caring about, say, hashing their passwords or authenticating their cookies.

I have an LG display with this anti-feature built in as well. An amusing anecdote about that: The OSD is not documented very well. There's a feature named “SUPER ENERGY SAVING” and a feature simply named “DFC”. As I learned via google, “DFC” is supposed to mean “Digital Fine Contrast”.

Now, about these two features: One of them turns off the backlight when I lock my screen, the other adjusts the backlight intensity automatically based on the display contents.

Did you think “SUPER ENERGY SAVING” was the first and “DFC” was the second? Nope, of course not - it was the other way around. “SUPER ENERGY SAVING” advertises itself as “saving energy” by reducing the backlight intensity when it's “not needed as much”, and “DFC” advertises itself as increasing the “dynamic” contrast (by basically turning off the backlight during the black frame test pattern).

Good job LG. This is actually one of the least sad bits about the OSD's horrible design and implementation.

I think this article does a fantastic job of illustrating why legal problems (determining or enforcing the Colour of something) can never possibly be solved through the use of (colourless) technology - the two are fundamentally incompatible. This is, for example, the reason why DRM has never ever stopped people from sharing copyrighted works - because DRM is trying to solve a legal problem (the Colour of bits) by using a function of those bits (technology), it is destined to fail.

Indeed, the only absurd thing about the law is when people try to flirt with it by treating it mathematically.

At some level, laws inherently have to be up for interpretation, and operate on some level of abstraction above the intimate details - because virtually everything in life is a spectrum, including the applicability of a given law. In the “fringe zone” in which it's not clear whether a law applies or not, judges have to resort to individual judgement on a case-by-case basis.

This is not something that's new or unique to technology, although technology does a fantastic job of illustrating the difference between a legal problem and a technological problem - as well as the different mindsets you have to approach both with.