Live data from Hacker News

Ask HN: What's the hardest problem you've ever solved?

news.ycombinator.com

301–310 of 441 posts

Re: Ask HN: What's the hardest problem you've ever solved?

#301
post #103

Earlier quoted context omitted.

I would 100% talk about this in interviews depending on the interviewer. I can think of a couple interviews I had in SF that would probably be appreciative of this level of effort because you principally reject memorization.

Admitting to significant academic fraud during a job interview is a very, very bad idea. Furthermore, I would question the ethics and morality of any company that said "Wow, you solved an incredibly tough problem in order to commit fraud. Boy, are we the place for you!"

I find your point of view very narrow minded. I even admitted cheating in my bachelor's during my Master's thesis presentation.

It was in Switzerland, and culture is different; maybe we're less black and white.

Re: Ask HN: What's the hardest problem you've ever solved?

#302

I eventually solved a bug that took about 1.5 years to figure out, since we were not able to reproduce it, and it only happened on a customer's system. Long story short, it ended up being a by-product of sending a (256*N)+1 byte packet through the system, and the fpga asserted a signal 2 clocks later that did not assert in time on those sizes. This resulted in a single buffer leaking, but eventually it built up expon…

I think that's the craziest one I've heard so far. I can't imagine trying to reproduce a hardware bug in an FPGA with a logic analyzer. How much time did you spend on the bug? Was it something that you ignored for a long time, and then you decided to dive in and spend a couple of weeks on it?

It was about 8 years ago, so my memory is a bit foggy. At one point we had everyone on our entire project working on it, which was about 20 people. We had daily calls with the customer since it was causing frequent outages on their network. I was full time on the bug for a while, and most of that time was spent making meticulous documentation for what happens in every clock cycle in the fpga.

I visited the customer's site about 3 times during that period with a very expensive logic analyzer. By that time I'd added a ton of debug code in the fpga, and the logic analyzer was set to trigger if any of those counters hit. A big breakthrough was we were counting packets at each point in the pipeline, and that debug was showing that at a certain point, the counters were off. This was huge since it was the first clue into what was actually happening. Prior to that we just knew that there was an exponential increase in retransmitted packets until the whole thing came crashing down.

Looking back on it, I'm really happy I ended up writing a large post-mortem with screen shots of the logic analyzer and everything. I can go back and see exactly what caused it, which is really interesting even today.

Re: Ask HN: What's the hardest problem you've ever solved?

#303

I eventually solved a bug that took about 1.5 years to figure out, since we were not able to reproduce it, and it only happened on a customer's system. Long story short, it ended up being a by-product of sending a (256*N)+1 byte packet through the system, and the fpga asserted a signal 2 clocks later that did not assert in time on those sizes. This resulted in a single buffer leaking, but eventually it built up expon…

I feel you. A bug in our recovery software would result in the live CD being unable to open the Windows kernel file after having located it on disk. No amount of logging we added to the code made sense. In the end, after more than a year, there was a customer in the UK that could reproduce the problem each time on a clean Windows 10 install (so no private info). I mailed him a new SSD to replace his old HDD and paid…

That's awesome!

Re: Ask HN: What's the hardest problem you've ever solved?

#304

I came up with a recursive layout (ie graph drawing) algorithm for directed acyclic graphs (DAGs). I was trying to draw program flowcharts and the hierarchical layout graphvis creates are very ugly and unbalanced. If you reverse the back edges of while and for loops a flowchart is a DAG. I did a python implementation. I research graph drawing for a while and the closest algorithm to mine was a “delta drawing”, I also…

> If you reverse the back edges of while and for loops a flowchart is a DAG. Depending on language there could be also end recursions that never return or - the horror- GOTOs.

Re: Ask HN: What's the hardest problem you've ever solved?

#305

* Creating a prototype of a low-cost alternative to braille displays for PCs for my thesis (without access to modern machining resources): https://www.youtube.com/watch?v=bPwgkf1aZ9I then filing for a patent (that I didn't get): https://patents.google.com/patent/US20130203022A1/en * Improving that design to make it work reliably and conveniently enough for mass production and deployment in 3rd world countries (still…

This is really amazing stuff! How do you keep moral and focus when tackling harder projects?

Re: Ask HN: What's the hardest problem you've ever solved?

#306
post #271
post #260

Earlier quoted context omitted.

I was going to say the same thing. We really need a HN hall of fame for many of these types of comments. Pure gold. Made my Sunday.

Are people kerping (private) lists for these? Would be great if they felt like sharing!

Some people keep "favorites", which are public.

Re: Ask HN: What's the hardest problem you've ever solved?

#307
Built a package manager to transfer user selected data from one installation of the system to another. The data was stored in a mysql database, and used foreign keys everywhere, so installing the exported records in the right order was necessary. Some data was local to the machines though, and should absolutely not be exported. But exported entities need to be able to reference these local settings, so these references were exported using a symbolic value - the records had a name field which was used. Exportable entities included packages, so the whole thing was recursive and all requirements also needed to handle that.

