skysight-inc/HackerNews huggingface dataset:
I've read both and I'm not sure I know enough about your argument to challenge it directly, which is my critique of it. You're invoking these "isn't PFOF common practice" and "maybe PFOF was beneficial" questions as if they were controversies; of course, they are not. PFOF is practically universal, and it is universal because separating out non-toxic order flow is a win-win.

If I had to summon a direct rebuttal to your argument, it would be this:

I perceive you to be suggesting that the problem with Robinhood is that it uses PFOF, which means that customer outcomes are dependent on private deals Robinhood inks with companies like Citadel, which aren't transparent.

The problem with that argument is that literally everybody, including, apparently, IBKR, inks private deals with companies like Citadel, which means you can't suggest that something is distinctively wrong with Robinhood for having done so.

I perceive you to be suggesting that Robinhood would be more honest and transparent if they simply charged a commission that covered their expenses, rather than doing weird PFOF deals. Again: practically every brokerage does PFOF, because it would be dumb not to. Most brokerages charge commissions, but that doesn't make them transparent; they are still turning a private dial in their back office that trades off customer savings with brokerage profits based on PFOF deals.

Robinhood, for what it's worth, is bad, and the badness does have something to do with "no commissions". But the problem isn't shady execution; it's that Robinhood is a gambling site, not an investment site.
BTW i love writing slacks at like 4am when i can't sleep but i def don't want people to know that i am kinda crazy so i schedule them to send later ...thanks for making...cool to see you on Show HN...i think i was one of the early users!
I'd suggest explicitly keeping those apps off the second monitor. I like keeping reference documentation and running notes there.
True, but the algorithms challenges are not very representative of the actual work we do in our industry. They are a nice way to filter people who are not willing to spend a lot of time studying challenges to have job interviews though.
"""For example, the PID namespace makes it so that a process can only see PIDs in its own namespace, and therefore cannot send kill signals to random processes on the host."""

Weird. You can't kill a process that's not running as your user, even if you can see it. That's not the point of PID namespacing, and I hate seeing non-existent security rationale backported to unrelated concepts.
FWIW, most small time devs aren't going to be "stewards of information" to any significant degree unless they're actively trying. Handling finance will be outsourced either way, using Stripe or one of many other 3rd party services, you wouldn't be processing any of that yourself. I buy a ton of 3rd party indy software on my Mac and always have, and nothing from the MAS, and typically the only "personal info", kind of, is an email and maybe my name (and it's not as if that's verified somehow, I could just put in whatever). I also have plenty of email accounts and can trivially make more, as well as developer-specific aliases.

Plus there are other tools to further layer if it was ever a problem, like virtual credit card numbers. In practice the very nature of credit cards means it doesn't seem to generally be a problem, has been less of a real world risk than hacks of physical retailers. If I see a bad charge, I just report it and get a new number.

Also FWIW, I've seen plenty of sites starting to offer Apple Pay as an option at checkout, I assume it's getting built into more payment systems now. That itself is solid defense, at least as good as the MAS though sometimes the checkout flows seem a bit wonky still.
91. don't buy XRP

but in seriousness,

I think it is easier to apply these rules to people you know than strangers. Look how often people lose patience with each other online.

>85. Cultivate compassion for those less intelligent than you. Many people, through no fault of their own, can’t handle forms, scammers, or complex situations. Be kind to them because the world is not.

Interestingly, being smart does not protect one from scams. Look at all the smart people who got duped by Madoff. Smart people are just as inclined to believe BS as less intelligent people are , if the BS is dressed up in such a way to appeal to smart people. If anything, being dumb helps, because scams typically require forms and complex schemes, such as investment schemes.
Ah, perhaps mine was that way at once point and switched over when I changed email addresses.
I don't see how the CEO refusing to continue to say she resigned bolsters the claim she resigned.

> calling it a resignation is completely correct and needs no retraction or correction.

Alternatively: publicly calling it a firing is essentially an admission of guilt. That's the one thing Google's lawyers would insist Google cannot do.

