phiresky

I'd guess they only proxy the main domains (which have the session cookies and probably the geoblocking criteria), but let the video serving domains (which at least in netflix are separate and "stupid") go through their normal network.

All of those rights or stronger are already in effect in the EU since last year, which means most companies doing online business already have to comply with them. In fact it's pretty clear that Yang mostly just copied GDPR with this whole proposal. I'm not complaining, it's a great law if you're for consumer protection.

Many companies already provide the option to download all data, and I've written GDPR data request mails to multiple US based companies with success. Mostly you get the data in JSON files (without schema).

Right now, many companies are trying as hard as they can to skirt the law, but there's land mark cases happening already that will hopefully put an and to that soon [1].

[1]: https://techcrunch.com/2019/10/01/europes-top-court-says-act... ironically, techcrunch is a prime example of a "tracking cookie consent" popup that is absolutely illegal and will hopefully get them huge fines once the data protection agencies have their hands less full with bigger fish (google, facebook, etc).

The main performance problem in pacman as far as I can tell is really slow xz decompression. This is mostly important for large packages:

    $ time xzcat /var/cache/pacman/pkg/cuda-10.1.243-1-x86_64.pkg.tar.xz >/dev/null
    1:17,33 total

Just decompressing that 1.8GB package takes 77 seconds.

There was a discussion in April to switch compression to zstd - which reduces the decompression time for that package to only 4 seconds (!) while keeping the same file size. That way the disk is the bottleneck again, as it should be. That switch would be awesome, but it looks like it's not happening currently.

I saw someone mention this a while ago and at first I thought it was stupid but over time I've come to agree:

Asymetric internet connections should be forbidden. They assume that users consume more than they create, and the internet should be a place where everyone has equal footing. In addition, IPv6 firewalls in routers should either be disabled by default or have a forced API to selectively disable them [^1]. (IPv4 for the "decentralized internet" is pretty much a lost cause because of NAT). In my opinion, this should be a part of net neutrality. The current definition of what constitutes "internet" is far too loose.

Many applications of decentralized hosting of websites or other content is much harder because most people have a very shitty upstream. If you could use all smartphones around the world that are currently connected to WiFi and an outlet, you could host whole websites (or at least chunked static content) over those. Currently, this is unrealistic because you can't NAT punch for every 100kb chunk and you won't get any good speeds.

[^1] My router by defaults blocks all incoming IPv6 connections to devices

Exactly. People here always seem to assume that its power consumption will increase linearily the more people it use (from what the whole network consumes now).

But in the future, the amount of energy consumed for a single transaction will tend towards exactly the fee paid for that transaction multiplied by the cheapest electricity price in the world.

So either the transaction fees will be outlandish, or for a transaction that costs $0.10 you will consume roughly 2kWh.

Yep. The only thing missing is nominal aliases to primitive types, which is requested my many people [1] and even the TS compiler itself uses hacks to work around the lack of them. No idea why they don't add them already.

Also of course any form of runtime type checking is missing.

[1] https://github.com/Microsoft/Typescript/issues/202

We hacked together an automatic door opening system controllable via smartphone that notifies you on ringing and sends a video, then opens the doors on button press with a Lego contraption [1].

[1]: https://www.reddit.com/r/raspberry_pi/comments/bwdv36/a_smar...

Would probably be shorter if you used `tostream`

> It's not clear whether libripgrep would be a good fit for this project or not

I actually looked into using libripgrep for this, but then I decided not to because of (a) not wanting to handle arg parsing myself (ripgrep has sooo many arguments), (b) missing or hard to find documentation.

The main reason it might be a good idea is because currently ripgrep does not know at all about a single file returning multiple "files", and all line prefixes are "hardcoded" (e.g. Page X: hello in pdfs is just prefixed per line). Also I can't rely on ripgrep's binary detection currently, because it would have to happen for "parts of files" from the perspective of ripgrep.

It would be great if ripgrep had a slightly more advanced preprocessing API - allow returning multiple "files" per filename input, maybe even with a "sourcemap" of line<->Page etc.

kind of.. though this tool does a lot more (caching, recursing into archives and extracting all text) and is a lot faster (for the file types it can parse, lesspipe knows more), and of course lesspipe is only indirectly usable for recursive searching.

