I can't get away from storing PII for signed in users. For non-signed-in users, I think it would be useful to avoid all PII.
1 karma · joined July 23, 2024
I'm the asker of the question that started this discussion. I'm a US citizen.
I'm actually on the side of the EU here. There needs to be privacy protections for consumers. Even though the requirement for a rep in the EU is impossible for me to fulfill, I admire the fact that they prioritized native EU companies over foreign ones because that is what's best for the EU inside the EU.
I'm mad at the US government for the CLOUD Act, which is egregarious and doesn't serve the interests of the US; it only serves the interests of the US government.
Perhaps my best solution is to block any user creation from the EU, any login from the EU, and any signed-in user request from the EU.
Maybe I can allow non-signed-in users from the EU to browse?
Yeah, I was afraid of this.
> The US has also asked US services to collect data they were not previously collecting, with a gag order to prevent customers from learning it.
I'm so bullish on privacy that I would actually shut down my company if this happens. US courts cannot force me to remain in business.
All operations will be in the US (interaction only through a website). The forge will be designed to allow all of a user's data to be downloaded by that user (easy access to all data). It will also allow wiping away any reference to a user in commits (right to be forgotten).
But PII does need to be collected, such as username, password, IP address, public keys, etc. There are zero plans to collect anything that is not needed; only the minimum data needed will be collected.
Edit: Oh, and the forge would not send data to third parties at all, unless such third parties are cloning code, but then they would be users, right?
Would it be legal to accept EU customers? If not, would there be anything to do to make it legal?
If my code was uploaded on GitHub, I would DMCA it because of Copilot, but it wouldn't matter because the information is already in the model. So the DMCA does not help here.
The only way it would help is if I could DMCA the entire model and force them to retrain without my code. As it stands, this lawsuit is the only way for GitHub to be reined in; I don't have the resources to do so on my own.
IANAL.
Also, about high impact, suppose Copilot has 1 million users that use it on average 10 times a day, 5 days a week. You claim that less than 1% of uses of Copilot would result in copyright violation. Let's assume 0.1%. How many times would copyright violation happen per day? It would happen 10,000 times per day. For five days a week.
It would take a mere twenty weeks (less than six months) to reach a million violations.
That seems impactful.
What else does this mean:
> The scope of this is intended to cover incidents where users harass other users or make bigoted, racist, homophobic, transphobic, etc, comments on our platform.
You say "harass other users OR make bigoted...etc, comments on our platform."
The fact that you said "or" means that you intend to kick users off who make comments that you judge to be that, even if it's not harassment. Doing so is admitting that you will ban people purely for political differences on those topics.
Yes, another of their missions is to facilitate aviation.
What I meant is that in my case, the default decision couldn't be to give me a medical. So I should have limited the "safety comes first" to my case.
A more charitable interpretation is to say that pilots without issues are defined as safe, which they are even if they are not in practice. They're safe enough.
I have a pilot acquaintance that would refuse to go to the doctor when he was younger.
I also tried to become a pilot, but because of a documented history of taking anti-depressants, the FAA grounded me for life, despite being years removed from needing them. [1] I wish that history was not documented.
[1]: https://gavinhoward.com/2022/09/grounded-for-life-losing-the...
Wrong. Some viruses don't get transmitted if the person is not symptomatic, even if there's an infection. Your lack of understanding belies your argument.
> Ask yourself what the efficacy would need to be for you to be pro-vax-mandate. I suspect I already know the answer.
Well, first of all, the vaccine has to be:
* effective,
* free of major side effects,
* for a virus that kills a large portion of the infected and that kills more than just the elderly and obese,
* and not mandated for people to actually live.
The COVID shots and mandates did not meet any of those requirements.
And if you complain that my last requirement is too much, remember that in the United States, the Federal Government has severe limits on its power on purpose. Sure, the government should be able to prevent unvaccinated people from accessing government facilities, but only temporarily (while the pandemic is going on) because the government has jurisdiction over those things.
But it does not have jurisdiction over telling businesses who they can and cannot do business with.
Being anti-vax-mandate for an ineffective vaccine is not anti-vax in any way.
And again, SQLite is used in places that Rust has no compiler for. This is a hard constraint that precludes using Rust.
Accuracy is important in the marketplace of ideas, and especially in programming. Software is too buggy already, and it would only add more bugs to have programmers not understand the languages they use.
> I made this same observation in the past, it never satisfied you.
Yes, you made that same observation, and I appreciate that. But as @kbd so unintentionally demonstrated, people still believe that Zig is colorless. I want to dispel that notion completely.
I think you are not adding to the problem, and that is great. But the notion is still there.
> Your blog post is full of wrong information. I tried to explain to you what was wrong when you first posted it (so you can refer to those comments, if you want), but you keep seeing this as some kind of philosophical debate, and I have no interest in having this debate.
Here is all of the comments you made on Hacker News on the comments [1] about my blog post.
> That's exactly it. It just enables code reuse. You still have to think about how your application will behave, but you won't have to use an async-flavored reimplementaion of another library. Case in point: zig-okredis works in both sync and async applicatons, and I don't have to maintain two codebases.
> https://github.com/kristoff-it/zig-okredis
> I thought using "colorblind" in the title of my original blogpost would be a clear enough hint to the reader that the colors still exist, but I guess you can never be too explicit.
and
> That's how it works in Zig. Calling an async function like this will also await it.
The closest thing to "explain[ing] to [me] what was wrong when [I] first posted it" is probably that first comment, which was in reply to
> I may be totally wrong with this assumption, but the way I understoo[d] Zig's color-less async support is that the compiler either creates a "red" or "blue" function body from the same source code based on how the function is called (so on the language level, function coloring doesn't matter, but it does in compiler output).
> The compiler still needs to stamp out colored function bodies because the generated code for a function with async support needs to look different - the compiler needs to turn the code into a state machine instead of a simple sequence).
> It's a bit unfortunate that red and blue functions appear to have a different "ABI signature", but I guess that's needed to pass an additional context pointer into a function with async support (which would otherwise be the implicit stack pointer).
(Original comment at [2] by flohofwoe.)
So if anybody explained anything, it's flohofwoe.
But flohofwoe's comment goes directly against the the language reference, so it's hard for me to believe.
The language reference says that sync functions are turned async if they call async functions. This implies virality of async on functions, which implies that many functions are definitely async-only.
If the compiler does something different, which it would have to if it actually makes two different versions of each function, then the language reference is wrong. Like I said, accuracy matters, so I would also like to see changes in the Zig language reference about this if that's the case.
> As I said to you already in the past, I just write software with Zig async and it works.
Yes, you write working software in Zig async, but you understand it better than most. People who go to the language reference and write based on that may not be able to write working software with Zig async as easily as you.
Then perhaps there is something wrong with the language reference?
> I don't even dare to describe Zig as colorless, in fact I say colorblind.
Doesn't that mean my blog post is right?
But my biggest beef is that people, including GP, used your blog post to then claim Zig is colorless. I mean, GP did it in GP.
Again, the original post about function colors talks about runtime, so how could I be disingenuous about that?
> Not in any meaningful way, no. Again, the runtime representation of async vs sync functions is unavoidably different, and has nothing to do with the language. The fact that Zig lets you write one function definition that can be called in sync vs async contexts (unless you're specifically choosing to do sync vs async things) is what it means to be colorless!
I mean, this would be true if it were true. But I tried to use the "blue" function in my examples in both contexts, and it didn't work. In fact, it didn't even work to use the "red" function in both contexts.
> I dunno if that's accurate? Someone with more knowledge of Zig internals would have to confirm, but I assume if the same codebase uses a function in each context it'll be monomorphized into the specific version needed, same as generics. I don't think that's contradicted by what you quoted.
I worded this completely wrong, so let me fix that. I should have said,
> if an async function is used in a sync context, the compiler makes the context async and continues on its merry way, so there is only one runtime representation of the function that was the context.
But it means that the sync function that was the caller is made async no matter what because it calls an async function. So there is no monomorphization; there cannot be since there is a call to an async function that always makes an async context that always turns the caller async.
I think Zig is getting too much hype. It's unfortunate because Zig could have potential, but hyping something before it's ready is a recipe for alienating early adopters and killing progress towards popularity.
The worst part of it is that I've heard people say that they've got Zig in production; with all of the bugs in the compiler, they are apt to get burned, and too many burns will lead to putting out the fire and rewriting.
It doesn't help that (in my opinion) there is confusion regarding basic things about Zig. [1]
[1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
The Library of Congress also recommends it for preservation of digital content, which would be harder if Rust compilers were lost. If all C89 compilers were lost, it would be much more simple to create a new one to compile SQLite than it would be to recreate a Rust compiler.
Sure, write new stuff in Rust, but SQLite needs to stay in C at this point.
One severe CVE in about 20 years is no reason to rewrite in another language and remove support for some platforms.
I know this because I've managed to add a form of RAII and borrow checking to portable C11, and C is known for being faster than Rust to compile. Imagine what happened if we made a language with that stuff built-in.
The funny thing is that C is also slower to compile than it could be because of headers.