1e-9

Good question. Given the apparent issues with pre-defined point-in-time reviews, the authors suggest continuous or random-time reviews instead.

The study found that regulated banks tend to unload risky assets prior to regulatory review and then load back up on risky assets after review. The authors conclude that regulated banks are carrying more risk than was thought (mainly in liquid securities) and that reviews should add a greater element of surprise in timing and structure to prevent this.

CentOS has had a stability advantage by being downstream of RHEL. It makes sense to switch the free version to be upstream of the paid version.

Unexpectedly changing CentOS 8 after many had already migrated to it makes no sense and thoroughly damages Red Hat’s reputation in my view.

Perhaps Red Hat will consider continuing CentOS 8 under the same terms they had promised, while also releasing CentOS Stream. Many would value earlier updates over additional stability and make the switch willingly. The rest would avoid having the rug yanked out from under them without warning. Obviously, this dual path would require more effort, but it would engender more trust in Red Hat going forward even if we knew there would be no CentOS 9. It would also keep many from migrating elsewhere.

> Why do you expect Red Hat to maintain a free OS which targets exactly the same use case as their paid OS?

Because they said they would.

They could have made the change effective prior to releasing CentOS 8, or they could have made it effective for all versions after CentOS 8. Either of those paths would be understandable. Making the change after many have already migrated to 8 sends the message that Red Hat commitments are not to be trusted.

Reading immersive fiction makes me significantly more productive. I believe there are two main benefits: 1) It hones my ability to stay focused, and 2) It exercises the world-simulation part of my brain, which I use heavily for understanding problems and visualizing solutions.

Whenever I go more than a few weeks or so without reading fiction, I tend to notice a drop in my productivity and problem-solving ability. Binge-reading a good book fixes it every time.

In previous rodent studies, intermittent fasting (IF) was found to stimulate production of neural stem cells in the hippocampus, which is a portion of the brain critical to memory formation. This study measured apparent IF-induced changes in a particular type of molecular communication (the Notch signaling pathway) that the body uses to tell itself to increase such stem cell production.

> VC is a casino for the rich and just like gamblers in casinos they have no idea what they are doing

Except that the VC expected return is positive. They just need a sufficient number and diversity of bets to lower their variance to a small value relative to their expected return, which most of them don’t do.

> But on probability your gut-feel will always fool you.

Yes, this is especially true when first learning; however, one can still develop intuition so that it serves as an invaluable motivator and guide through difficult problems.

Modifying a now trite-but-true saying from the statistical modeling world: “All productivity metrics are wrong, but some are useful.” I imagine there will always be an infinite number of ways an employee could add value that would be inadequately reflected in any finite collection of metrics, but that does not eliminate the usefulness of good metrics. Managerial judgement is always needed to account for exceptions that require accommodation.

> Never believe stories like this, measuring productivity is an impossible problem.

While I do agree that many productivity metrics are useless and even counterproductive, measuring productivity in a useful way is most certainly possible. For example, sales organizations measure sales per unit time for each sales person. I doubt you will find a successful sales organization not doing this.

> That is, if I were an automated machine trader, I would add LTSE and their slow price changes and compare them to NYSE and make zillions.

Limiting trading frequency, limiting order types, and disallowing shorting would create even better opportunities for automated trading than what LTSE would provide.

> Shorting is never a long-term game and should be banned, as it never does the company any favours.

The economy benefits when market prices more accurately reflect relative value between assets. Hampering the ability of the market to lower a price that is too high never does the economy any favors. More specifically, it harms investors who buy the overpriced stock and it harms other companies raising capital who merit a higher relative price.

Similar discussion, which also contains one of the funniest comments I've seen on HN: https://news.ycombinator.com/item?id=23248779

Those who have read it to insatiable toddlers --- sometimes 5 or 10 readings in a row --- get the reference.

Imaging missiles typically have the sensor mounted on a gimbal so the target can be centered in the image even when the missile body is not pointed at the target. But yes, the line-of-sight to the target will generally be off of the missile boresight.

Proportional navigation: https://en.wikipedia.org/wiki/Proportional_navigation

Very sad.

The extraordinary push by firms such as Robinhood to encourage unprepared individuals to participate in day trading is a troubling development. They can call it "investing" all they want, but it is clear that unlimited commission-free trading without any meaningful vetting encourages uninformed day trading.

The markets benefit from having a highly diverse set of entities, each with its own particular area of expertise that gets pooled together.

The markets are damaged by high rates of uninformed trading, which only promote instability and general disfunction. More importantly, these traders have overwhelming odds of getting hurt. The only ones who benefit from such trading are 1) firms like Robinhood who get paid for their unsophisticated order flow, 2) market makers, and 3) informed entities pushing markets back towards efficiency. Speaking as one who benefits, I can say that we would all be better off as a society without this particular order flow.

I think there should be a limit on the rate of commission-free trading until an individual can demonstrate a reasonable level of proficiency. A firm like Robinhood could do some good if they provided a great paper trading environment and tools that allowed users to evaluate expected profit and variance in particular strategies they want to pursue. Once a trader demonstrates profit beyond random noise, commission-free trades could be gradually increased. I think this would encourage people to learn how to provide services of real value to markets through their trading or else recognize they are unable to be profitable. Unfortunately, I doubt Robinhood would ever do this as it would significantly undermine their current business model.

