Smart TVs, TV sticks, and a lot of mobile devices will not be capable of decoding AV1 in software in realtime, given their low-spec CPUs. I imagine that Netflix is only serving AV1 to devices with hardware decoding support.
I have the G1 glasses and unfortunately the microphones are terrible, so the live translation feature barely works. Even if you sit in a quiet room and try to make conditions perfect, the accuracy of transcription is very low. If you try to use it out on the street it rarely gets even a single word correct.
This is the sad reality of most if these AI products and it’s that they are just taking poor feature implementations on the hardware. It seems like if they just picked one or these features and doing it well will make the glasses useful.
Meta has a model just for isolating speech in noisy environments (the “live captioning feature”) and it seems that’s also the main feature of the Aircaps glasses. Translation is a relatively solved problem. The issue is isolating the conversation.
I’ve found meta is pretty good about not overdelivering on promised features, and as a result even though they probably have the best hardware and software stack of any glasses, the stuff you can do with the Rayban displays are extremely limited.
Is it even possible to translate in real time? In many languages and sentences the meaning and translation needs to completely change all thanks to one additional word at the very end. Any accurate translation would need to either wait for the end of a sentence or correct itself after the fact.
Live translation is a well solved problem by this point — the translation will update as it goes, so while you may have a mistranslation visible during the sentence, it will correct when the last word is spoken. The user does need to have awareness of this but in my experience it works well.
Bear in mind that simultaneous interpretation by humans (eg with a headset at a meeting of an international organisation) has been a thing for decades.
This seems like the solution getting ahead of the problem. A series of API requests over HTTP can easily use a persistent connection and will practically default to that with modern client and server implementations. A claim that a more complex approach is needed for efficiency should be accompanied by evidence that the simple approach was problematic.
MCP can use SSE to support notifications (since the protocol embeds a lot of state, you need to be able to tell the client that the state has changed), elicitation (the MCP server asking the user to provide some additional information to complete a tool call) and will likely use it to support long-running tool calls.
Many of these features have unfortunately been specified in the protocol before clear needs for them have been described in detail, and before other alternative approaches to solving the same problems were considered.
I can't agree more, downloading OpenAPI doc for an API and parse it is more than enough to implement the core of MCP. But sadly the buzzword completely took of and for instance all participants to my trainings will ask for MCP, systematically.
> Elegant software is measured in the number of lines of code you didn't need to write.
Strong disagree. Elegant software is easy to understand when read, without extraneous design elements, but can easily have greater or fewer lines of code than an inelegant solution.
Sure, I generally agree. But you must admit, that description loses a bit of poetry.
I think software - like mathematics - becomes more elegant & beautiful when we find ways to simplify it without making it worse in other ways. Minimising the number of lines of code isn’t the goal. But sometimes making something smaller also makes it easier to understand and sometimes even more powerful at the same time. Those are the days I live for.
Alan Kay says the right point of view is worth 50 IQ points. There are plenty of examples of this in software. Innovations in ways of structuring our programs that make them at once simpler and more beautiful. All without sacrificing anything important in the process. We take them for granted now, but innovation is rarely obvious from the outset. Compilers and high level languages. Sum types. Operating systems. Maybe SQL and ECS. Sinatra’s http handler API. And so on.
> we cannot just require all generic parameters to be Clone, as we cannot assume they are used in such a way that requires them to be cloned.
No, this is backwards. We have to require all generic parameters are Clone, as we cannot assume that any are not used in a way that requires them to be Clone.
> The reason this is the way it is is probably because Rust's type system wasn't powerful enough for this to be implemented back in the pre-1.0 days. Or it was just a simple oversight that got stabilized.
The type system can't know whether you call `T::clone()` in a method somewhere.
All the #[derive(Clone)] does is generate a trait impl of Clone for the struct, which itself can be bounded by trait constraints. It doesn't have to know that every use of the struct ensures generic parameters have to/don't have to be Clone. It doesn't have to make guarantees about how the struct is used at all.
It only needs to provide constraints that must hold for it to call clone() on each field of the struct (i.e. the constraints that must hold for the generated implementation of the fn clone(&self) method to be valid, which might not hold for all T, in which case a Struct<T> will not implement Clone). The issue this post discusses exists because there are structs like Arc<T> that are cloneable despite T not being Clone itself [1]. In a case like that it may not be desirable to put a T: Clone constraint on the trait impl, because that unnecessarily limits T where Struct<T>: Clone.
You can already write method bodies today that have constraints that aren't enforced by the type definition though; it's trivially possible to write a method that requires Debug on a parameter without the type itself implementing Debug[0], for example. It's often even encouraged to define the constraints on impl blocks rather than the type definition. The standard library itself goes out of its way to define types in a way that allow only partial usage due to some of their methods having bounds that aren't enforced on the type definition. Rust's hashmap definition in the standard library somewhat notably doesn't actually enforce that the type of the key is possible to hash, which allows a hashmap of arbitrary types to be created but not inserted into unless the value actually implements Hash[1].
I'm not sure how these two things are related. When writing an `impl` for a struct, there's no assumption on the bounds of the generics (if any) unless they are specified _at the impl site_.
For example, the bounds of T in
impl<T> Weird<T> {
..
}
are independent of the bounds of `T` in any other impl or the struct definition.
The way the derives work is they generate code by utilizing the fields and their types. Here is a trivial implementation (of a custom trait, rather than Clone. still holds though) which will prove you wrong:
Types don't carry behavioral information about what the method does internally. Everything about a method is known from its signature.
The compiler doesn't introspect the code inside the method and add additional hidden information to its signature (and it would be difficult to reason about a compiler that did).
> Types don't carry behavioral information about what the method does internally.
I don’t remember specifics, but I very distinctly remember changing a method in some way and Rust determining that my type is now not Send, and getting errors very far away in the codebase because of it.[0]
If I have time in a bit I’ll try and reproduce it, but I think Send conformance may be an exception to your statement, particularly around async code. (It also may have been a compiler bug.)
[0] It had something to do with carrying something across an await boundary, and if I got rid of the async call it went back to being Send again. I didn’t change the signature, it was an async method in both cases.
`Send`, `Sync`, and `Unpin` are special because they're so-called 'auto traits': The compiler automatically implements them for all compound types whose fields also implement those traits. That turns out to be a double-edged sword: The automatic implementation makes them pervasive in a way that `Clone` or `Debug` could never be, but it also means that changes which might be otherwise private can have unintended far-reaching effects.
In your case, what happens is that async code conceptually generates an `enum` with one variant per await point which contains the locals held across that point, and it's this enum that actually gets returned from the async method/block and implements the `Future` trait.
> Types don't carry behavioral information about what the method does internally.
I was under the impression type inference meant that the implementation of a function directly determines the return type of a function, and therefore its signature and type.
While you can sometimes elide the return type (and what you describe only happens in closures — `|| { 0u32 }` is the same as `|| -> u32 { 0u32 }` — methods and free functions must always have an explicitly declared return type), that's not the same thing as being described above.
For the existence of any invocation of `<T as Clone>::clone()` in the method body to be encoded in the method signature, we'd either need some wild new syntax, or the compiler would need to be able to encode hidden information into types beyond what is visible to the programmer, which would make it very hard to reason about its behavior.
> could just make it collect CC details with every transaction
Only if the card is swiped (magnetic stripe) rather than tapped or inserted. EMV doesn't expose the full card details to the merchant; the card signs a payload with its internal private key and transmits it.
And the OP's root access wouldn't give card details in any case, because they didn't get root on the part of the reader that processes the transactions.
"she" is absolutely proper English for a ship or boat, with a long history of use continuing into the present day, and many dictionaries also list a definition of "thing, especially machine" or something like that, though for non-ship/boat things the use of "she" is rather less common.
Population density is pretty high in many European inner cities. Most of the cell sites around here are on top of apartment buildings and I doubt they have a genset. Here in central BCN the mobile network was completely offline within an hour or two of the power going out.
> Now, cable and DSL networks are standardized enough that there's a good chance you can get a third-party one to work. It will be the same with PON in time.
It’s mostly the same with PON now. I’ve always had success with the FS.com PON SFPs, once I get the necessary information for the connection to program them with (the difficulty of which can vary from “ask the tech installing the connection nicely” to “take apart the ISP-provided CPE and solder wires to the debug console pads”).
Regardless I would have carefully taken these down and put them in a box on the day I moved in. And then called them (or better, written to them) and given them a reasonable amount of time (maybe a couple months) to collect their property, making it clear that I would dispose of it after that time expired.
Not so. My mother bought a house in France in 1988. The previous owners had a mountain of stuff in the barn that they would come collect “soon”.
25 years passed. My mother started variously selling and disposing of their slowly rotting crap that they evidently were never going to collect, as she wanted to fix the structural issues with the barn, and their stuff was in the way, as it literally filled the entire ground floor.
And then, one day, 30 years later, their children showed up, wanting to collect their inheritance.
They sued. They won. She had to fork over about €100k.
So no, just because you own the house, you don’t own everything in it.
In Europe, it’s also common for you to buy a place, and then when you move in, you find the vendor has taken all of the wiring and plumbing with them. Sometimes they’ll even take things like doors, staircases, floors, you name it.
> In Europe, it’s also common for you to buy a place, and then when you move in, you find the vendor has taken all of the wiring and plumbing with them.
This is the first time I hwar of this.
At least in Norway the rule is that everything that is built in stays.
So table, chairs, TV, washing machine, dryer etc goes, but built in appliances and built in place furniture stays.
It’s the same in the Netherlands with the very odd exception for floors. Solid wooden floors are included but if it “laminaat” or anything not glued/nailed, it has to be explicitly mentioned in the sale contract. Just like with window shades etc.
Ok sure - Germany, France, Spain, Portugal, Italy, Austria, Belgium, the Netherlands, this happens. Can’t speak for elsewhere.
You have to ensure the contract of sale specifically includes things like wiring, the boiler, the radiators, flooring, light fittings and switches, because if they aren’t explicitly included, they aren’t included. There are some very odd definitions of chattels vs fixtures out there - in France, it has to be nailed to the structure to count as a fixture. If it’s screwed, glued, or otherwise not nailed down, it’s a chattel.
In France it’s only counted as abandoned if it is more than 30 years. These guys rocked up at something like 29 years and 9 months, and because there had been a verbal agreement that they would one day collect, and my mother allowed it, she was deemed to have stolen property she was entrusted to store.
I maintain that this is a dumb (i.e. completely unreasonable) outcome for your mother.
Abandonment should be measured at the takeover of property in lieu of agreement, and a reasonable time frame for pickup agreement is on the order of days, not years.
Both times my, ehm, good friend bought a house in uk the docs included a very thorough list of things that had to stay, as well as things that HAD to go.
Geographically, England is part of Europe, but regardless of the EU membership thing, UK domestic laws have always been very different from those in continental Europe due to very different legal histories. They aligned on the kinds of things that the EU regulates, but when it comes to something like property abandonment I’d expect them to be wildly different.
> In Europe, it’s also common for you to buy a place, and then when you move in, you find the vendor has taken all of the wiring and plumbing with them. Sometimes they’ll even take things like doors, staircases, floors, you name it.
LOL!
No. This is not common at all.
I've seen it from disgruntled former renters, but that's it.
And how is there any record of what was in the barn, or how much it was worth, or either it has been stolen or collected by the owner any time in the past 30 years. I don't want to call OP a liar, but a lot of times when I hear outrageous stories like this the details are very different than what was provided.
Among other stuff, there was a bunch of Italian modernist art from the 50s-70s. It was literally decomposing in there, and my mother sold a few pieces at auction at about the 25 year point, which was then used as a reference point for the value of the collection as a whole, and as evidence that she was acting maliciously, that she knew the value of what was in there.
The owner died in the early 90s - the folks who rocked up were the grandchildren of her ex-husband.
As for people who have said “oh she should have charged for the storage” - that would have been nice, but that wasn’t the agreement, and French law treats a verbal agreement as a contract, and also places the onus in this type of situation on the person holding the goods to make extensive efforts to contact the owner and/or their heirs.
I'm really shocked that 'soon' can be considered 30 years. So you agree to store someones stuff for a short time, and then you are locked in for 30+ years? I thought america had crazy lawsuits...
Oh, French property and tort law is nuts, and largely founded in egalitarian ideals from the revolutions. Quite the case of “be careful what you wish for”.
There was recently a case in the press where person sold “old junk” to an antique dealer. Antique dealer sells it at auction for fortune. Antique dealer is then forced to hand over full sum to person who sold old junk/priceless antique.
Squatters rights are incredible. A friend had their house occupied one winter while they were away, 16 years ago. The squatters had a baby. They are only legally allowed to remove them this year, when the child turns 18.
The napoleonic code. This is why France is full of abandoned properties, stuck in probate for all eternity, as finding and getting hundreds of heirs to unanimously agree on a sale or whatever is… hard.
Hindsight is a bitch. In short, she had no idea what kind of rake she was stepping on, and so saw no need to dissemble. She matter-of-factly told them they were welcome to take what remained, which was about 1/5 of what had been there — and then she got the letter from their lawyers, by which time it was too late.
It's not nice to stick eyeballs under people's vestiments. It's not nice to put hands on a stranger. Bad faith actions can be responded to without malice but there is no need to be nice. Non consentual cameras in a private dwelling are never good faith.
I completely agree. Involuntary bailee in the UK is one of the nastier parts of the law (IMO) it penalises you for being a decent person and gives the power to the asshole. It’s ripe for abuse.
Why? After cutting the power to them I'd tell the company if they wanted them back I can take them down and ship them back at my standard rate of $500/hr
