smcnc

One thing I noticed on the CS PhD side of the house is because many researchers don't want others to easily build upon their work (for whatever reasons), they don't often release the source code/data required to quickly validate it. This is a recipe for shortcuts, errors, and even in the worst cases, fraud.

We’re both #DudesForKamala

I was merely responding to replies directed at me. But that is probably good advice. No opinion was ever changed online. :)

“Flee and reside in hotels” not equal to relocate and continue mission. The major operational staff at these bases still work there. Support was relocated not fleeing.

US soldiers get hotels when fleeing? Wtf lol

US blew up C-130s stuck in sand. A few got shot up. Iranians on the ground got the brunt of the bullets, however.

There’s a difference between occupation (where this wins) and deterrence (where they can’t attack your country). The latter was the primary objective.

Define defeat here. I think everyone in this thread confuses actual defeat with indifference and political risk. If the US military could be defeated so easily America would cease to exist, no? It just loses interest and moves on. Nobody attacks the US because they would lose.

This is now Vietnam with no boots on the ground or years of war? Wow! Thanks

More leverage with less conventional firepower? Objectives of reducing conventional military threats and nuclear weapons seem less now, no?

Uncertainty.

90% destruction of military is meaningless if 10% can wreck havoc on the strait. The cost associated with eliminating that 10% was deemed too much. That is Iran’s “win”.

Agree with same comment as above.

This is true. 90% destruction of military is meaningless if 10% can wreck havoc on the strait. The cost associated with eliminating that 10% was deemed too much. That is Iran’s “win”.

This is true. 90% destruction of military is meaningless if 10% can wreck havoc on the strait. The cost associated with eliminating that 10% was deemed too much. That is Iran’s “win”.

Cost of insurance for ships did.

Search and rescue. Yes, it takes assets. Correct.

Insightful

I don’t see how the majority of comments paint this as a victory for Iran. Your entire formal military apparatus was destroyed, nuclear sites in rubble, defense industrial complex leveled, two levels of leadership KIA, and the only thing preventing you from permanent destruction or regime change is an impotent threat of attacking ships? I guess I’m missing something. War sucks but in this case Iran is a shell of the threat it was a month ago.

It’s pretty clear it was your post/project you reference, but how do you know he got inspiration from you? Did OP post on your Reddit post, confirming they were even aware of it?

Creating a tool via a LLM based on a similar idea isn’t quite stealing.

I think Zig really shines here: https://ziglang.org/documentation/master/#comptime

I’m personally fine with US gov backstopping depositors (but leaving equity unbacked) for the specific case of SVB, but the ultimate question remains: if the US government insures unsecured deposits over $250k (even if no practical risk with long term assets on balance sheet as collateral), doesn’t this in effect create a precedent of no upper limit to FDIC insurance moving forward? So now taxpayers are on the hook for all bank deposits (thus, creating potential for more reckless behavior by regional bank CEO/CFO/CIOs). Isn’t that somewhat dangerous?

We don't have an uninstall script at this time, but the install is pretty localized. You get a directory called wasp-lang under ~/.local/share and a binary called wasp in ~/.local/bin.

Thanks for the feedback. I agree that relying solely on per-provider integrations would not be ideal (for us as maintainers, or our users). But for now, we are using Passport.js just to help us quickly bootstrap maybe a half dozen social logins to get our users started. In the long run, I can imagine deeper integrations with Auth0 et al. and possibly building out some of the other mechanisms like you describe!

Hi there! Yep, we plan to add many more social login options. I'm confident all of those on that site will be supported. As with our first implementation (Google), each will be enabled by Wasp users by changing a few lines in their Wasp file and adding the appropriate envars. We're just refactoring it a bit as we add a few more to speed up the internal process of exposing them. Thanks!

Great question! Engineer on the team here - I will let our CEO, Matija, confirm tomorrow (they are in Croatia), but to me it comes down to the three most common options most OSS companies use for monetization:

  - we will provide a managed hosting service, think Wasp Cloud, that will make it the best place to run your Wasp apps with easy deployments, simple 3rd party integrations, great observability, DX enhancements and flows vs rolling your own on AWS, etc.
  - we provide some extra functionality that is more enterprise-focused and niche, but we charge for it (like more enterprise-focused forms of authentication, for example)
  - we provide support and maintenance licenses for those who want someone to be there when they call :)

Hi there! Engineer on the team here (and the one actually doing some of our auth and jobs stuff recently). We currently integrate with Google via oauth2 for social login, and plan to add more providers soon (GitHub coming next). The underlying mechanism is using Passport.js, which in turn uses oauth2 for most of their provider integrations, but that is abstracted so we can change in the future without breaking Wasp users. How would you envision Wasp itself being an oauth2 provider as beneficial vs integrating with other more popular providers?

As for username & password - correct, we do not do any email verification and reset right now. We actually changed the name from email & password to username & password to reflect the fact that we don't have tight email integration yet in Wasp. However, that will be coming soon, and once we do have first-class email support we plan to enrich that login method to have email verification with password reset, perhaps magic links, etc.

So long story short, we are trying to move quickly to add more auth options but be deliberate in how we integrate everything to ensure they all play together nicely. Please do check us out if it seems interesting and drop into Discord to let us know how we can improve to fit your use cases. Thanks!

Thanks! Right now we do have an "expected" structure that differentiates between client/server/shared code. But as a former Rails person myself, I can say everyone on the team appreciates how "convention over configuration" plus best practices can really help devs and it is something we try to do as well. So I think we will continue to make improvements in this area. Feel free to give it a go and drop into Discord and let us know what you think!