MySQL has advocated for decades spinning up a replica with the upgraded version, waiting for it to catch up to master before promoting it to the new master. You can do the same thing with Postgres.
Exactly, MySQL and PostgreSQL are the same here. Maybe one is a bit faster than the other at doing major version upgrades but the behaviours are quite similar.
Would you rather the company went under after it ran out of money and had to fire everyone instead? Not to mention a quarter of the company was laid off the year before the acquisition.
Year before the MSFT takeover. No idea about their actual financials but they were definitely shedding headcount pre 2020, including kicking people for trying to unionise.
No one said anything about bankruptcy, you seem to have made that up for your "argument" or whatever this is. The company didn't have a viable business model and was running out of cash. MSFT right-sized the team for the project they wanted it to be, rather than the business model the prior company was trying to be.
Apparently you don't understand what bankruptcy means. A company can run out of funds and not be able to meet payroll without declaring bankruptcy, they're different things. But by all means keep talking out of your ass.
Yeah, it's like people are forgetting that the executive team at GitHub was composed of sex pests and people defending said sex pest. Of course they'll call any attempt at unionizing as "damaging" to the company and must be blamed accordingly!
After all the company was in such dire straights that they were acquired for $7.5 billion! Only companies with terrible prospects get acquired, that's just business 102.
The company raised $10M, did two rounds of layoffs totaling a quarter of the company, and was then acquired not long after. Early stage companies like that don't do layoffs unless it's to extend cash runway, but run wild with whatever unfounded fantasy you have about it all.
Uhh, I'd expect the trillion dollar transnational corporation to do right by it's workers rather than rat fucking them to appease corporate do-nothing leeches if I'm being frank.
With smaller companies that can't yield global power. It would be better if cloud, office and OS would be separate. Then you wouldn't get shuffed OneDrive into the OS. It's also better for competition if the playing field is equal and one solution isn't the only one that can deeply integrate. Build APIs or don't do it.
Enemies of democracy don't want to do this because it would require acknowledge that technology companies in the US have been mostly a force of evil rather than good and the idea we should change that makes a small minority of people uncomfortable.
I'm not sure I follow. Fetching the data in one query should almost always be faster and more efficient - the same work is being done regardless, except now you have the additional overhead involved with a second query (network and connection overhead, parsing etc.)
Depends on how the database engine sets up the join. I've seen queries where the join ends up spilling into a temp table and it takes a lot longer to do it that way. IIRC, this can happen especially if you've asked the database engine to sort things.
Same with UNION vs IN. If you union 10 queries for one row each by id, it'll hit the index every time; but if you do it with IN, maybe it decides to do an index scan which takes longer.
You could say well the database engine is broken if client-side join works better than database-side join, and sure it probably is, but given the choice of fix the database engine or do a client-side join, I know which one is feasible in the short term.
Every major database uses nested loop, hash, or sort-merge joins. If the data is small enough to fetch in a second query, I don't see any scenario where it would make a query spill to disk when it otherwise wouldn't have (except those pesky OR's).
Most JOIN issues can be resolved by composing using sub-queries/CTE's to defer a join to a smaller intermediary result, and the only time this generally can't be done is if you need a predicate on the joined table.
> you've asked the database engine to sort things
I've only found this to be true when there's an OR condition where the single query ends up doing a bitmap against every row, in which case a UNION will be faster since it's just appending two already-index-ordered streams.
> Same with UNION vs IN
A union is almost always going to be worse - most query planners cannot optimize across queries in a UNION, so each query is going to have separate ops vs. a single op with the IN. The only case I've seen this be true is for multi-column predicates with an OR clause against a composite index. I just tested the former in both Postgres and MSSQL and the UNION query cost was 2x the IN clause.
> maybe it decides to do an index scan which takes longer
This has not been my experience unless the table statistics are bad.
Or were you doing something shady that was legitimate grounds for Shopify to remove those products? There's a big difference between what you personally think should be appropriate and what laws and compliance requirements consider. It's like the annual HN post about someone that claims Cloudflare shut down their account and eventually it turns out they were clearly doing something against the TOS.
Nope we’re electronic recyclers and work with real certified Apple refurbished sellers across the US. Let me know if you find any Shopify stores selling refurbished MacBooks like we and many other sell on Amazon and eBay legally. Same with generic batteries and chargers.
We ditched Shopify years ago and sell the same things on our Shopify alternative. Host on Railway and haven’t faced issues in more than 5 years, no need for a high risk payment processor either.
Yes, first I built Openship, an order management system, that worked with Shopify. Then it was easy to move off Shopify and build my own alternative. Any e-commerce seller knows all you need is an OMS. I also built a custom storefront so that was easy to migrate.
Are those sellers on Shop.app established? Try launching your own and get back to me. Apple will be on Shopify trying to shut you down immediately. Just like so many websites on the web, it’s hard to make accounts now and that’s the same with e-commerce. Shopify is essentially choosing winners based on who they allow to sell what.
Excepts it comes with a terrible experience that's not sustainable for any serious day-to-day work that doesn't involve constant coffee breaks to wait for some tokens to get generated. No thanks. They don't have to live up to the hype to be useful tools, and for something that costs me annually what I make in a day I'm perfectly happy with the value I'm getting of out of it all (even if someone else is subsidizing it... for now).
> going hundreds of billions of dollars into debt
This forum exists exactly because of these companies.
> Excepts it comes with a terrible experience that's not sustainable for any serious day-to-day work that doesn't involve constant coffee breaks to wait for some tokens to get generated.
I think you may have misinterpreted what I was saying to be a reference to local models? I am not talking about local. You cannot run DeepSeek on consumer hardware, despite a bunch of people conflating "some 30b model trained on DeepSeek outputs == DeepSeek". But businesses can purchase fleets of GPUs capable of serving DeepSeek for an investment measured in millions rather than billions, and offer something 85% as good as Claude to customers while actually profiting on inference with a $20 subscription, without the massive overhead of training frontier models from scratch.
> (even if someone else is subsidizing it... for now)
That they are giving away something they cannot sustain is the literal entire point of my comment.
> they are not governed by multibillion dollar companies
Every tech you mentioned is absolutely governed by multibillion dollar companies. Something like 75-85% of OSS code is contributed by employees doing their day job. Most Linux and Postgres contributions come from those same employees. HTTP and TCP/IP are managed by standard bodies and industry working groups that, you guessed it, are governed by multibillion dollar companies. Red Hat and IBM are responsible for 40-60% of contributions to Qemu.
The way I understood op is that we don't necessarily have to pay to use linux or postgres (when self hosting, for example). But we have to pay to use claude code... which sucks big time (also, open source models are behind private models)
Claude Code isn't OSS, so I fail to see the connection. You're paying for compute, not access to code. I'm personally more than happy to pay for access to that compute.
The usual model for OSS projects is that initially they are written for free. Then an inner circle forms and exploits the second generation of idealists who write entire large features without ever getting the same rights.
Some of the inner circle move to corporations to increase their power and are joined by corporate developers (sometimes their bosses) to take over the project.
A lot of corporate OSS development are entirely unnecessary rewrites or simple things like release management. So I'd put the number of useful code by employees much lower.
But governed, hell yeah, I agree. The corporations crack the whip and oppress real contributors.
This is a nice fantasy, but that's all it is. Most of the code used by corporations is also mostly contributed to by other corporations. Contributions by volunteers is the exception for most of the projects in this context. I also don't think this is a bad thing.
> you have to design to a lowest-common-denominator that balances
Something that's always stuck with me is a bit from the book "Don't Make Me Think" about cost vs. value in attention and complexity, that when you add a feature used by only a small percentage of users you're "taxing" 100% of users for the benefit of a few. That you should optimize for the common path and not edge cases. Over two decades later I still find this an exceedingly difficult challenge to juggle that doesn't just mean hiding advanced features behind extra menus.
Menus, gestures, keyboard shortcuts, advanced versions of the interface locked behind preferences, and fully customizable menus (including user-defined macro buttons). There are a ton of ways to hide the complexity for common users without frustrating power users. The challenge for the designer is the taste/judgement to know which features to show/hide and where (as well as how to organize all the menus logically).
reply