steerablesafe

Yes, it's more complicated, and parts of it might need hacks, as there are no standard way to get subpixel layout. That's a failure of those display APIs though, not the failure of the concept of subpixel-AA itself.

> does it make correct gamma rendering more complex? switch to dark mode harder?

Most text rendering is gamma-incorrect anyway, AFAIK, subpixel-AA or not. It doesn't make it more complex, just work in a linear colorspace either way.

Pixel boundaries on your display are imaginary, all you have are RGBRGB light sources next to each other. The pixel boundaries are determined by your left-most and right-most light sources on the display, so you have |RGB|RGB|..., but it really shouldn't affect how you render text in the middle of your screen.

edit:

> it is not grayscale that makes any false assumptions

Grayscale assumes that those pixel boundaries are real, and they are relevant.

> Greyscale-AA is the “natural” approach to anti-aliasing.

> Subpixel-AA is a trick that abuses the common way pixels are laid out on desktop monitors.

I disagree with this notion of subpixel-AA being "abuse". If anything, grayscale AA is a simplification, assuming that each color component of a pixel is emitted from the same area. Of course subpixel-AA is more complicated, but it doesn't mean that it's abuse.

For me this feels like a candidate to build on top of fmt instead of a standalone thing, with a custom formatter wrapping JSON data. I think that direction of extension might still be open, while keeping the current interface for convenience and compatibility.

Ah, I missed that.

If you only install supposedly non-conflicting packages, and there are conflicting file locations, isn't that a packaging bug?

Just to chip in what should the commit message say: it should express the intent of the change and the reason of the change (latter could be reference to ticket). I don't think expressing how the intended change is achieved is important, that's what the diff is. If it's not clear in the diff how the intended change is achieved, try adding some comments.

Well sure. Try not to download them at the same time.

Editing once, with the approval of the authors is one thing. "Automatic" editing on each download is an other.

It probably doesn't worth the cost. Metadata can be trivially stripped, and altering the encoded video and audio streams for each user for fingerprinting is costly.

I don't see why.

Then your tool is incomplete. Steganography works by encoding information into side channels, like precise positioning of words in the PDF, fonts, etc...

Your tool can be as crude as running the document through pdftotext and only keeping the text output. It can just throw away all these possible side channels that are not relevant to the actual content.

Others mentioned other more sophisticated side channels, as rewording sentences, but I'm sure authors would not welcome that.

I don't recommend normalizing differences, as in using both sources as input to produce one "cleaned" output. It could leave watermarks that happen to be the same in both sources.

I recommend having a tool that works on a single source, then verify that it produces the same output from multiple sources.

Also when downloading multiple times, try to do that from different public IPs and accounts.

You just pick a font and always replace with that.

To verify that a watermark removal method works:

1. Download the content with N accounts, preferably from different networks.

2. Run your watermark removal tool on each downloaded data independently.

3. Check if the processed outputs are bit-for-bit identical.

Have fun writing watermark removal tools.

> although I never seen it used in production

Well, of course boost has it, they use `<` and `>`:

[1] https://www.boost.org/doc/libs/1_78_0/libs/hof/doc/html/incl...

More generally if you want to redact pixels, then don't replace them with information that depend on those pixel values. It doesn't necessarily mean a black rectangle, but that's certainly simple and it works.

It's semantically slightly different. In the case of diff3 if you remove everything but the base part, then you get exactly the base version, while in the case of zdiff3 you also get the prefix and suffix parts from the two branches that merge cleanly.

I guess the difference is subtle, especially that there can be other merges within the same file that merge cleanly in both cases.

I don't know about Rust. Several people responded that Java already has a builder interface for creating a format string. That is possibly more type erased than the Rust macro equivalent. In C++ I would use variadic templates, as I originally proposed in my root comment: `format(year(), '/', ...)`.

That's perhaps true, but there is no reason why we can't have both. There are many hard-coded format strings in practice.

+1 for strongly typed and compile-time checked, but I'm still not a fan of a sub-language within a string literal. The language already has syntax to structure things, why make a separate language within strings?

Sure, the issue is somewhat orthogonal. But I assume they wanted to keep the format string parsing minimal, hence the single letter format specifiers. Once you have a strongly typed API, you are no longer bound by this and you can have sensible names.

Is it just me for thinking that using format strings instead of some strongly typed interface with verbose names for this is not great?

I would take `format(year(), '/', month(), '/', day())` over ad-hoc format strings by various APIs.

Reading the docs further this also stands out:

> For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created. For example, using a pattern of "MM/dd/yy" and a SimpleDateFormat instance created on Jan 1, 1997, the string "01/11/12" would be interpreted as Jan 11, 2012 while the string "05/04/64" would be interpreted as May 4, 1964. During parsing, only strings consisting of exactly two digits, as defined by Character.isDigit(char), will be parsed into the default century. Any other numeric string, such as a one digit string, a three or more digit string, or a two digit string that isn't all digits (for example, "-1"), is interpreted literally. So "01/02/3" or "01/02/003" are parsed, using the same pattern, as Jan 2, 3 AD. Likewise, "01/02/-3" is parsed as Jan 2, 4 BC.

I hope nobody uses this to parse historical data that happens to become older than 80 years recently.

It is for deterministically release resources based on scope (although Go's defer is tied to function-scope for reasons I can't understand). python's context manager is similar. Much like destructors in C++.

You can probably say the same about heap allocated memory, but GC'd languages make the choice the non-deterministic release of heap allocations are fine. But there are resources where you can't play the same game (open files, connections, locks) and you need a way to deterministically close them.

If you replace "short-lived objects" with "short-lived resources" then Go has defer, Python has context managers.

"echo" and "time" are explicitly bash built-ins, "which" and "cat" are not, and you will always get a process spawned there.

Your second strace is misleading, you didn't trace child processes.

    $ strace bash -c '$(which echo) hi' 2>&1 | grep 'exec'
    execve("/bin/bash", ["bash", "-c", "$(which echo) hi"], 0x7ffddfcdaee0 /* 59 vars */) = 0
    execve("/bin/echo", ["/bin/echo", "hi"], 0x55eb565cb0b0 /* 59 vars */) = 0
    
    $ strace -f bash -c '$(which echo) hi' 2>&1 | grep 'exec'
    execve("/bin/bash", ["bash", "-c", "$(which echo) hi"], 0x7ffd09b3e228 /* 59 vars */) = 0
    [pid 81493] execve("/usr/bin/which", ["which", "echo"], 0x5560d172e0b0 /* 59 vars */) = 0
    execve("/bin/echo", ["/bin/echo", "hi"], 0x5560d172e0b0 /* 59 vars */) = 0

> especially since `cat` is often inlined, without process spawning.

That would be surprising. How would that work? `cat` is definitely not a bash built-in.

> Maybe you’ll have to throw away an entire IT system because you’ve lost the know how to keep the business case for the system a net positive, but that means a lot less to an organisation (especially enterprise) that we tend to fool ourselves into believing myself included.

You are comparing throwing away an entire IT system to increasing the salary of _one_ employee.

If they got promoted at their new company then you can counter offer with a promotion too?

The main cash cow of Mathematica is the library, not necessarily the language. They could certainly make the language more open, while keeping the secret sauce in the library. They could also open up some core parts of the library too.