Its comically bad how this circus is playing out.
637 karma · joined December 26, 2021
Its comically bad how this circus is playing out.
On the flip side it always surprises me how rabid HN can be about throwing out H1B workers. I am sure some of the people who you may have come across were not deserving of it, but a large amount of them work hard to come here and setup roots. Cancelling visas or deporting them will not get American workers their jobs back. Please spare a moment to consider the pain and anguish it brings to families.
> with clear path to citizenship.
Or no path at all. Tying the citizenship carrot to the visa and letting the employers hold the stick is the worst of all possible outcomes.
> When China formally requested to join the ISS program in 2007, Roscosmos and the European Space Agency (ESA) supported cooperation with China, but the Wolf Amendment, enacted by the United States since 2011, prohibited Chinese participation. That same year, China launched Tiangong-1, gaining rendezvous and docking experience.
10 years later, they had a fully operation space station. Say what you will, the Chinese are efficient once they set their mind to something.
It seems like a deliberate pivot towards creating an AI-era language which make GPU programming as easy as writing Python.
I understand the point about people not wanting to be sysadmins - but surely hosting your Guardian Angel in a AWS data center has its own risks. Imagine how broken you would feel when us-east-1 goes down again.
I think this observation is generally true for the kind of problems the author is working on.
But I would not make the leap to avoid using LLMs for any kind of code writing. LLMs do fantastically well in the 95%+ of the code that engineers spend time on. And for those we should leverage the technology.
It is upto us as engineers to figure out when to stop using LLMs. We are smarter than just dumping logs and half dozen specialized markdown files to a LLM and have it figure out solutions.
We can definitely mould AI agents to think more critically about these things, I dont know how effective it will be in the long term honestly.
Developers and companies who put real care into their product will come out on top. A large part of that is going to be, what not to build - something AI agents will always say yes to.
To be fair, was always the case but its only going to be made more apparent as AI scales out.
I d like to think I have fully recovered from confirmed Lyme diagnosis with Doxycycline for 14 days. I had fever and weakness for a week and lowest HRV reading my Fitbit ever recorded (7ms v 50ms avg).
Interestingly, I have a lot of symptoms like anxiety, sleeplessness, and brain fog even today, but I know for a fact I had it even before Lyme. It had peaked during the COVID times when I sat at my desk working over 10 hours on the regular because there was literally nothing else to do.
So at-least in my case it seems COVID was the trigger and Lyme didn't seem to move the needle much either way.
You start off with everything in Postgres, it makes the most sense. Soon you realize some tables are growing really huge - usually some sort of time-series or log data reaching 10TB+. You can no longer fit it in one node. You can try you luck with some sharding extensions, but they add complexity to upgrades.
In that case it makes total sense to move these large tables off Postgres, and I think Clickhouse is a straight up replacement here. You can still keep your relational heavy tables in Postgres.
Yes it affects you ability to cleanly join data, and guarantee 100% consistency. With some smart application code, and schema design, you can replace parts of Postgres with Clickhouse for the big data problem.
I have seen some better clustering implementations, which give good sense for whats inside the cluster if you click on it.
Generally agree that the stacked individual points are a much better approach on modern hardware.
I d rather donate $1 to 10 different blogs every month, than subscribe to NYT or Atlantic.