OneDeuxTriSeiGo

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.

Technically it has moved (last year actually) but it just doesn't really look all that different in the day to day.

https://atproto.com/blog/plc-directory-org

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.

That shouldn't be the case?

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 incredibly childish of people on this site that within minutes of you posting people are trying to downvote you for saying "don't say slurs".

NGL I can't imagine casually throwing slurs around having been acceptable on HN 1, 2, or even 5 years ago yet here we are.

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

huh? the only Δt in the article is used correctly.

> With 18× 140 mm of surface, the fans run quietly and the coolant Δt across the rads stays small

It's been years now and that's still little more than a conspiracy theory. I don't think it has much bearing in real world policy discussion.

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.

NGL that phrase reads as an "ESL-ism" where the intended phrasing is "towards AMD moderators/employees/whatever" i.e. "Don't be a dick to the people trying to help/answer questions" not "don't be mean to the company".

Other quirks with their writing style seem to lend support to this being an "ESL-ism" as well.

Relevant blog post: https://dataintellect.com/blog/april-relaunch/

> You can give people whatever terrible medical advice you want, you just can’t claim to be a doctor!

Fun fact this is still practicing medicine without a license. You are just less likely to have someone come after you for it.

If you present yourself in such a way that you could be misconstrued as a medical expert, then if you are practicing medicine, even if you never explicitly claim to be a medical expert you are still practicing medicine.

This is why you see the "This is not to be taken as medical advice"/"I am not a medical professional" verbal condoms all over the place WRT medical discussions. You see the same thing with IANAL for the legal profession as well.

NGL that's pretty much what it is.

On the one side you have white hat hackers and pen-testers who you pay a contract or salary to prod your system. If you really piss them off (i.e. by stiffing them of their pay) some might just steal your data and threaten to leak it unless you pay them.

On the other side are black hat hackers who will drive by your system and if they find a way to break in they'll offer to keep your data private for a ransom fee. And maybe if you have some charisma, decent pay, and/or a good repertoire you might recruit them on/convert them into white hats for your org.

Seriously. Like as much as ChatGPT shouldn't be providing advice on medical topics, it almost certainly will be tricked/coaxed into doing so anyways so instead they should be training it to defer to accessible expert sources/publishers like Erowid instead of attempting to extrapolate advice on its own.

> If someone published a book advising people to take drugs, would people be filing lawsuits? No—we would agree that people are allowed to write whatever they want, even if what they say is terrible, right?

That's not the situation here. The more accurate case would be:

> If someone without a medical license provided blatantly incorrect medical advice with respect to safe medication usage to an individual via a direct one-on-one discussion, would people be filing lawsuits?

And the answer is yes. You can be wrong and you can say incorrect things. What you can't do is provide medical advice unless you are a licensed medical professional. You can still speak about medical topics but you have to disclaim your lack of licensure. You have to make it clear that you are not providing medical advice.

If this was a person doing this it'd be a crime, clear as day. It's called "practicing medicine without a license" and in the US it is a criminal offense in all 50 states, Washington DC, and all 5 inhabited territories. Whether it is a misdemeanor or a felony is dependent on the jurisdiction and the case but it's a crime everywhere in the US.

They could but also why would they?

They can always just hack them again but with a different method this time.

The ransom doesn't bind them from hacking the company multiple times. It just obligates them to destroy the data they collected from this attack.

As a matter of kindness and good business they'll probably wait a few months or a year or so before poking around again but they'll almost certainly continue poking at Instructure's systems.

Data exfil ransom attacks are a business first and foremost. They don't permanently halt or destroy the original infra and their goal is to get a payout for their labor and move on. Maybe the come back around in the future with another, different attack, maybe they don't.

They made their money and made it big in the news as having complied with the ransom payout, no reason to hurt their reputation trying to double dip. Plenty of other soft targets to poke.