Pup Biru

hard disagree on what belongs in the same commit history… a single merge should be an entire feature, and your commit history should read like a change log

Squashed commits are not atomic … overall task requires modifying multiple different systems

that’s why monorepos exist

i’d say squashed commits aren’t always atomic, but this is one of the biggest reasons people add the complexity of a monorepo: if changes cross multiple systems, ideally their merge/revert should be an atomic operation

you either have deployment complexity (ensuring the feature is in all deployed systems before switching over), code complexity (dealing with the feature only maybe exiting in parts of the system), or repo complexity (where tools manage a monorepo and thus commits and PR/MRs are atomic across your system)

okay but that’s also cats

even then we still need far more batteries. we need them for the grid (though alternate chemistries are looking better for that; cars are trickier in many ways), and even with public transit we still need trucks and vehicles for last-mile transport of goods

perhaps you should unblock specific domains in that case

but i’d also suggest a blocker that uses auto-updated lists rather than whole gTLDs; they’re likely to catch more and deny fewer false positives

either… some apps have just started to do single factor login with just email, profile options can be optional, if there are required fields or terms of service to agree to then that can come after email validation

i think these days the best practice for mobile apps re retention (other than sso or passkey) is to just ask for an email, then from the validate link continue with register

reason being that more steps to register means more ways people are likely to drop out of the flow, and this is basically about as short as it can be

when the user has validated their email, then they’re more invested so they are more likely to complete

that also fits nicely with what we’re talking about with good security

that was certainly in the back of my head the whole time… policy flip flop and lack of long term planning in modern politics is pretty much the norm anyway… but i think to encode that into a kind of standard way of operating is perhaps not a good thing… adding an extra layer that’s hard to undo before fixing the core problem is how the US got to where it is now

as an aussie that has a parliamentary system, and in that system has had a period where we frequently ousted the PM, it’s not that great of an idea

you want governments to be able to plan for the long term. really, even 4y is not great for long term planning because it kinda implies you need to show results before the term is up

we had a bunch of policy flip-flops during that period, which is very inefficient

i guess it doesn’t really matter if you get 2y no matter what: there’s no more after your 2y, but i think that’d lead to leaders doing a bunch of the “fuck it” last term stuff because they have no reason to make a good impression for their potential reelection

the old logo still exists. this is a new mascot intended to increase user connection to the browser by providing a friendly anthropomorphised front for actions taken by the firefox team, browser, and congratulating users on taking actions. in furtherance of this idea, kit is represented by ambiguous pronouns when written about in order to avoid unnecessary gendering, and allow the user to imply their own gender as they like

that line is from the branding guidelines for kit

whilst it is legitimate, it misrepresents the purpose of both kit and branding guidelines: kit is a feature meant to invoke feelings; not a character having made a decision about its gender

we don’t care about the kits genders but mozilla cares about it being ambiguous because kit is a character meant to increase feelings of personal connection with the user by being able to be interpreted however the user likes (female, male, or non-binary)

in both the intro blog post and the branding guidelines mozilla does bring up the new (complimentary; not replacement) mascots pronouns as explicitly non-binary

the firefox is explicitly (in the case of mozilla firefox) neither fox nor red panda

https://brand.mozilla.com/d/5UkPdpbtt8LS/visual-elements#/-/mascot-1

Our mascot is a Firefox — not a fox, not a red panda. It’s not a real-life animal, it’s Firefox’s own unique creature.

it even: the original source of the non-binary claim is an anti-woke blog post about them removing the old mascot and replacing it with a non-binary mascot, when in fact mozilla had a logo rather than full expression of a mascot, and now they’re a fully formed branding representation of the firefox which includes non-gendered pronouns (as a feature of the characters function; not as an explicit choice about gender representation)

but that was again not about removing the dino as much as as it was about differentiating mozilla from firefox by taking the mozilla identity from firefox because mozilla is more than firefox and behaves differently to firefox, and giving firefox its own identity which is more friendly

they do make explicit mention of non-gendered pronouns in their branding guidelines for kit. the intro blog post is an expression of those guidelines

but every announcement by mozilla makes it clear that kit isn’t about taking a stance on gender: it’s simply explicitly about not taking a stance on gender

it’s not even that… kit doesn’t have a gender identity: kit expresses ambiguity in gender so that the user can decide for themselves no matter who the user is. kit is a feature; not a character having made a decision about their gender… and their non-gendered pronouns are simply part of that feature

but it’s not a PR move… their blog post lays out the reasoning: kit is intended to exist in the browser to make users feel good about using the browser. it’s a friendly “congratulations for interacting” and “we’re doing something for your benefit” (as an anthropomorphic representation of that behaviour) character, and a feature of it as an engineered feature is that the user can apply any gender they like. kit hasn’t made a choice to be non-binary; mozilla has made a choice to make kit specifically ambiguous both in aesthetic when drawn and pronouns when written about

that’s exactly it: in context, kit is a feature intended to be interpreted by the user; not a representation of a sentient character having made a conscious choice to be non-binary simply because of mozilla’s chosen pronouns and lack of gender expression