HN user

yxre

90 karma
Posts2
Comments43
View on HN

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

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%

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

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.

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.

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.

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.

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.

Another article conflating AGI risks with ML risks. AGI has catastrophic possibilities. ML risks can range from accidents to annoyances.

Other than that, good insights from someone that works with self driving cars

I think there are a lot of frameworks on the edge of viability, but the bar is a lot higher than it used to be for front end tooling. React(70%), Angular(25%), and a little bit of Vue.js(5%) is the market for front end positions with React owning the Lion's share. There are always new things being built, but being used is different.

The React team has done a great job of being generic enough for a broad range of use cases. As new use-cases arise, someone can build a new framework to support it. SSR has gotten much more popular than the SPA style, and the core React team has moved to support it with server side components.

If they can continue to follow the innovators, React will continue to dominate the front end landscape.

If they choose to move forward with this migration, it will be huge for the project. Make or break type of decision. They are socializing this pretty well

Processes -> Threads is the same improvement that Nginx had over Apache, and its pretty clear that Nginx is the preferred web server these days. Also, Nginx's configuration system is much better, so it's hard to say why they have won out so clearly

LazyVim 3 years ago

I find that any IDE-type setup in vim causes vim to lose the most important thing, speed. If your movements slow down because of too many plugins, the experience is far worse than in a normal non-modal IDE.

Why not do num1.add(num2)? Or str1.append(str2)?

Like with many things in C++, its another grenade, but when used appropriately is pretty great

Its not really well known what is the motivation for witholding funds, but in some cases, it has been shared that is stuff around AML and people have extrapolated.

Conventional payment processors like Wells Fargo, BoA, and others do the paperwork up front, and then give you access. They don't have the spiffy features that Stripe and Paypal has.

Ultimately, I think Paypal and Stripe could have a better system, but they profit immensely this way. Like you said, good for them, but sucks for the industry because it is one of the barriers to growth is getting hit like this as you are scaling is huge.

This is a regulatory problem not a business problem. Payment processors need to understand a client's risk profile and what business they do in order to prevent money laundering, and in practice, regulators only care about clients that have a certain volume.

Paypal, Stripe, and any other major payment processor have developed a strategy of letting users use the service with no restrictions until they hit that volume then they begin doing things like this.

Ultimately, this is caused by regulation and needs to be fixed by regulation, but it won't because practices like this are extremely lucrative.

Why not keep the package separate? I also thought of reflect-metadata separately, and it doesn't hurt to allow users to install plugins to augment core compiler behavior.

Some people have very tight constraints for payload size, and types could blow up payloads

Just find a basic CSS library and use server side templating in whatever your preferred language is.

As systems evolve, they always get more complex. Web front ends are evolving to keep up with users, app archetypes, and business needs. People choose tribes to identify with, angular vs react vs vue. People are ambitious and pushing their own frameworks while tearing down others. Its just programmer politics, no different from windows vs linux vs osx.

I learned react, stuck with it, and it has worked out.

I don't think its intentional. I think it's a side effect of using a listener pattern.

If you use a listener, useEffect in react, to load data, it will start the request, track it is loading with a boolean, and then store the payload. That passes unit tests and QA.

If the listener doesn't check the error before starting the api request again, you have this infinite loop happen where the loading flag goes off and the payload is still null, so it just starts it again.

It's sloppy code, but its an unintentional side effect.