pwdisswordfishs

Yeesh. What a bunch of babies.

(All of this—and these people—are supposed to be cool?)

Trademarks and domain names are separate matters.

It would be interesting to see a clone under a totally different name (like "Operation Bluebird" here) but still use a twitter.tld domain.

AFAIK, to date Twitter hasn't required its users agree to a copyright assignment or an exclusive license to the content of their tweets, so it wouldn't be a copyright suit. Twitter wouldn't have standing to bring suit, as that would be reserved for the actual copyright holders, i.e. Twitter's userbase.

So computer science actually involves science now.

> Google signaled their wholesale abandonment of the Chromebook platform

When?

> Bloated file sizes due to javascript libraries for lazy loading data.

Use of JS, including the NPM-backed bloat you see in libraries used on the modern web, is orthogonal to whether a site is on a static host or not—which is what "static website" actually refers to.

For examples, see: a bunch (most?) of the stuff hosted on GitHub Pages.

> Nowadays every page you see is always using fancy technologies and "modern" UI that looks like unicorn barf.

... says the person responsible for authoring/publishing a post exhibiting some of the worst decisions I've seen for styling a Web page all week.

> There's plenty of people who occasionally need to create barcodes

> hopefully that [1MB] will be served from a cache

Aside from obfuscating the source code to sell licenses, how does this benefit from WASM?

Barcodes have been generated for decades on low-resource embedded devices. Even what would have been a modest-to-low-end machine 25 years ago would have no problem handling the compute needed for this job.

On this end, it just looks like the user has to deal with the penalty of dealing with 1 MB of resources when hitting the main page.

> I use change detection to monitor all sorts of websites for changes. Some of my favorite authors don't have RSS.

Have you considered offering, as penitence, a public feed to share the information that this process produces?

> it no longer works in every app because services insist on writing their own players that don't work as well as the player provided by Apple TV

So much for those oft-touted benefits of Apple's policy on gatekeeping third-party apps so it allows them to enforce quality standards.

> it just is an overlay for pirate streaming sites

Not "just". You left out its role as a bot network exit node.

For server implementations that aren't braindead, that is indeed the important bit. Computers don't inherently know how to run PHP. If the request handler doesn't look at the file extension to decide whether or not to pass the contents to the PHP interpreter (if PHP is even installed on the system), then image.php isn't going to run any PHP.

> I find that most datepickers are better than the browser's

You mean your browser's. There is no "the browser".

> the code itself makes it harder for people to contribute, especially those, like me, who don't use coding agents.

> Where are the interface boundaries? Why are there methods that are 200 lines long?

LLM-backed code assistants have brought to languages that have been historically less "toolable" the same downsides that IDEs brought to e.g. Java.

Expectation: nominally, an IDE would do one thing, which is to make it faster and easier to do what you would have done without the IDE.

The reality: IDEs make their programmer slightly more productive and other programmers not using IDEs much less productive; instead of "producing programs, faster", what IDEs do is produce programmers who produce programs that aren't especially work-withable (e.g. navigable) without tooling.

DHH, of course.

> it feels like this is much more a UX/social problem

It's not merely "like" that. That's what it is.

"Wiki" comes from the Hawaiian work for "quick". You spot an error, you click the button to change it, and the change is made. That's wiki.

"Open a pull request and get it approved" is not wiki. It's what the default collaboration model was before wikis and exactly why the wiki was invented (to replace it).

If the contributor instructions for your wiki requires:

1. forking the repo

2. committing the changes

3. submitting a pull request

... then you don't have a wiki.

I've gotten those taps on the shoulder. Every time I went for it, I ended up thinking, "Geez. What was I expecting to be good about this? This experience is awful."

> This wouldn't be an issue if patches were XML or JSON

Or MIME, even.

Solution: don't use mobile bank apps.

"Trivial" doesn't exclusively mean "easy", though it is often used as a euphemism like that.

In a literal sense, it very well may have been trivial, even if neither you nor the professor would have been able to easily show it.

Subjectively, it seems like it's even prudent to consider that someone who is involved in a discussion about whether or not they're suicidal is probably likelier than average to commit suicide. Fair chance that "I'm not suicidal" should really even be understood to mean, "I'm not suicidal right now".

Mozilla also isn't exactly strapped for cash. They pull in around half a billion dollars per year (to accomplish what could be done on a budget a tenth that size).

There are very good reasons why you 501(c)(3) doesn't allow setting up a non-profit that accept "donations" that benefit one of the non-profit's wholly owned for-profit subsidiaries.

You probably could have just dropped a line at the end saying that all of the links in the post so readers are advised 2 plz click so you can get credit.

Bunny.net purports to have a pay-as-you-go prepaid credit system that sounds like it works the way people want, and with their description of the way it works probably being sufficient to be legally enforceable if it turns out that it actually works differently and you were to end up with a surprise bill from them. And evidently it really does work that way; see this post from a couple weeks ago: <https://news.ycombinator.com/item?id=47676416>

The only other provider known to work that way is NearlyFreeSpeech.NET, which serves a completely different market segment (so much so that it might as well not even be considered the same kind of product/service).

> The same principle applies, though.

How?

"Firebase AI Logic"

Is this a Firebase service or not?

Google Maps is not Firebase.

And "Firebase AI Logic" sure sounds like something easy to confuse with a Firebase service...

There's a brand-new, Gemini-specific feature for that (as new as March 23), but historically the answer has tended to be "no" from all the cloud providers. Most giants and indies alike have always been strongly opposed to implementing this feature for business reasons. (When you run across something that does let you do things that way, it's one of a handful of exceptions.) Their response is to tell you to set up budget alerts, which is not a solution, as described in this post.

<https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...>

It's "implied" throughout the whole post (or more like assumed that the reader understands this, because it's the basic premise of the problem). It's why they link to a post that explains the basic concept after a remark that "This describes our issue in more detail".

> tl;dr Google spent over a decade telling developers that Google API keys (like those used in Maps, Firebase, etc.) are not secrets. But that's no longer true: Gemini accepts the same keys to access your private data. We scanned millions of websites and found nearly 3,000 Google API keys, originally deployed for public services like Google Maps, that now also authenticate to Gemini even though they were never intended for it. With a valid key, an attacker can access uploaded files, cached data, and charge LLM-usage to your account. Even Google themselves had old public API keys, which they thought were non-sensitive, that we could use to access Google’s internal Gemini.

From Google themselves, in the Firebase docs:

> API keys for Firebase services are not secret. Firebase uses API keys only to identify your app's Firebase project to Firebase services, and not to control access to database or Cloud Storage data, which is done using Firebase Security Rules. For this reason, you do not need to treat API keys for Firebase services as secrets, and you can safely embed them in client code.

<https://firebase.google.com/support/guides/security-checklis...>

... or at least that's what it used to say, until they quietly updated the docs to say this:

> API keys for Firebase services are not secret. API keys for Firebase services only identify your Firebase project and app to those services. Authorization is handled through Google Cloud IAM permissions, Firebase Security Rules, and Firebase App Check.

> All Firebase-provisioned API keys are automatically restricted to Firebase-related APIs. If your app's setup follows the guidelines in this page, then API keys restricted to Firebase services do not need to be treated as secrets, and it's safe to include them in your code or configuration files.

Followed later by (in different section):

> Use your Firebase-provisioned API keys only for Firebase-related APIs. If your app uses any other APIs (for example, the Places API for Maps or the Gemini Developer API), use a separate API key and restrict it to the applicable API.