OT: a friend of mine recently bought a house. They were surprised to learn at closing that the seller had financed their solar panels and that wasn’t apart of the home purchase.
So they had to negotiate who was going to pay off the solar panel, and this all had to be completed before home sale.
The "before closing" does a lot of work here. It sounds like the seller made the disclosure when they were legally required to. This is pretty common in large purchases. First the buyer and seller agree in principle, then they perform their due diligence. Sometimes sales fall through at that last step.
If, hypothetically, the seller never disclosed the financing, then that would be an issue between the seller and the financer. At most, the buyer would need to allow the financer access to retrieve their property. The financer could then sue the seller for the buy-out cost and/or breach of contract.
As an aside, at least around here (USA), if you see a house with solar panels, it is a good assumption that they are financed.
At least here in Brooklyn a significant minority (a third?) are purchased outright, as that gives the best long term return if you can afford the initial investment, and it simplifies a later house sale (see thread above). I think some of the tax incentives only apply in that case too.
> At most, the buyer would need to allow the financer access to retrieve their property. The financer could then sue the seller for the buy-out cost and/or breach of contract.
Nope, at least not typically.
Typically in the US houses are sold as-is unless it's noted in the closing docs. Everything in or on the house when you close is yours. The seller would be the one fighting with the financing company, as (again unless noted in closing docs) they would be considered fixtures and considered part of the real estate sale.
Financer is probably not the correct word here. The common model around here is that an installer puts solar panels on your roof, and sells you the right to their electric output in exchange for a fixed fee (with a fixed annual increase). That is to say, the original homeowner never owned the solar panels, and so never had the right to sell it in the firstplace.
If the solar panels were financed with an unsecured loan, then the home buyer would unambigously own them. It is also possible for the lender to have a lien against the panels; which again would survive the home sale.
In the UK there's a standard(-ish) form [1] the seller competes, before contracts are exchanged.
So if a seller wants to keep their smart doorbell, or their curtains, or to take all the plants from the garden - they can agree that, as part of contract and price negotiation. At the same time, the buyer gets to send people to check the property and can lower or withdraw their offer depending on what the inspections reveal.
In the US, Real Estate Agent is a sink-or-swim job. There are a lot of barely competent real estate agents who go through the motions, but otherwise only superficially understand how to do the job.
For example, I run an HOA, and agents routinely forget, until the last minute, to come to me for the HOA's paperwork. The state even requires 10 days notice. I've switched to an attitude where I proactively reach out to the seller (not agent) early in the process.
> Real Estate Agent is a sink-or-swim job. There are a lot of barely competent real estate agents who go through the motions, but otherwise only superficially understand how to do the job.
Language question (ESL speaker here): how does that square? I'd think "sink-or-swim" would imply those still swimming are competent enough by definition?
> "Sink or swim" is a common English idiom that means a person must either succeed through their own efforts or fail completely, with no middle ground or outside help.
There are a lot of jobs in the US that are easy to get, but many people fail at the job. Typically these are sales jobs where the pay is mostly commission. (IE, most pay is tied to making sales.) The "sink or swim" aspect is that either someone is successful (IE, they make sales and get paid) or fail (don't make sales and thus don't get paid) and move on.
Right, but I understood this to mean you either succeed at this job, or fail and go do something else. Succeeding or failing at individual sales isn't particularly interesting- broken down enough, every job has binary outcome subtasks.
At the time Starlink was announced as was rocket reusability. Both were widely mocked and considered infeasible.
Since then Starlink has succeeded, reusable rockets are a reality, ISS crewed spaceflight restored to US.
I expect all that had an impact on the valuation. Personally I wouldn't invest in Elon because his stock is a wild ride but space x has achieved a lot.
You know, it's always funny to read takes like "A broken compiler forcing you to write explicit SIMD instead of trusting auto-vectorization and coming out 20-30% faster is the best argument I've seen for reading your own generated assembly occasionally instead of assuming the compiler has you covered" because you can quite easily imagine an alternative one like "A broken compiler revealing that the auto-vectorization actually already accounts for 50% of total speed up of O3, and manual reimplementation and code restructuring provided only additional 20% in some scenarios is the best argument I've seen for almost never bothering with hand-crafting assembly anymore".
Is there some way to write unit tests for cases where you know vectorisation should have been applied? I guess micro benchmarks should cover the performance part. We have ArchUnit to cover code structures, it would be nice if something similar exists for generated assembly.
I've been begging for years for a a [[must_vectorize]] annotation that I can place before a loop I care about, and turn it into a compile error if the compiler can't figure it out.
The Safari beta is actually covering ~6 months of work in WebKit. So it isn't one release with 500 fixes. It is more of a consolidation.
But yes WebKit has been getting tons of feature gap and bug fixed in the past 2-3 years. I think it accelerated during Safari 17, and Safari 18 has been the release that I find it good enough for most cases and finally with no rendering issues on all the site I browse.
I have been trying to get the release note and update from Safari on HN frontpage but it never got much attention. Hopefully like you others will see how far Safari has come. And out of all the features coming from new macOS releases it has always been Safari that I am most looking forward to.
At the same time I still think it has some way to go before catching up to Firefox and Chrome is many areas. But at least it is improving fast.
It's because the EU is forcing competition on them for iOS Safari, and iOS Safari shares code with MacOS Safari. Now they have to at least try to keep up.
And it wasn't just laziness that made them drag their feet. They actively fear the web as a platform, and very much want everyone to do everything through their app stores, using their own macOS/iOS-exclusive proprietary SDKs... which also means developers themselves needing to acquire a Mac with XCode, and a Developer subscription.
Don’t think of this as super intelligence. Think of it as vendor lock-in.
We have a good compare, which is cloud in the early 2000s.
Everyone (at the time) thought cloud compute costs would go to zero.
What most corporations didn’t realize is how entrenched your workflows and processes get when you adopt cloud and you become heavily locked in that ecosystem.
That same ecosystem lock-in is what the frontier labs are hoping for with AI.
There are multiple people working on the JIT within the last 5-6 years. The WhatsApp folks also contribute meaningfully.
I suspect once the Erlang/OTP team squeezes all performance in the JIT, they will look into optimizing across modules, which will probably open up many new possibilities, but it requires rethinking some runtime primitives.
1. The cross module optimizations I mentioned above
2. Have a WASM target for the runtime itself
3. Make it easier to ship single file executables with the whole VM
But they are really “nice-to-have”s. I have been a happy user for 15+ years!
A few years ago, I was working on an interpreter implemented in elixir for a domain specific language. It was a pretty basic metacircular interpreter. It relied heavily on function signature dispatch. When I tried breaking up the massive “interpret” function across modules, performance tanked. I got it all back by using some macro shenanigans, but understandably the team did not like this.
Knowing what I know now, I would’ve tried to push for a threaded interpreter to get rid of the runtime overhead of dispatching altogether. I don’t know if they’ve changed the architecture of that module much since I left :-)
Presumably it gives the JIT more type information, parent example was specifically about one of the type-check functions you can use for guards (is_float). While running it'll use the is_float information to generate code for the float case, and bail out if the actual values fail the guards at runtime.
Other JITS like V8 will do things like speculative inlining and inserting its own type guards , but if this JIT is "Admittedly an extremely simple one" then it presumably doesn't do much of that.
i ran a quick experiment where instead of doing boxing the way its done in the beam currently, i used a different boxing (NaN strategy and there was a 10x speedup
So they had to negotiate who was going to pay off the solar panel, and this all had to be completed before home sale.
reply