It's not recommended because you can just use the --autosquash flag. No reason to make it the default.
especially since if you are rebasing you may want to rebase your changes from one branch to another (i.e. move to top of main or from on top of one feature to another).
So instead you can just do git rebase --autosquash -i last-good or just git rebase --autosquash and let it squash it down for you.
Understanding git rebase is important. You aren't expected to rebase mainline branches regularly but if your team operates on a merge/patchset workflow and isn't just squashing everything down onto main each PR you need to understand how to rebase your changes.
You do your development and use rebase to organise your code into logical commits/patches that can each be reviewed separately. This way when you do your review in github or on the mailing list or whatever you can review each logical change by going through and reviewing the commits separately (which you can do in github by selecting the commit in the dropdown for the review window).
And of course via email based workflows or "stacked patchset" workflows like what tangled provides then you can get deltas between revisions so that you can see what changed in a given commit between rev 1 and rev 2 so that you don't have to re-review the entire patchset/PR, only the stuff that matters (but still broken up into logical changes).
oh nice is there a tracking issue for this somewhere? I've taken a peek at the issues in the org on github but i didn't see one off the bat (mainly because there's a ton of other SMS related issues that pop up from history)
Tbh I have no idea. I kept up with it on the GrapheneOS discord and I think GOS put out bluesky/mastodon posts about it at one point.
> What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?
Well now I think the last major barrier is cleared (which was E2EE being nonstandard). Currently the on-device infra is very google-oriented but there is support for non-google-jibe RCS but it still requires google, etc to explicitly opt-in apps to get access to the APIs on device.
A big part of this IMHO is google refusing to give up their moat but they may finally get it into AOSP at some point.
If they don't at this point I think the only way it'll happen is if the EU forces their hand (which they hopefully will do).
So the issue with RCS is that google just this last year made the move from their internal implementation of E2EE for RCS to the standard implementation based on MLS (now that the standard impl is actually viable).
They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.
GrapheneOS has a bunch of security hardening to restrict crosstalk between apps and services and the assumptions GOS made and the assumptions Google made about how services and apps should be allowed to interact were disjoint. That mismatch in assumptions broke things for a while. And the lack of clear communication from Google about this change combined with various anti-spam/rate limiting issues (Gmessages kept trying to register not expecting to fail and kept slamming the servers which looked like spam and triggered exponential backoff retries) compounded together to render RCS broken for a few weeks during that migration.
Notably this was also broken for basically every other non-google/non-samsung android provider for a while as well due to how poorly the migration was communicated by google.
Then not long after that was resolved graphene changed how they handled their sandboxing to make it less brittle to google changes and since then there's not been much in the way of issues.
The only issue with RCS since then has been a brief break in RCS (~1-2 days) about a month ago due to what was essentially an update to Google's services putting the graphene sandbox briefly out of sync. This was fixed almost immediately on the alpha release channel and just took ~48 hours to move through the alpha->beta->stable pipeline.
From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.
Kagi nowadays has a feature called "SlopStop" that you can opt into. It's basically a global block list for LLM generated websites, etc that is shared across all users who opt into and anyone can report sites/content to it.
Kagi of course reviews it but generally it's good enough that I don't see much LLM generated content in the results anymore.
fwiw tangled itself is also an appview and they are gradually working on rebuilding it around their new XRPC oriented appview called bobbin.
The appeal of bobbin is it's fully stateless and pretty lightweight. IIRC you can run all the infra to run a proper tangled appview (including bobbin) all on your average lower middle end general purpose cloud instance.
It absolutely is. Mastodon has rate limits and administrators have to manage and adjust them as necessary for their instances.
You probably just don't notice it as a user or as the operator of a small instance which to be fair is exactly the same with atproto. Users rarely notice rate limits and small operators rarely do either. It's the operators of large services that see these limits and have to coordinate with other operators.
The issue with W social is that they have a chronic inability to coordinate or play nice with anyone else in the atproto space. Rate limits aren't a problem if you are a good neighbor and you know your neighbors but frankly they just don't.
It's not that they didn't warn bluesky specifically. It's that they didn't warn relay operators in general. And IIRC they just needed to coordinate with a single relay operator who is reasonably trusted (ex blacksky or eurosky) but they didn't do that either.
The default rate limits are quite reasonable but big launches will blow past them so you gotta coordinate with someone.
And note that the relay federation/gossip agreements are largely manual configuration at the moment. Until someone pushes a proposal for an automated/dynamic topology management algorithm that doesn't get plagued with spam issues it'll stay this way.
The distinction really kinda depends on the situation.
FDEs have been around for a long time in the defense contractor space and Palantir picked up the term, broadening the meaning a decent bit. Then it spread to the rest of the software/tech space.
Historically FDEs in defense are engineers who would literally forward deploy out to other countries where the hardware was being deployed so that they could provide on the ground hardware and software support. They'd either literally be called FDEs, Engineer (forward deployed), field engineer, or some other title that roughly got the meaning across.
You'd deploy some platform and send along an engineer or two and a few technicians. Depending on the platform or the scale of the deployment the engineers would either be normal engineers forward deploying for a few months to a year or so or you'd hire a dedicated FDE for that given deployment/site.
AFAICT it became a lot less common as internet communications got better and you could do practical remote debugging and live video conferencing but you still see FDE roles in the traditional sense from time to time.
But yeah then Palantir and big tech came along and basically rendered it into a glorified consultant and/or systems integrator role.
Yeah definitely but tbh a one-off expense at that scale while unfortunate isn't really lethal.
And tbh if you are performing ops at a scale where that level of expense is present it's nobody's fault but your own if your orchestration is cronjobs on the 58th second of the 59th minute of the last hour of the year.
And at any time scale past the order of seconds, this is a small enough time jump that it's a rounding error in ops expenses.
When a negative leap second is applied it just means that 23:59:59 is skipped. The seconds go 56 57 58 0 1 2 3.
vs a positive leap second where time goes 56 57 58 59 60 0 1 2 3.
So if you are billed by time and it's tracked via a timer then your time is still accurate but if it's tracked by reading your start and end time then your billing will just read an extra second.
Positive leap seconds are harder as they require you to reason about a clock that includes a 60th second but systems view negative leap seconds as if nothing happened for an entire second.
Now there are some cases where this runs into issues. If you have jobs that fire off based on the time then you can get jobs running a second early. Normally this shouldn't be a problem but in some cases this could result in contention of resources.
You could also accidentally trigger watchdogs but any watchdog worth its salt will use a real timer not wall time.
But overall negative leap seconds are way easier as they are still monotonically increasing and don't require downstream systems even understanding the concept of a leap second in the first place.
This is also something where how you interact with the IRS really really depends on your initial interactions.
If the IRS comes to you and says "your taxes are wrong you owe X amount" and you immediately turn around and prepare to fight them then they are going to be merciless with you.
But if they come to you and you turn around and show the auditor your methodology and what you thought you were supposed to be doing, etc and focus on fixing the issue and settling your debt then they are going to hook you up with IRS staff dedicated to helping fix this kind of stuff.
And most importantly they'll connect you with someone who can set up a payment plan out over whatever period of time to pay back what you owe without killing your business or taking your assets.
But again if you get audited and immediately become adversarial then they'll assume you were doing it intentionally and will take anything not bolted down.
-----
The rationale is basically that the IRS staff are mostly there to help you get your taxes in order and ensure that those taxes are paid but as soon as it starts to look like you are intentionally avoiding paying your taxes you get kicked over to the enforcement divisions and eventually the criminal divisions.
So good faith is absolutely something the IRS will honor but that stops the moment it looks like you are trying to hide stuff from them.
That's a leadership failure not a technical failure. If you can't dig your heels in and force time to tidy up technical debt then you need to find someone who can and let them take over as PM.
especially since if you are rebasing you may want to rebase your changes from one branch to another (i.e. move to top of main or from on top of one feature to another).
So instead you can just do git rebase --autosquash -i last-good or just git rebase --autosquash and let it squash it down for you.