ezst

Could it be that you vastly overgeneralize? While there's no perfect education system, many are much better than the nightmare you describe.

You can probably keep this kind of unconstructive comments to yourself. Even if this was a place to discuss one's beliefs, nobody was attacking yours to begin with.

there might be several gaps before that, even. From the top of my head:

- text description to 3D geometry gap: you can't easily describe complex geometry in a language that's common and convenient to both humans and machines

- 3D geometry to physical model gap: material , geometrical constraints induced by manufacturing (machines, tools, costs, …)

- physical model to model fit for simulation gap: meshing, constraints, stress modelling, …

- simulation outcome to fitness assessment gap: now you have a high-dimensional and numerically heavy simulation to weigh against a non-rigorously defined acceptance criteria

- simulation outcome to geometry profiling gap: how do you even start to guide the LLM into the vast space of possible changes to apply to the 3D geometry and reboot that loop?

LLMs don't strike me as a particularly relevant technique to apply here, to be honest.

Are you familiar with the problem space at all?

> Claude has been trained on high school physics textbooks, yo

The very fact that physics textbooks have little bearing in the real world is the whole damn reason why Mechanical Engineering exists as a separate discipline, yo

> It’s a problem of the human setting up the description of the problem in such a way that the model can operate.

It's a problem of defining the initial state (which is the trivial part that OpenSCAD may be a contributing element of), defining constraints and variables (what is allowed to be changed and not, for what can, in which ways, to what extent, i.e. what is the library of allowed material, fastening, machining, assembling techniques available to your very specific situation), defining evaluation and fitting criteria.

I see very little adequacy of general purpose LLMs in that

> the same way that ML has been used to produce optimal rocket engine nozzles and fuel transfer systems.

Which has nothing to do with "just use Claude, yo"

And then do what? Do you have any evidence that Claud would do anything relevant with those?

A LLM may produce OpenSCAD compliant syntax, I don't doubt that, but how do you make it produce designs that fit engineering constraints? How do you even express those to a LLM? How do you validate those? How do you iterate upon them?

The domain of ML-driven design optimization isn't exactly new, is quite specific, and I would need convincing that Claude has anything to contribute to it.

How would you even get Claude involved in that? This isn't your git repo that a language model can scrape for textual content.

Not OP, but LLMs didn't exactly invent the kind of content that's not worthy of your time, they merely turned it into a commodity (and made everyone have to work much harder figuring which is which).

This thread made me curious about remarkable, what would you say is a good summary or entry point to the whole remarkable hacking scene?

Following the handwritten comments brought me there, which I found to be HN-worthy: https://mzucker.github.io/2016/09/20/noteshrink.html

Also, as a sign of our times, it hyperlinks to what might have been a Microsoft tech page/knowledge base in the past, now completely replaced by poor taste LLM advertising slop. Good work, Microsoft.

Matrix attitude towards IRC (and bridge implementation) always felt like a trojan horse. Yes, it brought undeniable quality of life improvements over IRC for those who took the bait, but that didn't have to mean making the native IRC experience more miserable for no good reason. Matrix burnt a bunch of bridges with that attitude.

I would also challenge OP on the relevance of E2EE for very large MUCs: beyond a certain point, the room can't reasonably be considered private. With current (Signal-style, also found in XMPP, Matrix, …) crypto, you are encoding ever message for every user/client joined, which scales as poorly as one can guess, but is still adequate for small groupchats.

MLS stands to rise that threshold (and there's work in progress to include it in XMPP), but that certainly won't address the fact that this is just privacy theater.

and to add to that, XMPP has extremely simple and familiar "WhatsApp"-like clients, so there's really not much of a barrier to entry. Especially if you join by a user sending you an easy-invite link (XEP-0401). All you have to do is pick a username and you are good to go.

Core matrix is still an insanely complex and clunky protocol that's still struggling to stabilize and scale after more than a decade. That's not on spaces , threads or video-chats (which are mostly client-side features).

Doesn't XMPP check all those, and more? I run my local _ejabberd_ for a decade and some, and I'm joined to a couple 100+-users rooms. On my phone, I have a whatsapp-like experience with _Conversations_, that even the least tech-savvy in my circles use happily. On the laptop, I have _Gajim_, which is more "banquet-style" and serves to follow along fast-paced large rooms, most of which happen to be on IRC, but I don't even mind that, thanks to the _biboumi_ bridge which unceremoniously connects me there as if I was a regular IRC client. I also keep an eye on _movim_ which promises a more discord-like experience: it has gamers-style voice/video/screen-sharing rooms, it has spaces (although the paint isn't completely dry on those), and it's working on scaling-up calls to very large rooms by having galene as a SFU.

What I find also amazing in all this is that all the client/server/bridge names I brought up are independent and healthy projects. XMPP is very mature and decentralized. Not just in theory by nature of its protocol, but practically/politically by its many implementations across many stacks and implementers across many countries.

