I think this is a pretty common goal. This video is a bit pessimistic, but it shows a lot of evidence that many tech billionaires are aspiring to that end. Most notably Peter Thiel
https://www.youtube.com/watch?v=5RpPTRcz1no&t=67s&pp=ygUQZGF...
HN user
I think this is a pretty common goal. This video is a bit pessimistic, but it shows a lot of evidence that many tech billionaires are aspiring to that end. Most notably Peter Thiel
https://www.youtube.com/watch?v=5RpPTRcz1no&t=67s&pp=ygUQZGF...
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 hate to be that guy, but this is super common for stripe
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.
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
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.
1955 with the advent of the field with some very hopeful mathematicians, but the research never produced anything.
1980 after the foundations of neural networks, but it was too computationally intensive to be useful
2009 with Watson
https://www.hiig.de/en/a-brief-history-of-ai-ai-in-the-hype-...
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
Japan is a fascinating case. It's GDP is stable despite a shrinking population. Is it only staying stable because of the population change?
If western countries with a similar birth rate problem stopped immigration, would western countries have a similar economic outlook as Japan?
Thank you for creating this. I have used it a lot in a few different projects. So much better than postgres's procedural built in
I don't think its possible for any platform that allows for arbitrary code execution to be completely safe. The exploits of today are far more sophisticated than they needed to be 20 years ago, but they still exists and are harder to find and fix.
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.
Cython is pretty good for C interop. Numpy is implemented in it
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
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.
I don't see any antidote to the effects of AI on society except regulation. This is a good first step forward, but it needs to go further.
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
False Consensus Bias. Everyone is like me, so everyone should do the things that work for me.
The author makes interesting points, and "everyone" makes more sense when you scope it to the HN crowd.
As controversial as this might be, this type of regulation is going to be needed in the future. AI brings a lot of power and responsibility
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.
I use it, and it's better than google and duckduckgo. What features are they missing?