That's nice. But in this particular case the engineer says things that I know for a fact are not in line with DDG's mission statement so even if he speaks off-message he's actually destroying that trust. There is nothing about @yegg's response that strikes me as weasel speak, it is the content that is different and exactly where it matters: privacy first.
I wouldn't be surprised if there were bullshit reasons for explicitly not exposing this information to the user and this was an engineer's way of maliciously complying with that requirement.
>Everything I say on HN reflects my own opinion and not any organizations, which is what my profile states
Sorry, but I agree with dessant. Your profile doesn't disclose your affiliation and nor do your comments. It's absolutely relevant to the discussion, because whether you want to admit it or not (or try your best to act neutral), your day job will have some influence over your opinions on these sort of projects.
You're right that it doesn't change objective facts about the specification, but I think it's misleading to suggest that, in general, external third-party CDNs are first class citizens in the AMP ecosystem when they're not treated the same within search.
Of course it's weaseling. Maybe they disclosed such information on a slightly lesser scale. That passage doesn't say.
They all said stuff about "direct access", without discussing what would and wouldn't qualify as "indirect". They didn't deny doing all kinds of different access that could be called indirect in some way.
Which brings me back to my initial post, despite the (mind you, high level engineer)'s opinion, you should probably stay way clear. Support will just not help you in certain situations, and it's not worth the risk. Was surprised to even see a reply from him, Discord the organization has typically been _very_ clear it's not kosher.
> On the flip side we can't show much benefit from this kind of research.
In many ways GoF seems to bee like a site reliability team's "dynamite monkey Friday" where they try to break things in staging in unpredictable ways... hoping whatever they do to our staging environment doesn't leak to production. Fortunately, our app is not likey to cause bodily harm to anyone and not likely to cause a pandemic.
> Not wanting to support it is a strange argument for not documenting it.
Seriously, no. That happens all the time in all kinds of software environments. Someone adds a crazy hack in a product with an API. Do you add it to the API, even though bits of it may leak visibly into the stuff seen by the customer? Hell no. That's what happened here.
> Andrew has already stated publicly that Zig should not be used in production until v1 due to security vulnerabilities in the standard lib.
Andrew has made the claim a couple years ago that Zig should not be used in production yet. The part about security is not at all part of anything he ever claimed, and is in fact only something that you went crazy about on your own.
While I can understand holding real hard onto your opinion, please don't put words in people's mouths, especially when the person in question does not share your position on the matter at all.
@nupark2 how was my explanation "disingenuous"? I merely exposed the reasons why the C Ruby team decided to use a GIL and are not planning on removing it. It's not because you disagree with the core team conclusion, that it makes my post a "disingenuous justification".
It’s not “I hope they don’t read it”. It’s:
— they say they don’t. — developers who work on it say what they’ve worked on doesn’t. —dispute this conversation being a decade old, no one has reverse engineered the client or network traffic to prove it does afaik.
Honestly, read the original message and consider how you would have replied.
They showed work in a vacuum - demonstrated that dm-crypt has costs over raw device access (I would hope so!) on some unknown hardware, and then asks "does this look right to you?"
Well, yeah, that looks like it looks elsewhere, and by the way, there's a built-in command that also would have told you this.
People whine about technical mailing lists, I think because they don't get the context. Think of them as sort of like water coolers at an office that specializes in whatever the list is about. You get a short slice of expert attention in between doing whatever they actually have to get done.
Throwing a bunch of data on the floor and saying "hey, is this expected?" is not going to work well. Seriously, what were they expecting?
reply