matharmin

Without something like the GDPR, incentives are very different for exporting vs importing: Import functionality makes it easier for someone to switch to your service, while export functionality makes it easier for someone to switch away.

Additionally, if a service is missing import functionality, you can choose to not use it. While you'd often only realize you need export functionality while you've already used a service for years.

Maybe the case of porting data between social media services doesn't make much practical sense, but there are many other services where it does. Fitness tracking apps as an example - you'd likely want to take your history with if you switch services.

And usually these services would not be using the exact same data format for import vs export. But that's not as big an issue in practice - you'd often find third-party scripts or services that can do the conversion for you.

I've found this isn't an issue if you pay for a dedicated IP.

From the parent comment:

> it takes like an hour to catch up a new replica from scratch

That means it should be pretty easy to replace an instance - just create a new replica from scratch, then fail over (if you're replacing the current master/primary instance), and remove the old one.

My team has a lot of practical experience with Pulumi, after using custom bash scripts, manually-managing AWS config, some Terraform and CloudFormation in the past. We use it for dozens of services on Kubernetes and AWS.

While we did have to write some of our own tooling to reduce the boilerplate over different services, Pulumi has been by far the best tool we've found to do the deployments. Being able to automatically provision a resource in AWS, then use results from that in a Kubernetes service (env var) in the same deployment, is not something I ever expected to be able to automate.

We haven't had any issues with module availability (I think it uses/adapts Terraform modules to a large extent). The config as code feels way more approachable and reusable than any other tool I've seen.

I've never had any production issues because of Pulumi. It also allows you to preview changes before applying them, giving a nice confidence boost in the changes.

While I see the mismatched incentives here, I believe they have enough other incentives to make builds faster. I gladly switched over from the concurrency-based pricing to per-minute pricing on CircleCI when it became available. This ended up being significantly cheaper for me, and I never have to worry about how many builds I'm running in parallel.

I disagree with this.

Even a single project with 20-minute build times is enough to slow down or frustrate development.

At the same time, I would not easily justify spending time managing CI infrastructure with my team of 6-10 people.

Things may have changed since then, but the last time I self-managed build agents, it often lead to build jobs being tightly coupled to the build agent and installed software versions. With a docker-based CI system, you are forced to have everything specified in code, making it much more maintainable.

Additionally, hosted CI allows me to do 100 parallel builds on Linux, MacOS and Windows. Perhaps this is a niche use case, but I saved a lot of time and reduced build times by an order of magnitude by switching from self-hosted CI on Windows and MacOS to a hosted solution.

I run Ubuntu on a Dell laptop. I still keep the OEM Windows copy installed for one reason only: Contacting Dell support for warranty-related issues. This usually requires running their Windows-only diagnostics tools.

A couple of years back I ran into a JDK JIT bug during a project. The code ran fine until I ran it through benchmarks, which triggered JIT on a method causing it to return incorrect results.

Took a long time to find, because there were no errors, just wrong results (a specific if statement taking the wrong branch).

Trying to get assistance from others were mostly met with responses along the lines of "It's probably a race condition" (in single-threaded code) / "very unlikely to be a bug in the JIT". I did end up finding a way to disable JIT for the specific method, which solved the issue, and never got around to finding the root cause. I do believe it has been fixed in the meantime at least.

I haven't run into major compiler bugs since then, but often have to dive deep into libraries to find obscure bugs (database drivers and web servers most often).

I have never seen XML 1.1 used in practice. How many parsers actually support it?

There is a huge advantage to using an existing language (JavaScript/TypeScript) like this, compared to creating new DSLs. There is simply such a big ecosystem to leverage in terms of development tooling (auto-complete etc), existing libraries and existing libraries.

On the device side I've used a lot of code from the CanAirIO project: https://github.com/kike-canaries/CanAirIO. I do want to switch my code to the NimBLE stack instead of the default bluetooth stack at some point - apparently it uses a lot less memory.

On the web side I don't currently have any good public examples, but the generic Web Bluetooth samples here are a good starting point: https://googlechrome.github.io/samples/web-bluetooth/

Maybe I'll write a proper blog on this if I get some spare time.

Bluetooth API won't give useful fingerprinting information unless the user allows it with a very obtrusive prompt.

It's not something that's useful to the majority of websites, but I find it extremely useful for hobby ESP32-based electronics projects. It gives an easy way to configure individual boards, with no weird captive WiFi portal required. It's cross-platform (Windows, Mac, Linux, Android, just not iOS), and no native app required, an an easy-to-use API. This means means a lot less development overhead for my hobby projects. And it means I can give devices to family & friends without them needing to fiddle with firmware to configure the device.

I assume this would be a custom implementation.

For example, tag an EC2 instance with "CronStart: 0 8 * * " and "CronStop: 0 17 * *". Then have a service that queries EC2 instances with CronStart/CronStop tags, and start/stop the instances according to these schedules.

I haven't looked for any services that does this out-of-the-box, but it would not particularly complicated to implement on e.g. AWS Lambda.

VSCode semantic highlighting is mentioned by the author, and it does support these type of use cases. It works by first doing normal syntax highlighting, then asynchronously getting the semantic info for semantic highlighting, since it's a much slower process.

The current language-specific implementations do use it to just augment the syntax highlighting, since that is what is what most people would expect. But out of the box it already supports some use cases the author mentioned, such as different highlighting for imports or constants. The full AST and type info can be used for this (depending on the language server), so pretty-much anything is possible.

What I personally find very useful (and had to hack experimental support for) is highlighting of TypeScript async/Promise values and functions. This is something that a language server can identify easier than humans, and can make a big difference in coding.

This is like saying a political party leads to what it members want it to lead to, since it's a democratic entity. In practice different members want different things, and it easily ends up as political games with mismatched incentives.

It's a one-line summary, not an in-depth explanation or comparison. "Not directly used for mounting" is a good summary of the intended use.

Advantage is that most of the time, you have a fairly new browser engine available for your app, that is not tied to the OS version (especially important on Android). Also doesn't require embedding an 50MB engine (Crosswalk) in your app.

Disadvantage is that as an app developer you're not guaranteed to have any specific version available. Some devices never upgrade the pre-installed version automatically. The user is also able to switch between the Chrome webview and an OS webview on some devices (in developer settings, so it's not common). You can add checks in your app and direct the user to the update links, but requires quite a bit of work to do well.

