crazy5sheep

The whole point is that LLMs, especially the attention mechanism in transformers, have already paved the road to AGI. The main gap is the training data and its quality. Humans have generations of distilled knowledge — books, language, culture passed down over centuries. And on top of that we have the physical world — we watched birds fly, saw apples drop, touched hot things. Maybe we should train the base model with physical world data first, and then fine tune with the distilled knowledge.

The 1905 thought experiment actually cuts both ways. Did humans "invent" the airplane? We watched birds fly for thousands of years — that's training data. The Wright brothers didn't conjure flight from pure reasoning, they synthesized patterns from nature, prior failed attempts, and physics they'd absorbed. Show me any human invention and I'll show you the training data behind it.

Take the wheel. Even that wasn't invented from nothing — rolling logs, round stones, the shape of the sun. The "invention" was recognizing a pattern already present in the physical world and abstracting it. Still training data, just physical and sensory rather than textual.

And that's actually the most honest critique of current LLMs — not that they're architecturally incapable, but that they're missing a data modality. Humans have embodied training data. You don't just read about gravity, you've felt it your whole life. You don't just know fire is hot, you've been near one. That physical grounding gives human cognition a richness that pure text can't fully capture — yet.

Einstein is the same story. He stood on Faraday, Maxwell, Lorentz, and Riemann. General Relativity was an extraordinary synthesis — not a creation from void. If that's the bar for "real" intelligence, most humans don't clear it either. The uncomfortable truth is that human cognition and LLMs aren't categorically different. Everything you've ever "thought" comes from what you've seen, heard, and experienced. That's training data. The brain is a pattern-recognition and synthesis machine, and the attention mechanism in transformers is arguably our best computational model of how associative reasoning actually works.

So the question isn't whether LLMs can invent from nothing — nothing does that, not even us.

Are there still gaps? Sure. Data quality, training methods, physical grounding — these are real problems. But they're engineering problems, not fundamental walls. And we're already moving in that direction — robots learning from physical interaction, multimodal models connecting vision and language, reinforcement learning from real-world feedback. The brain didn't get smart because it has some magic ingredient. It got smart because it had millions of years of rich, embodied, high-stakes training data. We're just earlier in that journey with AI. The foundation is already there — AGI isn't a question of if anymore, it's a question of execution.

Apple is too greedy, it's a joke to have 256GB as a storage option nowadays

We left product development teams without anyone focused on production. We undid everything that made DevOps work in the first place.

Very good point, that's the same I have observed for the past couple of years when working on a devops team. Product team engineers nowadays feels like spoiled kids, they had no current how server runs, and asked for things unreasonable. I still remembered someone came to my desk and asked for me to increase the mem request to 10s of GB, he claimed that's the best solution he could think of is to load everything in mem.. and very often people don't even know what status code means 500, 502, 503, 504...

It really just a state machine

I thought it was just my asus router broken today, and I was about to buy a new one.

An interface with many methods is already a bad design. limiting it to a handful methods is way easier to maintain. it's fine to return an object has implement many interfaces, but you really don't need to use them all on the input side.

A 2D to 3D migration?

Use standing desk, and take good care of your neck.

Oh, this brought back a lot of good memory in Yahoo. This thing was originally called YTS, it has a very flexible plugin system, the caching functionality was pretty good and easy to use at the time.

Same here, I was inspired a lot by this post all these years. I really want to take this chance to say than you to Peter.

however, it's an easy and achievable investment.

There's once I was running some jruby stuff in jenkins during a build, the job kept on hanging on some stage, I thought there must be bug somewhere, I forced kill it a couple of times with no success, but kept the last one running before I head home. Then after a couple of hours, I found out an email said the built was passed... eventually, I had figured out that jruby was using /dev/random, since jenkins was running in vm, so no enough entropy was generated. after force mounting /dev/random to urandom, the hanging issue just disappeared.

Why did you kick the ball to the author, Google is on the monopoly side being too powerful and not caring. The author just voiced his concern but not a solution, what Google needs to do is to listen and come up a plan.

