>Does anyone know if this is any issue for non-vpn users of datapacket.com?
Probably not that much worse than other VPS providers with trashed IP reputations, eg. digital ocean, vultr, ovh. If you're blocking bots, the first thing to block is any datacenter ip ranges, not just known VPN servers.
DHH tends to build things for himself first, then share it with the world (sometimes free, sometimes paid) to see if others find value in it too.
Most of those things never become broadly adopted, which is clear from the long list of products 37signals has shut down over the years: Breeze, Writeboard, Backpack, Sortfolio, and others.
But every once in a while, there’s a huge success … like Rails, Basecamp, Hey, and apparently now Omarchy.
I honestly don’t think it’s much more complicated than that. He enjoys building things he personally wants. And when he sees others getting joy from what he built, he gets excited and doubles down.
It's also important to separate "commercial availability" into "commercially available in the US" and "commercially available for everyone else"
The US petroleum and automotive industries are spending many multiple millions of $$s to make sure the latest battery and electric car technology is not available inside the US.
This is a good example:
BYD Seal 08 debuts with Blade Battery 2.0: 1,000 km range, 5-min charging, 684 hp
This is a car in production in China now, which has 640 miles of range on one charge (not many gas cars have that range) and charges 10-70% in 5 minutes. Of course, the chargers that perform that high speed charge are also not available in the US.
With regard to quantum: let's just not drag that into a discussion of batteries.
The merchant typically uses stripe or adyen or whatever (mollie has a cute name!), a payment service provider or PSP.
The PSP looks at what methods the merchant wants to accept, which methods the user could potentially be using (based on e.g. country by geo IP or some delivery location) and show the relevant icons.
EU users will see schemes like wero or Przelewy24, Japanese customers will see 'konbini' among the icons, and US users may only see credit cards, Apple Pay and Affirm. There are TONS of payment services. Stripe lists 123 of them.
The merchant will want to exclude methods that have high costs (for themselves), maybe they also care about their customers not getting into debt (so no buy-now-pay-later or credit), and some payment methods have higher rates of disputes/chargebacks (e.g. Amex).
In general, most merchants will want to offer as many methods as possible to prevent consumers who have a preference (this week) for using account A over account B from bouncing.
Yes at the pay page there's a 'pay by X' list of options, you choose it.
You then typically have two choices: scan QR with your phone or login to your bank.
I normally open my bank app on my phone which signs in via my face (iPhone), I then press the scan button (first screen), point at my phone at the screen to read the QR code, the transaction pops up on my phone, I press confirm and again it signs via my face. Then you're done.
If you were shopping on the phone it's even simpler of course as the pay button opens up the transaction in your bank app right away, but typically I shop on my laptop after research.
I've had this for almost 20 years by the way in the Netherlands, but now it's pivoted to the EU standard.
Go to store, select "pay by Wero". Get redirected to payment screen where I select my bank. My bank just shows a QR code that I scan with my bank app, authenticate the usual way, redirect back to store, job done.
A "Pay with PIX" button is just a QR code. You reach the payment page, the merchant website generates a QR code, you open up your bank app, scan the QR code, confirm the merchant and the purchase, the merchant website runs a spinner for like 10 seconds while it confirms it in the background, and then you get a confirmation of your purchase with an order number.
> This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.
I'm saying you don't even need Mythos to find bugs in OpenBSD. GPT 5.5 is SO much better than humans at finding these things.
The fact that we don't even need Mythos, or $20k (I just pay $24/month and this was one of my MANY uses), to find bugs in OpenBSD shatters the dream that there exists any human who can write C properly with enough expertise, dedication, and time.
As I mentioned in the post, I only did a brief exploration of OpenBSD in order to cheer myself up. I took some findings, confirmed them being true bugs, and ended there.
As I said in the out of bounds null termination write patch, I don't believe it's exploitable. I would have gotten a CVE, website, and logo then (kidding!). But it was UB. And one-byte overflows have in the past been exploitable by better sploit authors than me.
In any case, I reported that since I felt it was clear that OpenBSD folks would obviously care about it, exploitable or not.
Confirming these findings take time, even though I found GPT to almost always be correct. I will NOT report upstream until I understand the bug. I ain't no slop reporter. As I said in the post OpenBSD (and all other code bases) need a larger effort. The Mythos/Glasswing effort focusing on actually exploitable ones may be a good method for getting them fixed, without overwhelming projects with patches, even when the patches are correct.
I did confirm at least one more UB, and did consider whether to report that OpenBSD `find` reads `status` via `WIFEXITED(status)` without checking `waitpid()` for errors. This is UB since `status` is uninitialized.
(https://github.com/openbsd/src/blob/ae684bfaed6cae797cd90e27...)
The reason is my previous experience with OpenBSD where the reply may be "<some standard> is wrong in this regard", and because they control their whole system, they don't care. E.g. in this case they may go "we build with GCC x.y.z exactly, and we know what actually happens in this controlled domain". This may be a bit unfair to them, but not by much.
GPT also flagged the extremely surprising behavior of running `cat -n file1 file2` if file1 doesn't end with a newline. And that `find /etc/passwd -execdir[…]` doesn't run the command. But maybe that's how they want it? I don't want to go through the whole thing for them to go "yeah we won't do that" again. So I think this project is for them. GPT is as available to them as it is to me.
Tangent: in running GPT against `cat` I learned that not only is `cat -n` not standardized, but it also behaves COMPLETELY differently than on Linux, if you provide more than one file.
It's certainly not the right platform. It'd be one thing if they had any official communication on the matter anywhere else. Maybe they're ashamed and are trying to limit the visibility while only technically issuing an announcement.
They announced this exclusively on X.com, which ranks barely above Pinterest in terms of usage. That's below Reddit, Snapchat, WeChat, and Instagram, and requires a user account to view profiles and posts. And that's ignoring all the reasons X is a divisive platform with an extreme political bent.
GitHub chose not to announce this on any other social media either (BlueSky, Facebook, TikTok, YouTube, LinkedIn, or Mastodon, as of this posting, and with no emails sent on the matter.)
Maybe, but I don't use it and nobody I know uses it. It's a very politically divisive platform, and users without an account can't post on there.
There are plenty of reasons not to use X, but that's not what's in contention. X.com was the _only_ platform they shared this information on.
It bears repeating: Github decided not to use email, which every GitHub customer has, and Github chose not to use their sites, and GitHub chose not to use their otherwise active BlueSky.
I’m not on X, so it’s good to know I don’t matter in tech. I always suspected. Since I’m a paying GitHub customer, though, I should probably matter to them. The right forum for GitHub to post this is with their status page, their blog, their website, or an email to all their customers. Using any sort of social media for this kind of thing is either incredibly sloppy or very intentionally quiet. Given that my tiny employer has a better incident communication plan than this, my guess is this an attempt to downplay things.
Maybe we need a cultural shift then, because if one needs to use a platform like X, nowadays owned and operated by fascists, then there's something deeply wrong with the tech world. It'd probably take a lot of effort to do so, but it'd be absolutely worth it.
Besides, even if that wasn't a consideration, only posting the announcement to X is just crazy. As others have said, you'd expect for GitHub to make the announcement on their official website. Any paying client would then just follow that for their announcements.
I just spent a few minutes trying to think of a better place, I can't think of one, there is no professional social network, and linkedin doesn't qualify.
You don't need a professional network. This is a company informing customers about a security issue. It should be on their website. Anyone can subscribe to the RSS feed if they are a customer.
Remember RSS?
There is no need to add a social network element.
It's been pretty common in the past for tech companies to announce outages and quick updates about them on twitter for decades. I'm sure their status page etc will be updated soon, but it's historically been the fastest way to get things out to the wider audience whilst bypassing the "official mail out" review by marketing etc.
I think that was a lot more justifiable when Twitter reliably let logged out users read tweets. X seem to tweak it all the time, or maybe it’s just broken a lot, but sometimes I can’t even load a tweet in a browser that isn’t logged in.
It doesn't show live profile pages to logged out users since a while ago. You get cached summary pages, an age gate error, or sometimes a straight up 404.
Most individual permalinks (.com/username/1234...) don't work without logging in, either, and the official client now uses `/i/` in place of usernames for permalinks(bogus usernames always worked; pkey was the timestamp).
This means an organizationally shared Twitter account for announcements is not a viable concept, at least until Twitter is to be transferred again to whoever would be a better keeper of it.
Even if it's a wingnut dense place, there's good arguments for using a channel independent of your infra in a case like this. You (or Github themselves) don't know if their status page is pwned.
I don't mind them using it as a channel per se (although the userbase isn't what it once was) but it certainly shouldn't be the only channel.
For example: Twitter/X, along with Nitter mirrors like XCancel, are all blocked at the client I'm currently working with so although they can see this discussion, they're excluded from some of the most important details.
(Like many former twitter users, I don't have an X account these days so I'm guessing wouldn't be able to see the full original thread - glad of XCancel, that's for sure.)
So? Is this where your corporate paying clients should find out about an issue of this severity?
Not to mention Twitter is not an open platform anymore! (A) I'm an employee in an organization paying for Github. (B) I don't have a Twitter account. I already have a Github account because of (A). Why should (B) stop/delay me from getting official comms about this?
> I can't imagine they'd spam every account with an email address
It's not "spam" if it is relevant to me, such as security incident disclosures.
Also, as tiffanyh pointed out, what's wrong with Github blog or is that exclusively for marketing fluff now? That would've been appropriate enough, without having to spend Sendgrid credits.
They should send messages directly to their customers as a first step in addition to posting an official article on their site. That’s the minimum. If they haven’t done that then it is hard to defend.
Beyond that, Twitter is the de facto default dissemination vehicle, due to its reach. Even if people are not on Twitter, they are likely to see things from people that are on Twitter.
Probably the best option after sending a mass email when customers need to take action.
The status page is for reliability issues impacting end users & the blog is for in-depth analysis.
I mean if you are going to use AI which was trained on code of statistically mediocre average at the best, have outages and major incidents every few days, why not go wild and start publishing incidents to twitter too? It checks out with the rest of the stuff.
I think the above person was making a commentary about the things Apple chooses not to do. Apple strategy is often to be intentionally last to market, after the dust settles.
The dust settled on these accessibility features years ago. Why would Apple choose not to do these things? Live captions in particular is useful even for those who are not hard of hearing because it lets people watch uncaptioned videos in environments that are too noisy or that need to be quiet.
By "dust settled" I don't mean that the technology "exists" -- but rather that feature development has slowed down and most products have stabilized as feature complete and mature.
The on-device ML models that are being used by Google and Apple are both quite new and in active development.
Many of Apple's most successful products have shipped years or even a decade after their competitors. They have tried using first-mover advantage in the past but typically fail when using that strategy.
They're in active development, but they already worked well at launch in English in 2019, serving enough customers to be very useful. I was using it myself.
Yeah, Apple releases most of their products/features long after competitors have useful products/features of the same type. This really isn't any different.
It's a lock/mutex implementation that puts the blocked thread to sleep, usually via cooperative yielding to the scheduler instead of continuing to perform CAS operations on the lock continuously. Spinlocks have great performance when they're not heavily contended and the locks are held for short periods of time, but if either of those things are true the blocked thread can easily consume an entire CPU core while it's blocked.
My reading on anthropic is that he strongly infers that they're profitable, realizes what he has said and immediately walks it back as explicitly not the case today and reframes it as a guess about some indeterminate point in the future.
> Those are the economics of the industry today, or not today but where we're projecting forward in a year or two.
Does anyone know if this is any issue for non-vpn users of datapacket.com?
https://www.datapacket.com/case-study/nordvpn
reply