Sounds fun right? Well, everything should also be installed keeping the integrity of the system intact, and if something didn't work out (say, an entity of the same name as one that is being installed already exist), then everything should fail in a controlled manner and the user should be given a good error message and there shouldn't be any crap left behind in the system.

Then the people in charge realized that this is nice, but as they built a big package hierarchy that was then installed and modified slightly in the customer systems, it would be nice to be able to serialize, and uninstall the local changes to packaged objects, uninstall the packages, install a new version and reapply the changes. These should also be possible to package, so that each customer system was possible to recreate. Supported serializable changes was not only fields, but also above mentioned symbolic references as well as whole new records.

This is easily the task that has formed me the most as a developer.

Re: Ask HN: What's the hardest problem you've ever solved?

#308

ICOs and DAOs both present difficult legal problems vis-a-vis the SEC and securities laws. Where others have failed we believe we have developed a legal framework for both a non security/unregistered ICO and legal DOA. To legitimize our legal position we submitted a No Action Letter to the SEC. Uniquely this is not just another legal article/arguement, because the SEC will not respond to a hypothetical No Action Lett…

I'm curious too, would you mind sending me a link?

Abstract: The Green Bay Packers are the only community owned team in the NFL. Legally they are a very unique organization - a non profit with stock-stockholders - in fact the NFL even considers them at a competitive advantage to all other teams because of that and has control over Packers right to offer/issue new stock to raise capital. But when the NFL does permit the Green Bay Packers to raise money by issuing new stock, the Packers file a No Action Letter to the SEC setting out their legal argument that Packers Stock is not a security or does not need to register. We published their original documents, our redline versions and our final version of the SEC letter and Public Offering Document. Our Delaware Certificate of Formation and Operating Agreement are also worth a look because they memorialize the LLC units being maintained and issued on the Ethereum Blockchain and include the addresses for the “Blockchain Stock” (ERC20) and public offering smart contract.

The SEC does not accept hypothetical No Action Letters so behind the cloak of anonymity of The Satoshi Nakamoto Trust we launched a Delaware LLC and submitted our legal argument. Initially intended to be a safe/sandbox startup to legitimize our legal framework, we memorialized the duration/powers/duties of the LLC into a decision tree - which isn’t but could further be memorialized in smarts contracts in future iterations - which begins to look a lot like a Delaware DAO.

SEC No Action Letter- Delaware LLC & Operating Agreement

1. The Green Bay Packer’s Proposed Stock Offering “No Action” Letter dated June 16, 1997 [1]

2. A redline version of the Green Bay Packer’s Proposed Stock Offering “No Action” Letter dated June 16, 1997 [2]

3. The Blockchain Stock Company’s Proposed Blockchain Stock Offering “No Action” Letter dated 31 October 2018[3]

a. Exhibit A - The Blockchain Stock Company’s Certificate of Formation (Articles) [4]

b. Exhibit B - The Blockchain Stock Company’s Operating Agreement [5]

Public Offering Document:

1. The Green Bay Packer’s Public Offering Document [6]

2. A redline version of the Green Bay Packer’s Public Offering Document [7]

3. The Blockchain Stock Company’s Public Offering Document [8]

[1] https://drive.google.com/file/d/1hhv5dKkU2R9D81wZUYaH5wxWAE1... [2] https://drive.google.com/file/d/1ATCnecraourkjNx5FYPsXzPsoJe... [3] https://drive.google.com/file/d/1XbUuDO-R1JUMh_BnHnSbcq5rRG5... [4] https://drive.google.com/file/d/1mrzY9mTXAqgXq-0SzevvYOmGCvK... [5] https://drive.google.com/file/d/1noePTMojVq-sw3UVMxSffAss1zX... [6] https://drive.google.com/file/d/1yrfu1eTGiev8bOa_cnGiOPr3-YU... [7] https://drive.google.com/file/d/10J1-oGCKXmuK1WeUqdcNk0ntjy1... [8] https://drive.google.com/file/d/12IC7oYYNzIcLp3uX1JJbumPY0Qe...

Re: Ask HN: What's the hardest problem you've ever solved?

#309

Earlier quoted context omitted.

This is 50ms. This is 200ms. doesn't quite work as well. Depending on the situation there has to be some theshhold of diminishing returns.

Fair enough. Unless you're talking about lags for automated trading systems/ algos where even that single "I really can't measure this" sec difference counts.

I mean, sure, the precision matters for HFT but at the scale the point would be moot since the time is so minuscule. Unless you hyperscale it: “on 1,000,000 trades the 50ms difference becomes very pronounced and could cost us $z” or something of the sort. But I still think it loses “the spirit” of the method — best way I can phrase that.

Re: Ask HN: What's the hardest problem you've ever solved?

#310

Earlier quoted context omitted.

I have to steal that idea next time someone talks about time delays and says "it's not a big deal!" Awesome!

This is 50ms. This is 200ms. doesn't quite work as well. Depending on the situation there has to be some theshhold of diminishing returns.

You can demonstrate that scale of difference using audio/video sync.
Post reply on HN