rarkins

1. Set a default label for issues (e.g. “autoclose”) 2. Make your auto closing and locking logic based on that label (eg the label-actions github action) 3. As a maintainer, remember to remove the label when creating an issue!

This seems to me to be the most likely explanation. Someone important and/or rich wants something memory-holed and the archive sites are amongst the last to contain the content, so someone else is creating a facade organization as an attempt to get it taken down in every way possible. And yes it's entirely possible that the archive sites have multiple "enemies".

I posted something similar to X yesterday: https://x.com/rarkins/status/1966785560556511489

What was even worse than there being dupe ChatGPT apps in the Mac app store was that Perplexity and Gemini both recommended installing chatgpt dot macupdate dot com as if it was the official app.

Hi, Renovate author/maintainer here.

The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is:

1. An attacker had write access to the tj-actions/changed-files repo

2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate

3. Important: this spoofing of commits wasn't done to "trick" a maintainer into accepting any PR, instead it was just to obfuscate it a little. It was an orphan commit and not on top of main or any other branch

4. As you'd expect, the commit showed up as Unverified, although if we're being realistic, most people don't look at that or enforce signed commits only (the real bot signs its commits)

5. Kind of unrelated, but the "real" Renovate Bot - just like Dependabot presumably - then started proposing PRs to update the action, like it does any other outdated dependency

6. Some people had automerging of such updates enabled, but this is not Renovate's default behavior. Even without automerging, an action like this might be able to achieve its aim only with a PR, if it's run as part of PR builds

7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design

Instapaper user here, with same questions

Renovate's TS tooling seems to work fine otherwise, and for ts-remove-unused as a new tool wanting to get adoption then you should be aiming to work the way your users already work, and not fail + tell them that they are the ones which need to change.

BTW the VSCode extension which someone else linked to discovered everything perfectly, which is another hint that your tool needs to improve, not your users.

Even if tsconfig.json was very important, and the users are all wrong and you're right, the only thing your readme says is: "The CLI will respect the tsconfig.json for loading source files." which is insufficient.

I tried it on https://github.com/renovatebot/renovate

It deleted 100s of files, most of which were Jest test files, and potentially all of which were a mistake. I restored them all with `git restore $(git ls-files -d)`.

I then ran `tsc` on the remaining _modified_ files and `Found 3920 errors in 511 files.`

Obviously at that point I had no choice but to discard all changes and unfortunately I would not recommend this for others to even try.

I'm surprised to find there's not more demand for "back to back" travel wifi routers, e.g. so you can connect once to a hotel wifi and immediately all devices are connected via the router's own wifi. This is useful not just for working around device limits but also for simplicity of setup when you have kids.

I don't understand this graph. Weren't there 85+ startups in the class of 2019, example? https://techcrunch.com/2019/03/18/here-are-the-85-startups-t...

But the graph shows 0/2

From https://www.marketscreener.com/quote/stock/PALTALK-INC-11131...

On June 30, 2022, we entered into a License Agreement with Visicom (the "License Agreement"), pursuant to which we agreed to distribute, at the discretion and direction of Visicom, a specified number of ManyCam software updates to certain license holders to whom Visicom has previously granted a "lifetime" license to ManyCam software. As consideration for distributing the software updates, Visicom paid us an initial upfront nonrefundable payment of $65,000. The License Agreement provides that Visicom may purchase additional licenses at prices specified therein. Other than providing a one-time, limited license to Visicom for the distribution of ManyCam software updates pursuant to the terms of the License Agreement, we do not have any obligation to provide support or service to the licensee end users.

This seems relevant: https://contracts.justia.com/companies/peerstream-inc-2967/c...

Visicom really pumped the ManyCam lifetime upsells. I found 15 emails over an 18 month period in 2020-2021 with them pitching lifetime (which I eventually bought). An example email text they used is:

Upgrade now to ManyCam Studio Lifetime for only $39 and get access to all the future versions and updates, forever!

What they presented to the user was unequivocal. In a just world, the company who sold ManyCam (Visicom Media) should not be able to get away with this.

What do you mean by "the included dependency checks"?

If you're referring to Renovate, there's no such paid option.

If you're referring to GitLab paid features, I'm not sure how that's any different between tools.

Disclosure: Renovate author

Renovate is indeed AGPL, but if you're just running it as a CLI, do you think there's anything to "watch out for"? It does not make any project you run it against AGPL, that's for sure.

Also you should be aware that dependabot-core, which dependabot-gitlab wraps, is not technically Open Source at all: https://github.com/dependabot/dependabot-core/blob/main/LICE... Wrapping a non-open source project in another project which claims to be MIT licensed does not change the underlying license. I'm not a lawyer but question the validity of them doing this without larger disclaimers.

However, I think that it's likely not something to "watch out for" either. Likely both licensing approaches were intended as a way to forbid or discourage competing services and each project welcomes people self-hosting.

In short I don't think that the license of Renovate or Dependabot is likely material for anyone planning to run it for themselves.

Additional background/details: https://twitter.com/rarkins/status/1574859892359368708 (thread)

This is interesting. It would be fun if one day contract negotiations were two people in their respective browsers moving HTML sliders back and forth across the “permissive” scale for each term (days termination notice, SLAs, etc).

Yarn’s offline support is not directly tied to PNP. Yarn v1’s support for “offline” installs was a day one requirement, and as I understand it one of the primary drivers for Facebook engineers (at the time) to drive the creation of Yarn.

If offline installs is what you want, I don’t see any advantage of node_modules compared to this feature - only disadvantages (size, noise, and cross-platform incompatibilities).

I agree. youtube-dl was another example of them turning a vulnerable moment into a win: https://twitter.com/natfriedman/status/1328365679473426432

Yes, rename out of pragmatism: there's no point retaining the friction/confusion which would persist forever