I don't want AI slop from big corpo and you think I am gonna want AI slop that's just as wasteful and harmful just because it's "locally produced"? That's Republican-ish crap line of thought.
One good quote from Marvel's What If:
I already saw the ~~killer robot~~ precrime bureau movie, and I don't think it needs a sequel.
Me parece puros buzzword y bullshit de C-suites, MBAs, ingecos rascas (o simplemente ingecos en general) y AI.
Lo pasé por bullshit.js y partimos con esto:
https://i.imgur.com/77QpEam.png
Signal is OK as a beginner privacy tool. Like with all gateway drugs or gateway animes or gateway videogames, you gotta start somewhere.
But it does is certainly a platform at-risk. Storage is US-centered, connectivity can be cut at any moment, and it's quite centralized to the point of forbidding 3p clients from interacting with the main Signal "network".
I come from the 90s. XMPP / Jabber is so much better.
Capitalism!
But technically is not the standard itself that is not free, it's the official documents and certifications. For example, my understanding is you have to pay quite hefty coin for the C++ Standard to be "compliant", otherwise you are just working with a "draft" that is not "official" despite being identical in all but at most the name and credits section.
Not a bad idea. I'll try to crosspost that news a few times later during the weekend to help build the bad behaviour portfolio.
.at_unchecked()
What kind of barbarism is that?
Doing that kind of split would kill genericity (more than it already is). If I'm using [] is because what I want is, more or less, to just access the value; not to maybe randomly and without any kind of source-level control or projected time/space boundaries go to the blockchain to check if the Rust devs are in the mood today to have blessed the given statement with the arguments given.
Frick. At least give me something like [checked(5)] or [unchecked(5)] for a more natural syntax. The more considering it has been possible to add compile-time checked access with something like [integral_constant<size_t,5>{}] since at least C++03! It just needs someone to propose a standardized notation shortcut. Or if there was some way to inquire or static_assert that the checks on the natural syntax are actually elided if I'm doing them myself elsewhere. But at it stands, uglifying the syntax is the worst of all worlds.
Well, you'll need dopamine and serotonin for all the new product spam mails you can get!
I think it’s pretty much guaranteed that they’re not going to take the sensible route of making it opt-out,
Because that's not the sensible route in the future, whether we like it or not. Hardened STL is being announced in the papers as "we are going to start with these silly one-line fixes that in theory should perturb no one, but as we iterate over this we're gonna start breaking things", which is not what you want to hear from the default.
One good example: placing enforced bounds check into the operator[] of std::array<> of all places. People keep telling me that I should be using std::array instead of normal C arrays, but then punish me for using std::array? That ends up making people revert to the True Old Ways That Work (aka: C arrays).
We can be shitty together! :p
I mean, you gotta start by seeing the positives.
publicado de forma cruzada desde: https://gregtech.eu/post/6514020
!iso8601@lemmy.sdf.org gang, rise up
Today in our newest take on "older technology is better": why NAT rules!
publicado de forma cruzada desde: https://lemmy.world/post/9470764
- ISO 8601 is paywalled
- RFC allows a space instead of a T (e.g. 2020-12-09 16:09:...) which is nicer to read.
Why wait? Debian is out there.