Hacker News new | comments | show | ask | jobs | submit | mcherm's comments login

It sounds to me like there was only one mis-step in this story. The mis-identification was resolved quite quickly once the accused had a competent private lawyer. So it seems to me that this case is not an indictment of our legal system as a whole so much as it is an indictment of underfunded and/or incompetent public defenders.

What if we tried funding the public defender's office with the same average amount of money per case handled as the prosecutor's office as? What effect would that have on both justice and people's perception of justice? And is this a simple enough test to be run with either public or private funds in a few sample municipalities as an experiment?

The mis=identification was not resolved quite quickly, and notice how they still think he did it. But why did it take a competent private lawyer to deal with the mis-identification?

I'm not sure why others are unimpressed with this article -- I thought it had one simple point to make. And my project has precisely this problem: people spend lots of time getting their environments set up and it is not reproducable.

Obviously, my project needs to be fixed. This article points out that Docker is one way of doing that.

Part of being a Ruby dev is learning how to quickly onboard. In the same way that as a C++ dev you need to learn your way around the output of configure and make, and be able to quickly figure out what error messages are telling you, you need to have that same baked-in knowledge of 1) pull the repo, 2) get the right version of Ruby installed 3) run bundle 4) install missing dependencies as bundler complains about them 5) run rails server and install backing services / configure environment variables as needed. 6) run tests and get them all passing.

If you don't already have this knowledge than you're working with an incomplete set of tools and need to acquire them. The good thing is, if you're sharp, you'll pick up the general gist of things pretty fast. That's why I think nobody's yet written a guide encapsulating this knowledge.

Docker is not the answer to the problem, it adds complexity rather than takes it away. You still have to know the ordinary way things work in case Docker breaks. I guess someone does need to write that guide, given how many people have issues with it, and the hopefulness evident in their pleas to just move to Docker already.

Story time? (Please!)

It was a long time ago, but I remember we were working on an embedded system controlling some industrial equipment, and it randomly crashed; the time between crashes was long enough that it'd take several days before it happened, so even getting a trace of the crash was an exercise in patience. Eventually we did get a trace, and it turned out the CPU would suddenly start fetching instructions and executing from a completely unexpected address, despite no interrupts or other things that might cause it. We collected several more traces (took around a month, because of its rarity) and the addresses at which it occurred, and the address it jumped to, were different every time. Replacing the CPU with a new one didn't fix it, and looking at the bus signals with an oscilloscope showed nothing unusual - everything was within spec. We asked the manufacturer and they were just as mystified and said it couldn't happen, so we resorted to implementing a workaround that involved resetting the system daily. Around a year after that, the CPU manufacturer released a new revision, and one of the errata it fixed was something like "certain sequences of instructions may rarely result in sudden arbitrary control transfer" - so we replaced the CPU with the new revision, and the problem disappeared. We never did find out what exactly was wrong with the first revision, other than the fact that it was silicon bug.

> the time between crashes was long

I know that pain. I was working on the NDIS driver (WinNT 3.5.1, later a 4.0 beta) for our HIPPI[1] PCI cards. The hardware was based on our very-reliable SBus cards, so when the PCI device started crashing, we assumed it must be a software error.

I probably spent 2+ months trying to find the cause of the crash. Trying to decide if your change had any affect at all when you have to wait anywhere from 5 minutes to >10 hours for the crash to happen will drive you insane. You have to fight the urge to "read the tea leaves"; you will see what you want to see if you aren't careful.

While, I never did find the problem, I did discover that MSVC was dropping "while (1) {...}" loops when they were in a macro, but compiled correctly when they macros were changed to "for (;;) {...}".

Later, a hardware engineer took the time to try to randomly capture the entire PCI interface in the logic analyzer, hoping to randomly capture what happened before the crash. After another month+ of testing, it worked. He discovered that the PCI interface chip we were using (AMCC) had a bug. If the PCI bus master deasserted the GNT# pin in exactly the same clock cycle that the card asserted the REQ# pin, the chip wouldn't notice that it lost the bus. The card would continue to drive the bus instead of switching to tri-state, and everything crashed.

Every read or write to the card was rolling 33MHz dice. Collisions were unlikely, but with enough tries the crash was inevitable.