> Are you going to warn the .x% of users that are using Windows XP to not even connect to the Internet?

Sure. The fact that more than 1% of Windows PCs still run XP suggests that additional warning is merited.

Please don't connect to the internet with Windows XP. It's not safe. Extended support ended in 2014.

There is always the risk that such a website is, or could become, malicious and save generated numbers for future attacks; or, it could suffer from a hardware, software, or environmental issue that reduces entropy. While I would not fully trust a website-generated random number for anything important; you can XOR a number from a website such as www.random.org with a number from your system's PRNG so that you don't have to fully trust either. Even better, you can XOR again with some dice-generated numbers, your own custom PRNGs, or whatever else you can think of. That way, as long as at least one subset of your sources has sufficient entropy, you are safe.

> The argument is that if you're on a currently supported, non-EOL Linux OS, you will not have this issue after November (since at that point in time, the RHEL 6 will be past end of life).

Limiting to only non-EOL and to only future timelines after November are your own chosen statement limitations, not mine.

My statement that the shuf default is insecure for certain versions is correct and I have provided specific examples. There may be other examples, but I only need one to establish truth.

End of life dates have no bearing on my statement. You seem to be trying to change my statement into something else so you can say it is incorrect.

You can narrow your own statements to only include versions and future timelines that you think are important, which is fine, but it doesn't help those who will still be using the affected versions for years to come. The ELS versions exist for a reason, which should be clear from the fact that Red Hat is a for-profit entity. There is a significant number of projects in areas such as industrial control, defense, and finance, that place a high value on stability and they want that extra timeline that extends far beyond end of life.

You seem to be arguing that there will be no need to use the --random-source option after November. If so, that is incorrect in my view.

ELS versions receive critical security fixes and urgent bug fixes until the end of their support. They are used right up to end of support, or even beyond in some cases.

RHEL 5 ELS will be supported thru November 30, 2020 and RHEL 6 ELS will be supported thru June 30, 2024.

This implies there will be RHEL 5 ELS users for at least 5 more months and there will be RHEL 6 ELS users for at least 4 more years.

So, for at least four more years, it appears there will be users who should use the --random-source option with shuf if they want to be cryptographically secure.

RHEL 6 ELS will be supported until 2024.

My comments are not contradictory to your point about 2013. They are only meant to make people aware that there are supported OS versions in use that have this issue.

The latest versions of RHEL/CentOS 6 use coreutils version 8.4, so I assume their shuf defaults to insecure. I imagine that RHEL 5 ELS must have the same issue. I don't know of any other currently-supported Linux or BSD versions that might be a problem.

Interesting. They stopped using /dev/urandom as the default random file in version 7.3, which created the insecure default situation. Later, in version 8.6, they updated to use a default nonce from /dev/urandom. It's odd that the documentation has not be updated. Perhaps it's because the latest version will still default to an insecure nonce if there is no /dev/urandom?

For easier-to-remember passphrases, you can download the EFF wordlist from https://www.eff.org/files/2016/07/18/eff_large_wordlist.txt and specify that file instead of /usr/share/dict/words

This may not be cryptographically secure. Shuf can default to using a small amount of entropy.[1,2,3] To be certain, you can add the --random-source option:

shuf --random-source=/dev/urandom -n 4 /usr/share/dict/words

[1] https://www.gnu.org/software/coreutils/manual/html_node/Rand...

[2] https://github.com/coreutils/coreutils/blob/v8.5/gl/lib/rand...

[3] https://github.com/coreutils/coreutils/blob/v8.32/gl/lib/ran...

Edit: As ThA0x2 points out in a reply, the latest version of shuf uses /dev/urandom to generate a default nonce, which vastly improves upon older versions. As long as your version of coreutils is at least 8.6 or later and your OS has /dev/urandom, the default should be fine. If you don't have /dev/urandom, even the latest version of shuf (version 8.32, as of June 15, 2020) will still default to an insecure nonce.

With an array of photomultipliers to detect the light, you can estimate direction by measuring the differences in arrival time between detectors.

This is fiction.

My biggest improvement came from eliminating a tool. It was when I stopped using debuggers (except maybe once a year) and invested more time in creating efficient runtime error checks and internal self-tests. Debuggers make me lazy. I find I can solve the vast majority of my bugs more quickly with a little thought rather than running to a breakpoint and examining things.

Most useful tools:

- tmux

- vim

- catch (https://github.com/catchorg/Catch2)

You can configure a new Dell XPS or Dell Mobile Precision laptop with Ubuntu for a no-hassle solution.

If you want CentOS or Red Hat, I've had good luck picking any Ubuntu Dell that is also listed as being tested and certified for Red Hat at https://access.redhat.com/ecosystem/search/#/ecosystem/Red%2.... The only real hassle has been when I wanted to use an Nvidia driver, which requires a driver reinstall after kernel updates, although I believe you can now avoid this with DKMS. I expect that Fedora would also work without issue on any of these.