nialo

In case anyone here hasn't seen it, I want to share this very cool youtube series of an Australian clock maker creating a replica of the Antikythera device using only tools believed to be available to the ancient Greeks: https://www.youtube.com/watch?v=ML4tw_UzqZE&list=PLZioPDnFPN...

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.

In the spirit of learning about these things, you might want to try these: https://cryptopals.com/

In particular, problem number 17 from set 3 is an attack against CBC mode AES used with Mac-the-Encrypt. Maybe a fun exercise would be to first implement that attack against CBC mode, and then try to see if you can make it work against your CFB-HMAC protocol.

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.

In addition to being a better analogy, I am told it is possible to replicate the effect with a physical capacitor and a gas-discharge lamp: https://news.ycombinator.com/item?id=4600996

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)

Is your suffix array implementation open source/available online anywhere? I'm always curious to see what other people's version of these sorts of things look like.

(I wrote an implementation of Ukkonen's suffix tree algorithm in C as maybe my second C program, it was pretty frustrating for a long time)

I haven't read this paper, and haven't worked with the compressed variety of suffix trees/arrays. That said, I'm confident it's possible to retrieve the original file from a normal suffix tree, although it would be pretty slow. I imagine it must be possible to retrieve the file from the compressed version as well.

If nothing else, I think it is possible to retrieve a complete file from any index that lets you search for substrings and get a full string and position in the file back. Just search for all length 1 substrings, get a map from position -> string, then reconstruct the file from that.

I doubt it's worth storing files this way, because turning the index back into the file sounds very slow. I'd rather just store the file and the index, the time v. space tradeoff seems like a good one if you really care about search performance. That said, I use The Silver Searcher, and it's fast enough with no index that I don't think any of this stuff is worth the effort for searching text files on a file system.

They solve different problems. In particular, ripgrep and friends are designed to search arbitrary and potentially large directories with no pre-computation. They run in time ~linear in the size of the files to be searched.

The paper under discussion here is about a new way to create an index that also takes time ~linear in the size of the files to be searched, although presumably with a higher constant factor than just searching those files. After you have the index it's possible to search it in time linear in the length of the query rather than the files. This is much faster, but requires storing an index that is at least as large as the original file set, and keeping it up to date as things are changed etc.

Asking because I don't understand:

What's the difference between the seller owing me money back and me having a property right in that money? They seem similar to my not-at-all-a-lawyer intuition, what am I missing?

I wasn't particularly talking about software engineers. I have a mechanical engineering degree, and none of the ~20ish engineers at the first place I worked had a PE licence. If you want "engineer" in a job title to mean "has a PE licence", you're going to need to change the title of perhaps 95% of people currently employed in mechanical or electrical engineering. Probably more than ninety percent of aerospace engineers too. There is maybe an argument to be made that programming shouldn't be called "software engineering", but this really isn't it.

Also for whatever it is worth, I've now worked in mechanical engineering for 5 years and software for about 1 year, and they both feel the same to me. Software is sometimes faster and sloppier, but I think that's just because the build process for a program takes minutes and the build process for the CVD machines I used to design takes months.

This may be a reason why, but it's not a great one. The vast majority of people employed in the US with "engineer" in their job title are not Professional Engineers.

In one of the Mill talks, I've long since forgotten which, someone asks Ivan Godard a question about RISC. His response is something like "there was a brief window in the eighties where if you had a RISC machine you could get the whole computer onto one chip." I don't enough experience to know if this is right, but it strikes me as a nice clean explanation. It also explains why x86 won since then, because a couple generations later it was possible to get the whole computer onto one chip with x86 as well.

(I may have misquoted badly, in particular I'm not sure about the dates)

(edit: I found the talk, it's the last couple minutes of this: https://www.youtube.com/watch?v=LgLNyMAi-0I)

I think this is correct but maybe not quite far enough. I am much more willing to give out my social security number than my Gmail password.

I don't think it's worse. The (possibly missing) context of this post is a Compute Shader running on a GPU spending more time writing out the results of a computation than actually doing the computation.

As I read this post, the moral of the story is just to try to write your code in such a way as to always have that substantial work to do with the data. Prefer one big pass over everything to several smaller passes, each of which must write out results, especially on a GPU. Try to actually have 11 instructions per byte of memory access.

I don't think the intent is to make any argument in particular about the state of CPU or GPU design or anything of the sort.

I went to Georgia Tech for Mechanical Engineering, I think generic engineering has approximately the same set of sexism problems as CS. I wouldn't try to use it as a way to say that CS doesn't have a problem

That is really cool, thanks for the link. I should apparently make fewer assumptions.

I'm not sure why I thought there was a rubber seal, I have vague memories of seeing an exploded view with one somewhere.

Helium does go through metal, although even in this case the amount is probably insignificant.

Helium also goes through whatever the sealing gasket is made from, at a much higher rate. http://lpc1.clpccd.cc.ca.us/lpc/tswain/permeation.pdf is a neat chart, probably the gasket is buna-n because it's cheap. I think that chart and https://en.wikipedia.org/wiki/Permeation are enough to get an order of magnitude answer to OP's question, but I'm not quite up to doing the math.

Serious vacuum systems have to worry about this sort of thing more than one might expect. I once had a project where two test engineers and myself spent around a week hunting for leaks in a vacuum system that turned out to be caused by my specifying Silicone o-rings instead of Viton.

I think the trick is that the glass actually doesn't need to bend much. Notice that the caption here: https://en.wikipedia.org/wiki/Schmidt_corrector_plate#/media... describes the plate as being hard to tell apart from a flat disk visually.

It feels to me like the root problem here isn't how many people are doing the homework problem or whatever. It's that this is increasing your time spent as a candidate relative to the in-person interview.

I think your last paragraph is very close, but I think the thing that matters is "no wishy-washy rejections". Not being the only person taking the test or how much time the company spends seem like ways to make that happen to me.

Maybe I'm just completely wrong here, but I think most of the objections to homework type tests are being caused by processes where the homework test was in addition to the in-person whiteboard interview, not instead of it.

How would you feel about a process that was: some preliminary screening -> nominal 4 hour homework thing -> in person meeting to confirm that you're not a complete asshole and negotiate salary?

I am confused by this, could you help me to understand why this is so?

In particular, it seems to me that take-home assignments are strictly better for candidate scheduling etc than in-person interviews, if time spent can be held equal. Maybe time spent is just not equal very often?