I could be mistaken but if I understand correctly, this is similar to how the TfL is run. If it is, this will be a huge boost and is a step in the right direction. TfL has its faults, but, in my experience, it is a thousand times better than anything the franchised train operators have been able to deliver.
Maybe it's time for developers to help with the fight back. Break things in Chrome, and encourage people to use Firefox. The amount of time I've been told to use Chrome is ridiculous. I regret being part of the crowd who jump on the Chrome bandwagon when it came out all those years ago.
Having to explicitly opt out regardless of what you do is terrible. So now you're telling me that I have consciously disable it every time I create a new website/page? How do we force Google to stop this?
Terraform 0.14 is pretty much fully compatible with 0.13, so no such command is necessary. All you have to do is make sure your state is for version 0.13. Outside that it's a bunch of usability changes that do not affect your tf code.
> What I want: Use Terraform programmatically, i.e. call "cdktf deploy" or similar FROM node or python and give users some scripts they can use where I can abstract away some of the difficulties of learning to use Terraform natively for simple use cases (i.e. deploy an S3-based frontend host).
Maybe not node/python, but I'm pretty sure you can use terraform as a package in go. If not, there is always the "make temp dir, write/download files necessary tf files, run terraform apply"
You can use tfenv to upgrade individual workspaces one at a time. You don't need to do a big bang upgrade.
Note upgrading to 0.13 is quite easy and terraform actually has a subcommand that does most of the work you (usually no additional steps required).
> I am already looking around for some way to remove Terraform from our org because it is slowly strangling our productivity.
The only other alternatives you have are Pulumi. All other alternatives are in my opinion, way worse. You can use ansible, which I'd even worse because you have to manage ansible version upgrades and have no way of figuring out what changes will be made (yes, --diff is usually useless). You can manage manually, but good luck. Lastly your option is CFN (or Azure/GCP equivalent) but then you have no way of managing anything outside of the cloud environment.
Reproducible infra, gitops, automation and much more.
For me, the biggest thing is, when I go into AWS I struggle to find everything that is intrinsically linked to another resource. Say you have a lambda, to find which iam is linked to it, and what permissions it has is 2 separate tabs, then another for e.g. security groups, probably more tabs for other things. While using aws-cli makes it slightly easier, it's still a lot of effort to do this effectively.
With terraform I can look in one repo that has all the above, often in the same file too. Finding out what your infra looks like is a lot easier.
Regarding the state, you should not be touching your infra outside your code, if you do (e.g. while you're testing in dev), you should make the same changes in tf once you've confirmed it's what you want, and otherwise you undo those changes.
With further automation (e.g. tfcloud) you can even enforce these things by auto applying workspaces which ensures manual changes are always undone.
One thing I absolute hate about magic in code is that it's often done at runtime. Considering the idiomatic way for go is actually have code generated and checked into git makes a huge difference.
Thank you, I'm aware of the Linux client and it got me excited when it was announced, however since switching, OSS has become more and more important to me, so it's unlikely that I'll switch back.
Bitwarden. One of the big reasons for doing so was because when I left my company, they took my Mac away from me, so I invested in a new laptop, for me there was no way I was going for Windows or Mac. So Linux it is. 1Password at the time had extremely poor support for Linux - no desktop client, their 1PasswordX was missing a lot of features and was super slow too.
I switched to Bitwarden because it's open source, and because they have a good enough Linux client. Their browser extension and desktop client doesn't come close to what 1Password provided on Mac, but it does the job.
Bitwarden isn't without its issues, but at $10 a year, and its open source nature, it's worth every penny and then some.
> It is so common in SPA that the long-press of the back button to see the list of recent sites should be muscle-memory by now for everyone.
This is not a good excuse for laziness.
> But not ever using a site because of it seems silly when it's literally a half-second longer click.
I highly disagree. With this site at least it is actually possible to leave. Many websites I've come across with this issue, it is entirely impossible to leave without physically holding down the back button in the browser to get a list of history items, and then clicking a site from earlier.
> (Also, for this site I don't actually see the bug. So either they fixed it very rapidly, or GP was just referring to individual searchers being in the history, which is common for any search engine.)
I'm assuming he's referring to their beginnings of being a mostly local password manager (iirc they also had a one-off lifetime purchase), to forcing people to migrate to their cloud only infrastructure with a relatively high subscription price.
I'd never heard of 1Password before they were fully SaaS, but as I understand it, some of the original users were pretty upset with this move. Either way, I used to be a 1Password customer, and their product, at least on the Mac, was the most polished password manager.
This kind of thing is enough for me to never want to use a site. If it's a bug, high recommend you fix it, if it's not, highly recommend you reconsider your position.
I don't know about you but having to prefix every line of what I'm assuming is something similar to heredoc with `\\` doesn't seem simple to me. It's as bad as having to suffix each line with `\` to escape new lines. That's an odd design choice and horrible UX.
Also requiring the provide the type every time you retrieve an element from a JSON string again seems odd. JSON already has the data type, why do I need to provide the type every time I retrieve the data?
Their software and hardware are open source. Far cry from alternative android tablets. Either way, building a tablet, even based on a raspberry pi, is no easy feat.
One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when prompted).
We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use. Forcing user interaction at worst raises awareness, at best prevents the privacy of individuals from being invaded.
Do you have more information on this? A link maybe?
EDIT: Never mind, found it - https://github.com/bitwarden/desktop/issues/552. This isn't exactly an RCE. You can say the same about anything. By your logic Microsoft auto-updates are RCE. Same with pacman/apt-get/yum package managers. Same with pretty much anything else.
I'm not saying they're not valid concerns, however, if you're this worried about all of these things, maybe cloud-based software isn't for you.
The few tickets I've been interested in, their answers have been along those lines. I've mentioned this before, but Bitwarden has been broken in Firefox's private mode, and to this day they're just blaming it Mozilla for deprecating some APIs due to privacy concerns. Mozilla has given a safer alternative, but they're refusing to fix it. Someone even raised a PR to fix it, but they had some feedback. The PR has since gone stale.
> The server sees what domains you have passwords for.
The server does not see the domains you have passwords for. The following data are saved in plaintext:
- A list of "equivalent domains" (this starts out with a default list, but individuals can change this). This totally can be used to deduce which websites you have an account for, but that's not really enough information, as most websites will not have an entry here.
- Some metadata such as your email, master password hint
- Most of the boolean values (mfa enabled, email verified, premium)
- Custom field types (types only, field name, and value are both encrypted)
- Revision date
- Bunch of UUIDs
Here is what a single password entry looks like when retrieved from the /sync endpoint, which happens before decryption: https://pastebin.com/FLr19qiN
> You have to trust the server also if you use the web client because the web client is loaded from the server.
This is true! However, the android app, cli, and other clients do not get loaded from the server, thus, in theory, you can inspect the source of them, possibly compile it yourself, and use that. In those scenarios you do not have to trust the server.