So the law requires a fridge be provided, but doesn't state what kind. So now renters can expect to move into an apartment with a tiny, old fridge that does not suit their needs. Then they have to find a different fridge that will hold more than a half gallon of milk, as well as find a place to store the provided, unusable fridge until they move out.
Uniquely you are allowed, as a renter, to turn down the refrigerator and bring your own if you agree at the signing of the lease. The landlord can't make this a condition but can accept it as a modification.
The bill is very poorly written and under specified. The only restriction is that the unit itself not be under any manufacturer recall.
First versions of laws expected to meet significant resistance usually are. So you make v1 as vague as possible to get it passed, then once everyone is used to it and agrees it needs fixing, pass the v2 law you actually wanted to pass originally.
A thing I've experienced is people buying a bigger fridge, and then just leaving it when they move out because they're moving to a place with a fridge that is fine (for example, moving in with someone who has a nice fridge). Everyone walks away from that basically fine.
There is no actual argument here that wouldn't apply exactly the same to the stove and the toilet. If an apartment has a shitty fridge, it simply is a less attractive, less valuable property. If you want full control over such details, you can buy instead of rent, or you can buy your own frdge and keep the original in a storage unit until you move. If that sounds stupid, I agree that would be stupid.
Yeah, it seems like mandating transparency here would be better. I've never moved into an apartment that didn't have a fridge, but if the landlord wasn't providing one before, I can't imagine they'll spend on a nice one now.
I mean, if the lack of a refrigerator is a uniquely Los Angeles thing, it seems like you could just predict what will happen based on what happens in _every other city_....
they could do like germany where most apartment/flat kitchens are bare --the renter needs to bring their own appliances and furnishings. this means fewer appliances and kitchen stuff gets mistreated by the renters since they own them. kinda sucks to move apartments though.
as to why... german renter/lessee culture prefers having their own stuff to give it a more homey feel, i guess.
It hugely sucks because things like fridges and stoves often need to fit the dedicated space in a kitchen exactly. The chances that your previous apartment and new apartment fit the same size appliances is virtually nil.
This is why it makes sense for them to just be part of the apartment.
I don't know what you mean by "mistreatment" -- anything in an apartment can be mistreated I suppose, it's not specific to appliances. If you damage anything, that comes out of your deposit. But I'm not really sure what there is specifically to damage about fridges and stoves? They get dirty and you can clean them. They don't generally require any super-special treatment.
The medieval French word (and English borrow-word) was immeubles - immovables. While it's not clear what these were to me, there is a distinction between buying furniture (meh, it's your stuff) and buying immeubles (which meant you were staying longterm).
There is a scheme that is sometimes used by landlords in Germany in which an apartment is only rented out if the tenant agrees, before the rental contract is signed, to buy a fully fitted kitchen that is already installed — and usually at a price that is far from cheap. Otherwise, the prospective tenant does not get the lease. Given the current shortage of affordable housing in Germany, this puts the prospective tenant under considerable pressure to buy the kitchen from the landlord.
The landlord is fully aware that when the tenant eventually moves out, the landlord can require the tenant to take the kitchen with them — after all, it is the tenant’s property, not the landlord’s. The landlord can therefore demand that the outgoing tenant removes the kitchen. This again puts the tenant under pressure, because fully fitted kitchens very rarely fit into a new apartment.
At that point, the landlord can make an offer to buy the kitchen back from the departing tenant so that it can remain in place — but the purchase price is then only a fraction of what the tenant originally had to pay the landlord when moving in.
In this way, the landlord can indirectly force one tenant after another to buy the kitchen and later sell it back.
I've lived in Germany for four decades with plenty of moving around, and have yet to move into a place where a kitchen was not either provided or left there from the previous tenant (sometimes with a more symbolic compensation; it's not worth to rip it out since it often only fits that particular place anyway so there is pressure to give it away cheaply).
I think that copyright should be abolished. But this does not mean you can't make money off software. For example, game studios could still charge for online play on their servers (an ongoing service), even if they can't legally prevent people from sharing copies of the game files, in this model. Similarly, theaters could still charge for movies, but what they would be selling is not a "right to see the movie" per se but the theater experience.
It may be hard to imagine, I don't think things would be massively different overall.
If the game is reasonably priced, people may still buy it out of convenience. For example, I'd rather pay $5 for a single player game on Steam and get out-of-the-box support for Linux through Proton than download a possibly malware-ridden copy in the high seas and then spent time figuring out how to run it. It's the same reason people still buy hard copies when every conceivable book is on Anna's Archive.
So your fist attempt was an online coding course where you would train users and they agreed that once they got a job, they would pay you a portion of their salary. But no one would honor their agreement once they were trained and employed.
As much as people want to believe that there is a tried and true formula for success, there isn't one. Many self-help books and videos want their customers to believe there is one, but if you get 100 determined and talented individuals to try their formula; you may get 100 different outcomes.
There are certainly traits and tactics that can enhance your chances for a good outcome, but nothing is guaranteed. Every story of success or failure is just another anecdote.
What if AI can greatly reduce the amount of money (i.e. tax receipts) that the government needs to function properly? What if AI can quickly determine who really qualifies for government assistance, and cuts off all the fraudsters without needing an army of bureaucrats?
We could even cut out a ton of middle-men and return congress to a part-time job. One can only dream, right?
> What if AI can quickly determine who really qualifies for government assistance, and cuts off all the fraudsters without needing an army of bureaucrats?
Surprise, Surprise. LLMs will respond according to the set of data that their model was trained on!
While just about every LLM is trained on data that far surpasses the output of just one person, or even a decent sized group; it will still reflect the average sentiment of the corpus of data fed into it.
If the bulk of the training data was scraped from websites created in 'WEIRD' countries, then it's responses will largely mimic their culture.
I developed a new database management system and I needed a GUI application to use as an admin tool for it.
I decided to build it using Qt (Qt Widgets in c++) mainly because my whole data engine is also in c++. Since it just uses standard windows and dialog boxes; I haven't felt the need to keep up with the latest Qt version. I am still using Qt 5 (I think revision 13 or 15).
I have been contemplating moving to Qt 6. Have users noticed a big difference (e.g. performance) between Qt 5 and Qt 6?
QtQuick uses a different runtime which is (afaik) faster and targets modern graphics backends (eg. Vulcan) in a way widgets does not.
It also uses an a javascript scripting engine.
Saying “they’re both c++” is seems kind of misleading and meaningless right?
It’s probably more accurate to say QML is actively being worked on and receiving performance enhancements and updates and widgets is not, and has not for some time.
So yes, it’s actually pretty unlikely that QML would be slower (depending on what you do with your scripts) but it’s probably not as clear cut as you are suggesting.
QML apps that heavily implement core logic in javascript would be slow as balls.
> Saying “they’re both c++” is seems kind of misleading and meaningless right?
Not really, if you avoid writing Javascript code in your QML components, than most of your executable will end up being compiled C++ code. If you do write Javascript code in your QML components, than it *could also* be compiled to C++ code using the QML script compiler[1[2].
> QML apps that heavily implement core logic in javascript would be slow as balls.
The entire point is to separate logic and view where logic is written in C++ and QML simply represents the view (which almost end up being built upon simple primitives that *are* C++ objects). So if you keep this separation you get amazing performance with great simplicity and velocity.
I already showed in my benchmarks that my block editor is faster than all block editors on the market - even more than those that uses native frameworks. And there are ten of thousand of lines of QML code (and round the same of C++ as well).
You can't claim something is slow without showing empiric data. I showed mine when I claimed programming Qt C++ and QML together is fast. If you claim otherwise, you need to support it with data.
If you ever run into trouble with execution of JS slowing down your Qt/QML application, you are using way too much JS. The most common performance issues in decently written applications are rendering of invisible items aka overdraw (especially on very weak embedded SoC GPUs) and slow startup time. There is tooling to find these and ways to fix or improve them.
> The most common performance issues in decently written applications are rendering of invisible items aka overdraw
That's indeed what I found as well! Especially, these hidden items consume a lot of unnecessary RAM. What tools do you know for Qt/QML that can help with this issue?
For another perspective and more details, RenderDoc (or another frame debugger if you have one) is a nice tool as well.
Also don't use Rectangle { color: "transparent" }, use Item {}. An Item has geometry, but doesn't render anything. A transparent Rectangle probably also doesn't render, but it's still (at least slightly) more resource-intensive and makes you look like you don't know what you're doing.
Use Loader, StackView and visible liberally to disable stuff that isn't currently relevant. If unloading causes trouble with lost state, you may be carrying too much state on the QML side.
Reminds me of the old saying: 'If you have just one watch/clock, then you always know what time it is; but if you have two of them, then you are never sure!'
Makes you wonder if the reason why some trivial bug in a closed source project goes unfixed for years; is because all the engineers are afraid to touch the code in some obscure library and instantly become its new 'owner'.
Mostly it is that you don’t go around fixing random stuff.
You might actually get in trouble picking up stuff that is not a priority.
Company I work for is less strict so we do “fix anything Friday”.
But for some other companies you might get a slap on the wrist for not following the plan and product owners pick what gets fixed and what not based on business plan. If there are big customers nagging - bug will be fixed asap.
reply