I'm guessing the user you're replying to is meaning that the vscode default config file is 11k lines and the AI setting just one of many lines in the file.
I don't think they meant that their own settings are that long, just the default in the app and they're commenting that it's ridiculous to expect a person to find it there.
I use emacs, so maybe they're better trained on my editor. But I've had a lot of success resolving little annoyances I have just lived with for years talking to Claude in gptel.
I can't get it to do real work for shit, but it's A+ at helping me waste time with yak-shaving. lol
Alternatively, use the single setting that was literally just given to you above. That is pretty much as easy as it gets without resurrecting Clippy to help you figure it out. It's not reasonable to expect a massive bloated gui if people have 10k+ settings they are using.
The problem is that they keep adding new ai "features" all under different names and different settings, then shuffling the settings around.
Having a "master switch" doesn't matter, since their standard operating procedure is to waffle-stomp more "features" into vscode every month that will fall under a different setting and then they'll continue to shuffle them around.
Their indifference towards their own user-hostility with regards to this is the main problem.
I'm confused—how does putting in a master switch for those who want to opt-out entirely from the AI revolution occurring at the moment not matter? Are you saying that new features will fail to respect it?
That, in a nutshell, is one of my biggest complaints about VS Code: there are many overlapping settings for various things, and I could never get clarity on what takes priority. Setting up things like formatters (and their settings) for various file types was a nightmare; between VS Code complaining I didn't have one set up (I did), the settings seemingly being ignored, and various other issues, I break into a cold sweat whenever I have to edit my settings file.
But more to the point, I don't understand why one would ever have to edit the file directly when there's already a settings panel that lets you search for a setting using natural language, and get back a list of matching settings. Why doesn't VS Code let you make all the changes from the settings panel, without having to mess with JSON directly?
You should really look in to the difference between opt-in and opt-out. Opt-in respects the user; opt-out is for foisting features that the user might not need or want.
The anti-AI folks should just fork everything at this point, because it's hypocritical as hell to complain about it and use a bunch of stuff built with it. Then you can opt out of society!
I'd say the percentage of stuff developed using AI now is higher than the percentage of pro athletes who use performance enhancing drugs, and there's almost as much incentive to mask it and say "made without AI"
Oh, I use coding assistants every day, just not the one that came with VSCode. Because I want to decide if/which coding assistant I want to use, not whatever VSCode forces upon me. In fact, at many companies, GitHub Copilot is explicitly forbidden.
Not the smartest argument to brand this as anti-AI.
I really like the Copilot autocomplete across multiple symbols in the file (e.g. predictive edits that you can tab through).
For most other stuff I prefer Cline/RooCode/KiloCode, but sadly it doesn’t seem like any of those offer similar autocomplete (Continue.dev did with even Ollama support for local models but the whole plugin was a buggy mess and it didn’t work well). Oh and sometimes Claude Code or Codex is nice in a terminal directly.
Personally, I don’t mind something being there by default (same as how JetBrains has their pre installed plugin and also something like Junie available), as long as it’s easy to turn off or uninstall.
Similar to how I wouldn’t scoff at a Git integration plugin even if I prefer to use Sourcetree or GitKraken.
In my experience it’s people with “agents” mass editing their code, in their 10th attempt to convince their tool to do what they want it do, are people with a disrupted workflow, in a constant struggle with their tools.
Is there any reason to expect there would be "toxins", given that it's just water? I can imagine how there might be accumulated toxins it's a pack of chicken breasts left in a hot car for 8 hours, but if it's water it should be fine? After all, boiling water is a tried and true way of making water safe to drink.
Yes, there are substances that slip through, but it works well enough for most cases that it's probably fine. Otherwise you get into weird edge cases like "what if there are prions in the water?!?" or whatever.
Heavy metals are a big problem, especially from cheap brass fittings common in outdoor water hoses.
Indoor plumbing, by contrast, uses copper and/or plex tubing and so there’s near zero risk of metal poisoning (caveat on cheap plex fittings- don’t do that.)
I agree with everything, just want to add a downside of proton which is often forgotten: there is no search. You cannot search your emails’ body (headers work, but keywords like “from:” still do not work for search), you cannot search the content of your files, etc.
It’s the price of end-to-end encryption.
The only workaround is synchronising everything locally and searching locally.
But you still can use Thunderbird for that. I recommend it no matter what mail provider is used. Web interfaces are so heavy nowadays, compared to that, Thunderbird feels so fast.
yes, so I can search my emails solely on my laptop if I install proton bridge and synchronize 50GB of emails. And in case you have ever tried to search 50GB of data with thunderbird, it’s slow.
I tried synchronising the data directly in the browser, without any email client and the search is mediocre and slow.
This is not a great experience for search.
But again, it’s not a critique of Proton, it’s just how it is with E2EE. At least it demonstrate they are really doing E2EE.
I still hope some time in the future homomorphic encryption will help, but I think we are at least a decade away from that.
This is a problem of encrypted storage in general (and hopefully homomorphic encryption will solve that), but I knew this and for me that is a feature, not a bug. I use 2-step password auth (NOT 2FA) explicitly so no one can read my emails without my consent - not the provider, nor the government.
I am assuming that the second password is like decryption key.
I have saved the second password as "mailbox password"
The way I interpreted is that first password is for the account, so verify I am who I say I am.
But since the emails are encrypted, browser can't show my messages in human-readable form.
Second/mailbox password decrypts it and shows the emails in human readable format.
This is just a guess.
I would love to hear about second password from other/more knowlegeable folks.
Proton does not have access to your email contents, no matter if you use one or two passwords. They do not have you password, neither the first one, nor the second one, they have a hash of it, to be able to verify you have types the correct password. Only the actual password (the first one or the second one) can decrypt email content. Decryption only happens in the browser (Or in the proton app).
Of course you need to trust them on this, it’s difficult to verify, but it as been audited multiple times.
The second password is an old vestige of the time where they couldn’t manage to use a single password for both authentication and decryption.
I use the second one as well, but I use it so I can use VPN on some common devices the family use as well, without having to enter the second password. So if the family device is lost or compromised, only my first proton password has ever been used on it.
Agree with everything in that list (and made many of these mistakes myself) but actuators (e.g. Shelly) in the wall behind actual switches were the exception for me. Especially for things which were not light switches, like blinds, sky lights, pumps…
I would agree in general, but in this specific case it’s still an advantage for the iOS platform in general. It just removes a buying incentive for the AirPods.
The general problem is that there must be a line.
Vendors don’t create lock-ins because they are malicious, they create it because it makes them money.
Now, if we limit these lock-ins, it will reduce their ability to make money and yes, it will impact some features - short term.
But looking at it long terms, vendor lock-ins are actually a reason to stop innovating: your customers are locked in anyway.
So, overall, I would say this is good for innovation in general.
I actually have a problem with this. I want AirPods to be undeniably the best experience for me because I am fully locked into the Apple ecosystem, and I know many folks have complaints against that. I find it to be rather pleasurable to use compared to all the other alternatives out there. So if I have to start sacrificing my experience in favor of universal support, that really sucks.
But this isn't sacrificing your experience, you're free to keep using your Apple AirPods with the quality and reliability you'd expect from Apple. This just means other brands can create products with similar features to AirPods, and if they're not as good or reliable, well that's why you're paying Apple for theirs.
It removes incentives to differentiate a platform because the EU will just come in and make every company exactly the same by forcing others to allow other companies access to their R&D budgets. Why bother? It’s easier to just avoid the EU market
The best code is no code. Every line of extra code added, and every extra platform supported is potential for more bugs, which has the potential to affect my user experience.
I'm not seeing an incentive structure for them to change being the only source of good workflows for their users - it's their whole thing "It just works" - regardless of if it's true in practice or not.
If you want the "it just works" experience, you can still buy the Apple products though, that's not changing. You just also have the option to not do so.
which other company spends as much investing in UX? there is not a single other company on the planet with as polished of a user experience as apple, so who would develop a better workflow?
They did their initial AirPod implementation in a pretty insecure manner because it was securely locked to their hardware and they could trust themselves to not be malicious. If they have to build a feature, plus all the security around it, plus documentation, etc… it makes it much harder to bring to market. They may opt to skip it in favor of something else.
the long term innovation outlooks are still better, so you benefit long term as well.
It’s just less obvious / measurable that immediate benefits.
And also, short term, isn’t it that other EarPods are getting better, rather than AirPods getting worse?
Medium term, I don’t think that Apple will stop innovating on AirPods just because of the EU market and this one feature not being exclusive to AirPods anymore. But it’s a possibility, I agree.
Thanks for the data. While it does need more cross referencing it would indicated that deceased drivers are more than twice as likely to have traces of THC. We need to eliminate non-drivers but I think the proportion of drivers with traces of THC will remain higher with drivers than in the overall population.
Next, same stat for alcohol, that would be interesting.
Maybe adapt the THC threshold a bit to really only count people who recently consumed THC.
reply