Presumably neither one of us are the experts on EEOC and employment litigation strategies. So instead I'm going to take the statements at face value. And at face value: Google is no longer willing to state that Dr.Gebru resigned. Anything else is spin.
Why not use Let’s Encrypt, e.g. with DNS validation so they do not need to hit your HTTP server?
> I don't think the 'stops buggy programs' argument is particularly compelling, since that could apply to pretty much any restriction

This is the part that irks me the most. If I have an algorithm that is neatly written as a recursive algorithm and mechanically rewrite it to use an explicit stack, that doesn't change the fact that an infinite loop is still a bug. It's just that it's going to manifest as the process using all the available RAM instead of as a stack overflow.

> yet they're somehow fine with inheriting these weird restrictions from C & co.?

Sometimes that's because the interpreter itself uses recursion. That can be convenient for whoever is implementing the interpreter, at the cost of inheriting the stack limit from C.

That said, there are also languages that enforce a recursion limit even when they don't use the C stack at all. In which case I ask the exact same question as you do.
So in other words, a small subset of customers significantly overpaid so that a large number of customers could get a bargain. The question is whether that's this a good thing, and also whether it's sustainable. Presumably those high-paying customers are going to be top candidates for competing brokerages to steal away with offers of better execution price. If that happens, does RH just content itself with lower profits -- or do they start finding new ways to increase revenue on the backs of their remaining customers?
Trial decryption. This is a potential server behaviour for Encrypted Client Hello (the current iteration of the work to encrypt SNI in TLS traffic) too

ECH will be GREASEd. To prevent those who might want the capability to stop ECH in the future from getting a head start while it's uncommon, implementations would always pretend to be doing it anyway.

So talking to any TLS server, even one that has no idea about ECH, the client says basically "Hi, here is a normal unencrypted TLS 1.3 Hello message for this.server.example, also, here's an Encrypted Client Hello message". If the server actually does offer ECH, there could be a real Client Hello, perhaps addressed to another.server.example, encrypted inside the Encrypted Client Hello, but if not there's just random noise. An eavesdropper doesn't have the key, so they don't can't tell which is the case.

Obviously if your server can't do ECH, the Encrypted Client Hello is just a mysterious unintelligible extension with noise inside it, no further inspection needed.

And in some setups the server knows how to tell easily which key would have been used for any valid ECH, so if that key doesn't work then it was just noise, and can be ignored.

But in other cases the server knows two or more keys that might be valid, yet the client either can't or has chosen not to be open about which (if any) was used, so the server has to try them all until it finds out.

This is Section 10.4 of the current draft:

https://tools.ietf.org/html/draft-ietf-tls-esni-09#page-28
Hey, thanks for comment and sharing the React Server Components news - have checked https://reactjs.org/blog/2020/12/21/data-fetching-with-react... . 18:02 - "server components can not have any interactivity". So essentially this is (something similar to) renderToStaticMarkup with some bells&whistles.

Would live to share quote from https://news.ycombinator.com/item?id=25358976: "I feel like we're in a transition period where we will eventually get both the nice developer experience and flexibility combined with nice performance".

Am wondering if anyone tried to bundle vanilla js for dom manipulations alongside server-rendered react componenents which deliver html+css server-side. Where do you put js code inside the component folder? What are the patterns and best practices of using react only for html+css composition and using vanilla js for interaction? Thanks a lot for any tips!
> Due to the signed system volume, doing so is now impossible without disabling system integrity protection, one of the main platform security features of macOS.

No, macOS is fine without SIP! SIP just defines a set of actions that Apple thinks no user, including root, should ever be able to perform. Consequently, disabling SIP empowers root users to do whatever they want, which is exactly what root is supposed to mean! You're still protected by the standard UNIX permission system—just don't grant root to software you don't absolutely trust!

Security is all about layers—but in the case of SIP, the security comes from delegating control away from the user in favor of Apple. If you're a power user, I'm not convinced this is necessarily good, because you're giving Apple almost absolute trust. What if they get compromised?

