Pre-IPO price padding. xAI is going nowhere but at least for now it has some value. Move it under SpaceX, bump up SpaceX’s valuation and therefore it’s opening IPO price. Then kill xAI and write it off.
The two major US parties are in the midst of another swap of which is conservative and which is liberal.
Marin County California, probably the area most heavily voting for the Democrat party, is clearly the most classically conservative part of the country, allowing almost no development and strongly objecting to even the slightest offenses in speech, whereas rural counties in the south want classically liberal safety nets and protections and heavily vote for the Republican party.
> Follow-up 2: Yes, I know that the Tacoma Narrows Bridge collapse was not the result of resonance, but I felt I had to drop the reference to forestall the “You forgot to mention the Tacoma Narrows Bridge!” comments.
Not to take away from this device, I think it’s pretty neat. But you can run tailscale on anything, even Apple TVs. If you have a Unifi network odds are that you have at least one spare computing device that can run tailscale.
Problem is that I think my Apple TV goes into some sort of deep idle mode where tailscale stops working. So it’s been effectively useless for me when I travel.
Check the Tailscale blog and docs for AppleTV. ISTR reading about an issue like this popping up and they had a workaround of some sort. Never happened to me.
If you compile with -fno-exceptions you just lost almost all of the STL.
You can compile with exceptions enabled, use the STL, but strictly enforce no allocations after initialization. It depends on how strict is the spec you are trying to hit.
Not my experience. I work with a -fno-exceptions codebase. Still quite a lot of std left. (Exceptions come with a surprisingly hefty binary size cost.)
Apparently according to some ACCU and CPPCon talks by Khalil Estel this can be largely mitigated even in embedded lowering the size cost by orders of magnitude.
Yeah. I unfortunately moved to an APU where code size isn't an issue so I never got the chance to see how well that analysis translated to the work I do.
Provocative talk though, it upends one of the pillars of deeply embedded programming, at least from a size perspective.
Not exactly sure what your experience is, but if you work with in an -fno-exceptions codebase then you know that STL containers are not usable in that regime (with the exception of std::tuple it seems, see freestanding comment below). I would argue that the majority of use cases of the STL is for its containers.
So, what exact parts of the STL do you use in your code base? Most be mostly compile time stuff (types, type trait, etc).
Of course you can, you just need to check your preconditions and limit sizes ahead of time - but you need to do that with exceptions too because modern operating systems overcommit instead of failing allocations and the OOM killer is not going to give you an exception to handle.
I don't think it would be typical to depend on exception handling when dealing with boundary conditions with C++ containers.
I mean .at is great and all, but it's really for the benefit of eliminating undefined behavior and if the program just terminates then you've achieved this. I've seen decoders that just catch the std::out_of_range or even std::exception to handle the remaining bugs in the logic, though.
Well, it's mostly type definitions and compiler stuff, like type_traits. Although I'm pleasantly surprised that std::tuple is fully supported. It looks like C++26 will bring in a lot more support for freestanding stuff.
No algorithms or containers, which to me is probably 90% of what is most heavily used of the STL.
It's not undermining, it's asserting/showing off their independence. India doesn't want to play for anyone's team, so they play on everyone's team. It's a reminder to all sides that they are not an automatic partner to be taken for granted.
reply