> I wanted to give an update on GitHub’s availability in light of two recent incidents.
[Emphasis mine]
Vlad, you are living in a very different world to me.
GitHub has suffered dozens and dozens of outages since the beginning of the year. It is notably less available and reliable than it was even as recently as last year. People have created dashboards and heatmaps showing how bad GitHub has become. At least one of those has made it to the front page of Hacker News. In fact its unreliability and persistent availability issues have become a frequent topic of conversation across sites and communities frequented its users - of which HN and Reddit are two obvious examples. At this point GitHub's unreliability risks becoming a meme, if it hasn't already done so.
The only thing your post makes clear is that your priorities ARE NOT clear.
> Our priorities are clear: availability first, then capacity, then new features.
WRONG!
Your priorities are:
1. Availability
2. Availability
3. Availability
You have NO OTHER PRIORITIES.
If you want other priorities, focus on AVAILABILITY for 6 months and then come back and we can all have a serious conversation about something else.
In the meantime, you need to understand that GitHub's reliability over months and months - not just in April - has been completely unacceptable.
I've recently built a script that periodically (every 25 minutes) fetches the latest merged PRs to check for some potential rule violations. I'm not an admin and couldn't get the events API working, so I just resorted to polling.
On an average ~8 hour working day, there's at least one failed request. In fact, looking over the logs, I can't spot a single day that did not have a failed request.
Now, I can't guarantee that these are all caused by GitHub (as opposed to my connection), but it is pretty funny.
I would credit my relative success (compared with many complaints I’ve read) at building software using AI as a helper to the fact that I’ve already solved the problem in my mind before I prompt the AI, and I tell it how I want the problem to be solved. Generally it’s possible to do that in English much more tersely than it is in code.
So what I’ve done is the hard (in the sense of problem difficulty) work and simply got the AI to do all the typing for me because I just can’t be arsed any more. The typing isn’t the hard part of software development: just the part that, historically, has taken up a massive chunk of my time in the domains I’ve worked it.
I’m not saying this works for everyone in every situation but, as far as I’m concerned, bring it on.
>Generally it’s possible to do that in English much more tersely than it is in code.
I really doubt this is the case for any decent amount of complexity. English is ambiguous. Programming languages exist because we don't want this ambiguity from natural languages. A sufficiently descriptive spec written in English is barely indistinguishable from just code. We've come full circle.
A lot of the value of these domains stems from the popularity of sites they may have been attached to in the past, or search terms that relate to them.
So these people are literally making money off of the back of others’ work whilst providing no benefit themselves, probably not that much even to their advertisers.
Such squatting sites are, at best, an annoyance to web users as well.
You could dual license as well, so it’s GPL or AGPL for personal, OSS, or academic use, but requires a paid for commercial license for commercial use.
I suggest GPL or AGPL because their copyleft clauses make them hostile towards platform providers who might otherwise seek to profit from your work without paying.
Yeah, but the copyleft makes anything they build around it a derivative work that they also have to release sources for - especially with AGPL. Most don’t want to do that because that’s where their IP lives.
Not all open source licenses are copyleft licenses (e.g., MIT very much isn’t), but at the very least copyleft licenses make it much harder to exploit open source code commercially without giving back in some way, whether that’s code, or cash for a commercial license.
Not perfect, by any means, but definitely an improvement over more permissive licenses.
I am aware of how much I’m starting to sound a bit like RMS in my old age.
I wholeheartedly agree. Licensing is a complex topic of which I've read a good deal, and even within the Open Source communities there are usually a lot of misconceptions, so I like chiming in with less commonly pointed but very practical effects of it all, in case it helps someone to learn a tiny bit that day.
In this case the provider would of course have to comply with the AGPL and release their modifications as you mention, but it's important to note that No FOSS license protects at all against, for example, just offering the code as a service. It's the exact reason why Mongodb changed licenses and then a stream of commercial products started to change into "Source-Available" licenses in the recent past.
It would be dual license effectively... the base version AGPL and the Commercial version with additional functionality. Though I'd considered BSL and alternatives... and as mentioned, just closed/commercial only.
I believe use of Electron is known as premature deoptimisation and if it had been a thing when Knuth coined the original phrase I'm sure he would have come up with that term too. Use of Electron to deliver software is popular and works but that doesn't make it any less of an abomination.
I'm actually considering, for the first time since 2013/14 when I worked on a Visual Studio extension, creating a piece of desktop software - and a piece of cross-platform desktop software at that. Given that Microsoft's desktop story has descended into a chaotic mishmash of somewhat conflicting stories, and given it will be a cold day in hell before I choose Electron as the solution to any problem I might have, most likely I will roll with Qt + Rust, or at least Qt + something.
20-odd years ago I might have opted for Java + Swing because I'd done a lot of it and, in fairness to Swing, it's not a bad UI toolkit and widget set. These days I simply prefer the svelte footprint and lower resource reuqirements of a native binary - ideally statically linked too, but I'll live with the dynamic linking Qt's licensing necessitates.
That's a good idea because, although I love this, 1 minute per token is absolutely savage. Whereas if you can juice the performance you're into semi-credible Jar Jar Binks simulator territory.
It does also make me wonder what you could do with somewhat more powerful retro hardware. I'd love to see what a transformer running on a PSX or an N64 could do.
I don't know if I'd go so far as to call it "manchild" territory: hobbies are fine, and if your hobby is DIY mechanical keyboards, more power to you.
Where I start to break out the scepticism is when people start talking about how much more productive they are because of their fancy keyboard, or how important exactly the right keyboard is to productivity.
That's mostly nonsense.
I've got valuable work done in a whole variety of more and less ideal/noisy/comfortable/uncomfortable environments on a 13 inch laptop using its built-in keyboard.
The primary driver that makes you productive or non-productive is your motivation. If you want to get it done you'll get it done. To a very large extent, everything else is incremental. Multiple monitors, fancy keyboard, cool mouse, ergonomic chair, whatever. They're nice, and they do help a bit. But, fundamentally, what really gets things over the line is desire, motivation.
Whereas a lot of this work adjacent stuff is a form of procrastination.
I've gone through a similar experience with musical instruments and studio gear, versus actual music creation. At some point you just have to stop tinkering and start making music, and what I've realised is that the only item I have available to me at almost all times to do that is my laptop, so maybe I should focus on working in the box instead of on acquiring more hardware.
I have to disagree. It isn't nonsense that a good keyboard feels good, and something that feels good makes someone more productive by inspiring them.
What is nonsense is that everyone cares. For some people it won't make any difference. It also won't make any difference in the quality of work (except in the case the keyboard is broken) when you force yourself to work.
If a good keyboard gets your over the hump and working then it isn't procrastination.
Computer Shopper in the UK was a lot like that back in the 80s and 90s: just a massive wedge of a magazine where the vast majority of pages were ads.
The classified/small ads section alone was enormous. And then you’d have companies that sold computer components include huge swathes of their catalogues and price lists in multi-page adverts. Would have been a real boon for system builders, but I didn’t have the cash back then. I was still in the world of 8-bit micros and 16-bit machines.
Sure, but 80 -> 28,000 -> 54,000 is a hell of a lot of slippage.
Trading platforms can guarantee a maximum slippage on stops, and often even offer guaranteed stops (with an attached premium), so I don’t see why Google and Firebase can’t do similar.
Yep. And cloud providers could eat any slippage cost (enforcing, say, every 5 minutes by stopping service) without even a rounding error on their balance sheets.
The fact that they don’t indicates that there’s no market reason to support small spenders who get mad about runaway overages, not that it’s technically or financially hard to do so.
> Trading platforms can guarantee a maximum slippage on stops
Yeah no, physically impossible. If nobody is selling at that price, there is no guarantee your sell stop will execute near that price. They can sweep the market, find the best seller price and execute.
There might be a costly way to do it with microservices as I indicated, but your example easily falls apart.
They can take the other side of your other themselves, lose money sometimes, but make it up in the premium they charged you in the first place (or in the old days, from your other trading fees or your monthly subscription payment).
Cloud providers would be taking way less risk interacting with their own services than a broker does interacting with the market. Perhaps they would be more at risk from bad actors, but it shouldn't be significant: they could reserve this behaviour for people who have already spent, say, $100 with them so you can't abuse it at scale.
If they are a market maker, they can buy/sell at or near your stop. It might be a bad idea for them, but if they have a guarantee, this is how they will do it. Or, it will be like the Amazon guarantee (refunding free shipping on your late order).
Not impossible to do: they can hedge and/or absorb the cost, hence the premium. They usually also specify a (fairly large) minimum distance for such stops.
That's exactly what I proposed in my response. Big corp can waiver the extra costs to match your limit. Glad we finally got to that part of my response. The question is: will they? Probably not. Do brokers do it? I haven't seen any. Maybe you know more.
[Emphasis mine]
Vlad, you are living in a very different world to me.
GitHub has suffered dozens and dozens of outages since the beginning of the year. It is notably less available and reliable than it was even as recently as last year. People have created dashboards and heatmaps showing how bad GitHub has become. At least one of those has made it to the front page of Hacker News. In fact its unreliability and persistent availability issues have become a frequent topic of conversation across sites and communities frequented its users - of which HN and Reddit are two obvious examples. At this point GitHub's unreliability risks becoming a meme, if it hasn't already done so.
The only thing your post makes clear is that your priorities ARE NOT clear.
> Our priorities are clear: availability first, then capacity, then new features.
WRONG!
Your priorities are:
1. Availability 2. Availability 3. Availability
You have NO OTHER PRIORITIES.
If you want other priorities, focus on AVAILABILITY for 6 months and then come back and we can all have a serious conversation about something else.
In the meantime, you need to understand that GitHub's reliability over months and months - not just in April - has been completely unacceptable.
Focus on fixing that and on nothing else.
reply