There is definitely a need for provider matching services. This could be something a YC startup could and should take on. Honestly, I was a bit hesitant to think AI could help but now I think it's a needed way forward. That and insurers need to be held to account.
Wouldn't the lambda here by always escape? It gets created in the function and passed into another one. Looking at the byte code it looks like it always allocates in when its in the interpreter:
I would expect the relevant optimization to be inlining and/or specialization. An inlined function could allow the JIT detect that the hot path creates and destroys an object without ever using it. Alternatively, if the JIT could specialize the callee for the specific function that is passed in, then the overhead would go away.
(One think I like about less heavily JIT-reliant languages is that it can be more obvious when something will incur a runtime cost.)
1. One of the underlying cryptographic principles is multi-party / secure-party communication (https://en.wikipedia.org/wiki/Secure_multi-party_computation). e.g., three people want to share their salaries to each other, but don't want the information to be traceable to back to the source.
2. Another is Steganography, hiding text in, say, an image, or audio.
3. You want to prevent the problems with Signal, Tor, Bitcoin, etc. This means, no "50%" problem like Bitcoin, no monitoring of exit nodes like Tor, no centralized distribution issue like Signal.
Imagine:
Alice "sends" a message to Bob by creating an account on Reddit and posts a cat meme which has the hidden text (steganography).
Bob knows how to find the text in that cat meme, and responds by posting something on Twitter, which Alice can read and decrypt.
All this is deniable (I didn't get anything from Alice!), available (e.g., Twitter goes down), and secure.
Indeed. For extra security, post cat pics to three different image boards; only by successfully combining all three can the receiver decode the message. If you are limited by the speed of finding / generating new cat pictures, publish frames from public webcam feeds that show life in a big aquarium, or sunsets, or clouds, or apply artistic filters on hourly charts of stock-trading sessions, etc. Make sure that not every picture contains a part of a message, but that every picture has steganography-like minor alterations, also explainable by applying a sensible but crude filter. In general, you can lace any of the plentiful reasonably stochastic streams with a steganogrphic side-channel.
The approach has limitations: your bandwidth is very low, and your latency is also pretty poor. Worse yet, you have to first establish a complicated protocol between you and your counterparty. In general, I think, it's not cracking your byzantine protocol that would ruin you, but a couple of small opsec mistakes (see Dread Pirate Roberts and the end of Silk Road), and these mistakes may be not even done by you but by your counterparty. Spear-phising, exploiting the local system that runs the communication and has some sensitive material in plain text, game over.
The problem with highly secure and clandestine communication (or any other activity) is that it makes your whole life complicated enough, puts enough extra strain on you, that you become noticeable by that alone. Maybe not immediately, but the probability of a small mistake that could put you on a watch-just-in-case list of a willing state-level actor is always nonzero. This does not mean that the situation is hopeless, but rather means that you have a time limit before your cat-posting scheme, still unbroken, becomes irrelevant, given enough interest from The Man against whom you conspire.
The problem with highly secure and clandestine communication.... it makes your whole life complicated enough, puts enough extra strain on you, that you become noticeable by that alone.... always nonzero.... a time limit before your cat-posting scheme, still unbroken, becomes irrelevant, given enough interest from The Man against whom you conspire.
Hide in the noise, embrace counter-culture, call it while you're up.
Oh, and they have everything forever, so you can't ever make a mistake against future adversaries, within your risk-window.
and if you think the Latina Beaches will serve you as they did those delusional fantasies, they watch those, too.
The beaches, that is.
You can still fantasize about it, though.
If those before you tell you to beware of dragons, do not sneer at their skeletons.
The basic idea, AFAICT, is that _federal_ law should not punish _state_ crimes under this specific section of the law (§666). As noted elsewhere, there might be other laws on the books for bribes, but §666 doesn't apply here.
The distinction between "gratuities"/ "gifts" and "bribes" is artificial to me, as a normal person, but I understand that the law makes a distinction.
I'm sympathetic to the federalism argument (every state should have anti-bribery laws so that _states_ themselves can take them to court instead of waiting for the feds!).
But I don't understand why someone would explicitly write a law that tries to draw a fat line between bribes and gifts. Is that the legal equivalent of a bug? A bad law?
Also worth pointing out that the original Nissan Leaf is now at least 13 years old, a lifetime ago in lithium battery tech, and intentionally used very cheap cells to keep the cost down.
I recommend reading it. It's actually pretty well done.
Secondly, the report itself and common sense dictate that regenerative braking on EVs (or hybrids) greatly decrease brake usage, therefore brake dust. Some EVs have "one-pedal" modes where you don't use the brakes at all in normal usage.
Looks like tire issue is a toss up, and it depends on what the type of tire and how you drive. The much higher torque on an EV and a heavy foot will wear down the tires a lot more, but that has more to do with driver behavior than EVs.
Also, this whole issue is kind of a red herring because tractor trailers and heavy pickups and SUVs are a much, much larger source of brake and tire dust, and overall particulate pollution.
You are dismissing the weight factor a bit too quickly. Many EVs regardless of their size weight as much as some ICE heavy pickups, especially as the trend of driving SUVs hasn't disappeared with EVs.
Don't quite understand the hate. This is very reasonable behavior for a compiler in 2024. I would even go so far as to say that a compiler should never execute any user code by default.
Imagine if gcc could automatically, by default, download some shared library and include it in the build because of a special macro included by a random header file on the system.
Of course, this change is optional (just add `-proc:full` to the command line) if you want the old, less secure behavior.
Also, Lombok is not affected because it's not an annotation processor. (Also, look at Immutables: https://immutables.github.io/).
To me the hate started when Java went from a statically compiled languages, to a half way dynamic language that does a fair bit of compilation at application startup, based on a bunch of annotations. Suddenly many Java projects introduced Ruby-on-Rails level "magic" (yes looking at you Spring(Boot)).
I'm not totally against annotations, but it's easier to over use them just to remove a bit of boiler plate.
To me Kotlin's approach makes more sense: reduce boilerplate by making the language more expressive, adding KClass and KFunction (https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.reflect) while mostly avoiding annotations and exceptions.
reply