Such a wonderful take on Firefox. The only thing it is really missing to make it perfect for everyone is proper sync not just on one computer but across systems.
Without wanting to sound rude: you're talking about browsers – serious business. Most hackers – I feel – need a bit more than 'I strongly suggest it' to even consider switching to a nascent browser :D
The main issue is security. The browser is the most sensitive piece of of software you can run on a machine. It’s susceptible to both supply chain and JS attacks and a huge target for both of them.
it’s a firefox fork. ‘most hackers’ would research it no matter what was typed on a msg board prior to installing. the first step is knowingg about it. personally, im a big fan and daily drive it on my personal systems. but I do find their tab groups implementations to be a bit subpar.
I think the internal web tooling was pretty good compared to anyone but AWS circa 2016 but by 2020 when I left it felt a bit antiquated. Similarly they didn't have linters rolled out until it was industry standard iirc.
But BCL is still the worst language I've ever used.
> I'm an SRE and I think it's quite likely the best infra language I've ever seen.
I only worked with 4-5 SREs and they all grudgingly tolerated it. What did you like about it, compared to other infra languages you've used professionally?
Every SRE I've worked with has said different things, though at the time the controversy was around Piccolo. It flip-flopped between shiny new thing vs deprecated. Then the SREs I worked with got laid off, and I started cargo-culting the Piccolo we had lying around.
See my reply here: https://news.ycombinator.com/item?id=49216714. The hatred of BCL was due to people not understanding the benefits of a restricted language with carefully chosen semantics, and stubbornly insisting in "a real programming language".
I still don't understand why all that dynamic config stuff isn't just Python. Sure, static configs should be protos, but GCL is a whole nasty programming language. They came so close with Piccolo and Gmon but still made it not Python. Have heard some language purity rants involving determinism, but I don't buy it. And they keep inventing new stuff like Starlark. They need to stop.
> GCL is a whole nasty programming language. They came so close with Piccolo and Gmon but still made it not Python.
The GCL designers made several mistakes in its design, but the worse was the lack of a versioning that would make language evolution easier, as well as interoperability between different versions. GCL2 solved some issues, mainly cleaning up the interpreter. Still, BCL is IMNSHO by far the best infra language there is.
> But it's almost a general-purpose language, so why not just use one?
The usefulness of not being a general-purpose language it that it makes static analysis very good; that's what made the BCL-based tooling so useful: being able to easily diff two versions of the same module (a tool called UBdiff), compute the transitive closure of a module's dependencies, trace the execution of BCL code and correlate it with the AST, to point out where an error comes from.
All these features were either unavailable or took years to develop for Piccolo, because Piccolo was based on Python.
> I'm still not seeing why a DSL was necessary or helpful.
BCL has distinct evaluation rules and a notation that encodes many patterns that SREs used for defining services, and that made BCL code much more compact and easy to ready than all the alternatives.
BCL was designed to be unidirectional: a module was evaluated locally, and the result sent to the Borgmaster. Compare that to Terraform, whose execution model consists of an execution tree where some nodes come from RPCs, meaning that it's not generally possible to statically analyse a TF module, because some errors can come from from feeding RPC results into new RPCs, and execution often fails after tens of minutes. All very janky.
Thanks for the detailed explanation. I get the appeal of this then, I just don't think it's worth. Whatever you do will produce some static proto in the end that can be diffed at least. General lang benefits from everyone understanding it and all the standard debug/test methods applying, which I'd much rather have than easier static analysis of the dynamic part. And yeah I was uninformed on Google's config langs, but so was my entire team for 7 years, all cargo-culting.
You're saying the general lang approach led to Piccolo, but that was still a DSL. It looked sorta like Python but it's not, you don't even call functions the normal way, and tons of magic stuff is happening, so just GCL/BCL except worse for the reasons you said. But they must've had a reason to try it. Seeing them continue changing around and making new languages says it's not just me, nothing is working well enough to stick. SREs weren't just arguing about which is better, they were asserting X is deprecated in favor of Y.
TF has seemingly stuck outside. I'm still not a fan of that being a DSL, but at least it's one tons of people use and now Claude can easily handle.
> General lang benefits from everyone understanding it and all the standard debug/test methods applying, which I'd much rather have than easier static analysis of the dynamic part.
Perhaps. I consider that a very narrow view that's detrimental on the long term.
> But they must've had a reason to try it.
They were obsessed with using a general-purpose language, and Python was the thing they knew.
> SREs weren't just arguing about which is better, they were asserting X is deprecated in favor of Y.
This is a kind of dishonesty I saw a lot at Google.
> TF has seemingly stuck outside. I'm still not a fan of that being a DSL, but at least it's one tons of people use and now Claude can easily handle.
Unfortunately Terraform still has significant flaws that prevent it from being used in a reliable fashion.
CEO of <thing> at Google (not Alphabet) was always an informal title. There is no CEO of Cloud, CEO of YouTube, or CEO of DeepMind within Google internally -- it's always been an SVP role.
You don't really need to tmux at all for Claude Code CLI. Claude Code CLI supports streaming json input, and streaming json output; you can use stdin/out as a pipe to control Claude Code CLI.
We have very strict and very well engineered data retention systems. When we say data is deleted, we mean it. Various levels of automation ensure the data is purged, and all data is tracked meticulously for violations across every datastore.
It's one of those systems I wish we talked about more -- it's a marvel to behold just how much work goes into retention policies and the automation that drives it.
So that includes all online and offline + offsite backup systems, presumably? And hopefully any such data is "de-trained" from all applicable ml models and systems, of course.
Without going into too many details, yes. The trick is that you can key sensitive data, encrypt it, and delete it by throwing away the key.
I don't know if Google can do de-training (depends on how the training data is generated), but generally if the trained data can't be tagged for removal it also can't be reversed from the output of the training.
Have you considered the possibility that someone on the inside works for an intelligence agency (domestic or foreign) and is secretly exfiltrating the data for the purpose of obtaining blackmail material?
In the PRISM disclosure of 2013, the slide deck stated that the NSA had direct access to Google's systems. The deck claimed "collection directly from the servers". That, by its very design, goes around all the safeguards people are discussing here.
It's definitely been considered because it has definitely happened before (explore the history of Google cutting ties with China for about a decade).
... in response, Google took measures to prevent that category of insider-knowledge attack. With audited builds, zero-trust internal model (xref BeyondCorp), and infrastructure cross-checked by multiple human beings to guard against hardware-level attacks, such an insider attack is infinitesimally probable now.
The cloud documentation suggests a deletion period of 180 days; so for cloud data, at least, when it says it is "deleted" it seems to mean it will be [fully] deleted within half-a-year. https://cloud.google.com/docs/security/deletion
Former google employee, no knowledge of current situation, not involved in any of this stuff even when I worked there: different types of data get handled differently. If material is important enough then it's going to be backed up onto tape for disaster recovery purposes. If a user then requests it be deleted, that's a huge pain - the easiest thing to do is just wait until that tape has rotated out of backup, which may take a while.
More sensitive user data is likely to be handled differently - both for privacy reasons and because it's honestly just not as important to keep hold of it (a user's cloud data gets lost? That's a big deal. A user's location history data gets lost? Meh), so it's unlikely to end up in long-term backup storage.
Why would the Google Cloud data deletion policy for 1/ paying 2/ enterprise customers deleting their own data that they 3/ opted in to store, and then 4/ opted in to delete have anything to do with the retention policy for Google Maps' 1/ free 2/ consumer customers having data deleted by Google that the customer 3/ did not choose to store, and then 4/ did not choose to delete?
At least 4 meaningfully different qualifiers about the situation for entirely separate parts of Google.
I note that the announcement is VERY VERY SPECIFIC about the data being gone from the opt-in "Location History" feature (with the capitals and everything).
It does NOT say that every copy Google has is deleted. It just says that the user-visible copy is gone.
What about, say, Sensorvault? Or whatever other internal systems I don't know about?
This would run afoul with data retention laws, which Google strongly adheres to. So it can't be true. It might be true for some definition of it, but not materially when it comes to records access.
Let me ask you about an edge case: someone carries out an arson attack against a clinic providing abortion services and inadvertently leaks clues to their identity when gloating about it on social media, which information finds its way into the hands of law enforcement.
(to downvoters, that's something that happens and I have a specific and recent case in mind)
I think the downvotes are because your description doesn't make any sense. Can you rephrase the scenario to better describe what you mean?
Are you saying "Someone carries out an arson attack, they (the attacker) leaks clues to their (the attacker's) identity when gloating about it on social media, and those gloat-posts find their way to law enforcement?"
How does that scenario relate to Google data retention? Google data retention has nothing to do with Twitter policies.
It relates to Google data retention because law enforcement's next move might be to ask Google for geofenced location data from the 72 hours preceding the attack in hopes of confirming the arsonist's identity.
>We have very strict and very well engineered data retention systems. When we say data is deleted, we mean it. Various levels of automation ensure the data is purged, and all data is tracked meticulously for violations across every datastore.
Ok, how would you know that is true?
How many ways can you think of would there be for your statement to be false?
If someone "higher clearance" than you decided to make you believe the above, but actually retain it somewhere in someway you weren't allowed to see. Are the number of ways more than one? How valuable could deleted data be in the case of blackmail or espionage? Can you actually be confident that someone above or before you didn't write a false delete function?
I'm not implying, I'm suggesting that "things we know to be true" is a smaller list than people think.
You suspect WIPEOUT is real, but can't actually know, and you are inside. Why would I believe for even a second?
There is a reason behind the usual in court phrase of "..tell the truth, the whole truth, and nothing but the truth...". So, if a third party would get copies of the data, it would be true Google deleted it...It just not be "the whole truth".
> How many ways can you think of would there be for your statement to be false?
Not as many as you might think.
The systems at Google may seem incredibly complicated--and they are--but when I worked there, the scenarios where somebody intercepts and exfiltrates data without your knowledge are extreme.
> If someone "higher clearance" than you decided to make you believe the above, but actually retain it somewhere in someway you weren't allowed to see.
The way this data is stored, it is designed so that access to the data is logged and the logs have various alerts / auditing procedures to catch exfiltration attempts. SREs will periodically create user data and try out clever ways of destroying or exfiltrating it to test that these controls work. The Snowden leaks also cast a long shadow over work at Google, and since then, basically, all the traffic and data in storage has been encrypted in ways that make it difficult for state level actors to surreptitiously intercept it. These systems are a bit nightmarish to design, because there are competing legal/compliance reasons why data must be retained or must be purged. For example, certain data must be retained for SOX compliance, data may be flagged as part of an ongoing investigation, data may be selected for deletion for GDPR compliance, etc.
Obviously, it is POSSIBLE that someone is still exfiltrating data, but you have hundreds or thousands of smart engineers who are trying to prevent "insider risk" and "state level actors". People within the company are a big part of the threat model, and agencies like the CIA, Mossad, KGB, etc. are also part of the threat model.
The stack may be complicated, but it's also designed with defense-in-depth to prevent people at lower levels in the stack from subverting controls at higher levels in the stack. For example, people who work on storage systems may be completely unable to decrypt the data that their storage systems contain.
If you're going to get pissy about it, it's obviously true that we are not 100% certain that data is destroyed when we say it is. But this invokes a standard for "knowing" that precludes knowing the truth of any statement which is not an analytic statement.
You don't have to believe, even for a second, if you didn't work with the wipeout systems. That's fine. I'm not trying to convince that wipeout works as intended, because I know that I can't provide the evidence to you.
However, you seem to be arguing that other people don't know that the wipeout systems work--that it's somehow impossible to know.
Many years ago, I worked for a contractor where we required clearance. We hired this one sysadmin "stick it to the man" type of guy that was extremely well educated and talented.
When he got to the part of the form that asked if he has ever consumed drugs, he said "yes" as he should have by being honest. The follow up question asks something along the lines of, "If yes, will you ever consume drugs again?"
The jack-ass decided to answer "I won't not do them again..." We fired him a few days later.
With these sort of things, it's better to tell the truth and get fired than to lie, and wonder if you're going to get prosecuted somewhere down the line for lying to a federal agent. Jobs aren't so rare; you should think twice before lying.
Edit: Yes, it is better to work at a car wash than to get convicted for lying to federal agents. Don't believe me? Ask any federal prisoner if they'd be willing to work at a car wash in exchange for their freedom.
Are those questions about illegal drugs or all drugs? Can you answer you don't take drugs when you smoke or drink alcohol? What if you have Marijuana in a country where it is legal? What about alcohol in a country where it is not? Is the trouble for the government that you are willing to go against the law, or that yoj could be under influence?
"In the last seven (7) years, have you illegally used any drugs or controlled substances? Use of a drug or
controlled substance includes injecting, snorting, inhaling, swallowing, experimenting with or otherwise
consuming any drug or controlled substance.
[...]
In the last seven (7) years have you intentionally engaged in the misuse of prescription drugs, regardless of
whether or not the drugs were prescribed for you or someone else?
[...]
In the last seven (7) years has your use of alcohol had a negative impact on your work performance, your professional or personal relationships, your finances, or resulted in intervention by law enforcement/public
safety personnel?"
It's a questionnaire to get a security clearance in the US. Pretty sure it's only from a US perspective and you'd be disqualified if you lived abroad where these concerns would make any sense.
I agree. One of the most amazing things about watching this project unfold is just how quickly it went from 0 to 100 with minimal overhead. It's amazing to watch companies and individuals push the boundaries of what is possible with just the push of a button.
