bumper_crop

You misread. I'm saying his reasons for filing are in question. NIST probably was being dishonest. That's not the reason there is a lawsuit though.

If NTRU Prime had been declared the winner, would this suit have been filed? It's the same contest, same people, same suspicious behavior from NIST. I don't think this suit would have come up. djb is filing this suit because of alleged bad behavior, but I have doubts that it's the real reason.

This definitely has the sting of bitterness in it, I doubt djb would have filed this suit if NTRU Prime would have won the PQC NIST contest. It's hard to evaluate this objectively when there are strong emotions involved.

This is great news! For far too long, Website owners have been collecting data on their users at no benefit to the users themselves. When website owners try to collect data on their users (for any and all reasons) it just violates the privacy of those people and needs to be put to an end. Those French website runners should really create their own, CNIL and GDPR compliant anonymized data storing, rather than using off the shelf, low cost alternatives. After all, things have been a bit too easy for them. (Running a website is pretty easy, I would know!). In fact, The fact that other, compliant-data aggregators, offer fewer features and lower reliability is actually a good thing. Trying to improve your website or even pester me with whatever you made is just irritating spam; I can't believe those independent owners would even dare. They should just be flushed out of existence.

HEY! Why is everything being centralized to just a few services? Why is the web dying?!

Do you talk with regular people, outside of the tech bubble often? If money were really the problem, Walmart employees would jump at an opportunity to work at Costco or any of the other higher paying places. OP is claiming that because salaries aren't high enough, people are deciding to stay home and watch Netflix.

Same here. Ironically it's rising rent and gas prices that will force people back to work, rather than pay bumps because bills still need to be paid.

This is lazy explanation that's easy to agree with if you don't think very hard about it. Two reasons:

1. A shitty job at $15 an hour is equally unappealing at $16 an hour. Someone who doesn't want the crap hours, crap boss, and crap customer interactions isn't going to change their mind over an extra buck an hour. The money isn't the problem, it's that companies make it _not rewarding_ to work.

2. Raising pay ratchets up inflation, and isn't a response. Cause and effect are reversed. Unlike food, gas, houses, movie tickets, and restaurants, the amount of money transacted in wages/salary cannot go down. McDonald's can't tell their employees that due to supply and demand, they are only going to make $14.83 an hour this week. Imagine if your company lowered wages due to the "expected recession". You would start looking for a new role. This means pay increases can never go down again after a temporary bump. I won't say it's the cause, but it artificially limits deflation from ever pulling things back. Like an elevator that can only go up.

> I hate how it forces to you create a module everytime.

This affected me recently, so I have sympathy for the author. Trying to upgrade an older project I had to the module system meant trying to find out how to import modules which don't have reachable URLs and were only on the GOPATH. At I hate how it forces to you create a module everytime. some point programming in Go stopped being for fun.

When this came out, someone in my dorm made a mock of it on our whiteboard. With a few extra lines, it looks like a fat guy bending over. People always look for a human shape in what they see.

Step 1: have a lot of friends. You can usually spend a little politcal capital to get your first few users/customers by talking to them directly. For products that are targeted towards businesses, you'll need to call up your buddies from previous jobs and talk to them about it. After that, you'll probably need to hire a BDR or an AE to start looking for the next few. For B2C, I am not familiar.

Very timely; I found out yesterday that the UPX program (EXE specific compressor from many years ago) was made by the same guys who made LZO. I had this realization that there is a progeny from people who write compression stuff. In a similar vein, The Rob Pike post from yesterday mentioned Ken Thompson had made a custom audio compression for the Plan 9 release. He also made the UTF-8 compressor too. I love seeing how these people keep refining the state of the art.

You'll need to go back earlier than 15 years. ConcurrentHashMap and friends were added in 1.6, but String.intern has been in there since the beginning. Since Java shipped with Threads in the standard library, (but no memory model) that meant it would have been very difficult to do concurrent String deduplication yourself. If you agree string deduplication is needed, then String.intern() was a good implementation for a long while.

String.intern() also offers some other benefits for certain use cases. Earlier versions of java did not cache the String hashcode, which meant that to use Strings as hash table keys meant hashing a lot more. But, an interned string can be used in an IdentityHashMap, which was faster for a long portion of Java's early life.

(I worked on a moderately popular Java library that targeted Java 1.5 as the minimum version. It does occasionally come up useful, but only in specific, and increasingly rare circumstances)

Independent of Apple, I think we need an industry wide of saying "I'm not an idiot, this bug report is real". I've been on both sides (in a moderately used OSS project). The main problem is that the attending doesn't have a good way to filtering the noise from the signal. As a result, the likes of Apple (and the other FAANGs) implement these aggregate-and-discard blackholes for bug reports. "Only a 0.1% increase in crashes? Ship it" is the way the story goes sadly.

Make sure to read between the lines. It only looks like a busy loop. Remember, the OS can pause and preempt your thread at any time. This is a real and likely event.

One of the things that made linearizabilty click for me was thinking in terms of happens-before:

    volatile int a;
    a = 1;
    print(a) // Could this print Zero?

Even assuming only one program, one thread, one process, no interleaving and nothing fishy, could the final line print 0? In the serializable consistency, the answer is yes. Linearizability is framed in terms of clocks, but really that's just trying to establish that one thing happened before another. The "clock" in this example is the line number.