Also, most of it is completely safe Rust, so no out-of-bounds writes there :). The most dangerous part currently is probably the PDF parser.

Well, it uses the exact same pdf parsing library that e.g. Evince uses.. so if you ever open untrusted PDFs in a normal viewer, this will expose you to the same danger (maybe less since it only extracts text). But yeah, if there was a nice safe PDF library written in pure Rust I would of course link against that.

Thank you! Yeah, I like to think I have some interesting projects. Maybe I should make an overview page because you can only pin 6 repositories on Github :)

There is an option to limit the maximum archive recursion `--rga-max-archive-recursion=` which defaults to 4. That is also needed to handle droste.zip [1] which is a zip file that contains itself. So for huge archives it will simply take a fairly long time, unless you limit recursion more.

[1]: https://alf.nu/ZipQuine

Nope, haven't tried it. I just saw that ripgrep is using appveyor for windows instead, so I assumed it doesn't work on travis. I was actually just trying to add appveyor to this [1], but I'm getting a weird error.

[1]: https://ci.appveyor.com/project/phiresky/ripgrep-all/builds/...

In ripgrep itself you can apparently only look in files of encodings other than UTF16LE with BOM by manually specifying `--encoding UTF16BE` etc.

I could maybe add encoding detection myself, but I'm kind of discouraged since not even the unix `file` tool can detect those files as text, and a normal editor opens at least a UTF16BE file completely wrong. So I'm not sure if I want to spend my time on trying to write heuristic detection on those, especially since UTF16 itself is broken and shouldn't really exist at all...

I'll look into what encoding_rs has to offer.

Windows support should be fairly trivial, the main problem is packaging it up and that travis doesn't like Windows.

> doesn't support other UTF encodings like UTF-16

UTF-16 should in fact work, since ripgrep supports it too. Looks like my binary file detection is at fault [1]..

> Not sure if it can search in single-line mode either

That works fine, just use `rga --multiline '\n' fname`

[1]: https://github.com/phiresky/ripgrep-all/issues/5

It's true that you could mostly replace the "rga" binary with `rg --pre=rga-preproc` and just publish the rga-preproc binary, which does most of the work.. But rga itself adds convenience regarding filter selection and other config options like caching.

