Yes, it is messy when you want your MySQL databases to be mission critical in production, e.g. handling a large amount of customer data. Historically MySQL's High Availability architecture has a lot of design and implementation issues because it was an afterthought. Dealing with large amount of critical data means you need it to be performant, reliable and available at the same time, which is hard and requires you to deal with caching, sharding, replication, network issues, zone/resource planning, failovers, leader elections and semi-sync bugs, corrupted logs, manually fixing bad queries that killed the database, data migration, version upgrades, etc. There is a reason why big corps like Google/Meta has dedicated teams of experts (like people who actually wrote the HA features) to maintain their mission critical MySQL deployments.
I wrote an app tracking my location using the latest SwiftUI and SwiftData and the performance is so bad to the point it starts to stall the UI after just a few hundred data points. Apparently the magic of SwiftData + SwiftUI is only useful for making demos and anything beyond a few hundred data points wouldn't work out of the box. Everything is done on the main thread and offloading to non-main thread creates huge headaches and breaks the UI updates. It's almost as if the dev guys at Apple were just trying to hit their WWDC OKRs by releasing something so immature and useless for production. Even just reading/writing data to local, CoreData is two to three orders of magnitude faster than SwiftData in some cases. Their newly released core location APIs for getting location updates are also full of caveats and not useful for production at all. It seems that the teams are just focused on making good-looking Swift code using fancy new language syntax sugars.
Unfortunately it's not gonna work. The GFW periodically disturbs/resets any persistent or large-enough traffic to IPs outside of China and bans them. That's why even if you have the best obfuscation protocol (like setting up your own server outside with truly indistinguishable traffic like a normal HTTPS), you still cannot have stable connections with large traffic. The current reliable ways of evading GFW are using IPs inside China via non-GFW controlled IEPL connections. These are loopholes deliberately left by GFW in order for certain legit use cases to bypass them (like research / big international corps etc.)
Might depend on provider? I have a single endpoint and no such issues. Transferring multiple GBs on some days. I'm using a custom protocol though that's basically udp but with the tcp protocol number in the ip next protocol field. I'm simply ignoring any injected rst packets etc.
Yes, depends on a lot of factors like provider (different telecoms have different network settings/policies), location (GFW is multi-tiered with at least provincial boundaries, certain cities/provinces might have tighter control/policies), time/date (e.g. sensitive periods), etc. But what I'm saying is that traffic analysis is really effective. A single IP with multiple GBs on a day is on the low end and thus probably fine. GFW target potential VPN-like services which have much higher aggregate traffic over a period of time. If you have higher traffic it could trigger IP bans regardless of your custom protocol. I had custom servers setup like yours before and they die mysteriously sometimes so I had to rotate once in a while on new IPs.
I very rarely had outages of half a minute to two or three minutes, and every time I feared it was an ip ban. Wouldn't be too bad though, I have access to most of an /24. I had silly ideas like load balancing across multiple ips, but as a custom protocol is already standing out, I wonder how much louder I could scream "here I am" :)
I'm sure they have monitoring services to detect banned IPs and rotate on new IPs. However, in my experience, the most popular VPN providers are actually not specialized in evading GFW despite what they claim. During sensitive periods of time, most of the them couldn't be connected reliably. Those providers specializing in providing GFW evasion are called 'airports' or 'ladders' in the Chinese community and they use custom non-VPN protocols and tools for their services.
I don't understand why people are just mad about OpenAI for their pioneering work towards AGI as if they are the only one who has skin in this game. OpenAI, Google, NVidia, MS, Meta, almost all the AI researchers who publish meaningful work in top literatures, are pushing the boundaries today and has their fair share of responsibility. They are all in it for something, money, power, control, fame, curiosity, academic recognition, whatever the incentives are. At this rate, it's already a race to the bottom and I don't believe the first place AGI was born would be able to kill it off. AGI is like nukes, it's so powerful that nobody will take the risks seriously until they have it, and nobody is going to stop pursuing it because everyone else is chasing it. If OpenAI slows down, Google will take the lead. If the US slows down, China will take the lead. That's basically the doomed future we are facing in reality.
> At this rate, it's already a race to the bottom and I don't believe the first place AGI was born would be able to kill it off. AGI is like nukes, it's so powerful that nobody will take the risks seriously until they have it, and nobody is going to stop pursuing it because everyone else is chasing it. If OpenAI slows down, Google will take the lead. If the US slows down, China will take the lead. That's basically the doomed future we are facing in reality
Its amazing to me that Oppenheimer became such a box office hit around the same time all the AI / AGI hype really built. There are plenty of parallels between the Manhattan Project, and nuclear weapons in general, and real AI.
Heck, just watch the last 5 minutes of Oppenheimer and tell me there's no lesson there to be learned before going right back to work the next day trying to build artificial general intelligence just because we can.
People are particularly focused on OAI because it’s both the clear leader and the one with a corporate charter that appears to run totally contrary to their actual behavior.
Braun is the only shaver brand that I can confidently get a smooth clean shave without getting rashes or pulled beard. Esp. their series 9 which cuts even curly beard perfectly. This says a lot about their engineering design superiority.
The real reason why we can't easily replicate Twitter/Facebook/Google is because we don't have the distributed storage/caching/logging/data processing/serving/job scheduling/... infrastructures that they have built internally that are designed to provide some level of guaranteed SLAs for the desired scale, performance, reliability and flexibility, not because it is hard to replicate the application logic like posting to timelines. That's also why Threads were built by a small team rather quickly -- they already have the battle-tested infras that can scale.
Any attempt to build a simplified version of the ecosystem will face the same fundamental distributed system tradeoffs like consistency/reliability/flexibility/... For example, one of the simplifications may be mixing storage/serving/ETL workloads on the same node. And the consequence is that without certain level of performance isolation, it could impact the serving latency during expensive ETL workload.
For Rama to be adopted successfully, I think it is important to identify areas where it has the most strengths, and low LOCs might not be the only thing that matters. For example, demonstrating why it is much better/easier than setting up Kafka/Spark and a database and build a Twitter clone on top of that while providing similar/better performance/reliability/extensibility/maintainability/... is a much stronger argument.
Ads suck. But you know what's worse than Ads? Selfish people. If Google, YouTube and everywhere else starts asking you to pay high subscription fees for using their services, are you willing/going to pay? You looked up information for work, for life, for leisure, you spend hours online each day, gorging information and content for free. You even learned valuable things and made money using their services and information. And yet all you have to say is don't bother me while I'm leeching off your free content.
>If Google, YouTube and everywhere else starts asking you to pay high subscription fees for using their services, are you willing/going to pay?
Based on my rudimentary knowledge of microeconomics, it depends on how much they charge.
But bringing economics into it, it does seem strange that the internet is probably the only industry where this form of exchange (ads, producers, consumers) exists.
In any other industry, the producer pays money to ads, the ads get me to the place and I pay the producer.
We already pay these fees ourselves collectively because the advertising costs are incorporated into the price of products.
Plus we now pay an additional tax on top of it to Google et al.
Plus we pay with our attention, and with our data (as someone else already noted).
On top of this all, the near-monopoly of Google is forcing prices for ads up, and there is a vicious cycle where companies need to buy increasingly expensive ads to outcompete each other (or, to stay relevant). Which, of course, the consumer ultimately pays for.
Seems these guys never learn from the Python 2 -> 3 mess. GIL to NoGIL is even worse. Most changes from Python 2 to 3 are syntactic, but GIL to NoGIL could require a complete redesign and rewrite. Either it takes another 10+ years migrating OR nobody with a realistic production codebase with 10k dependencies can turn this No-GIL thing on.
The first sentence already raises a big red flag. "This paper examines the way of thinking and limitations of physicists regarding the phenomenon of superconductivity". Stop these ridiculous presumptuous claims about "limitations of physicists" before the work is actually verified and proven.
Koreans have a mean and antagonistic streak, that's why they're so good at making dramas, but still outrageous opener lol. I wonder if Korean academic culture is different from ours.