And, if you're the sort of person who would want a de-Apple-ified version of macOS, I would think you'd have already disabled SIP.
Care to expand? Just negativity is not very useful for conversation.
What is an "LW-style rationalist circle"?
We built Papyrs for this (https://papyrs.com). Would be curious to hear your thoughts on this!
Sounds like what https://www.levelshealth.com/ is doing
SRP was good for its time, but things have moved forward in the password-authenticated key exchange (PAKE) world. See for example OPAQUE:

> Currently, the most widely deployed (PKI-free) aPAKE is SRP [RFC2945], which is vulnerable to pre-computation attacks, lacks a proof of security, and is less efficient relative to OPAQUE. Moreover, SRP requires a ring as it mixes addition and multiplication operations, and thus does not work over plain elliptic curves. OPAQUE is therefore a suitable replacement for applications that use SRP.

> This draft complies with the requirements for PAKE protocols set forth in [RFC8125].

* https://tools.ietf.org/html/draft-irtf-cfrg-opaque

More on PAKE generally:

* https://blog.cryptographyengineering.com/2018/10/19/lets-tal...

* https://news.ycombinator.com/item?id=18259393

If you're looking for a challenge-response system for your application, then it's hard to go wrong with SCRAM (which Postgres went with a while ago):

* https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...
As I understand it, if you make $1 more than $1M, it's not that you suddenly owe an extra $150k in "back taxes," but rather that going forward, you'll be in the 30% "tax bracket." It's still a tax cliff, and therefore kind of problematic (if it's November 2021 and you've made $950k, you're strongly incentivized to shut down sales until the new year!), but as you say, that's a problem 99% of devs would love to have.
You know who the other hero is? The CEO who gave him the time and the opportunity.

I would call it "common decency". An uncommon trait for corporate executives.

But there's no reason to elevate the occasional few who are capable of it to "hero" status.
Instructions for Launching VR – Microsoft Flight Simulator
Also I suspect nobody wants to work on it because who wants to do printing.
I should :)
Microsoft is also mostly purely tech. Amazon and Google (Alphabet) are more pervasive and threatening to other industries.

For that reason, I'm not surprised. I've seen the decision come down to not wanting to give money to the other two many times. MS is in a great position there.
Can a process increase their own stack limit or do they need to spawn a child process with a higher limit?
I wonder — is an iOS user worth any more or less to an advertiser than an Android user? I assume more — maybe even a lot more. Would adjusting shares to reflect that make Apple’s share look more significant (thus the major marketing push by FB)?
Stahl's Essential Psychopharmacology is also free and online[1], and written in a way that people like myself can understand it.

edit: actually only sections of it are available online. The book isn't hard to find, though.

[1] https://stahlonline.cambridge.org/common_home.jsf
Indeed! In this case, Unbound is Mac only, and probably will remain so for its entire life.
Medical 24/7 – Unique, Global Healthcare Platform
In very loose terms: Rust's async/await syntax defines an interface to async programming, not an implementation.

Rust leaves the implementation, and thereby choice of concurrency strategy, to libraries. Tokio is such a library. There's at least one other popular one of note.
The author of sled[1], an embedded database in Rust which has a number of promising features, has also written parts of rio[2], an underlying pure Rust io_uring library, which is intended to become the core write path for sled. rio has support for files but also has a demo for TCP (on Linux 5.5 and later) and O_DIRECT.

I tested rio recently as I had a Brilliant but Bad Idea™ involving file access and was pleasantly surprised by the API, as I have been with sled's.

I'm excited for the experimentation in the Rust ecosystem and for such low level crates to handle the complex io_uring tasks (relatively) safely!

[1]: https://github.com/spacejam/sled

