As a non American, I have to admit a lot of things sounds very weird to me, especially on the "mortgage loan fees" part.
In particular, the title part sounds horrible (and expensive). As far as I know, over here it's all handled by the state, no insurance required. I don't know if it's because of different laws regarding future claims (the registry is the truth, too late to change it?) or just better records?
Same with tax/insurance escrow, you just pay directly as it comes, but since we have essentially no property taxes, it's probably not required?
On the other hand, here mortgages only have a closing fee (and quite often even none at all, with all the small fees being invisible and rolled into the margin), so that transparency is welcome.
The title part is kinda weird. The government makes a best effort to ensure all lien holders are satisfied, but that can't be always guaranteed, so title insurance happens. They do the indepth research and put their money on the line (and charge a pretty penny for it). It's pretty rare, but there's little recourse if you buy a home from somebody and they weren't empowered to sell it to you. Banks obviously want to be protected from these situations since the loan is secured with the property. If the title company finds something suspicious, they won't insure it, which is why it's almost never a good idea to buy it for yourself too.
> Same with tax/insurance escrow
You can do this, but only for jumbo loans (>400k). Property tax and home insurance is usually paid once per year, and especially for first time home owners, not being prepared for one of these could be significant financial hardship. So the bank mandates an escrow to make sure a regular yearly charge isn't going to make you miss payments to make. They don't make money on this escrow and there's no interest or fees involved.
> On the other hand, here mortgages only have a closing fee (and quite often even none at all, with all the small fees being invisible and rolled into the margin), so that transparency is welcome.
Yeah, it's super nice. Spells out all the fees, the interest rate, the APR and everything. It clearly delineates fees that can be negotiated/shopped for and which are set by the government and which are set by the bank that you can't shop for (unless you change banks who might charge differently). It's also required to be provided to you in advance with a minimum time window to allow you to read, understand and come prepared.
Yes, it will take effect in 2028. Although that's unfortunate, it was a good tax to equalise tax treatment of owners vs renters.
The Swiss market is also different in many ways: no capital gains taxes except on real estate, which really shifts the invest against house appreciation towards renting.
> Basically farmers and the upper quartile of income earners are the majority of owners.
I'm not certain the second part is very true. Of course, given how prices are you need to be rich to buy, but I think the bias is a lot more towards age than income: those that own are overwhelmingly those that bought a long time ago or inherited.
Finally, rent control results in some crazy price to rent ratios in the big cities: Zürich is around 35. But as usual with rent control, it's if you can find the right place.
You both guys are today's lucky 10000! You can export entire gmail history with takeout and import the history locally to thunderbird. You can even make backup of it. Then delete everything and anything you want from the online gmail. Select 50 items at a time with "Select all" and delete page by page, go guys you can make it!
Backup the thunderbird profile, it's just a directory. Seriously why my parent comment is downvoted FFS?! WTF? You are receiving free advice while others would sell you paid subscription for it.
I'm using Thunderbird for the accounts I care about. I know I could hook into Gmail using IMAP. Just sayin' the Gmail UX for deleting is horrible and Thunderbird existing is no excuse for that.
The poll is by Tamedia, a reliable polling company (as much as any polling company can be). It has been widely cited in others media, including the public one.
There is significant support for the initiative. Initiatives tend to lose steam as time go by, so it might not be enough in the end, but like Brexit, don't underestimate it.
Let's not pretend like Tamedia doesn't have a bias that has a significant overlap with people who tend to follow the SVP vote suggestions. Much like it's well known NZZ will come out with articles against the 10 million cap because it has a significant FDP bias. Swiss private media has well known biases and is just thinly veiled propaganda most of the time.
But SRG does a good job at presenting things neutrally.
Of course nobody should underestimate the initiative. But I think you will agree that "Most Swiss back initiative to cap population at 10 million" is a sensationalist title since most people probably didn't make up their mind about their vote yet.
Apparently it's quite widespread, so I would assume a bug on their side. That's what support seemed to imply at least. We're still blocked at my company for one month+ now.
For something like this, I would generalize a "bug" to encompass both software and human processes. Some decision-maker saw some metrics consistent with spam and enacted a spam-blocking measure. Any decision like this is going to lead to false positives. Maybe they decided "I don't need to confer with anyone", or maybe they did and got the green light even after multiple eyeballs looked at it. I'm not saying that this does any good for Microsoft's already-sullied trust, but mistakes happen and combating spam is a constantly evolving arms race. There's no way any organization is going to get it 100% of the time even after decades of dealing with it.
I doubt someone manually went and flagged all the accounts as invalid suddenly or whatever and that was their goal.
By a bug I mean some kind of automated action that did not produce the expected outcome.
Also because, at least on our side, the account was in an inconsistent state: we were correctly enrolled/validated, but could not access the signing interface.
If I remember correctly, in all the recent cases it was picked up by automated scanning tools in a few hours, not because someone updated the dependency, checked the code and found the issue.
So it looks like even if no one actually updates, the vast majority of the cases will be caught by automated tools. You just need to give them a bit of time.
Usually the luxury part is not the price of the car, it's the associated costs, especially parking. Coupled to the fact that you don't actually need the car (and it's probably a hassle for day to day life, so you only use it for the rare out of town trips).
From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").
I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eitehr.
Turns out there was a known bug in Microsoft schannel that had yet to be patched and they'd wasted weeks of our effort by not searching their own bug tracker properly.
I hate that so much. It's everywhere. An example is a bug with discord. They wanted me to restart my phone, reinstall the app, what are my versions, what phone am I on, what settings, etc. After all of that they go "oh that's a known issue." Whyyyyyyyyyyy. I get that multiple things can have the same symptom, but maybe start with that. Not like I signed any NDA so they aren't hiding it's an issue from the public.
puts on paranoid hat It could be to demoralize you so you subconsciously decide to not file a bug next time, knowing all the rigamarole you'd have to go through. takes off paranoid hat
My favourite variant of this merrygoround is when they ask you to demonstrate the issue live in a Teams session, you do so, and there's this moment of silence followed by an "Oh... I see".
Then you assume, naively, that this means that they've recognised that there really is a product problem and will go off and fix it. However, then in turn the support tech needs to reproduce the the issue to the development team.
They invariably fail to do so for any number of reasons, such as: This only happens in my region, not others. Or the support tech's lab environment doesn't actually allow them to spin up the high-spec thing that's broken. Or whatever.
Then the ticket gets rejected with "can't reproduce" after you've reproduced the issue, with a recorded video and everything as evidence.
If you then navigate that gauntlet, the ticket is most typically rejected with "It is broken like that by design, closed."
It'd kind of sad, how the market went. I suppose there are pluses too.
But back in the 80s and 90s, margins were significantly higher. If you look at hardware, I recall selling hardware with 30% margin, if not more... even 80% on some items.
Yet what came with that was support, support, support. And when you sell 5 computers a month, instead of 500, well.. you need that margin to even have a store. Which you need, because no wide-scale internet.
On the software side, it was sort of the same. I remember paying $80 for some pieces of software, which would be like $200 today. You'd pay $1 on an app store for such software, but I'd also call the author if there was a bug. He'd send an update in the mail.
I guess my point is, in those days, it was fun to fix issues. The focus was more specific, there was time to ply the trade, to enjoy it, to have performant, elegant fixes.
Now, it's all "my boss is hassling me and another bug will somehow mean I have to work harder", which is .. well, sad.
It really depends, support is usually the first thing companies adjust when they want to improve their margins.
Even when you're paying millions to AWS you have to get through their first line of support and they will ask silly questions until you can convince them to escalate.
Not really, you get "really dedicated support" at most, but not a "really good" one, otherwise all those decades-old bugs common in many software producs would've been fixed since they affect people at all tiers
Back then, computers didn't had competition from the analog world, so vendors had to provide excellent service such that users would be convinced into switching over to the digital way if doing things. Now comouters have a monopoly on how we work and live, so vendors care as little as possible.
This is simply a bug, it's an implementation mistake, it's even possible to imagine from what we do know about the implementation inside Windows to imagine how you'd likely write that bug, simply you're writing the "lock stealing" code and you realise you need some context -- are we stealing the write lock or the read lock? You realise that context won't fit in your tiny flag budget (flag bits are hidden in the bottom of a pointer) and you forget that you actually know this context at the exact moment you need it - you were asked for either a write lock or a read lock, that's what you're stealing. So, you write code which does what it can without the context, always steal the write lock. Oops. Bug.
And yet several people insist that this wasn't a bug it's actually the proper way for this to function. Not only in this github ticket, and in the Microsoft internal bug, but I saw several third parties defend the bug as obviously the correct way for this to work.
Fortunately it seems STL understood that and the internal ticket was eventually fixed and (presumably) in Windows 11 today this bug is fixed.
That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability. They would not remain employed in my company.
When I developed software I would jump right on top of any bug reports immediately, and work until they were fixed. I was grateful to my customers for bringing them to my attention.
It is different when you have a billion customers, all with different setups. At that scale, you notice real defects through product telemetry, support ticket volume, or trusted channels. You receive a high volume of bug reports that are due to user confusion, misconfiguration, or misbehavior of other software on the device - where solving an issue for one customer doesn't result in improvements for the other billion. Triage, filtering, and winnowing are necessary here.
I got a lot of those too, it meant I inevitably did a little bit of free tech support for my customers. In the end I felt it was worth it as they raved about the quality of support and it was a real differentiator - not to mention built a lot of brand loyalty (and internal staff loyalty too once I grew enough to build out a team - they derived real satisfaction from actually solving problems instead of playing ping-pong).
I agree regarding the need to triage at scale, unfortunately most large companies I've encountered fail to do this well and seem ill-equipped to accept high quality bug reports of edge case defects generated by expert users (save for the odd exception that arrives by social media from someone who happens to have enough followers to get their attention outside the regular support pipeline).
In my experience this doesn't usually boil down to a systems issue (the ticketing systems etc. exist that should theoretically allow for eventual escalation to the right engineer/developer) but a corporate culture thing (the company just doesn't prioritize customer feedback especially at the level where staff who actually deal with customers interface with the teams that write/maintain the software). Often it's genuinely valued at the C-level (the Bezos story of calling Amazon"s tech support line during an exec meeting is a fun example) but diluted somewhere between them and the rank-and-file.
(Ps. I'm not arguing with you and appreciate you took the time to craft a thoughtful reply)
It should be the other way around - at billion customer scale you should be responsible for how your product interacts with other software whose developers have less resources than you.
My guess it's just the emergent behavior that results when a company doesn't provide developers time to fix bugs.
If their week is already booked full just trying to keep up with the roadmap deadlines, a bug ticket feels like being tossed a 25lb weight when you're drowning.
You could say: "but have pride in your work!"
But if your company only values shipping, not fixing, that attitude doesn't make it through the first performance review.
What I've found to be most effective for program management is to set aside a maintenance team separate from the feature teams. The roadmap is then planned without counting anything for the maintenance team and they deal with bug tickets as they come in. Rotate the assignment periodically so that every developer has to occasionally spend a few months on the maintenance team.
Doesn’t this lead to problems like the feature team pushing buggy code and having no accountability or responsibility to deal with it?
My preference is to treat the defects like feature work, size and plan. Yes you might not get all the feature work done but the team is accountable for everything they make
There's a lot more to effective program quality management than I can explain in a comment here. Forcing all developers to rotate through the maintenance team is one incentive not to ship crap because they might end up having to deal with it anyway. But more importantly you have to shift left the quality assurance and control activities to minimize the risk of defect leakage in the first place. And set up a closed-loop system where any leaked defect triggers a rigorous root-cause analysis that results in further process improvement.
You’ve just described AGILE development, a way for product owners to backlog code rot while empowering developers to feel like they have a say in things.
In particular, the title part sounds horrible (and expensive). As far as I know, over here it's all handled by the state, no insurance required. I don't know if it's because of different laws regarding future claims (the registry is the truth, too late to change it?) or just better records?
Same with tax/insurance escrow, you just pay directly as it comes, but since we have essentially no property taxes, it's probably not required?
On the other hand, here mortgages only have a closing fee (and quite often even none at all, with all the small fees being invisible and rolled into the margin), so that transparency is welcome.
reply