Joe

Indeed. Additional context will influence the response, and not always in predictable ways… which can be both interesting and frustrating.

The important thing is for users to have sufficient control, so they can counter (or explore) such weirdness themselves.

Education is key, and there’s no shortage of articles and guides for new users.

Bio and memory are optional in ChatGPT though. Not so in others?

The age guessing aspect will be interesting, as that is likely to be non-optional.

The LLMs aren’t being assholes, though - they’re just spewing statistical likelihoods. While I do find the example disturbing (and I could imagine some deliberate bias in training), I suspect one could mimic it with different examples with a little effort - there are many ways to make an LLM look stupid. It might also be tripping some safety mechanism somehow. More work to be done, and it’s useful to highlight these cases.

I bet if the example bio and question were both in russian, we’d see a different response.

But as a general rule: Avoid giving LLMs irrelevant context.

I agree. What you get with chatbots is the ability to iterate on ideas & statements first without spreading undue confusion. If you can’t clearly explain an idea to a chatbot, you might not be ready to explain it to a person.

They rolled this update out mid-journey, and I had to scramble to swap seats with the manequin driver. Not cool, Elon.

Not. Cool.

You will need more than a month to figure out what its good for and what not, and to learn how to effectively utilize it as a tool.

If can properly state a problem, outline the approach I want, and can break it down into testable stages, it can be an accelerator. If not, it’s often slop.

The most valuable time is up front design and planning, and learning how to express it. Next up is the ability to quickly make judgement calls, and to backtrack without getting bogged down.

There is plenty of consumer hardware that is supported on Linux, or will be as soon as a kernel developer gets their hands on it, reverse engineers the protocol if necessary, and adds support. For things like keyboards, there are often proprietary extensions (eg. for built-in displays, macros, etc.). It pays to check for Linux support before buying hardware though. Sometimes it’s not the kernel drivers, but supporting software (eg. Steam input) that might not support it.

First class vendor support for Linux is more common for niche/premium hardware designed in the west, than cheap chinese knockoffs that follow it. Long term customer support is not their strong suit.

Sure… but why would el cheapo hardware want/need to support proprietary drivers? Now, for premium hardware and software, they might still want vendor lock-in mechanisms… So unless you absolutely have to, you should avoid hardware on Linux that needs proprietary drivers.

My theory is that he is a quarter german. He can probably only pronounce the voiced ‘th’ too.

That’s capitalism for you. But also Linux, where it’s typical to upstream hardware support and rely on existing ecosystems rather than release addon drivers or niche supporting apps.

China has made some strategic investments in Linux over the years though – often domestically targeted, like Red Flag Linux, and drivers for chinese hardware, etc.

Don’t bet on it. Senior devs tend to know there is complexity and pitfalls over time, and hope that by using library X (or following pattern Y) they can future proof the product. So instead of writing 50 lines of self-contained code + tests, some people will happily write 60 lines of integration code + tests, and pull in a dozen dependencies.

However: With appropriate interfaces and a little forethought, you can start with the simple solution and extend it or complement it with libraries or needed abstractions down the road if and when the need arises.

Another bug-bear of mine is being asked to review/run over-engineered one-off programs (eg. simple ETL scripts). I remember replacing about 1000 lines of java (many years ago) with a 20 line python script, and passive-aggressively asking the senior developer to review the new script.

One of the interesting use-cases for LLMs is to find potential inconsistencies (across many sources), brainstorm abuse vectors & potential legal challenges, and then rewrite natural (including legal) language in a less ambiguous way. If this process were guided and vetted by talented lawmakers, it could be quite a useful tool, and is probably already used that way in many quarters.

The current executive will almost certainly abuse it and come up with hilariously bad proposals, vetted only by a marketing team, which will be ridiculed for years to come. Popcorn time.

Removed by mod

Removed by mod

Removed by mod

Removed by mod

Removed by mod

Removed by mod

Removed by mod

Removed by mod