rthrfrd

Thanks for the feedback - I'll do that!

Sure, I think your characterisation of "people who are always bored are boring people" is much more credible! Thanks for the thoughts - I must return to doing the boring things I need to do today that I'm avoiding :)

Ok, imagine the original assertion was “All square numbers are even”.

I only need to introduce a specific example/constraint to disprove the original assertion: 1

My introduction of the example/constraint is directly relevant to disproving the original point. That is the whole point of introducing it, so it is absolutely not orthogonal.

If you then remove my constraint (1) and say: “but 4 and 16 can both be square numbers”: Sure you're not wrong, but that also has nothing to do with why I introduced my example in the first place, nor does it invalidate my example, and is thus completely orthogonal to proving/disproving the original point.

> I don't think you've dispelled the original assertion at all.

I did though. Otherwise what you're saying is that you've never known someone whose imagination and appetite for experiences was not constrained by their wealth. You've never know someone who had to endure boredom doing boring things in order to have a shot at doing the things that did interest them. That would be quite the luxurious and unencumbered circle to inhabit.

> Your assertion that 'wealth does matter' is as orthogonal to the original as 'wealth doesn't matter'

Re-removing the constraint from my example to make an orthogonal point has nothing to do with why I introduced it in the first place to disprove the original point - that's not really how the logic works.

> and there are plenty of examples in favour of each position

Yes and I only need one to disprove the original assertion. Thankfully I don't have only one - there are literally millions (billions?) of non-boring people who have been in that situation.

All you're saying is that your imagination and appetite for experiences should not exceed the means already available to you. Sounds unimaginative and boring to me.

What if I said the interesting person is the one that will tolerate being bored doing something boring, in order to be able to do the thing that satisfies their imagination and appetite for interesting experiences? Like you were forced to at school? Unfortunately many people are trapped being bored doing boring things as a means to an end for much longer than just childhood: That doesn't make them boring.

"People can be boring or not regardless of wealth" is orthogonal to the original assertion of "Only boring people get bored": I raised the incredibly common situation where wealth does matter that dispels the original assertion. I don't disagree with your assertion.

Which completely fails to account for the fact that a boring person with great means may use those means to avoid boredom, while an imaginative person with little means may be trapped in boredom because they are forced to use their time to meet basic, boring needs.

So it's a shallow and naive statement that ignores externalities either way.

China’s competitive advantage is cheap labour brought about by poor workers rights and a low quality of life. Innovation has nothing to do with it. It is hilarious that you think European economies want to compete with that. The tariffs eliminate the exploitation that China can leverage that European manufacturers cannot. They are actually levelling the playing field in this market - you know - making it more competitive through innovation (the thing you apparently like) vs maximising exploitation of the workforce.

I see YC as doing what every successful mature business does, which is come to rely on its experience and market position (it’s hard to disrupt yourself), which for better or worse creates habits, which in YC’s case means very coarse investment heuristics. As an outsider they seem very obvious. I’ll omit how that relates to my own experiences and biases (I’ve only ever made one half-baked on-the-deadline application so I don’t think they are relevant). Just my 2c as a long-time follower.

I think it would be awesome to see YC break at least some of itself off into some more elite and disruptive units (where elite refers to the quality of the intake and YC expertise, not the founder education history).

Very sad to hear. We’ll certainly miss having his perspective to ground us in this era of AI hyperbole, as thousands of engineers start confronting the ambiguities of consciousness with incongruent mental frameworks.

Fair, I post it as a starting point to establish ones own interpretation of self-awareness, so as not to wade into the philosophical rabbit hole of bringing my own definition.

The reason I think it can be useful as that, is because I see competency and comprehension as requiring 2 very different levels of "self".

I find Daniel Dennett's framing of competency vs comprehension a good place to start. He did a nice talk at the RI on it some time ago[1]. A previous one overlaps with similar ground[2].

[1] https://www.youtube.com/watch?v=TTFoJQSd48c [2] https://www.youtube.com/watch?v=AZX6awZq5Z0

I think it's useful to distinguish between self-awareness as mutable or immutable. In which sense I agree that both your server and this LLM have an immutable self-awareness which is indeed not very interesting.

I'll only start taking any talk of self-awareness seriously once online learning is happening.

> Ironically, this is evolution in action. The folks that "remember" how to have a family and raise kids have an uncontested claim to the future. The "it's too hard to have kids" crew is selecting against themselves, evolutionary speaking. That won't last.

You're only thinking about the "nature" part of "nature & nurture" though. Playing genetic pot-luck with your partner isn't the only way to have a legacy.

For example, think about all the spare time and energy that a non-child-rearing adult has to shape the cultural & technological future, and the impact that might have on the critical "nurture" element of your own child's life.