Code cannot be patented - copyright covers that.

Patents on software are not that simple - it needs to describe an entire physical system that gives value to a user, not just an abstract function that does computation.

The tag also contains the commit id, not just the date.

This does not appear to be a cross-browser issue - just a plain bug. It's broken on both Firefox and Chrome.

It's one of the few remaining features needed to create fully functional web applications, on par with the functionality of a native app.

As an example, I refuse to install a native Facebook application because of privacy concerns, but a web version with push notification support could provide the same functionality.

Thread-safe just means it won't result in data corruption, race conditions or other similar issues when used from multiple threads. That's still quite different from being able to execute concurrently.

I feel nowadays containers generally refer to the concept, and cgroups and namespaces are the implementation details of a specific container runtime. These are very important implementation details for security and performance, but it doesn't fundamentally impact how you structure your containerized application.

You can take the same container image, and run using Docker, Firecracker, gVisor, or many other container runtimes. Some of them are exactly "like a VM, but lighter".

Get an external mic. It's a niche enough use case that they don't need to cater for it.

At my company I take a very different view depending on where in the stack the tech is used:

Developer tooling (Developer machines, IDE's, source control, CI, issue tracking, etc): Pay for the best.

The product: Only use FOSS. Give back by contributing and by making some of our work available as FOSS.

For the product, especially for the client-side, I just see it as too risky to include proprietary software. Even if the pricing is fine for right now, it can easily change later (got burned by both Google Maps and Mapbox years ago), and in some cases even prevent you from using different pricing models because of base costs it may add per user.

On the infrastructure side I'm more flexible, but even there: 1. Stick to commoditized services as far as possible, where the pricing is predictable. I'd include most cloud services in this, and most "enterprise" offerings not. 2. Avoid hard vendor lock-in if feasible, but only up to a point (don't build something from scratch just to avoid the lock-in).

See https://news.ycombinator.com/item?id=22652047 for some discussion on using heart rate

The article is about injecting a backdoor in a Node server using a malicious NPM package.

And then you'll get the "My account has been banned by Amazon after misclassifying a single listing" posts.

There are two sides to the problem, and changing criteria for suspension just shifts it to the other side.

Interesting backstory, but the article doesn't actually provide a reason. It just states ifconfig has a bug, and "I do not fully understand they did not just update ifconfig(8)".

We passed our SOC2 Type 2 audit without any MDM - we're just doing a manual quarterly audit on machines to check that they're update to date.

MDM helps to detect issues earlier, and can remove the need for manual audits, but is not a hard requirement - same with most other things in SOC2.