ajbonkoski

Did the N64 have an MMU? I guess so, COP0. I wouldn't have guessed that.

Yes to this a thousand times. I firmly believe the framers of the constitution would be horrified by this law. This should have been killed a long time ago.

I've used i3 for years. It's an absolute love affair.

I used Xmonad and awesomewm before. I don't understand enough Haskell to configure Xmonad and awesomewm is a giant dependency mess (the irony being that it's a fork of dwm , the minimalist suckless wm)

Anyways: i3 has struck the perfect balance for me. Written in C, easy to modify, configuration is intuitive and obvious (I have no interest in spending weeks learning how to configure it), and best of all super stable and bug free.

Highly recommended!

I started using WSL2 on my windows machines just to run i3 on windows. That works too! (Basically you vnc to WSL to get i3)

Bad reporting, just go read the paper directly. They busted the coin example.

I was super confused by it because it suffers from classic AM-GM inequality mistake. I doubted that Peters would make such a trivial mistake (he didn't). He talks about the utility of a single outcome of the game, not the expected value of 10 plays of 10 different games.

In the article: Using an arithmetic mean on percent-return doesn't make any sense. If you calculate the expected value and mistakenly use arithmetic mean you'll get +5%, but it's actually roughly -5% when calculated correctly with a geometric mean.

Which is why all their silly simulations come out negative.. none of which has anything to do with Peter's actual work.

This. Value investing is characterized by "long-term performance". Looking at a single month to make this argument is kinda silly.

Stopped reading at:

"In the past week or so, fortunes have reversed. Technology stocks have sold off. Value stocks have rallied, as prospects for a coronavirus vaccine raise hopes of a quick return to a normal economy. This might be the start of a long-heralded rotation from overpriced tech to far cheaper cyclicals—stocks that do well in a strong economy. Perhaps value is back."

Haha. No. It's not back.

Over the past YTD, AAPL has returned 70%. The article's publish date is 11/14/2020. Around that timeframe, AAPL moved less than 5%. This is not evidence for collective change in investing philosophy. Perhaps tech is over-bought, but you have to argue better than this. It took me all of 2 minutes to check.

This gets at the heart of one of my big gripes about how we talk about engineering and technology.

Often a fancy new thing is introduced with a very long list of pros: "fast, scalable, flexible, safe". Rarely, is a list of cons included: "brittle, tough learning curve, complicated, new failure modes".

This practice always strikes me as odd because the first law of engineering is "everything is a trade-off". So, if I am going to do my job as an engineer I really need to understand both the "pros" and "cons". I need to understand what trade-off I'm making to get the "pros". And only then can I reason about wether the cost is justified.

Rookie mistake: It's not just about the FLOPS, the interconnect matters too.

There is a reason why everyone builds super computers in a large local cluster. It's so they can have a high-bandwidth low-latency interconnect between all of the compute. The second you need to shuffle partial data results between compute nodes, you have to pay the latency hop. Interconnect quality is often a huge bottleneck, ignore it at your peril.

I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives"

I would hope that people with the same objectives would agree on simplicity for that domain.

Examples:

Need a lot of machine control, direct memory control (page alignment, cache alignment, shared memory, numa, etc) interact with system calls directly, interact with hardware, and security is not important in the domain (e.g. private hpc cluster behind a firewall)

C is probably the simplest

Need to quickly prototype something medium sized that involves non-trivial data structures or needs to interact with an http server. And you don't care about performance.

Something like Python is probably simplest

Etc etc etc

By contrast.. try doing the former with Python, Java, etc and see how much additional cognitive load you have to add.. ever try the later with C.. no fun.

(sigh) They're comparing averages, so the whole theory is suspect.

Averages are a terrible way to do a comparison. Averages aren't terribly useful unless you know that your data is Gaussian (or a sum of IID Random Variable => see the CLT). Folks love to erroneously assume Gaussian.

In this particular problem, I would expect to see a multimodal distribution for the liberal arts majors.. (i.e. some folks have massive salaries (famous authors) and some have small salaries (high school English teachers)).

In such a case, the average can end up at a value that basically doesn't exist in the underlying distribution. So you end up comparing nonsense.

This a load of nonsense FUD. It's all sensationalism in response to the current political climate. He'd be singing a completely different song at the height of Obama's presidency.

Even the language and word choices are FUD: "elites". Conspiracy theories work because people respond more viscerally to fear and uncertainty than to optimism.

Even more amusing: his argument is actually that (1) we basically didn't have a democracy because the "elites" ran the show, then (2) technology made the US more democratic, so (3) democracy will fail.

What? Because things are more democratic, the democracy that we never actually had is going to fail now?

You believe or you know? Nothing I've read suggests that. Please don't advance ideas like that without giving proper justification; this is exactly how myths start.

Reading the mailing list end-to-end actually shows how much research Tim did before designing it. To suggest that the "academics" had no clue is extremely disingenuous. Worse, it misleads the next generation of great would-be algorithm designers into thinking that studying the research is foolish. Study of both the theoretical and the practical are hugely important; ignore either at your peril.

I don't get articles like this.. they seem to miss the bigger point.

Typically there are two modes in my computing: (1) Scripting / Command-line get stuff done and throw-away, and (2) Serious applications that are heavily used, need to process lots of data and be as fast as possible (e.g. processing millions of files like this one where the algorithm constant factor really matters).

In case 1: Hack something together with shell or python and get an answer. If it takes 100-1000x of the equivalent C program, than fine..

In case 2: Custom special purpose C or C++ code

I really don't understand the middle ground here. The equivalent C version that does the same job runs in ~250 millis on my slow Yoga 2 Pro laptop. Total line count 83 of pure C (no other libraries).

Is it "elegant"? Depends who you ask.. But, at the end of the day, "elegant" doesn't pay the bills..

Page 4 summarizes all that really needs to be said here: http://www.sec.gov/litigation/admin/2013/34-70694.pdf

Knight didn't have a proper risk system. A correct risk system is a dead-man switch. There is just no way to place this many erroneous orders and get them filled. Capital Limits Exceeded: Full Shutdown. Risk System Crashes: Full shutdown. Heartbeat fails: Full shutdown.

Better to have a paranoid risk system than a rouge strategy.

The real flaw wasn't legacy code, it was straight-up laziness. This really isn't rocket-science.

"The tradeoff for the bad hours/pay is that you'll get more autonomy in your work and the ability to really influence the product. To me, this is why you should work for a startup."

I'm beginning to really hate hearing this over and over. So many people accept this at face value when in reality it's dubious at best.

Case in point: 6 months ago I left a start-up for a medium-size company (~300-400 people) that has been around for ~15 yrs with no ambitions of going public nor taking outside investment. I get both amazing pay and an insane amount of autonomy. I doubt this could be matched by a Big or Small company.

Here's the rub: Silicon Valley markets itself VERY WELL and if you're willing to internalize everything that comes out of this marketing machine, then yes... it's snake oil.

I'm not diminishing the the importance or impact of entrepreneurial ventures, but I think we can do better than Cookie-cutter Generalisms repeated ad nauseam without independent thought.

"we have a particular use-case where we have a large contiguous array with, say, 100,000 lines and 1000 columns"

This is where they lost me. This is NOT a lot of data. Should we be surprised that memory-mapping works well here?

Below about 100-200 GB you can do everything in memory. You simply don't need fancy file-systems. These systems are for actual big data sets where you have several terabytes to several petabytes.

Don't try to use a chainsaw to cut a piece of paper and then complain that scissors work better. Of course they do...

This is so broken. The author describes front-running and then goes on to conflate that with arbitrage. Those aren't the same thing! The only thing the author gets right is that neither are a consequence of HFT, they can happen at any trading-speed granularity. Further, there is absolutely nothing unfair about arbitrage. Every-time you go to a store and think "I saw this cheaper at a different store, I should buy it there instead", you're also doing a form arbitrage. Arbitrage synchronizes prices. The arbiter earns the price spread as a reward for moving the prices into alignment.

Argh, I really dislike this article. It spreads a LOT of misinformation:

  1) His friend did NOT write a bytecode interpretor, he wrote a bytecode compiler: there is a HUGE difference between those two.

  2) No, it wasn't faster than assembly code. And the arrogance and audacity to make such a claim is obnoxious. Unless you gained access to Intel microcode, this is just plain wrong.

Well, I'm always a little baffled when I see such great techniques for rejecting potentially awesome candidates.

Why overthink a toy example? The only purpose served by fizzbuzz is to weed out people who can't write any code.

If you want to know anything else, ask a more relevant technical question. It's downright lazy to simply jump to conclusions, and as a result you end up hiring the wrong person.