The one without the relieve valve is nicer to use because it's (much) easier to clean. Source: I've cleaned these things pretty much every weekday for the last 2 or 3 years.
That sucks. I have both and the ones with the pressure relieve valve are a pain in the ass to clean. You have to pull out the rubber inner thingy, you can't get a towel inside the hole that thingy goes into, and in general the rubber thing gets lost easily. I wish Thermos would send me a few of those 8 million stoppers, I'll promise I won't be a dumbass with them :(
That's not very empathic of fellow people who might just have mistakenly forgotten food in the container.
It's not like they were intentionally using this for brewing some illegal substance or misusing it in a way specifically forbidden in the manual or obviously unsafe (e.g. removing a magnetron and all of its protections from a microwave to make pretty wood carvings).
Can you also guarantee with absolute certainty that you'll never forget them anywhere another person who's unaware of the contents or the danger could find them?
If I buy a lawn mower, I don't expect anyone to guarantee with absolute certainty that there will never be a person who thinks 'hey maybe I can just stick my hand in there to unclog it' and gets their fingers chopped off. Probably a wrong analogy but I can't even be bothered to think it through, of course fermenting food causes things to explode, how is that even remotely the fault of the manufacturer? I loathe the times we live in where everything needs to be padded and cushioned because heavens forbid we start expecting people to think for a second. I mean, the valve requires a crevice where all sorts of things can grow (I've seen them, I've cleaned these things after they were left in a school bag throughout two weeks of school holidays with food in them), I'm not going to complain that it would somehow be Thermos' fault if one of my kids got sick off something getting stuck in there. At some point, there is such a thing as 'personal responsibility'.
I get your take that people should take the responsibility for things they are doing.
Without arguing your point there are a couple more things to consider from the perspective of the company and the society at large.
From the company perspective, if their product gets a bad reputation the sales will be worse. This could even extend beyond the one product. It doesn't matter if it is fair or nuanced at all. Even if everyone is a moron, investing in protecting the morons from themselves could be a good business decision.
From the society perspective, there is a positive-for-business intent in forcing a baseline for consumer safety and satisfaction. Threading that needle is of course hard but it makes it easier for a free market of consumer products to exist as a whole if the consumers can offload some of the investigation required before committing to something. The idea is that in a 100% buyer beware situation there is less buying overall and the market can't be big and as full of options because the cost/risk of buying isn't worth the end goal. You can make the counter argument that the trust should be part of the brand value but it might enable new companies and new products more effectively (making more good options in a free market) to reduce the consumer risk of purchasing their products.
Additionally, if everyone is doing the same prerequisite research (is this safe before I buy), it makes sense to consolidate this step either through curation/certification groups (the people who care fund it themselves - makes sense for specific preference choices [eg "plant based", "cruelty free"] or niches [eg "gluten free", "non gmo"]) or regulation (everyone funds it collectively - makes sense for broad application like "will I get food poisoning" and "am I risking being maimed").
Beyond personal purchases there's also society wide implications worth preventing for things like if a million cars exploded or if 10% of profession X and profession Y ended up losing fingers.
Like I said, not arguing with you about if people are dumb and if companies should be required to pay to deal with that, just pointing out there are other reasons a system might be in place beyond just a patronizing nanny state situation.
>Can you also guarantee with absolute certainty that you'll never forget them anywhere another person who's unaware of the contents or the danger could find them?
Why does he need to do that?
We're talking about a product that lightly injured ~20 people for ~8mil units sold and seriously injured ~3.
Should be be keeping his champagne in a protective enclosure?
I've seen Champagne disappear faster off the shelf more so around MBA's who are celebrating accomplishments having dubious value, compared to engineers who have actually achieved remarkable milestones ;)
I wonder if they track how many people are sickened by the difficult-to-clean valve, because I bet it's a lot more than 3.
Luckily I got one of the valveless models, and you bet your ass I'm keeping it. Maybe I'll stick an "open away from face" label on top or something, but I'm not about to go increasing my risk of food contamination.
There's not really any way to make anything containing hot pressurized foods safe from people pointing it at their face. Either you get the lid in your face or you get steam in your face. The poor hygiene the vent creates is just an added bonus.
I'd rather they slap a warning on it, like everything else that you can't safely point at your face.
"LLMS are good at "find me a two week vacation two months from now"?"
Of course they are. I gave one a similar prompt a few weeks ago, albeit quite a bit more verbose (actually I just dictated it, train of thought, with couple of 'eh actually, forget what I just said about x, do y instead") and although I wasn't brave enough to give it my credit card and finalize the bookings, it would have paid for the bookings I had it set up for me, had I done that. I gave it some RL constraints, like "we're meeting friends in place xyz at such and such date, make sure we're there then" and it did everything from watching we wouldn't be spending too many hours driving per day to check that hotels are kid friendly to things to do and see and what public holidays there are so that we know when supermarkets close early and a bunch of details I wouldn't have thought of. It checked my (and my wife's) calendar, checked what I had going on work wise, etc.
That is a fully solved 'problem' man. LLMs will run the whole thing for you. Just provide it with the login details to booking websites and you're off to the races.
I did have it upgrade the car, even if that pushed the cost outside the budget I gave it. Next time it'll know LOL.
It's a matter of getting used to things. We're only a few weeks further, I maybe would have given it now. It'd need some way to keep it private I guess, maybe I could have used a one off CC number. Those are just technicalities at this point. It got me to the point where I just had to enter my details and click a few confirm buttons. Those are solved problems. I'm not sure why the denialists here are saying those things are 'impossible'. I mean I've seen them happen, what do you want me to say? Claiming this is 'just hype' is ostrich behavior. I've been playing with an abliterated Gemma 4 yesterday on my local machine. Yes it would take longer and require a bunch of harness fiddling, but even if OpenAI and Anthropic would collapse tomorrow, I'm confident I could still do the exact same thing the day after with with what I have right now on my hard disk. I'm not sure what you want me to tell you mate. Yes there's rough edges to work out or just in general workflows to improve but the ideas are way beyond 'proof of concept'. There's people like myself using these things for purposes that 6 months ago were science fiction. I don't care if you believe me or not, I'm just some dude on the internet, but level of delusion on how 'inferior' these models (with proper harnessing) are is mind boggling for someone like me who sees it happen literally 20 centimeters to the side on my screen from where I see people claim that those things are impossible.
I have it, it's great. There's a free one, I paid a few bucks for the full set. Guy has a Youtube channel too where he shows how he does a few of the designs. Good guy, I had some troubles with the payment getting through to him and then the download didn't work for some reason (some weird combination of issues, don't remember details), and he just send me the whole pack without even knowing if I was going to actually put in the effort to make the payment work.
Why would one want to couple these two? Doesn't that couple, say, your API interface with your database schema? Whereas in reality these are separate concepts, even if, yes, sometimes you return a 'user' from an API that looks the same as the 'user' in the database? Honest question, I only just recently got into FastAPI and I was a bit confused at first that yes, it seemed like a lot of duplication, but after a little bit of experience, they are different things that aren't always the same. So what am I missing?
The ORM doesn't force you to use the DB model as your API schema. It's a regular Pydantic BaseModel, so you can make separate request/response schemas whenever you need to. For simple CRUD, using the model directly saves boilerplate. For complex cases, you decouple them as usual. The goal is not one model for everything, it's one contract. Everything speaks Pydantic, whether it's your API layer or your database layer.
You might be interested in a library that flips around the concept of an ORM, like sqlc [1] or aiosql [2]. You specify just what you want from the database, without needing to couple so much API with database tables.
A lot of people have this misconception that Pydantic models are only useful for returning API responses. This is proliferated by all-in-one frameworks like FastAPI.
They are useful in and of themselves as internal business/domain objects, though. For a lot of cases I prefer lighter weight dataclasses that have less ceremony and runtime slowdown with the validation layer, but we use Pydantic models all over the place to guarantee and establish contracts for objects flowing thru our system, irrespective of external facing API layer.
One advantage of something like attrs/cattrs is you can use the regular attrs objects inside the module without all the serialisation/validation baggage, then use cattrs to do the serialisation at the edge where you need it.
With proper DRY, you shouldn't need to repeat the types, docstrings and validation rules. You should be able to say "these fields from user go on its default presenter, there are two other presenters with extra fields" without having to repeat all that info. I have a vague memory that Django Rest Framework does something of the sort.
This feels hard to express in modern type systems though. Perhaps the craziness that is Zod and Typescript could do it, but probably not Python.
With this you don't need to have two sources of truth on the backend. Previously you will end up with one set of DB ORM level validation and a second set of validation on the data transfer object and you have to make sure the types line up. Now the data transfer object will automatically inherit the correct types.
The two sources of truth are for two disparate adapters. Neither the API nor the DB define the domain, but both must adapt the domain to their respective implementation concerns.
The ontology of your persistence layer should be entirely uncoupled from that of your API, which must accommodate an external client.
I'd rather define my db domain in-code so I do not have to worry about writing the queries without type hinting.
Raw sql -> eh, I don't have the patience
Raw sql w type hints -> better, I at least get a compilation error when I do something wrong, and preferably a suggestion
ORM -> this usually introduces it's own abstraction that needs it's own maintenance, but at least it's more code-oriented.
Yes, SQL is an awesome solution to querying DB's, hence I prefer option 2
Well yeah, of course. Sorry, when I said "DB" what I should have said was "data-layer," and this can include: repositories, ORM models, query-builders, etc. All of these are type-hinted "db domain in-code" and, still, not one coupled to your API.
I also find it really strange this weird ORM fascination. Besides the generic "ORM are the Vietnam War of CS" feeling, I feel that with average database to ORM/REST things, end up with at least one of:
a) you somehow actually have a "system of record", so modelling something in a very CRUD way makes sense, but, on the other hand, who the hell ends up building so many system of record systems in the first place to need those kinds of tools and frameworks?
b) you pretend your system is somehow a system of record when it isn't and modelling everything as CRUD makes it a uniform ball of mud. I don't understand what is so important that you can uniformly "CRUD" a bunch of objects? The three most important parts of an API, making it easy to use it right, hard to use it wrong, and easy to figure out the intent behind how your system is meant to be used, are lost that way.
c) you leak your API to your database, or your database to your API, compromising both, so both sucks.
The vietnam of computer science was written 20 years ago (2006 even), and didn't kill off ORMs then. We've only had 20 years of improvement of ORMs since then. We've long ago accepted Vietnam (the country) as what it is and what it will be in the forseeable future. We should do the same with ORM.
I for one don't want to write in a low level assembly language, and shouldn't have to in 2026. Yet, SQL still feels like one.
I've written a lot of one off products using an ORM, and I don't regret any of the time savings from doing so. When and if I make $5-50M a year on a shipped product, okay, maybe I'll think about optimizing. And then I'll hire an expert while I galavant around europe.
SQL is a pretty high-level, declarative language. It's unnecessarily wordy though, and not very composable.
The problem with ORMs is that they usually give you a wrong abstraction. They map poorly on how a relational database works, and what it is capable of. But the cost of it is usually poor performance, rarely it's obvious bugs. So it's really easy to get started to use; when it starts costing you, you can optimize the few most critical paths, and just pay more and more for the DB. This looks like an okay deal for the industry, it seems.
Suppose an API GET /users/:username call returns a "User" type. If returns the the same type as in your database, wouldn't you also get their password hash as well with that request? How do coupled frameworks deal with this?
Related to this, has anyone investigated how much typos matter in your chats? I would imagine that typing 'typescfipt' would not be a token in the input training set, so how would the model recognize this as actually meaning 'typescript'? Or does the tokenizer deal with this in an earlier stage?
GP said 'open bar with 2 bartenders'. I.e. commercially priced drinks, and staff. Did you have those? If so, pro tip, next time just get a few cases of various drinks, plonk them on a table with a bunch of glasses (rented, if need be) and call it good. People can't drink soft drink for more than, say, 3 USD worth in an afternoon; and even if you served 12 years Glenfiddich to everyone including the children, enough of it to knock them all out, you still wouldn't have spend more than $1000.
So yeah still wondering what sort of party you threw. I mean, yeah it's easily possible to spend that much, but it's also possible to do it for much less and you don't even need to really try.
You seem to be misreading his comment. Some guy making some observation biased comment is irrelevant. It's flat out wrong that Germans 'need' it less. The obesity curve in Europe trails that of the US a generation or two, yes (and several Asian ones trail it more). But the numbers and trends don't lie.
reply