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.
DKIM2 and DMARCbis are actually the opposite of this. They are long awaited fixes of brittle and often broken systems that are designed to now make providing secure email easier rather than harder.
They both have fairly clean migration paths and resolve a lot of the annoying edge cases that currently exist with authenticating and verifying email.
NGL I'd argue there's a certain appeal to "use AI to prototype a feature as fast as possible and focus your engineer hours on building a comprehensive testing and fuzzing plan" followed by a "remove and review everything that can be cut without breaking the tests" cleanup pass.
Hot melt ink/solid ink has a laundry list of problems that complicate it.
- A single ink clog can destroy a printhead.
- partial clogs can result in ugly messes with ink smeared all over the pages and the assembly further smearing on later prints.
- the printer has to be calibrated to the specific formulation of solid ink to work properly. A bad ink batch or calibrating to the wrong formulation (or a drift in specs on the formulation) can cause clogs, print head failures, etc.
- solid ink printing massively complicates lamination if that's something you need to do (ex in an office).
Overall it's a far more unforgiving process. You can't really have aftermarket inks like you can with modern inks and even variations in the first party manufacturing process can have catastrophic effects on the print hardware.
It's not literally IPFS but atproto/bluesky is using most of the bones of IPFS (IPLD) to do their entire data propagation and event broadcasting.
And tbh it shouldn't be terribly difficult to extend the existing infra to supporting a full IPFS based system but I don't think anybody has considered it worthwhile yet.
ATproto uses just the bits it immediately needs even if it could probably benefit from the other parts long term (ex for archival relay stream preservation).
> The purpose of signing your emails or commits is to provide a good indicator that it actually came from you, not someone who managed to get access to your email account at the time.
This is true and it's still true in the ATProto ecosystem but in a different context.
It asserts that events and records are authored by your PDS, not by you specifically. Which is certainly closer to the intent of TLS certs.
And technically you can maintain a PDS proxy that can only host, broadcast events, and receive content but that doesn't have any keys or signing capabilities.
Then you can have a local PDS that does your signing and sends signed events and records (basically signed state updates) to the PDS proxy to actually emit to the network. This then allows you to lock your keys behind a hardware key to better lock everything down. Of course there are trade offs to this. If it requires physical auth then it can only work on one device at a time or you have to self host it homelab style at which point it might just make more sense to host the PDS yourself anyways.
There's a project thats working on this very thing but I've not kept up with it and I can't remember what the name of it is. If any ATproto people in the comments knows the name/link feel free to reply under this to enlighten me + everyone else.
Kind of. Your PDS can impersonate you but you can have higher ranked "recovery keys" that can undo/recover all the damage.
Socially whether you can explain off that your PDS acted maliciously or that it was hacked or whatever is a different story but if you keep recovery keys for your DID you can take back control and undo everything your PDS did that you didn't authorise pretty trivially. The UX for it needs to be improved but technically the process is super simple/straight forward.
And those recovery keys provide a mechanism for declaring "hey i didn't do this I was hacked" on top of specific events but nothing for taking advantage of that cryptographic opportunity has been built out yet.
Note that you don't have to have a social account. And there's work on the semi-distant horizon for creating sub-accounts which are independent but all under a common top level account kinda like how GPG conceptualizes subkeys or cryptocurrencies handle derivation keys.
For the current moment though you can just create an atproto account without creating a bluesky account. Tangled for example supports this on their site by creating one for their PDS and you can always move to another PDS in the future.
The over-arching idea isn't that your code is tied to your socials but rather that you can have a bunch of disparate services that you can interlink over a common identity layer and that those services are only loosely tied to the people/orgs hosting them but could be trivially hosted by anyone else.
Users of different appviews are just using a different aggregator/backend in effect. The network is still largely the same but there may be minor moderation or feature differences between appviews.
Users of different PDS would be the closest thing to a mastodon instance and there's thousands of different PDS without much issue. I'm on a "third party PDS" and I've had barely any issues.
I use a "third party" PDS, appview, PLC directory mirror, CDN, and client so 99.9% of my interaction with bluesky and atproto at large is independent of bluesky the corporation.
Despite using a third party "basically everything" my experience is essentially the same as a "default" bluesky user if not better in many ways
It's not really the same thing. If we exclusively tested coronavirus with PCR tests it'd be a lot more similar but the presence of kit tests and "30 minute covid testing" really muddied the water.
And of course Covid tests are primarily mucous membrane based which is going to be inherently harder to evenly test compared to a blood sample where viral load is pretty evenly distributed.
At least for blood based diseases, detecting viral load via PCR testing is to such a sensitivity that if there's essentially any active viruses out and about or any active viral RNA floating around in cells then the tests come back positive.
And with sustained antiviral use testing is less about "do I have it/will I become contagious in the near future" (like coronavirus) and rather "is my antiviral regimen still killing the virus faster than it can wake up from latent genetic material sleeping in DNA".
The former is a timing problem from one shot testing the latter is monitoring a steady state to track that the treatment remains effective and when it ceases being effective there's a lag time between viral load being detectable and sufficient viral load to be meaningfully contagious.
Yeah HSV on its own would be awesome to find a good vaccine for but the insights it would give for vaccinations against the broader human herpes virus family would be massively impactful.
A successful HSV vaccine would also almost certainly lead to a vaccine for epstein-barr, cytomegalovirus, and roseolovirus.
Even ignoring the thousands of connections HSV is suspected to have to other diseases, getting insight towards the other 3 big "uncured" HHVs would be a massive deal.
EBV/mono is a silent but debilitating disease that infects a near majority of the population even in "developed countries" and is all but confirmed as a requirement for developing multiple sclerosis. EBV is also directly connected to a long list of cancers as well.
cytomegalovirus and roseolovirus while less common in the developed world are still far too common and globally are major sources of harm for infants and young children.
Any steps towards effective vaccination against the broader family of HHVs would be monumental.
You are confusing it with HPV (human papillomavirus). Hep B is a very different disease.
The first Hep B vaccine in the US is given to all infants within 24 hours of birth (unless the child is already positive for Hep B or severely underweight). And then the second vaccine a month or so later and the third between ages 6 and 18 months old. Hep B vaccination is one of the most common vaccinations received in the US.
And also as a fun little fact the first Hep B vaccine was given exclusively to gay men for a decent while until it was deemed safe enough for the general population. It was also manufactured from the blood of gay men and needle based drug users.
The Hep B vaccine that came later was recombinant and that one was given to everyone from day 1 and that's the vaccine that's been more or less the main Hep B vaccine in use up to today. Recently there's at least one new one that has been approved but the original recombinant Hep B vaccine is still regularly given.
I really like the approach but it'd certainly be nice to be able to use alternate topologies.
Also it'd be nice if there was an underlying grid plotting the metric/distance function to help conceptualize distance/relationships better when you get to the edges.
That's less because it was Bitcoin and more because the entire effort was a slapdash affair pushed by Bukele in an effort for him and his buddies to profit off the cryptocurrency boom rather than being an inherent knock on cryptocurrency itself.
Also of all the cryptocurrencies Bitcoin is a pretty poor choice since it could be pretty well argued that it has lost the original purpose and devolved into a raw "line go up" financial instrument.
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.