HN user

kelthan

294 karma
Posts0
Comments63
View on HN
No posts found.

What I really want is this induction stove like this but that also has a single gas burner. Induction is great, but there are some things you can't do with it, but it covers 90% really well.

I guess the alternative is to get a portable high-output single burner butane stove that I can pull out when I want to arroser a steak, for example.

This solution doesn't do anything to prevent leaking memory in anything but the most pedantic sense, and actually creates leaks and dangling pointers.

The function just indirects malloc with a wrapper so that all of the memory is traversable by the "bigbucket" structure. Memory is still leaked in the sense that any unfreed data will continue to consume heap memory and will still be inaccessible to the code unless the application does something with the "bigbucket" structure--which it can't safely do (see below).

There is no corresponding free() call, so data put into the "bigbucket" structure is never removed, even when the memory allocation is freed by the application. This, by definition, is a leak, which is ironic.

In an application that does a lot of allocations, the "bigbucket" structure could exhaust the heap even though there are zero memory leaks in the code. Consider the program:

  int main(int argc, char** argv) {
    for (long i = 0; i < 1000000; i++) {
      void *foo = malloc(sizeof(char) * 1024);
      free(foo);
    }
    return 0;
  }
At the end of the million iterations, there will be zero allocated memory, but the "bigbucket" structure will have a million entries (8MB of wasted heap space on a 64-bit computer). And every pointer to allocated memory in the "bigbucket" structure is pointing to a memory address previously freed so now points to a completely undefined location--possibly in the middle of some memory block allocated later.

There are already tools to identify memory leaks, such as LeakSanitiser https://clang.llvm.org/docs/LeakSanitizer.html. Use those instead.

The one thing to keep in mind when reading this article is that the malloc/free API was built when many of the issues that are identified in this article (alignment, sizing, etc.) were not issues. Until the early 80's computer memory was the limiting cost factor for most machines, and the memory models were fairly simple. Alignment to something like a page boundary was something that was completely unreasonable/unfathomable, since wasting that much RAM would have been extraordinarily wasteful.

Modern CPUs have more memory built in to L1, L2, and L3 caches than most computers had in total working memory until memory started getting cheap.

I agree with the author that has lead to some "sharp edges" for the API, but that is a normal growth pattern. I'm not saying that the API doesn't have to change, but I did want to make sure that people understand that the creators of the old APIs were not stupid, they just faced different constraints than we do now. And that led to API "shapes" that may be surprising and frustrating to use now, but made perfectly good sense at the time.

First off, let me give a shout out to the author of the article. It's quite well written with clear support for the answer he provides.

Now back to the thread:

It turns out that most people expect "random" to mean a random selection without duplication (at least until the source is exhausted). That is called a non-replacement randomization: once a song (or comic, or whatever), is played/displayed, that item is no longer considered as part of the pool for future selection. However, that requires saving state for the individual user to save which information has been presented to this specific user, which adds a whole lot of additional requirements for cookies, or account registration, or other things that we all generally loathe.

The fundamental problem here is that most people don't really understand randomness and probability. If they did, casinos and lotteries would be out of business (see The Gambler's Fallacy[1]). This is not a failure of education, or mental capabilities: it is a fundamental friction with the way that the human brain has evolved.

The human brain is fundamentally a pattern matching system. We look for "meaning" by identifying patterns in our world and extrapolating what actions we should take based on those patterns. As such, we assume that _all_ systems have memory because that's how humans learn and take action, so we generally assume everything else does, too. But truly random events have no memory: there are streaks that appear "non-random" to us, such as multiple tails occurring in a streak during a fair-coin flip. But streaks often occur in truly random data, we as humans just don't expect it.

The existence of the Feynman Point[2] is an example that even someone well versed in randomness and math thought that a string of six 9's appearing in the value of PI, an irrational number, was something worth noting.

[1] https://www.investopedia.com/terms/g/gamblersfallacy.asp [2]: https://en.wikipedia.org/wiki/Six_nines_in_pi

Not really. It makes it harder, since the warrant would now have to include the cell-provider(s) for your mobile device(s), which would all them to geofence you by tower location or the HTTP headers (which Google could also be compelled to provide). And they would need to correlate the various data to be able to get a rough idea of where you were, as opposed to getting that data in one step from Google.

There is a difference between genomic data and biometric data: biometric data has a known potential exploit vectors. So, with a picture of your retina, a sophisticated adversary could potentially reproduce your retina to allow access to some secure facility.

Genomic data doesn't have the same risk factors--at least at the moment. I think that the point many are trying to make here is that there may be risk vectors available at some point in the future that aren't known now. A couple of theoretical examples:

* You had to give a blood sample rather than other biometric data like a retina scan.

* Spoofing DNA evidence. That would be very/prohibitively expensive/difficult at the moment, but I suppose could become as easy as 3d printing at some point in the future.

But having the company update a TOS that automatically removes rights from the consumer, after the consumer already agreed to a TOS that didn't previously restrict those rights is likely not going to hold up in court, either. Especially when the TOS changes were made after an event likely to trigger litigation.

This isn't a case of a minor change to consumer rights in the TOS like changing who would arbitrate a case. It's a significant restrictive change to the rights of the customer in favor of the company. And it was made after a security breach that affected a huge portion of the companies clients which is likely to trigger lawsuits of the form that the TOS now seeks to restrict.

This is clearly a case of attempting to close the barn door after the horse was spotted in the next county over.

