nialo

I want to second this, I worked as a mechanical engineer and never had accurate time estimates there either. Estimates of how long the work will take will be wrong whenever there are new problems to be solved, which is all engineering worth the name.

I spent some time helping someone get this set up for their music group, and it's really really nice just as a voice chat program. It's amazing how much of the unpleasantness of something like a Skype call goes away with really low latency

The vague impression I get is that maybe the answer is "Because Apple's software people and chip design people are in the same company, they did a better job of coordinating to make good tradeoffs in the chip and software design."

(I'm getting this from reading between lines on Twitter, so it's not exactly a high confidence guess)

I have walked out of pharmacies without buying Sudafed that I would have wanted because the "ask for a pack of Sudafed" step was too uncomfortable. Buying liquor is easier because I don't have to say words to explain what I want.

Edited to add: I'm not particularly up in arms about needing ID, and I feel like buying Sudafed got easier somehow recently, but this seemed like a place where I could help explain what sorts of things can be uncomfortable/difficult for some people.

I work on another music file management system, my personal special hell is playlist files. An m3u playlist file is just a new-line separated list of file paths, which can be relative or absolute, and potentially encoded in whatever locale is set on the users computer. Some fun issues:

* Windows and Mac filesystems are generally case-insensitive, so some users will have the file names in the playlist file in one case and the actual file names on disk in another format * Sometimes file paths cross between two different filesystems, because one is mounted in the other with a USB drive or over CIFS or similar. Sometimes these two different filesystems have different case sensitivities * There's no way to know how the playlist file was encoded * HFS+ normalizes file paths to Unicode NFD, but there's no guarantee that the paths in a playlist file will be normalized. Also, sometimes users generate an m3u file on a Windows system and expect it to just work on a Mac. Also, the filesystem nesting problem with network or USB mounts can happen this way too.

I switched also recently, the thing that helped me was adding this:

alias rg='rg -S'

to my .bashrc so that rg had the same default case sensitivity as ag.

CVD in general is slow and time consuming, but because graphene is just one atom thick growing graphene specifically might not be too bad. Also the process gas/chemistry requirements are relatively very simple.

For reference, I used to see ~4 hour cycle times for growing graphene on copper sheets. I think most of that was in the heat up and cool down, maybe order of 30min actual growth time. These numbers might be off by a factor of 2-5, it's been a few years since that job, and I was a equipment design engineer not a process guy as such.

Asking honestly because I would like to know: What is wrong with writing a state machine using gotos? Assuming that one is solving a problem that definitely needs a state machine for some reason.

Do you know if this is still true with the newer "concurrent" garbage collector in more recent Mono versions? I work on an audio player app rather than games, but also have problems with the GC in Mono on IOS. We're hopeful that eventually they'll go away, but haven't tried again recently.

Have you tried implementing the length extension attacks?

Truncating from 512 bits to 256 bits hides 256 bits of the state from the attacker, so in order to use a length extension attack they would need to "guess" those bits.

SHA-256 truncated to 224 bits is vulnerable to length extension attacks if the attacker can brute force the remaining 32 bits of the state. Some use cases will make this possible or practical, some will not. It depends on the details of the problem being solved.

This is somewhat self correcting.

HFT firms are make money by taking a spread, which is effectively the cost of making a single trade. As they compete and get better and better at there jobs, this spread well be reduced, the amount of money available to pay for the best and brightest programmers will come down, and they'll suck fewer of them away from other parts of the economy.

The point being, the further they go past this 'point of diminishing returns', the less money they can possibly make. To the extent that HFT is a zero sum game, there will always be a limit on how much money they can spend.

(I believe but cannot prove that this limiting effect has already started, HFT firms are consolidating and making thinner margins than they used to)