No one is ever going back and reading individual commits
I do, regularly! In a repository where care has been taken, it can be super valuable when tracking down a bug or regression, and understanding the intent of the author
HN user
[ my public key: https://keybase.io/jimhealy; my proof: https://keybase.io/jimhealy/sigs/paeLbB80W8_zwEM29yfvmJui43a1wgOJvspWMN1VfJo ]
No one is ever going back and reading individual commits
I do, regularly! In a repository where care has been taken, it can be super valuable when tracking down a bug or regression, and understanding the intent of the author
The article is wrong, the PDF spec has introduced breaking changes plenty of times. It’s done slowly and conservatively though, particularly now that the format is an ISO spec.
The PDF format is versioned, and in the past new versions have introduced things like new types of encryption. It’s quite probable that a v1.7 compliant PDF won’t open on a reader app written when v1.3 was the latest standard.
Viewable without logging in to x though, and shareable on fediverse
Via fediverse, for those not on x: https://bird.makeup/users/penpizzareport/statuses/2007347706...
interesting idea, good on them for trying something different in the Ruby ecosystem.
The website is quite extensive, but the gem only has ~1.5k downloads. It’s presumably very early on the adoption curve
At a previous employer we did this with our docs repo.
The public docs site was managed and deployed via a private GitHub repository, and we had a public GitHub repo that mirrored it.
The link between them was an action on the private repo that pushed each new man commit to the mirror. Customer PRs on the public mirror would be merged into the private repo, auto synced to the mirror, and GH would mark the public PR as merged when it noticed the PR commits were all on main.
It was a bit of a headache, but worked well enough once stag involved in docs built up some workflow conventions. The driver for the setup was the docs writers want the option to develop pre-release docs discretely, but customer contributions were also valued.
Since 2024 you can disable the root credentials on all accounts except the Organization management account: https://aws.amazon.com/blogs/aws/centrally-managing-root-acc...
I don't think the post mortem details whether the root access was on the org management account or an org member account.
Not really a new vulnerability, and yet Notion just shipped it this week. All caution thrown to the wind in the name of an announce-able AI feature
I live in Melbourne (on Jemena’s distribution network) and this isn’t my experience.
Our power is very reliable and rarely goes out. Every few years a car hits a pole or something and we get a brief period of quiet time
Related content: Corey Quinn on the AWS GenAI obsession
If you’re still looking for an alternative, https://dnsimple.com is an excellent engineer focused no bullshit domain registrar and they support .co.za
Implicit or explicit, I’m OK with the global namespace.
On paper it’s awkward, but in reality convention and social norms make it rarely an issue.
The global namespace only supporting exactly one version of each gem encourages a health culture of stable ABIs and deprecation periods too. An absolute dream compared to some language ecosystems
I've never used aurora serverless v1, so I'd somehow never heard of the RDS data API before this.
It seems like it'd be useful in some cases, particularly because connection pooling to postgres is managed for you.
Is anyone using it production workloads? How have you found it?
Bummer that it can only query the writer and not readers.
I'm not the author but I work at the same company.
None of our systems require perfect ordering of IDs generated across our distributed system. Most of the system was built with random UUIDv4 identifiers so no code assumes the ID ordering is significant.
However, in much of our system recent data is frequently accessed while old data is rarely accessed. In that world, just having the IDs *approximately* clustered in creation order has been a huge performance boost for many queries, and we've seen significant reduction in postgres Write Ahead Log rates, because writes to UID indexes happen in a smaller number of pages.
I'm not the author, but I work at the same company. ULIDs are nice, but we're a 10 year old company with many TBs of data across multiple logical databases and most rows had UUIDv4 ids.
Maybe if we were starting from scratch ULIDs would have been an option, but given where we were UUIDv7 was a much easier transition.
That would be super useful, but is it possible? Would it depend on cable markings?
pgredis - A server that talks the redis protocol to clients, and stores all data in a postgres database.
No regrets, I learnt a lot and had fun messing with it for a while.
GitHub should insist on it being converted to a GitHub App before they allow it to be re-enabled.
That way org admins can see the requested permissions and control exactly which repos are permitted. GitHub OAuth apps are an absolute nightmare to audit or control.
It happened to us too.
There's no JVM (or log4j) in our environment, but we received this notification listing 6 instance IDs as having done DNS lookups to suspect domains.
No trace of those instance IDs in our account over the past few weeks, and after following up with a ticket we were told they're actually the instance IDs that sit underneath some fargate tasks (no info on what tasks or ECS service of course, because that would be sensible).
We've rechecked the bits of our stack that run on Fargate and confirmed there's definitely no JVM, so we figure it must be a false positive. Maybe DNS lookups to customer controlled hostnames (which we support as part of a feature, and sandbox carefully).
The Australian Bureau of Meteorology has pitched building one: https://www.zdnet.com/article/bom-floats-idea-of-antarctic-s...
Not quite. The volunteers involved in the process are working on it, but there's probably still some hours to go.
Some progress updates are being posted to twitter: https://twitter.com/debian
The author seems to be developing the draft on GitHub and there's a few edits since the v01 version linked here
When I was a kid in the early 90s our family car caught fire while parked in the driveway and turned off.
It'd been parked for an hour or two, and the trigger was something electrical in the engine cavity.
I'm an old timer and would probably convert, but I get this at https://pinboard.in/convert:
nothing to see here
https://www.washingtonpost.com/technology/2020/10/09/coinbas...
Cryptocurrency start-up Coinbase recently sought to restrict political speech by employees, a move many interpreted as a shift to the right because it came in reaction to internal discussions of Black Lives Matter.
That makes it sound like the Coinbase thing is less about the company holding a public political position, and more of a "leave your politics at home" thing.
Sounds like the corporate version of the recurring debate about whether open source projects should reject contributions from those with objectionable political views.
Is this a uniquely Amerian debate? I live outside America, and I don't really understand the subtext of these Coinbase posts.
What does are some concrete examples of a company being political or apolitical? What are the kinds of things the Coinbase used to do and no longer does, which employees might leave over? Is it about the company donating to political compaigns, or openly participating in community debates and having a position on social issues (same sex marriage, abortion, Black Lives Matter, Trump, gun control, etc)?
This is neat.
I'd love an NTP sync'd wall clock but my time for hardware hacking is pretty limited. Are there any off the shelf wall clocks that do NTP? Bonus points for POE and no WiFi.
A similar anecdote from my family.
My uncle (a sheep farmer) and I discovered that:
1. I was afraid to touch anything in a car engine, but happy to muddle through unfamiliar computer issues
2. He was afraid to click unknown buttons on a computer screen, but comfortable pulling apart and rebuilding an unfamiliar car engine.
In both cases, we were confident because we knew whatever mistake we made we'd be able to reverse it. And in both cases, we were afraid of making a mistake that we couldn't reverse.