Recent submissions

Comment · 1 year ago
Comment · 2 years ago
The use case for more is managing the history of it in a specific way to make it easier to understand. Most applications don't need this level of management since most applications don't have lives depending on them
Comment · 2 years ago
its getting worse. Noticably very bad.

I have started double checked with web searches more and more. It went from 100% of the time to only 20%

Comment · 3 years ago
I hate to be that guy, but this is super common for stripe
Comment · 3 years ago
I am also learning about the linux kernel, but not in an embedded context. Here are some good resources I have found.

https://man7.org/tlpi/ This book is considered the best overview of linux kernel interface. Its old, but still gives a broad coverage of topics.

https://lkml.org/ Browsing LKML is really helpful since it shows you where current development is happening and how kernel devs think. Some conversations get very advanced and nuanced.

https://kernelnewbies.org/ is a good starting place for starting to compile and deploying kernel builds

Other than that, reading and tracing the source is probably the most productive thing to do for an experienced dev to do

Comment · 3 years ago
Expanding on your first criteria. The technology stack is fundamentally wrong is a good reason for a re-write. Language too slow. Doesn't handle the workload well. Other stacks have a better ecosystem.

Re-writes are also needed when the architecture doesn't match the problem space well. This can be incrementally done. Single threaded loops instead of using parallel-safe constructs like tasks and jobs.

Comment · 3 years ago
Observability is so key for successful infrastructure. A poor infrastructure with good observability is going to be more successful with than good infrastructure and no observability
Comment · 3 years ago
Conspiracies aside, there are a lot of reasons for this. Reducing liabilities. Responding to complaints. The "Shiny new thing" effect reducing over time.

This is going to be the biggest problem with general AI chat systems in the future, inconsistency. Often, they are too complex to know precisely how they work. Small tweaks will break some use cases while improving others. As more complexity is added to fix the next series of bugs, the systems will become less effective overall while user's have their workflows broken then mysteriously fixed.

From the end-users perspective, consumers will lose trust and move on.

Comment · 3 years ago
Comment · 3 years ago
Apple products communicate with each other even if they don't know each other, so an airtag will utilize the cellular of a nearby iphone in order to get information to apple's servers. I think google has a tracker that does something similar.

Its easy to imagine that previous generation tracking devices that sends its information across a broader range than an airtag will need to be larger battery thus being larger.

Comment · 3 years ago
Subpoenas are for criminal cases. It looks like this was a civil matter.

A better comparison would be the Twitter user that was tweeting Elon Musk's jet flights. This was before twitter was purchased, and Elon Musk was not able to get the court to order Twitter to hand over that information.

Comment · 3 years ago
For the most part, ML doesn't control high-risk things with a human in the loop. The worst cases for ML so far have been stock market crashes from algo trading.

Its entirely possible that an update to self-driving car's algorithms cause a day of chaos as the self-driving cars lose control and crash. Worst case scenario.

I agree that the secondary effects of the ML systems are going to be far worse than the primary. We can only see how it goes.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton