As I mentioned it is to reduce dependency on CI tool. You may have to shift the tool in the future and if you use a lot of commands specific to the CI tool, that is going to be a nightmare.
Ansible is agent less and only needs SSH access. You can SSH into your local system, from the same local system. Need to add few entries in your SSH config and known_hosts. Essentially everything in Ansible are shell commands. So you are not really that much locked into Ansible.
On the question,
Does that make running it locally easier?
If you mean making it easier compared to remote, on the surface level, the answer is 'no'. But it makes CI pipeline easier to run independent of your environment. Ansible is here to reduce dependency on a specific tool.
Bonus point is you can also create a working but basic CD system with Ansible.
Regarding SSO my concern is not the ChartDB team having my email, that I was planning to give anyway, but SSO provider knowing I'm using this tool. It's a personal paranoia than anything else. I know it's much safer and easier to have 3rd party SSO than managing your own authentication service. Done that, hated it. So not really that annoyed about it.
The Mac only part really annoyed me to the core. Then I received an email telling about Buckle, which amplified it. I think the problem is you advertise it as 'ChartDB 2.0' and then suddenly it becomes 'Buckle'. I can understand the thought process behind such presentations, but really don't like it. TBH I would not be this mad if a similar tactic was used by a large corporation. But being an open source tool I have some ethical issues with these practices.
Again, I know these are just some inconveniences, and not a scandal. So not really complaining, but just sharing how I felt. Apologies if that has been rude.
I have some critical comments not about the tool, but about another related stuff. Please look at the next section for doubts and suggestions.
The tool need to be more clear and less annoying about ChartDB v2.0.
So this is shown as some big rework, so I signed up. Only then it said only MacOS would support it initially. This was a huge disappointment and I felt kind of deceived into giving my email id I don't remember seeing it's only mac at the beginning on the sign up page. May be I missed.
Another thing is it looks like a different product altogether with the name 'Buckle'. Again I didn't see it in the sign up section. Why a new product name? Are you switching to freemium model?
Last but most importantly, why does a third party sign up for it? If you just want to inform the user when things are ready, just take the email and use it. No need to have access to my Google or GitHub account.
Apart from this terrible experience, I love the tool and how it visualises it.
I have a doubt. When I visualised my postgres db it also showed the views I had, apart from the tables. But I could not find an option to add a new view from the interface, so that I can use it as a more capable design tool. Is it a feature in the pipeline?
Also I could not find an option to set the length of Type: varchar. I remember seeing this feature in other design tools.
Sorry for the delay. I got busy. I'm not entirely sure this is a dynamic registration issue. Your screenshot points to something like a permission issue. This is a bit wild guess with very limited information.
Do you have any info saved when you attempted to register the client manually and use client id and secret?
I will try to do some tests when I get to my setup. Do ping me if you have any updates.
Oh, so no separate config is used and only env variables I guess. Is it possible for you to get the URL your app is requesting? If yes, please share a sample.
Also double check the realm name. I assume you created a new realm for your use and not using master.
I think I got the idea. So essentially a new copy of the file is created and stored only if there is a change, else it just refer to the older SHA. Am I right? Now I understand why LFS was needed for binaries, else it createds a lot of storage problems, but not the huge monorepos.
I'm not a developer, but a design person who covers much more including architecture. But in my org I happen to teach developers how to use Git. Strange, I know. But that is the case. It gave me a good opportunity to learn Git in depth.
I went through your blogs and patch stack workflow. I have to say that I have not been happy with the branching workflow and I always felt that is not the best (I agree to the point about "unjust popularity"). The patch stack workflow makes more sense to me. Unfortunately we won't be able to adopt, since getting everyone to Git itself was a huge effort. Also developers are not that keen into creating good code, but just working working code. I'm extremely frustrated with that.
Also your blog design is really good. I love it. I always wanted to create something like that. But never managed to sit down and do it. Can you give me a brief about the tech stack used for the blog?
Do you use RNote for diagrams? The style looks familiar. Or is it something else?
Aah. I assumed linting was part of the build also. My bad. I did understand the idea you were mentioning. Just that assumptions kind of threw me off.
I wanted to ask something related to that. As you mentioned, git takes a snapshot of the repo on every commit. So splitting up the bug fix and other activities means you have 3 or 4 commits instead of one. Let us say we are dealing with a very large repo. This does not look ideal in that context right? So do you think the way you proposed is only suitable for smaller repos?
Oh, never heard of amnezia. Never needed actually. But it looks like a good improvement on Wireguard. I will need a separate setup to test it out and currently I'm away from home with no clue when I will return. If I happen to find anything, I will definitely ping you.
In the HN page you linked many people mentioned v2ray. Have you tried that? How good is it?
Have you considered having Headscale on a cheap VPS? We are actually doing that and it is pretty capable. IIRC, you can configure not to use the tailscale servers at all, and use your own public VPS for coordination. Bonus point, tailscale hired the Headscale developer and maintainer, and they are allowed to work on Headscale while on their payroll. The team looks very much into FOSS.
So this bit confuses me. The article says in the intent and scope section that the entire process of bug fixing, in the included example, is literal bug fixing, clean up toggle, correct lints, correct duplication. That point to linting issues.
The earlier section says that a commit should be 'buildable' and 'testable'. So if there are linting issues, the commit won't satisfy this criteria right?
Oh, I was not aware about the 2022 policy. Thanks for sharing. I completely agree with the last point that if they retain the '.io', it will be a complete opposite of the written policy.
My company has a '.io' domain. We have to plan for the scenario of '.io' getting retired, I guess.
What is the rationale for all comparisons returning false for IEEE754 NaN values?