I believe I recently built something to do exactly what you're describing for HTML, though it's C++ (but maybe a useful basis for a rust version - I don't know).

https://github.com/rthrfrd/webxx

> Please familiarize yourself with the definitions of market efficiency and market equilibrium.

Yes I did that once during my economics degree. It’s a bastard science and can be debated no end, but those debates are a lot more valuable when the participants actually explain any of their conjectures.

But I sense you are more in it for the argument than to help either of us learn.

Thank you for articulating this. This is not just about monetary policy, but structural failures and regulatory capture that are creating unprecedented opportunities for rent-seeking.

Personally I also believe that the pandemic only accelerated this, as smaller players were disproportionately disadvantaged in many key markets where economies of scale dominate.

Innovation gives you a valuable competitive advantage - that doesn’t mean it lasts forever - that’s why companies have to constantly develop to stay competitive.

Or, they gain enough power to create a failed market, in which it is practically impossible for new entrants to compete and eliminate the incumbent’s rent-seeking. This is what we so often see now, particular in markets with strong economies of scale.

An “efficient market” does not mean it is at its optimal efficiency all the time, but that there is an efficient equilibrium it is capable of tending towards.

We can when we prescribe different meaning to the words we use, which is easy to do when we suddenly have many people grappling with complex and subjective concepts that AI is entangled with. Unfortunately this use and abuse of language derails many of these LLM discussions away from the fundamental philosophy or technology. Ironic really.

I’m curious as to what “higher order emergent behaviours” you believe you are observing? Thanks.

Viewing your child as an optimisation problem centred around your subjective view of good and bad could be all the trauma you need to inflict. Of course that's anything but a new pattern, parenting is training and training is optimising. However wielding extensive tracking & data to make your imprinting even more precise & targeted would certainly - for me - eliminate the joy of seeing someone grow into someone I admire, possibly in ways I never expected.

Roxhill | London, UK | Senior Engineer | Onsite | Full-time

We help the PR industry explore, analyse, monitor and engage the media. We've been growing successfully for 3 years now and need talented engineers to help realise our ambitious roadmap. The product is feature-rich and data-driven, so the work we undertake is varied and challenging. We place particular emphasis on efficiency, maintainability and scalability.

We're looking for both frontend and backend engineers - more information here:

- Senior PHP7 engineer: https://roxhillmedia.com/jobs/senior-php-engineer/

- Senior JS/frontend engineer: https://roxhillmedia.com/jobs/senior-front-end-engineer/

I run the technology side of things so do get in touch with me directly at alex.carver at roxhillmedia.com.

Stack: AWS / Docker / MySQL / Elasticsearch / Redis / DynamoDB / PHP7 / Symfony / Vue2 / ...

Some more background: https://hired.com/company/roxhill-media-ltd

In the case of ES the short answer is; we don't. We have fault tolerance in our replication system to guarantee eventual consistency instead. I would say using ES as a consistent source of data isn't really playing to its strengths so we don't use it that way. The consistency you want is determined at read time: If you need consistency then hit MySQL, but for our use case that almost never happens as eventual consistency is usually instantaneous enough.

Our other tool is to decouple lookup (which objects to fetch) and population (what data to return for each object). You can mix and match, e.g. do a lookup against an inconsistent ES but still get consistent objects by populating from MySQL (or vice versa). As others have alluded to it depends entirely on the requirements for the result set.

FWIW we went through a very similar process to that documented here by Github (~3 months ago). It was entirely due to operational reasons and nothing to with shortcomings in Redis itself. MySQL was the master record for 99% of our data while Redis was the master record for the other 1% (as it happens it was also a kind of activity stream). Having the single 'master' reference for our data reduced complexity to a degree that it was worth running a less computationally-efficient setup. We also have nowhere near Github's volume so we did not have to do such significant re-architecting to make unification possible.

Now we still use Redis for reading the activity streams and as LRU cache for all sorts of data, but it is populated like all of our specialised slave-read systems (elasticsearch, etc) by replicating from the MySQL log.

Hope that helps!

Roxhill Media | London, UK | PHP Developer | Onsite

We combine analysis of live media sources - from national papers to twitter - with a comprehensive graph of journalists, figures, organisations and topics, to provide valuable insight to our users in the world of PR. Since launching last November we now count many of the world's largest financial institutions and consultancies amongst our happy paying customers. We distinguish ourselves by the quality of our product, our agility, and our use of cutting-edge, thoughtfully applied technology.

We need developers to design & build a mixture of REST APIs and microservices - backed by an exciting mixture of tools, technologies and data - to deliver our ever-expanding and improving product. While not an Ops role, you'll also be involved in the day-to-day maintenance and deployment of the product, and the fully-containerised infrastructure it runs on.

You should have commercial experience in:

- PHP 5.3+ (or similar) for several years. - Using an MVC framework. - Designing and implementing a RESTful API. - Integrating with other services and data stores. - Implementing best practices on all levels, from syntax to structure and architecture. - Scaling up. - Planning for failure and learning from it.

Bonus points if you’ve worked with any of these which we use extensively:

Elasticsearch; Redis; Big MySQL tables; Docker; DynamoDB (or other distributed KV stores); MapReduce; Continuous Integration; Queues (asynchronous, event-based architectures).

You can reach me directly at alex.carver(at)everlution.com