Brave can make micro payments to content creators based on the number of views to the site, directly supporting content creators without ads or the need to join the patreon for each creator. It’s a fully optional system, off by default but prompted upon opening the browser for the first time. It’s a cool idea but they kind of spoiled it by making it be a crypto wallet with ads to earn the crypto.
Also, Brave doesn’t have a subscription…?
Honestly, despite the crypto, good on Brave browser for trying to subvert the advertising model by providing an actual monetization alternative
Have you used fish? The built-in fuzzy matching works pretty well for me. Wondering if there’s any reason to add atuin in. Sync seems like a negative to me more than a positive.
Rust is a lot more niche and intimidating of a language compared to Swift. Swift is familiar to C++ devs, while modernizing the language and toolchain, and providing safety guarantees.
Also, Safari on Windows had low usage, and was probably a pain to maintain. Swift cross platform is more about abstracting out Apple specific things (like the standard library and UI toolkit). Apple has already been investing multi-year efforts into Swift on the server for longer than Safari on Windows existed. The last couple versions of Swift (~3-4years of development) have been almost entirely focused on safe concurrency, which is intended for server-side development.
Actually, this isn’t true. Apple has a vested interest in cross platform Swift. They’ve been pushing hard for Swift on Linux because they want Swift to run on servers, and they’re right to. Look at how hard JavaScript dominates on the server-side because of one language everywhere.
I’ve worked with Swift a bunch for Apple platforms, am mildly familiar with how it works on other platforms. It should be able to compile on a wide host of platforms with minimal/no issues. The runtime dependencies are localized to Apple platforms, and I think the dominant UI toolkit on other platforms is a Swift port of qt. So it should be just fine?
This is a fantastic write-up, thanks for sharing!
What’s wrong with Business Insider? Genuine question
You declare it in the package.json as a category when publishing. It’s completely self-selected with no oversight, review, or enforced permissions.
I believe they’re referring to lower down in the article, where the researchers analyzed existing extensions on the marketplace:
After the successful experiment, the researchers decided to dive into the threat landscape of the VSCode Marketplace, using a custom tool they developed named ‘ExtensionTotal’ to find high-risk extensions, unpack them, and scrutinize suspicious code snippets.
Through this process, they have found the following:
- 1,283 with known malicious code (229 million installs).
- 8,161 communicating with hardcoded IP addresses.
- 1,452 running unknown executables.
- 2,304 that are using another publisher’s Github repo, indicating they are a copycat.
I use Jenkins for work, unfortunately, so I have plenty of experience
FYI, Jenkins has an endpoint to validate the pipeline without running it, and there’s a VSCode extension to do this without leaving the editor: https://www.jenkins.io/blog/2018/11/07/Validate-Jenkinsfile/
FYI you can (sorta) redirect searches from the start menu: https://www.windowscentral.com/how-let-google-handle-cortana-web-search-results-windows-10
Mine all go to DDG in FF
I feel the same way. Designing good, opinionated APIs is HARD, but it also provides the best experience for both the author and the consumer.
Among other examples.
In a world where your IDE and maybe also compiler should warn you about using unicode literals in source code, that’s not much of a concern.
VSCode (and I’m sure other modern IDEs, but haven’t tested) will call out if you’re using a Unicode char that could be confused with a source code symbol (e.g. i and ℹ️, which renders in some fonts as a styled lowercase i without color). I’m sure it does the same on the long equals sign.
Any compiler will complain (usually these days with a decent error message) if someone somehow accidentally inserts an invalid Unicode character instead of typing ==.
Do you mean admonitions? E.g. info, warning, etc? There’s precedent for that in commonly-used open source implementations, e.g. obsidian.md (which uses the same syntax, and started before). What semantics does it break? It’s designed to read well in plaintext and render nicely even if used in a renderer that doesn’t support admonitions, e.g.
[!NOTE] Information the user should notice even if skimming.
As opposed to other common markdownish implementations that use nonsensical plaintext which renders poorly in alternative renderers. Here’s a discussion on the topic in the CommonMark forums.
My “scrum leader” (who we handled agile just fine without before) is constantly complaining about points or priorities shifting, to the point that he’ll tell us to not put what we’re actually working on on the board because it’ll mess up the burndown chart.
One of the 4 values of agile is “responding to change over following a plan”. He’s parroted this to us before, and yet still doesn’t seem to see the irony.
Actually I’m guessing this is a localization failure
Swift:
: Equatable(assuming all the members of the struct are themselves equatable, if not the compiler will tell you to implement the
==method)