Very cool. It would be good to support multi touch, letting the user instantly switch to another noise by reacting to the latest finger. You would need to use viewport meta to disable page zoom as well.
Building the open source repo gets you something which isn't VSCode. It doesn't install a lot of VSCode extensions, therefore you shouldn't call it VSCode and shouldn't say VSCode is FOSS.
This is very well put. If the open source repo was named "VSCodium" it would communicate better what is going on. (Chrome / Chromium.)
Edit: to be clear, I think Microsoft should offer VSCodium themselves and state clearly that they take that, bundle it with other stuff, and are calling that blob VSCode.
You can't use Gitpod, Theia IDE, etc with Pylance. Or GitHub Copilot. Or Live Share or numerous other VSCode extensions.
The idea is people start a project in VS Code, need to scale up to a reproducible dev environment for multiple users, and follow ads in VSCode to GitHub Codespaces, which charges by the hour for VMs. Now you're locked into that, you're locked into GitHub as well, and they can cross sell you GitHub Actions, GitHub Advanced Security &etc.
Therefore, Pyright is almost the minimum needed to add type checking to your CI process.
Edit: to clarify, not only is Codespaces advertised in VS Code, it also uses private APIs so no competitor can publish an extension which replicates this functionality on the VSCode marketplace.
Like I wrote here [0], corporate has an azure subscription. All the companies code repositories already live there, including build automation. A capable vscodium isn´t going to eat into Azure baseline.
I don´t think MS is after solo hobby devs. For startups they have other incentives to lure them into their ecosystem, like free Azure credits.
And that is why open source projects on github are free too. Because the paying organizations depend on the free software ecosystem, build by volunteers in their free time. MS wants control [1] about that nonetheless, because not having that is a risk to their baseline
1. That is not necessarily harming libre software per se, but keep in mind that MS is only interested into OSS as long as their commercial customers depend on it.
Not really. The idea is to split work into separate stages which are reviewed separately, but as a whole.
In the example: "small refactor 25LOC -> new API 500LOC -> migrate API users 50LOC"
Making a PR of the small refactor will probably garner comments about "why is this necessary".
Opening two PRs at the same time is clutter as GitHub presents them as separate.
As well, sometimes CI won't pass on one of the stages meaning it can't be a separate PR, but it would still be useful in the code review to see it as a separate stage.
I'd be quite happy with seeing the three jobs in the article as three separate PRs. Fixing a bug and adding a feature are two jobs that, as I think we all agree, need to be tracked individually - so work on them individually.
> As well, sometimes CI won't pass on one of the stages meaning it can't be a separate PR
Could you give an example of this? Not sure what you mean.
By doing this, you break commit atomicity and make bisects hell. Please don’t do this. Commits aren’t perfect at first for sure, but they should be by the time you make them reviewable.
I completely disagree. In doing so you lose all visibility into the components and gradual evolution of the code that atomic commits provide. Same thing with squashing (which is just the worst).
the comments about "why is this necessary" can be handled with a decent PR template, and a comment.
What I tend to do is make the changes locally with different commits and then cherry pick the refactor into a PR branch and wait for that to be accepted. Then I rebase the FULL branch with "master" after the merge and create the PR.
Maybe not. I recently did the lengthy CPSC form, to report a defective new name-brand microwave oven unit, which was manufactured with a 1/8" mis-seating of parts, where I measured with a professional meter to be leaking much more than anywhere else.
A week later, I heard back:
> [...] The product or particular concern that you describe does not fall within CPSC’s jurisdiction. You may wish to contact the agencies listed below, which we believe can best handle your concern.
> U.S. Food and Drug Administration Center for Devices and Radiological Health Document Control Center – WO66-G609 10903 New Hampshire Avenue Silver Spring, MD 20993-0002
(BTW, I suspect the process apparently not forwarding a report between two agencies will result in some problems falling through the cracks. And it did, in this case, since I stopped holding the defective unit (I'd asked in my report that they let me know if they wanted to examine it), returned it to the store, and never looked into starting over the reporting process with a different agency.)
Like I said, I’m comparing the extra year to situations where products shut down immediately without an extra year. You would agree that having an extra year is better than not, wouldn’t you?
Yes, people are pointing out that “it could be worse” is a cruddy thing to say. It’s bad! It could always be worse, but there’s no point in saying so. Continuing to harp on “it could be worse” is not helpful. It sounds like you are disagreeing that it’s wrong and bad to disable future use of a product that is locally installed and not a subscription.
Thank you for acknowledging that my comment is being misinterpreted and that it could be worse. Of course it’s bad, the product died. That sucks for people who like Finale, sucks for people who paid for it recently, and it sucks for MakeMusic too! That simply does not justify attacking or disparaging the developer, nor making assumptions about their motivation, nor making unreasonable demands about how they handle the transition.
What do you actually want? Do you need to convert your Finale library? By nearly all accounts, Dorico’s a massive UX upgrade and being offered at a 75% discount. I haven’t used it, but I just don’t understand why the pitchforks are out, especially when I’m not hearing many personal stories in this thread, so that makes it seem like bystander outrage where the bystanders aren’t invested.
There is nothing unreasonable about the demand that continue to make software that they sold installable by the owners. That's completely reasonable. It's actually far more unreaonable to sell someone a product and the next day make it unable to be reinstalled. That's unreasonable. I would even hope that would be illegal; it's too bad it's probably not.
> It’s actually far more unreasonable to sell someone a product and the next day make it unable to be reinstalled. That’s unreasonable.
I agree. So does MakeMusic, I guess, which is why they have at least a 30 day refund, and a whole year before new install authorizations end. I feel like I’m being misunderstood and misquoted and you’re arguing against things I didn’t say. I agree that losing access to new installs of Finale after a year sucks. I understand why paid users are angry. I assume the no re-auth after a year part could be a non-compete stipulation in their agreement with Steinberg. If most current Finale users value the ~$450 Dorico discount, maybe it’s worth the blowback, otherwise, maybe not.
If you agree that losing access to new installs after a year sucks, and you understand why paid users are angry I don't know why you keep replying. This is an unnecessary user-hostile thing to do and, in my opinion, should be illegal. If you sell a product, you should not be able to post-sale revoke access to that product. This is even more cut-and-dried than products that rely on servers for actual functionality.
I’m replying because we’re having a discussion, and because it has been clear all along that you didn’t quite understand my position before arguing with it, so I’m trying to better explain it. I do agree that losing access sucks, and I do see why some paid users are angry, so maybe you don’t actually disagree with me after all. Maybe it should be illegal to turn off new installs after a year, I could agree with that in some circumstances, but you continue to exaggerate and oversimplify the actual situation which doesn’t help, and this feels purely dogmatic now and not particularly real-world. Leaving the auth server on is unlikely to benefit very many people. In both directions, it seems more symbolic than functional. If they turn it off, hardly anyone will be affected but maybe it appeases Steinberg, and if they leave it on, hardly anyone will be affected but maybe it appeases internet mobs.
They should just remove the need for the auth server entirely. Whether or not it benefits very many people is beside the point; it's the principle. Allowing their users to continue to use the product that they have fully paid for is morally (and potentially legally) the right thing to do.
Yes I see your point is a principle you have and that you aren’t interested in discussing any nuance or details. I have heard and acknowledged your opinion multiple times that they should not disable the auth server. I understand that and I’m not disagreeing with it, so there’s no need to keep repeating it over and over unless you have new evidence, reasons, points to discuss.
For MakeMusic, I don’t know, but whether it benefits the most Finale users may be the entire point from their perspective. And it might matter to the users too, even if it doesn’t matter to you. The dev’s principles might prioritize maximum benefit for the most users over the anger that shutting off the auth server could potentially lead to. They are offering a tradeoff for which there is no perfect solution for everyone. Leaving the auth server on but not offering a Dorico discount might be overall significantly less good than what they did, even if what they did isn’t perfect or agreeable by your standards. That possibility is interesting and worth considering to me, even if not to you.
I see your point. But it actually concerns me more if the Dorico discount is contingent on explicitly preventing re-installs of the app. It's one thing to be merely negligent in providing a way for users to continue using the product but it's another to purposely revoke access as part of a deal that the user didn't agree to. That actually borders on shady to me even if you could spin it as a user benefit.
The app's useful for audio posts. But mostly it's just an extra chance for them to make money. Push notifications, the home screen icon, etc. Most people I know, their inbox is barely functional due to the marketing emails, and they're reliant on features like Gmail's "Important" which only highlights real people, not Patreon content.
You're not the average user, and if the average user gets a billing email and hasn't bothered to read their content email, visit the site or open the app, they are more likely to end their subscription.
There's another erm... "creator oriented" Patreon-like service that works entirely through the web. Specifically to avoid Apple and Google's cut. And they seem wildly successful, although perhaps the type of content may influence user's decisions.
I made a very simple PWA and every time after reboot I have to re-log in. Of course, the browser will auto-fill my password but same page as a PWA it won't.
I also did some testing with macroquad [1] and I was finding that occasionally as a PWA the GL stuff just didn't work. I suspect Apple was disabling the GL stuff in the PWA as an anti-fingerprinting technique; there's no way they do anti-fingerprinting for an app.
---
PWAs just can't do the same things that native apps can. This is probably intentional otherwise who would give not only 30% of their revenue but allow them to be a middle man between them and their customers?
PWAs are only able to be limited by technical measures, not business measures. For instance, anti-fingerprinting logic wouldn’t be needed in an App Store. There, Apple can say if they find out you are fingerprinting users without going through Apple’s specific ATT user consent process, you are in violation of our developer agreement and may be permanently banned from the store.
Each update of an app is reviewed, while a website can change completely at any moment (or have different versions served for different people). This is why for instance web extensions are heavily reviewed and audited.
This means they are pretty fundamentally different models.
The prompt for location is different for example because Apple enforces you are using the location information you gather for a specified reason, and has the aforementioned business penalties for misuse, and has tied all that to a real world identity. The browser can’t know if the page asking for location data is for mapping, for marketing tracking, or so that someone can drive to your home. The two features are going to look and behave distinctly.
I know PWAs can't do many things that apps in general can. But people were suggesting that Patreon should just be a website and not an app. And that's why I said PWA. If you can be just a website, you can be a PWA and be a bit better than just a website.
Given Apple's back and forth history allowing or not allowing and limiting or not limiting PWAs, I'd be hesitant to risk my business model on them. Which is exactly what Apple wanted I guess
Aside from many users not being familiar with PWAs and not wanting to install them, I believe they’d also have to drop support for older iOS versions, as for example PWA push notifications were only added in iOS 16.4.
reply