[2]: https://github.com/spacejam/rio
In what universe are whiteboard interviews used this way, as opposed to the interviewer expecting an exact answer regurgitated instantly?
Have been searching for this for a mighty long time! Could not remember the name of this series. Can’t wait to watch this over the weekend.
Unless you have a PWA, you only need a /favicon.ico and the touch PNG icon. The browser will fetch them automatically, no tags required.

Tip: the ico can just be a renamed PNG file.

I wish people stopped cluttering their sites with a thousand useless variations.

The SVG favicon part is interesting and maybe that requires the 2 rel=icon tags.
> But we don't have a "Djikstra amnesia" to describe all the times we fall short of the ideals of our own discipline, but forget about that when holding other people to our notional ideals of their disciplines.

Perhaps we should?

(And then, of course, someone can post:

> Nitpick: Its Djikstra amnesia, tptacek's name for Edsger Djikstra's amnesiatic behavior, not an effect discovered or promoted by Djikstra.

when it eventually gets rounded to "Djikstra effect".)
https://developer.apple.com/app-store/small-business-program...

> If a participating developer surpasses the 1 million USD threshold, the standard commission rate will apply for the remainder of the year.

If you make $999K from January to June, your July revenues will be charged at 30%. That's pretty close to a progressive fee structure, but not quite exactly progressive.

In no case will they claw back $150K from the money they already paid out.
What are you on about? He never got his clothes back
You hired a coach to learn deep learning? Was it one-on-one?

Also, for CPR, was it a group class?
Some people talk enough that just listening/responding will yield a good conversation. Many don't, or will only do so in certain moods, or after they feel very comfortable with you. If you are one of these people, learning to connect with others of the same "type" could expand your world.
I was very harshly judged for my interest in KFMDM :p
>Maybe I'm just in the dwindling minority of Mac users.

I mean, I'm sure you are, but you're not alone. Same boat here. In principle Mac App Store could have been a really wonderful thing, I think Apple in the 00s had a real opportunity to do a great service to their users by creating a unified, solid and flexible licensing system for all devs (and then offering a fully optional vetted software store beyond that). Unfortunately they didn't do that and the MAS sucks. There is no upgrade system which is just absolutely fucking insanity. There are huge restrictions on useful functionality, so it can never be a one-stop place. The licensing and Apple ID management is a total fucking mess too, can't consolidate or transfer licenses like just about every previous Mac system in existence, all sorts of normal concepts like vol or other discounts are a pain/non-existent. I have an old iTools account, and I'm not even allowed to change the primary email address!

The MAS experience, and Apple's online service experience in general over significant time, is just miserable, completely unnecessarily too. Maybe they'll fix that someday, but it doesn't seem to be a priority so here we are :(.
It's not absolutely required for end-to-end encrypted apps (that encrypt data with password or use it for authentication). The two benefits of SRP-like (aPAKE) protocols are:

- a password hash (verifier in SRP) is not transmitted during authentication. (But is transmitted during registration and stored on the server). This isn't really required if the secure channel is already established — e.g. TLS — you can as well just send the password hash via TLS, which the server will hash again and check against the stored hash. For registration you already need some kind of non-password based secure protocol to transfer the verifier anyway.

- mutual authentication (that is, client also learns if the server knows the password/verifier). For this case, an app would already come with some kind of mechanism to ensure that the server it talks to is authentic (e.g. TLS with pinned certificates or some other public key protocol with hard-coded keys). So the benefit of verifying that this authentic server is the one that stored your verifier is also limited.

To summarize, there's not much use for SRP in a typical e2e app, since it already needs a secure connection between a client and the server, and SRP verifier is a client-side password hash.

SRP is useful if you need to establish a secure connection with a password and nothing else, but it requires first to store the verifier on the server somehow.
++ biggest pain point is page load speed. Glad its on the radar as suspected. Appreciate the tool though - thanks!
They're not talking about extrapolating from one mistake though. They're talking about drawing one observation from a population of an unknown distribution. At that point that single observation the only estimate of the quality of the entire book. If you decide to not sample further (that is find other chapters in the book of which you are an expert) then the conclusion that the book is trash is the only rational one.