Developing with docker is not necessary a micro service, it's just a way of packaging, distributing and deploying your application in a clean way. And docker is not a virtual machine, there's not much overhead, you don't need kubernetes if it's just a simple app, but you can just take advantage of managed service like ECS, you get auto scaling right away, and you don't have manage your node and deal with the stupid thing like systemD

Prometheus is great, the main problem is the bloat of metrics it's collecting. one really needs to carefully define the rules to scrape, compute, reduce and filter the ones that are not needed and the ones that need to precompute.

without generic support, Go couldn't even provide things as simple as a Max(...) function for all kinds of numbers in their standard library.

That's exactly what I have been done for years.

I have create a git repo specified for the question, with some code working in way, but buggy, such as logical bugs or race conditions...etc. with a lot of not business relevant assumptions. I usually told the candidate what this code supposed to do, and ask him to review the code first, then tell me what was his impression on the code base, and what were the problems, and how he can fix it. By doing this, I can judge the candidate if they are good at general coding, debugging and and comfortable to work on projects which they are new to, as well as their mindset on writing maintainable software. A good candidate will not just fixing the obvious issue, but propose some architectural changes, then I will ask them what are the strategy to do so as the project has existing dependents, this can give me signal on how the candidate coordinate with other teams. Then I will ask him some more questions related new features, and scaling..etc. to measure his design, communication skills and more.

It never failed me for senior level positions hiring, that either the candidates were hired and proven to be a great match, or they got a better offer elsewhere.

heart rate related?

If country B does nothing, it would be pure stupidity. The US was already late on taking actions.

I was in Guangdong when SARS happened in 2003, I have heard rumors for months until the Chinese gov eventually admitted there's such virus exists. Ever since then I basically have zero trust in the Chinese gov. For this time, since Chinese new year is coming, I had actually warned my coworkers do not go back to China, especially Wuhan, a couple days back. So bad not everyone listen, now they are kind of scared.

Either you didn't switch jobs often, or didn't want to spend time on interview preparing sites like leetcode.

I don't agree the issues OP later discovered has anything related to `refactoring` itself, but more a issue of premature optimization.

my 2 cents, an interface is defined, it shall not be modified for no good reason. Even if you do, you can still have some way to make sure it can be compatible with the original system. and I don't believe you can't extract some common behaviors of those repeated code, and use them within the interface, refactoring doesn't mean you have to rewrite the whole project, it can be done by piece by piece. reducing a line of duplicated code can save you a lot of efforts on maintaining the project in its life-cycle. a lot of times, I have seen a code change was made to fix some bugs were forgotten in other place which duplicated the same original code.

China or not, most of the jobs won't come back, they were eliminated by automation. The bottom line of the so called UBI is the redistribution of wealth. It's not only for individuals, but regions too. I somewhat image that the money you give to individuals is able to encourage them to move to regions where there are less jobs, but lower living cost. meanwhile, the newly moved in individuals are able to revive the region, creating new local business and jobs...etc.

how can one imagine at a higher level, it will just magically get better then?

And the Chinese govt can also have a thousand different ways other than law to harass foreign-owned companies. that said these law means nothing to real business in long-run, but just a response which attempts to fool the US govt for stopping the trade war.

But you can not store anything in your session ID. JWT can carry a small amount of data that's need by my service. I only need to validate JWT and check if it's been invalidated. Then I can go ahead to perform by business logic. I don't want to hit db to get all these data. Yes you can argue why not just store them in redis too, but with JWT I only need One bit.

Really, why ppl keep saying JWT cannot be invalid? isn't it simple enough to use a redis bitmap to store the info? each token only takes one bit, how many tokens you can have, 1 Billion? 120MB is more than enough. What you save here is the time and resource you hit the database.

This is the reality, don't expect every code base is clean and well organized. I have come across the same situation for a couple of times in my career. I felt disappointed at the beginning, I wondered how high-paid engineers could write such shitty code, but quickly I found it's actually a very challenging job. To understand the code base was like playing puzzle games with debugging tools. I had invented tools with some new stuff I just learnt to trace and visualized the program, or wrote scripts to clean up the code. Eventually I became the owner of these projects, and refactor the hell out of it.

It's a known issue that latest version of Mac OS has problem to connect to external 4k monitors. I did not experience kernel panics, but lagging on display, high memory and cpu usage on the windowserver daemon.