Right. Also, the practice of having a sticker on a shrink-wrapped box of software that read "By opening this package you agree to the Terms of Service contained within", where the TOS was inside the box that you needed to open the package to read, was deemed unenforceable back in the 90's. It's the reason that TOS' are now displayed as a pop-up during installation. Not that many more people actually read them before installing the software, but at least they are given the option to.

I suspect that a competent lawyer could fairly easily argue that this "automatic opt-in" is the same thing in a slightly different format.

Yes, from the perspective of any user/consumer of the service. But since they are facing litigation, any lawyer will tell you that keeping your mouth shut until the action is adjudicated is THE best course of action, regardless of what some politicians and corporations may do these days.

The only other thing that they could say would be "We do not comment on matters involving pending litigation." But that's just a longer way of saying "No comment." It's not any more satisfying for the customers or partners understandably seeking answers to what happened, how, and why.

Automatically opting-in customers to a more restrictive TOS is pretty suspect, especially given the timing. IANAL, but I'm pretty sure that a court would not allow that, given that the TOS was changed AFTER the breach and it's pretty clear that the company is trying to avoid legal issues after-the-fact.

I would expect the court would evaluate any breach under the TOS that was in effect at the time of the breach, rather than under a new (and arguably suspect one) that was put in place after it, arguably in an attempt to "rewrite history".

And then saying publicly that they should be "fired" after they take his message to "f*k off" and stop advertising seriously and halt their advertising spend on X/Twitter.

[dead] 3 years ago

Wasn't it just last week that he told advertisers that they shouldn't advertise on X and that they should just "F*k off!" and that he couldn't be "blackmailed" with money or advertising?

Now he says if they don't advertise on X, they should be fired?

I'm confused. Though not as confused as Musk is, apparently.

I agree it's biased against Musk, but that's the point of the article. Were there specific conclusions that you disagreed with, or just the tone?

I notice that they didn't announce any substantive changes to the actual mobile app. So, it appears that rather than addressing long-standing complaints about the app that lead people to use 3rd party apps like Apollo (that Reddit killed off with absurdly high API pricing) they decided to invest in customized and proprietary fonts and logo updates.

It appears that the app will still have all the same bugs, problems, and usability issues. But the text, logo, and color scheme will be awesome.

And if you are one of those advertisers, how "common" a problem does this have to be to make you think you don't want to advertise there anymore? Even X's filing doesn't claim this "can't happen", just that it doesn't happen frequently.

For CMOs making major ad buys for carefully curated marquis brands like Apple, IBM, et al, I suspect that the only concrete number that they want to be assured of by their advertising platform is "0".

That is a "black swan" argument from Musk, et al.

Media Matters set up a test account that showed that it was possible for X's algorithm to pair ads with objectionable content. Given that, how can X claim that "no company has its ads run next to anti semitic content in general" when Media Matters has shown that it is possible? Unless Media Matters "photoshopped" or otherwise manufactured the results--but that isn't what the filing claims. They claim that MM set up a few small accounts following only a few other accounts-fringe content and brand advertisers--and then scrolled through the feed until they found something bad.

The line in the filing that mentions that MM's tests used existing accounts to get by new member restrictions shows the fragile nature of X's arguments. Most real-life users are going to have existing accounts, so it's that experience you want to check, not the highly-constrained environment X puts new subscribers into because they don't trust them yet.

Customers like Apple, Comcast, NBCUniversal and IBM, are sophisticated ad buyers that wouldn't let a single story change their buying strategies without additional information/confirmation from X. If they made the choice to leave X, I'd bet that the Media Matters story was the last straw, not the first one. And it's quite possible that the Media Matters story was the result--rather that the cause--of those companies' decision to leave the platform in the first place.

While X is trying to spin this a Media Matters "did bad things" to convince Apple, IBM, Comcast, and NBCUniversal to stop advertising with X, it is far more likely that the highly volatile and bombastic behavior of X over the last year had far more to do with that result than Media Matters' article did.

The BTC arbitrage in Asian markets was absolutely NOT very above board. He lied to get Japanese bank accounts opened and to keep them open. Transferring the BTC into Korea was against the law there. He just figured out how to do it for quite a while without getting caught.

Yes, it made money. Yes, he claimed it was legit, but it wasn't--it was money laundering illegal gains. It just sounds so much better when you call it "arbitrage".

This was all covered in the case.

The interesting thing is that while he espoused effective altruism, his actions are anything but aligned with the goals of that movement.

He displays many of the tendencies of a narcissist or sociopath: never wrong, what benefits me is what matters, I'm the smartest one in the room, willing to flout societal norms, frequently lying or shading the truth to benefit themselves. All of this was testified to in court by the people who worked with him.

To be fair, he was clearly quite smart. But...not as smart as he thought he was.

I'm not a doctor or a psychologist, so I'm not making a diagnosis, just offering the possibility that that may be what is at the root of the situation.

Yes, it is unreasonable.

You have contributed to the growth of the company. Find out what they are selling shares for to new investors and sell back for that, or don't sell back at all. Those shares are part of your compensation for working there and taking the risk of a startup. Don't just give up on the value that you helped to create.

I really hate it when people use graphs with non-zero axises. The initial graph in the article makes it look like downloads have dropped to zero, when they have actually dropped by about a third. Downloads were volatile, but hovered around 15M, and now they are around 10M. But if you didn't actually look at the labels on the Y axis, you wouldn't know that.

The loss of about a third of the downloads is still significant.

The README starts with "Powered by a custom QUIC protocol", which raises some concern. When looking at the protocol doc, I see "standard QUIC transport protocol RFC 9000 with Unreliable Datagram Extension [(RFC 9221 Draft Proposal])."

Is that the extent of the "custom" QUIC protocol?