(If you want to read more about this then google "single observation unbiased estimator")
Only an idiot would rob a bank (2012)
Apple is implementing a feature that a lot of users want: requiring opt-in for tracking. Facebook wants users not to know when they're being tracked and definitely doesn't want them to have to opt-in to tracking. Facebook knows users don't want to be tracked.

Does adding this new feature make Apple a good and virtuous company? I'll leave that for the Tech Vatican when they decide whether Apple gets to go to Tech Heaven.

Personally, I don't really care about that, I just want the feature and find Facebook's argument against it to be very weak.
Cancer isn't one disease. Targeted treatments take a long time to develop, and only cure one type. The vast majority of cancers are still treated using a sledgehammer approach. I had lymphoma, and took both a general poison (bendamustine) and a very narrowly targeted monoclonal antibody (rituximab). The bendamustine kicked my ass a bit because it's simply poison. The rituximab hardly had any side effects at all, because it only targeted specific cell types (both healthy and cancerous cells of that type, but still focused).

The idea that there is or ever will be a "cancer cure" is a popular misconception. There are hundreds--if not thousands--of cancer variants. The more targeted the treatments are, the fewer patients any one treatment can help. It takes a decade or more and hundreds of millions of dollars for each targeted treatment. There's still an enormous need for broad-spectrum treatments in addition to targeted ones.
A single SVG icon will get one to 88% browser support, which depending on use case may just be good enough.

https://caniuse.com/link-icon-svg
This is celebrating their Nature publication today. Here is the preprint:

https://deepmind.com/research/publications/Mastering-Atari-G...
https://arxiv.org/pdf/1911.08265.pdf
I didn't realize you could actually leave SIP on but use a different chain of trust! Would you be recompiling XNU to do this?
Hey! Yes, we’ve contacted restaurants about whether they can cook ‘off the menu’ and almost all of them said yes. The problem appeared in price estimation, thus a step to send your meal to the preferred places first is needed. Restaurants then see if they can cook and for which price (only those with the ingredients available). Also, they need to respond to the customer via the app asap, which is okay for most restaurants.
There hopefully will be a feature to start with a restaurant and create from their own ingredients (like at Domino’s), as it can more appealing for some users, like you suggested
I think another problem is the accuracy of the info and ability to dispute it. I noticed my FitBit (and I'm told with many other wrist-based heart rate monitors) don't do well with sports like boxing and rowing. My chest strap is more accurate, but doesn't get integrated with FitBit's data. I'm sure there are many other unaccounted for issues and often these kinds of data sets can't be disputed because the process is mostly automated and not transparent.
> Tip: the ico can just be a renamed PNG file

6+ years of webdev and I just learned this now. So many wasted "convert png to ico" Googles...
I have been checking out OPAQUE for sometime. But I couldn't find any reliable javascript implementation that I can use in my webapp. Do you know of any such implementations.
There's a blog post claiming the Earth is flat. Would the BBC publish an article on it outside of satire?
> They are a nice way to filter people who are not willing to spend a lot of time studying challenges to have job interviews though.

They filter for general problem solving skills. Whether you acquired those skills through a degree, self-study, a week of leetcode or 3 months of leetcode will be up to your individual background and aptitude. It's a hiring process - filtering for something is the whole point. Personally, I prefer being tested on more general stuff (like algorithm problems) over most of the alternatives.
Tune into Forests from Around the World. Escape, Relax and Preserve
It happens all the time. The last time I was looking for a new job, I interviewed at a bigger tech company in my area (SF based though). In the first screen I was open about not having recent JVM experience and 0 experience with JVM optimization/tuning. The hiring manager said it was no big deal and they hire and train people that are new to that space all the time. I was then given a take home challenge that required Java. Then, during the technical assessment, all of the questions were around JVM optimization. I just kind of laughed and skipped a lot of questions until the interview ended, where I emailed the hiring manager withdrawing from further interviews.

Interviewing suck. Sometimes it to them, not you.