S3 is not a CDN.
Check CloudFlare, Akamai, ...
593 karma · joined April 10, 2023
Check CloudFlare, Akamai, ...
Just a nitpick, but what you describe here is byte range requests. They can be used with or without chunked encoding, which is a separate thing.
Would it take off? Would it tank? I believe WordPress is GPL, so I don't see why they couldn't (as long as they could legally fork or counter things like WooCommerce, that is).
It's a bit different from the situation with OpenTofu and similar since WP Engine would only need to keep their existing, highly invested customers to get a good start. The rest is a matter of marketing.
T'will be interesting to see how this ends.
(Note: I'm not saying that there is or is not merit to Mullenweg's or WP Engine's position. I haven't studied the situation enough to have an informed opinion there.)
Coming back "early" would also occur at a cost of either tens of millions of dollars for an extra launch, or at a cost of valuable experiments not getting run because the space station was empty of personnel. NASA policy would prohibit the remaining astronauts from... well, remaining, because they have to have a lifeboat, which the two "rescuees" would have just used to go home. Thus, all of them would have to go home.
IOW, painting this as "normal operations" in any sense is disingenuous. The danger levels may not be overly exacerbated, but it was a very costly failure, and it may well be a drastic inconvenience to the astronauts. We likely won't know the truth of the latter until they write their memoirs.
It's easy to manage spin when the opinions being spun are in orbit on a restricted communication system.
Most users of these sorts of app don't pay enough attention to security to care. Do you really think that most developers are any better?
Most developers are just normal people who happen to be able to write a bit of code and convinced someone to employ them. Just like anyone else, far too many live under the delusion that "it can't happen to me."
Translation: making them eat their own dogfood and risk their own embarrassment won't help; they would have to know better, first! =)
That said, I think this is something a bit different, or at least a different application. If my translation of the summary is correct (I'm not very fluent in sciencese), it's basically using them as some kind of matrix multiplier rather than memory. Whether they're making use of power-off data retention at all was unclear to me, but then I just skimmed it.
Interesting, but I was really hoping for fast, persistent memory to appear.
PostgreSQL's manual indicates that partitioning is a thing[1]. Is the something different than what you're thinking of?
One of my projects has the need to drop millions of rows a month based on the time period, and I've been considering a switch to postgres because they also have a module that will do that automatically.
What am I missing?
[1] https://www.postgresql.org/docs/current/ddl-partitioning.htm...
I'm also not working with super-high-performance production-critical loads, though, so grain of salt and all that.
I don't know anything about K1, so all I have is confusion (and a sudden urge to switch entirely to postgres).
You never truly finish something. If you think you did, you are quickly disabused of that notion. You are lucky to ever feel that sense of pride in completion, and if you do, it is brief.
Pride in a job well done is fleeting, if you are ever allowed to feel it at all.
Yes, I'm a recovering victim of burnout, and no, this was not the only cause, but sometimes I wonder...
That said, I feel like you're asking for something that is fairly non-standard in the industry in general, though I could be wrong; I've never tried to do things that way myself.
If I were fastmail, those tax issues they mention would definitely take precedence over other issues in any event. Writing your own sales tax/VAT/whatever software strikes me as a special kind of hell given all the tax laws that have to be supported (and kept updated!) for every different jurisdiction out there.
For me, being able to pay three years in advance and only have to renew once every three years is fine, and they did offer a workaround for you, but to each their own I suppose.
Eh?
I just purchased a new 12 month Fastmail plan for my business with no issue a few weeks ago.
Up to 36 months is still listed on their pricing page...
Nobody expects to have to turn their video camera sideways to capture in the "correct" orientation... but you must on a phone.
Have home automation? Sorry, you'll have to use the Internet.
I vote with my dollars, so it cost them the higher-margin sale. I also went with the mid-tier system, and grabbed a Z-Wave compatible thermostat along with it. I wonder if I'll miss the nifty variable-speed system?
I really wish everyone would stop trying to trap us into their walled gardens. Apple at least lets people write software for theirs, but the hardware/appliance manufacturers (not to mention the automotive folks) are awful about this.
If you are loyal to your employer and do not own a significant part of the organization, then you should take a good hard look at why you're loyal -- and whether or not your employer is loyal to you in return.
Hint: in most companies, they aren't. It's exceedingly rare.
Base your decisions accordingly.
I will note, however, that there is also more to the story than simply "being disposable." An argument can be made that laying off however many employees also helps to preserve the ongoing livelihood of the employees who remain.
The error is often not in the layoff. It's in over-hiring in the first place. And that changes the "how evil are these people?" equation rather drastically IMO.
Of course, this is just the random off-the-cuff thoughts of someone who is currently far too alcoholated, so YMMV, and--
Look! A boulder of salt!
And on that note, I'm going to bed. Tootles!
Bah. Text boxes in browsers suck, and mine's not cooperating at the moment, so instead of writing another book, I'll just say: thank you for the reasonable response. =)
I don't care if the competing solution would have been git, Perforce, hg, or whatever. The point was not "git". The point was "off the shelf". I also do not dispute that Piper may well be a great system; I've never even seen it, so I wouldn't know.
The issue is not about "outsourcing" (which is a rather loaded term that should not be substituted for "using off the shelf products"). It's not about "engineer productivity", per se. The question is about overall business efficiency.
I'm sure it could make engineers that much more productive to have the latest and greatest laptop every year. That doesn't mean we replace all our hardware every year. We also don't give every developer a terabyte of RAM. It's the same basic issue.
It's always a trade; those dollars can potentially do more good somewhere else.
You'll note that I have at no point stated outright that I thought they made the wrong decision; only that I'm skeptical. I asked the question about the ROI, and people decided to get all heated about it. The only arguably inflammatory point in my comment was about Google's case of NIH.
It's really hard to deny that Google has acute NIH.
Sometimes that's a good thing; they've done some amazing things and given us some amazing technologies. Other times, I question their decisions.
I don't think there's anything wrong with that.
For me it's always "what are we trading?". In an organization the size of Google, it's far easier to amortize away the cost of such a thing. That doesn't mean it's not a cost, though. And there's a lot of tooling around modern SCM that they won't get because they're on a bespoke system, so there's a cost there too.
As you say, at the time the variables may have been very different.
It's just an area where if I had to make that decision (even back then), someone would have had to be exceptionally persuasive to convince me to authorize what is effectively a multi-million dollar project... to recreate source control. =)
I wondered if it would have been cheaper overall to use pre-existing tools and adjust things than to build a whole new product that has nothing to do with your core business, and then have to maintain that product. This is a wholly different argument.
TANSTAAFL right back at you; development and maintenance time is not free either, and there's a potential argument that pivoting their other tooling would also open them up to other off-the-shelf opportunities, though that is much harder to evaluate.
I've worked at scale. I am well aware that sometimes custom is the only way. I've been there and done that, and walked it back when someone finally did something off the shelf that was cheaper to maintain. Custom comes with a cost, and that cost can often be hefty.
Source control... is not usually where you hear the "it should be custom" argument, and even less often is it at all supportable when you look at the big picture.
Google is certainly large enough to have unique requirements, but that alone doesn't justify the choice.
I thought about the larger organizations, and of them I could identify only Microsoft and IBM as other companies who have their own SCM products (though that's probably ignorance; there are probably more ;). The difference with them, though, is in the fact that they sell those products as products, making them part of the core business. Profit center instead of cost center.
Google doesn't do that AFAICT, so all that investment in development and maintenance is nothing more than cost at the bottom line. And not just monetary cost: what else could those developers be doing with their time?
Hence, it really makes me wonder if there's a bunch of developer religion that's costing Google a lot of unnecessary cash. If I were by some strange miracle brought in as a CTO at Google? I'd be wanting some pretty hard facts on that (or a plan to productize it) to justify its continued existence.
If someone tells me that monorepo (or multirepo) is better, I'll respect their opinion even if I disagree with it. If, however, someone tells me that one or the other is the only way, and they must have a custom source control system to prevent things from collapsing like a house of cards?
Yeah, I'm going to call bullshit.
A single senior developer full time @ Google is probably a half million dollar a year investment, give or take. How many do they have maintaining it? How long before that yearly cost exceeds both license fees for an alternate solution and the cost of development and migration?
The answer to that is not obvious.
(edit: response specifically regarding "astronomical" costs)
How repos are organized is a choice. Google could just as easily (financially speaking) have chosen to break up that repo and use more standard tooling. They did not choose that. Did they have (possibly perfectly valid) reasons for that? Sure.
That does not render it as their only possible path.
Rather than switch their source control strategy to something that would work well with existing products, they chose to build a brand new product to support their existing strategy. This is, IMO, not an obviously sane decision from an outside perspective. Why?
Because source control has nothing to do with their core business, and in addition to the cost of developing and deploying that solution, they now have to bear the cost of maintaining it, which is likely not insignificant.
That's how it looks from an outside perspective.
The question I'm asking is not "why didn't they use git?!". The question I'm asking is, "what is the ROI of building and maintaining their own solution versus biting the bullet and pivoting so they can use pre-existing products?"
Haven't seen an answer to that yet. People are too busy implying or outright stating that I'm stupid for asking the question in the first place.
The point is that either product should theoretically have the ability to handle Google's load. They were both built for scale. If I have the timeline correct, they existed at that point. I would expect those organizations to have positively salivated at the possibility of having Google as a customer; they would have bent over backwards to make it support Google's workflows.
The ROI of such a choice vs going custom is the interesting question.
Of course, if I have the timeline wrong, then the discussion is moot.
(edit: the point being that at least one of those tools existed when they started Piper if I have the timeline correct).
I would love to hear the reasoning behind going custom, and if that ended up truly being worth the investment.
Or maybe I'm misremembering the timeline on when certain things became available. shrug
None of the things you mentioned have been even hinted at to my knowledge beyond mere speculation. They also probably won't affect the bottom line much in the long run even if they do happen; some level of unforeseen circumstance mitigation is almost certainly already factored into their business plan. Not to mention the effects of various insurance policies they may or may not have.
Possibility won't move the stock much; probability will. As it stands, it appears that the most likely outcome is that they'll skate, so no movement.
The only other potential to tank it that I see is order cancellations because the aircraft ceases to be viable for the buyers. For most of them, it'll have blown over well before the delivery date anyway, and if it was going to happen, it probably would have by now.
Therefore, nothing to see here... until the next mishap, anyway.
That leaves a lot of time for them to worry about booking new sales before it becomes an issue.
I couldn't find an easy answer to whether or not that's already happened, though (order cancellations out of the norm).