[1] https://en.wikipedia.org/wiki/HIPPI

Ok, that one should get the prize. The chances of spotting that are insanely small, kudos on making progress at all, more kudos for eventually tracing it down to the root. I really hope I'll never have anything that nasty on my path.

Most of the credit goes to the hardware guys that were able to finally isolate the problem.

We found the bug, but the months of delay (and a few other problems like losing a big contract[1]) killed the startup a few months later. While I'm annoyed the SCSI3-over-{HIPPI,ATM,FDDI} switch I got to work on was never finished, the next job doing embedded Z80 stuff was a lot more fun... and a LOT easier to debug.

Incidentally, I found a picture[2] of the NIC. Note that HIPPI is simplex - you needed two cards and two 50-pin cables. This made the drivers extra "fun".

[1] "no, I'm not going to smuggle a bag of EEPROMs with the latest firmware through Malaysian customs in my carry-on" (still hadn't found the bug at the time)

[2] https://hsi.web.cern.ch/HSI/hippi/procintf/pcihippi/pcihipso...

That's a beautiful board. I remember the FAMP made by Herzberger & Co at NIKHEF-H, I used to hang around their hardware labs when those were built. Similar hairy debug sessions in progress. Those worked well in the end iirc and ended up at CERN.

That reminds me of this: http://www.linusakesson.net/scene/safevsp/

"A technical explanation appears in the demo as a 10-minute scroller, but the same text is provided below, for your convenience."

Hehe :) That's a really neat one: if you've fixed your machine you can read it, otherwise you can't...

Awesome sleuthing, and the take home is if you get down deep enough digital is analog again.

Sounds similar to the Dragonfly BSD/Matt Dillon episode[0][1], with AMD except that Matt figured it out after more than a year(!!!).

[0] http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/14518

[1] http://thread.gmane.org/gmane.os.dragonfly-bsd.kernel/14471

Have you read anything about the quality of public defenders? If not, here's a recent article:https://www.washingtonpost.com/opinions/our-public-defender-...

What public-interest agencies are you talking about? As far as I can tell, the ACLU, EFF, and a handful of others provide no-cost support for a negligible portion (way less than 0.1%) of civil cases.

Does it? I was not aware of that. I know that my state, Pennsylvania, does no such collection -- or at least it did not a decade ago when my children were being born.


My impression is that the collection is so routine and automatic that most parents don't even notice it's happening, and would need to assert themselves in advance in writing to exercise their religious opt-out.

This site suggests Pennsylvania's policies for sample retention (8 months) and use of results (by subject and their medical provider only) are more restrictive than "save indefinitely" states like California:



Yeah, during newborn delivery there is so much going on, most parents will not notice that this happens at all.

So my question is what leg does the EFF stand on when making this complaint?


> So my question is what leg does the EFF stand on when making this complaint?

The honorable Carol Yaggy, trial judge for the superior court of San Francisco. http://www.courts.ca.gov/opinions/revpub/A125542M.PDF

If indeed DNA is being collected at birth, without consent, the EFF would have similar grounds to object to that. If an act is against the law, it doesn't matter that the state is breaking that same law in another instance. Breaking the law twice doesn't validate it, or, as my first grade teacher Mrs. Thompson might have said, two wrongs don't make a right.


It does and people are aware. It's offered as screening for diseases, etc. Few parents opt out. Fingerprints are also collected at DMV, they should look into that, afaik, there is no opt out, except not getting an ID.

Thank you for the link. It was a good talk. Actually, I am struck by what a large percentage of the talk and this essay are identical in content.


Although the conversion rate to paying customers provides one simple-to-estimate portion of the value and at an astounding 11% conversion rate, that alone might pay for it if the support costs weren't so high.


Support is super hard to scale. The best way is to design your product so well that you rarely need to answer calls/emails.


Yes, it can under certain circumstances.


That depends on whether the OS or package manager does a better job of providing security updates, or the application does.

Historically, browsers -- because of their enormous potential risk (easy to exploit) -- have done a better job of providing security updates quickly than have other tools.


Original Article Title: Indonesia’s palm oil fires are emitting more greenhouse gases every day than the entire US

More Accurate Title: Indonesia’s palm oil fires are emitting more greenhouse gases on some days than the entire US



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact