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?
Sadly most users don't even know that they are using Chrome or Firefox or that these have a version number. So breaking up things for them won't help, they won't make the switch...
It has to be a regulatory decision imposed on Google, much like when Microsoft was forced to do something about Internet Explorer long time ago.
> 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"
That's good to know at least; will give the go API a look. The latter option you're recommending is essentially what I went with (Node bin script that shells out to run cdktf commands).
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.
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.
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.
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.
Yes, this. I don't have any problem with paying for updates, or even really a subscription. I have a problem with their hard push to "use our cloud", burying the abilities to not immediately create a cloud account, and the way they respond to customers in their forums when they ask about non-cloud options.
It's exactly this - the original switch to SaaS was a high price to pay for basically what you already had if you had local sync/dropbox setup.
They finally fixed many of the objections with the "family" SaaS subscription and it just works and the price may be "low enough" that I don't bother figuring out a way out of it - but it is still pretty much the perfect example of "locked in".
What do you mean by locked in? When I think of locked in, I imagine it being hard to cancel and move to another service. I switched to 1Password last year from LastPass and the first thing I checked was the process for exporting my data. It seemed on par with LassPass, which was very simple, so I made the switch.
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.
Thanks for sharing. I’m sorry it took us so long to release a native Linux app. We have a great app for Linux now in beta and will move it to an official release shortly.
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.
You can self-host this unofficial version https://github.com/dani-garcia/bitwarden_rs if you prefer. maybe not worth $10/month of your time amortized to set up, but it has been fire-and-forget for me.
My kids have started accumulating more passwords than they can memorize (and their memorized passwords were terrible), so I wanted a family password manager. I considered using "1password for familes" which I have access to for free from my day job, but if/when I leave the company then I'll have to go back to paying for it. So far I greatly prefer the experience of bitwarden over 1password. I use the web vault, the native mac app, and the linux command line app (through a janky homegrown dmenu/xclip shell script), and I have no complaints at all.
I used 1Password for a long time. When they shifted to the SaaS model I left angrily. Over time I tried out several other programs such as Enpass (came close to the original 1pw), keepass varieties, Bitwarden but found myself back at 1Password this year.
One big thing, which funny enough is another dark pattern I guess, is the family account feature. I allows me to take family members on and we can share certain passwords and I think even help recover an account. This is also important because 1PW is the most easy to use password manager and my mom was really struggling with Enpass.
A new feature that adds value is not a 'dark pattern'. Lets not be dramatic.
Even moving from one-time to subscription isn't a 'dark pattern', its a business model move to shift to recurring revenue, which we know is something that businesses need to keep the lights on. You can debate the merits of it, but it's not a dark pattern in and of itself. HOW they execute that might be, but the change itself isn't. You just have a personal preference to not want to pay for it in a particular way.
> A new feature that adds value is not a 'dark pattern'. Lets not be dramatic.
Family plans are in my eyes. They log users more into the platform and makes it very difficult to switch. If you want to move away from Spotify, you now have to convince enough of the others to make it feasible.
> Even moving from one-time to subscription isn't a 'dark pattern'
I did not claim that it was one. I also was not even mad about recurring payments, to me the problematic change was that the data was now hosted on some other machine owned by the company who is producing the software (e.g. in theory single point of entry).
I'm trying to charitably understand what you're advocating for but it sounds like you're arguing that getting multiple people to use any app is criteria for dark pattern because once they do start using that app, to switch you have to convince them as a group. So.. should everyone use different apps? Or is a protocol the solution?
As far as where data is stored, which sounds a bit like a different argument, I guess what you're advocating for is some kind of peer-to-peer sync solution across family member devices that would work anywhere. That's cool but I think it may a lot of technical complexity vs a cloud solution, and it still doesn't change the fact that you still have the issue above about switching as a group.
It might be worth reviewing what dark pattern actually means - UI tricks to get people to do things they don't want to do. If people like a product enough that they convince others to use it as well, that's ... a good product? I get the data storage concern though.
>to forcing people to migrate to their cloud only infrastructure ... fully SaaS
A slight gentle correction. I criticize them elsewhere in this thread, but in fairness I have to point out that this isn't quite correct yet. It's still possible (though they've buried it) to buy a standalone perpetual license for the latest 1Password, run purely local vaults, or keep syncing via Dropbox, iCloud, or manually over WLAN. There isn't any hard tie to the 1Password.com service yet.
Perhaps they'll put the kibosh on that in the future. And they can be and I will criticize them for not having better local sync options, which they clearly stopped bothering with in favor of their own cloud offering. But for the time being I've still got a fully local 1Password 7 license that works the same as every previous version.
Well, until they intentionally break something like the 1password4 integration with the browser extention. And after asking why it broke they say: sorry you're out of luck but here is a shining new subscription just for you.
Now you're forced to buy the new version just for the integration that has always worked fine.
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.
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.
Yes, it's an annoyance. Yes, sites should fix it. But not ever using a site because of it seems silly when it's literally a half-second longer click.
(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.)
> 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 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?
> 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?
Because JSON is a serialization format, so as such it is external to your code. One day an element in the JSON you receive is a boolean, but another day it's a string, because another system had a bug and started producing junk data. Now in your code it's good to 1. document what type you expect, 2. trigger an error if the types don't match. It also has the benefit that all types can be checked statically, without providing any surrogate input. A schema integrated somehow with the language could be a more optimal solution though. But no schema, and no type annotations in the code is a no-no from me.
UPDATE: Now that I'm thinking about it, I'm wondering why JSON was used in the Zig example at all, instead of using builtin data types. Seems like a really odd choice.