Because the tools are somewhat comparable, you seem to have been tricked into conflating "protectionism" (which has some stabilising virtues, especially in the area of agriculture, arms, heavy industries, resources extraction) and "dumping" (which is an aggressive act). There is also something to be said about the scale of it. And of the validity of a world view where "every trick is allowed, everything is for grabs, and let the biggest be the winner, and the winner take it all".

> Ultimately a win for the consumer, China does not tend to ban technology as a weapon

Doesn't have to, China will just subsidize their businesses, sometimes at a substantial loss, for as long as it takes to bankrupt the international competitors. So yeah, if by that you mean "they end up unemployed and in overall economic pain, but for a short time some stuff was abnormally cheap" then yes, "it's a win for the consumers"

I'm more than aware that my comment won't move the needle on the AI debate a slight bit, but I do think that the readership deserves some honesty and transparency there. No, not a single LLM ever has "deployed SQLite in Production", had to be on duty during the weekend, had to pop open a terminal to a misbehaving service while on family vacation, nor meaningfully suffer the anguish and stress to hotfix a botched or misconfigured deployment. Only humans have. What makes or breaks a software product, costs you your holiday, and perhaps even your job, probably won't be found in some generic piece of common knowledge rehashed and repackaged with some stylistic tweaks. It's the fine details, the one-off things, those weird edge-cases and compounded factors that in hindsights were obvious but had to be learned the hard way, and hopefully, shared by benevolent contributors.

That's the whole reason why many here put the effort to read/post articles and argue over comments: so there's something non-obvious to be learned. LLMs are effectively "knowledge averagers". They will put together a pretty article that's not worth reading, except maybe if the problem space is completely new to you. And that's the kind of disclaimer I would hope to see ahead of anything LLM-produced, and particularly on this website.

Is the last release on GitHub from 2022 or is it me?

I think I'm like you in the sense that I'm a law abiding citizen in what I consider a high trust society. That said, I'm not naive to the fact that "having nothing to hide hence nothing to fear" doesn't cut it: privacy eroding laws are a slippery slope eventually leading to finding yourself on the wrong side of what's deemed acceptable. That, and to the fact that law enforcement association with political extremism has only increased in recent years, as evidenced by the number of reports about bursting neo-nazi groups and such.

Let them start somewhere. Inequality has only accelerated in the past decades, undoing the fabric of the fair and democratic society which many/most people perceive as a condition for long-term stability. If taxing wealth isn't it, then what else do you propose? We seem to agree that taxing income stinks while news like "50 richest families own 50% of the country" abound. Those didn't get there by working a job or being clever/lucky about betting their pension money on some ETF. Only extraordinary measures will make a dent on this extraordinary accumulation.

But then can't the case be made that narrower and stricter-defined use cases are better served by more conventional ML? If/Wherever efficiency is a concern, that is.

You mean, communism?

(/s but you never know especially these days)

Or now that python has ~types, this is really an area where things could be improved. Filtering would just be lambda predicate with fields auto complete as seen in .NET, scala, etc

Amazing resource, indeed, Good job there!

I would really love to try MD: besides the "tactileness" of it, the storage limits imposes to actively curate playlists and make compromises on how much/what music you can carry with you given the circumstances. An iPod classic already has so much storage available that this thought is secondary and you don't have to engage with your music to the same extent.

The tactile experience is a nice throwback in a touchscreen mostly/no physical buttons present, but the display is garbage by modern standards, finding specific tracks sucks, and doing any amount of playlist management is an exercise in frustration. And that is with replacing the firmware with rockbox, which significantly improves on those areas :-)

https://www.rockbox.org/

For what's worth, I only really started using passkeys after committing to bitwarden/vaultwarden as my password manager. I've been skeptical of Google's/Apple's/Microsoft's passkey implementations forcing you into their password managers and seeing them as yet another power play to lock you in their ecosystem.

Passwords+TOTP have that universality going for them that you can always move away to a different password manager/do without one if you ever want. With vaultwarden and that dependency/liability cut off, passkeys have phenomenal UX, especially coupled to a SSO/identity provider like pocketId.

> and the manufacturers are barely surviving

I feel for them because I wouldn't mind paying 2/3 times the price for something of measurably higher quality and durability, but it takes effort and dedication to accomplish that as a customer. Effectively the market is saturated with premium-branded items that are marginally better or sometimes worse (a lot of what you see as "technical clothing" comes across that way at least), you feel gaslit by marketing, fake reviews and astroturfing campaigns, and there are only so many deceptions, defeats and financial losses you can sustain before going back to the devil you know: the default everyone else is buying.

Would you still adore it as much today, though? I know I don't adore my iPod classic as much now as I did in 2006, and that's inclusive of the nostalgia kick. It's just not very practical and usable in today's world.