It's great to have .NET ecosystem expanding.
I am a .NET dev, and I still use web optimized for mobile as my mobile platform(where applicable). Tried MAUI and all the other stuff, just doesn't cut it for me. You can make an app using it, but I would rather not to. The best 'mobile platform' for me was blazor hybrid, but then again - if it's already blazor why not go full web...I guess it depends on the 'seriousness' of your mobile application. If I had to develop a complex mobile app, I might choose another language framework, cause MAUI uses XAML and MVVM stuff that is quite a big overhead IMO.
"just use postgres" is an excellent advice. How about incidental complexity and ridiculous limitations of an ORM?
Time spent learning how to use an ORM can better be spent 'refreshing' your SQL knowledge.
Also, when you learn how an ORM works, you still don't know proper SQL nor how do databases works, so when you switch language now what, you quickly take a course on another ORM?
SQL is a language, ORM is not,it's just ' an entire layer of code that your application doesn't really need' and in some applications you could never ever use an ORM.
It is rather clear that I am the only one in this discussion who recently had to write code that synchronizes data that I do not control with an SQL database. Everything is easy in toy applications, where you have your USERS table with First_Name and Last_Name.
Seems like it could also be useful in planning combat(strategic) actions ad hoc, given limited resources, but I guess military already has some other tech for this...
Nice, why don't we apply the same principles to our regular applications?
Ooh, right, cause we couldn't use them and a whole industry got created that's called cybersecurity and it's supposed to be consulted BEFORE releasing privacy nightmares and using them. But hey, regular applications can't come up with cool poems.
Yeah, IT tried so hard to teach us something as basic as "don't click on links in suspicious emails" yet so many people fail that after multiple trainings and tests.
But guess what? AI! Agents! <company name> Copilot! Just let them do things for you! Who would have thought there might possibly be a giant security hole?
I think they hope they will because if they don't at some point people are going to expect a return and get tired of throwing good money after bad.
The longer they go without that and the more the sentiment starts to shift away from what they convinced people LLM's where vs what they actually are the riskier it becomes, are they are useful tool yes, are they not what they've been hyping for the last four years, also yes.
They either crack it or they become an also ran.
At which point Microsoft investors are going to be staring really hard at the CEO.
You're missing context and/or didn't read OP's comment. He said "will" with regards to reaching AGI. He said "only AGI can find" with regards to profit. It was the latter that this thread was addressing.
You're missing context and/or didn't read OP's comment. He said "because". It will happen because that's the only way to reach profit. That's why it will happen.
Yeah, exactly. The context here was about the profitability part of OP's comment. The parent said "plenty of businesses fail to find a way to make a profit," and my point was that OP's statement doesn't contradict that. OP was saying they'll need AGI to be profitable, not that they're guaranteed to become profitable.
Sure, they phrased it as "they will reach AGI," but that's clearly tongue-in-cheek...the underlying idea is "they better reach AGI, because that's the only way they could make money." So my comment ("necessary, not sufficient") was just pointing out that even if AGI is required for profitability, it doesn't mean they'll actually get there or succeed once they do, and that the original comment was perfectly compatible with the idea that not every business reaches profitability.
I think Spring doesn't consider vulnerabilities in one of their components to be a Spring vulnerability. At least they do not release an updated version until the next scheduled patch version, not even in the paid version.
You can either wait and accept being vulnerable or update the component yourself and therefore run an unsupported and untested configuration. Doomed if you do, doomed if you don't.
And now that everything is a package, it won’t get fixed with windows update. Which means that if the website isn’t actively developed and regularly deployed, it will remain vulnerable
Actually this bug is in Microsoft.AspNetCore.App.Runtime which is an implict package that comes from the runtime. So simply updating your version of the dotnet should fix any vulnerable applications.
On Linux, system-wide installations are handled through the system's package manager.
On Windows, if you have the "Install updates for other Microsoft products" option enabled, .NET [Core] runtimes will be updated through Windows Update.
If the domain's group policy won't let you turn it on from the UI (or if you want to turn it on programmatically for other reasons), the PowerShell 7 installer has a PowerShell script that can be adapted to do the trick: https://github.com/PowerShell/PowerShell/blob/ba02868d0fa1d7...
