Prusa are clearly tools: you can fix it, modify it, and still have warranty apply. You can get after-sales parts, and service.
Bambu are appliances. They can work great out of the box, but appliances do not have upgrade paths. You do not upgrade a microwave, you throw it out and get a new one. Or maybe it's more like a fridge, you can limitedly repair some bits, but you cannot wholesale upgrade from V1 to V2.
Anyways bought the core one a few months ago, on kit, and did the whole assembly. The assembly was fun, and the resulting printer has been great. The print fails I had were all easily understandable, entirely due to adhesion issues to a dirty print plate.
I also ordered the indx and am looking forward to capabilities that are not possible with the AMS system. I'm more of an artist though, so I'm looking for interesting and cool ways to make things, not just 3D printing figurines or sculptures etc.
What value to a person does teaching "how to use it effectively" deliver?
How does that benefit their development, learning, society as a whole?
Before you start in with "it'll help them get a job", full stop - education as a public good isn't strictly vocational technician work. It's not a work training for companies.
I think "working product" is doing a lot of heavy lifting for you here.
I think anyone who has done serious product development wouldn't be so flippant and dismissive about the difficulties of even conveying WHAT to build, let along getting the right balance of quality, timeliness, and actual functionality.
The price hikes are going to be absolutely devastating.
Imagine oracle level price acuity along with 0 competition and utter dependence. This is the future the AI labs are drooling for. You will be charged based on the value it delivers. People will be start making trade offs on if hiring humans would be cheaper than AI, etc.
There's no way they're going to leave all that money on the table when there is all that investment to pay back.
That's the thing, often when people say stuff like "its banned" what they really mean is:
- the cost of mitigating the human health risk is too high
- competitors in low-environmental regulation places don't pay for those costs
- ongoing verification is expensive
I mean, let's face it, "self-regulation" of industries isn't really working that great. And for things that are health hazards that are basically borne by someone else, why should a local government make it easy to cheat and lie about this stuff?
The people arguing against this seem to assume that their right to have a business, make a profit, whatever, is a self-evident Good Thing, and rarely provide any additional arguments beyond "but the jobs". If they were at the VERY LEAST saying "we can make X safe" then maybe it'd be interesting. But as it is, the argument is basically asking us to mortgage the health and safety.
Paint VOCs sounds fine, until it's done at industrial scale, and it's also your neighbor, and also all the children in the neighborhood have asthma, and also healthcare is a lot more expensive...
This list isn't things you "cant do in california" but "polluting things you can't do in highly populated cities".
I'm not sure what the conclusion here is other than health is not important.
I've used chatgpt-shell, but I have since turned my LLM usage to gptel inside org-mode buffers. Every day I use org-roam-dailies-goto-today to make a new file and turn on gptel (the use of org-roam-dailies is 100% optional). Then I do my interactions with gptel in here, using top level bullets and setting topics to limit context.
I have 10 months of chats, and now I can analyze them. I even had claude code write me up a program do that: https://github.com/ryanobjc/dailies-analyzer - the use of gptel-mode allows me to know which parts of the file are LLM output and which I typed in, via a header in the file.
Keeping your own data as plain text has huge benefits. Having all my chats persistent is good. It's all private. I could even store these chats into a file.gpg and emacs will auto encrypt-decrypt it. Gptel and the LLM only gets the text straight out of emacs, and knows nothing about the encryption.
I found this better than the 'shell' type packages, since they don't always keep context, and are ultimately less flexible than a file as an interaction buffer. I described how I have this set up here: https://gist.github.com/ryanobjc/39a082563a39ba0ef9ceda40409...
All of this setup is 100% portable across every LLM backend gptel supports, which is basically all of them, including local models. With local models I could have a fully private and offline AI experience, which quality based on how much model I can run.
The "just generate go code automatically then check it in" is a massive miswart from the language, and makes perfect sense because that pathological pattern is central to how google3 works.
A ton of google3 is generated, like output from javascript compilers, protobuf serialization/deserialization code, python/C++ wrappers, etc.
So its an established Google standard, which has tons of help from their CI/CD systems.
For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience. Ditto monorepos. Ditto centralized package authorities for even private modules (my least fave feature of Go).
It's kind of weird how you downplay tardive dyskinesia, as if it was kind of a no big deal, whatever kind of thing. Would you accept having tardive dyskinesia induced by a drug?
Is that really your position?
Your other words seem fine, but that is a standout sentence!
regarding #2: "Automate the dumb/boring stuff", I always think of the big short when Michael Burry said "yes I read all the boring spreadsheets, and I now have a contrary position". And ended up being RIGHT.
For example, I believe writing unit tests is way too important to be fully relegated to the most junior devs, or even LLM generation! In other fields, "test engineer" is an incredibly prestigious position to have, for example "lead test engineer, Space X/ Nasa/etc" -- that ain't a slouch job, you are literally responsible for some of the most important validation and engineering work done at the company.
So I do question the notion that we can offload the "simple" stuff and just move on with life. It hasn't really fully worked well in all fields, for example have we really outsourced the boring stuff like manufacturing and made things way better? The best companies making the best things do typically vertically integrate.
So, how much do you trust your own intelligence? When has it failed you?
I think you have too much hubris. What do these people know that you do not? What non technical things do they know that you do not, that totally change the context and the reasoning behind these solutions?
Solutions exist to this that can respect the distributed nature and not rely upon a single authority. Multisig wallets that require N of M where the participants are chosen from a broad swath of the relevant community is popular. That way you can go in and change transactions after the fact, all without requiring the blockchain to (a) know about it and (b) everyone gets to choose their own relevant security model.
It even exists now, if you mis-send USDC/USDT you can petition Circle or Tether to reverse or change a balance. Commonly required when sending USD* to an address that can't move it out or handle it.
But ALSO a lot of payment systems that people like are in fact not reversible, even by courts. And people like them that way - it prevents fraud. Fedwires, Swift wires. Consider selling a high value item: there are few ways of electronically transferring amounts that can't be frauded out later. This is why many used car sales are done via cash - can't undo cash!
A centralized database of fungible and useful assets is going to eventually be hacked. Just ask OKTA about that.
Whereas there is no central point of hack for a well designed and tested blockchain. Distributed custody in an adversarial environment with mutual trust and dis-trust.
Yes it's not everything, but tradfi solutions are not 150% bulletproof either - they may only seem that way to the outside, but there are massive hazards lying just under the surface waiting to blow up. See: GME settlement risk end of Jan 2020.
EDIT: I used to be a huge skeptic of Eth and smart contracts. But I knew basically nothing about how they actually worked in practice. I learned a lot more and now I am a big believer.
The reality is you just likely do not know enough. Your skepticism of the space prevents you from learning and seeing the value that's sitting right in front of your eyes. You also have baked in presumptions that existing systems are somehow... workable or great, when they are not.
In addition to standard multi-color needs!