Pretty hard to make rg search in files within archives though without actually extracting them (which I've seen more than one request for in the ripgrep issues [1]), which is why rga includes streaming, recursive decompression of archives including running other preprocessors (like pdf) within them (second example in the above post and readme).

[1]: https://github.com/BurntSushi/ripgrep/issues/918

From the author of uBlock on this:

What we see are the public statements, for public consumption, they are designed to "sell" the changes to the wider public. What we do not see is what is being said in private meetings by officers who get to decide how to optimize the business. So we have to judge not by what is said for public consumption purpose, but by what in effect is being done, or what they plan to do.

This is how personally I see the deprecation of the blocking ability of the webRequest API in manifest v3:

In order for Google Chrome to reach its current user base, it had to support content blockers -- these are the top most popular extensions for any browser. Google strategy has been to find the optimal point between the two goals of growing the user base of Google Chrome and preventing content blockers from harming its business.

The blocking ability of the webRequest API caused Google to yield control of content blocking to content blockers. Now that Google Chrome is the dominant browser, it is in a better position to shift the optimal point between the two goals which benefits Google's primary business.

The deprecation of the blocking ability of the webRequest API is to gain back this control, and to further now instrument and report how web pages are filtered since now the exact filters which are applied to web page is information which will be collectable by Google Chrome.

https://github.com/uBlockOrigin/uBlock-issues/issues/338#iss...

> Objectively, it simply isn't, obviously

To be fair, TS has some pretty bad unsoundness problems, especially regarding co/contra variance in generics, and for example some annoying weirdness with number/string keys in objects. Still, the type system is one of the most amazing ones I know.

here's a full example. If you do this:

    function test(p: {k: false | 'x' | 'y' | undefined}) {
        // do stuff
    }
    const p = {k: 'x'} // inferred type: {k: string}
    //...
    test(p); // type error : Type 'string' is not assignable to type 'false | "x" | "y" | undefined'
    

The problem is that the type of p.k is inferred to `string` not `x`. The compiler can't know this is fine because you could call `foo(p)` in between the declaration and the `test` call, that mutates p.k.

If you add `as const` or an explicit type to p it is fine.

(I think this is what the GGP was referring to)

Your problem there seems to mostly be that you tried to directly port it without any modifications, and your code is actually incorrect in some places. For example, if you implemented Result<T, E> as a single class that had a `if(this.is_ok()) ...; else ...` it would work fine without any type assertions or any anywhere.

As it is, Ok only depends on T and Err only depends on E, so why do you have them depend on both?

One problem is that TS does not want to merge unionized function signatures like this:

    map: (<U>(fn: (arg: "yep") => U) => Ok<U>) | (<U>(fn: (arg: any) => U) => Result<U, "nope">)

This can be mostly fixed by removing arguments that you don't need.

I couldn't figure out .map_or_else, but .map().or_else() works.

Admittedly, with this way you can get an output of Ok<a> | Ok<b> from some functions, but I don't know where that would be a problem (still fully type checked, you would just get the expected error further outside.

Here's a updated gist: https://gist.github.com/phiresky/621f8d8ed6eb00c9a0ddb47217e...

Inside of type descriptions, literal values are always treated as literals. The problem only appears when you declare a variable _without_ an explicit type like `const foo = {k: 'x'}`, which the compiler then infers to be of type `foo: {k: string}` and not `foo: {k: 'x'}`.

Both of these are valid inferences, and it's impossible to know which one the user wants in the general case, which is why you have to explicitly say `const foo = {k: 'x' as const}`.

> in many cases being unable to import a JS library in that doesn't include typedefs

Make sure you have "allowJs": true in your tsconfig.json. Otherwise, you'll have to create a minimal file with `declare module "xyz";`

> I fail to see how TS can be considered a superset of JS

You have to interpret all TS "errors" as warnings for that to be true (which they mostly are considering tsc still emits code regardless of non-syntax-error errors)

> I just cannot take a type system seriously when workarounds like that are needed.

Your problem really just seems to be that the type inference does not have magical powers. There is no other programming language that has union types as powerful as TypeScript (as in discriminating by whatever you want), but yeah when you do `return {x: 1, y: 2}` the compiler doesn't always know whether you mean to return an object where the type of x is `1` or where it is `number`. In some cases it could be better still, but doing this in general is just not possible.

True.

My main problem is that blocking WebRTC blocks some very interesting methods to "re-decentralize" the web, which are only viable if most people don't have it disabled.

The only thing blocking WebRTC gets you is that it hides which subnet you are on, right? As in, an attacker can still just enumerate all of the common ones (10.0.0.0/24, 192.168.0.1/24, and like 5 others) and get the same results as with WebRTC enabled. So blocking it really just slightly increases the obscurity, but not really the security.

> People who speak different lanaguges litteraly "think differently"

This widely held belief is absolutely not a proven fact. It's called linguistic relativity or linguistic determinism [1] and the strong form (language determines thought) has not been taken seriously by researchers in the field for a while.

The weak form (language can have somewhat of an impact on the way you think) has not been proven or disproven and is a topic of debate. You just state it as if it was known, even though the causal relationship of most examples you could name can easily be the other way around (culture / thinking affects how a language develops).

I'd argue that everyone learning and speaking the same language would have immense benefits for a global society. You can keep recordings in museums and linguistic researchers to keep a historical record of languages, just like we have for other tools and methods that we no longer have any use for.

[1]: https://en.wikipedia.org/wiki/Linguistic_relativity

Framing a law that forces companies to allow you to export your own personal data in a readable format to reduce vendor lock in as "this will definitely cause the next Cambridge Analytics!" on the basis of "but user authentication might be bad!" is absolutely laughable and the fact that this article got so popular here is pretty discouraging.

> Wrong, false, liable, limited set of privacy related information should be correctable, removable

Which is exactly what the law is for.

The examples in the article were deceptively reported. For example, the doctor who asked The Guardian to take down articles about her suspension: she had successfully appealed that case, and a judge overturned her suspension and ordered the record expunged: her name was dragged through the mud on bad information.

Compare that to the US where any kind of accusation, even if it turns out to be false, can easily permanently ruin someone's job, career prospects, or life.

Have you tried using a different camera app? e.g. Open Camera