Live data from Hacker News

“Stop reverse engineering our code”

blogs.oracle.com

301–310 of 358 posts

Re: “Stop reverse engineering our code”

#301
post #241

Earlier quoted context omitted.

It is somewhat rare that companies will recognize the fallacy of sunk costs ("We've already spent so much, we need to do this"). I think the world would be a much different place if we could somehow overcome this cognitive error.

makes for good examples that everyone can learn from

easier said than done.

Re: “Stop reverse engineering our code”

#302
post #273

Earlier quoted context omitted.

Silencing false positives when one runs static analysis tools is only enough for the purpose of a single bug-finding campaign, not for a sustainable effort. To deal with false positive reports from customers, Oracle needs to archive what the false positives in each release of their software according to popular tools are. Not the tools they use to find bugs: all tools customers use. It's not like they cannot afford t…

Oracle needs to archive what the false positives in each release of their software according to popular tools are. Oh, wow! How could we be so stupid. All we have to do is build a false positive database of all tools, everywhere. Don't forget for all versions. Not just all versions of the tools, all versions of your code . And whenever a new tool or version comes out, rerun everything. Because inevitably some guy lim…

I doubt there is such a flood of false positive reports from customers misusing static analysis tools as the article complains about, but as far as Oracle wants to do something about them minimizing the cost of writing off a report as a false positive is the only rational solution. (Complaining about reverse engineering is not rational.)

Investigating analysis tool reports once and for all is the only way to minimize this cost. You seem to neglect various cost-mitigating factors:

- Reports from different tools are going to hit the exact same spots in code, for the same reasons, making the marginal cost of analyzing the report from yet another tool low and decreasing and making the matching between support tickets and known false positive reports very easy. Closing tickets as vague would also be easy.

- Reports for version N and version N+1 of the product are going to be very similar. Likewise for version N and N+1 of a static analysis tool.

- Only popular (and good) analysis tools deserve up-front usage before releasing products. Others can be run only after someone files reports, and for the most unlikely ones being unprepared is the best choice. There's no value in a strawman like complete coverage of all possible tools.

- Static analysis tools are useful. Using them thoroughly would provide significant value beyond the dubious niche of reverse engineering support tickets.

Re: “Stop reverse engineering our code”

#304
post #80

Wow. Really? This single blog post is strong evidence for why you should never, ever buy an Oracle product, and if you are running anything written by them, why you should plan to migrate away. Now, the culture of consultants in the Oracle sphere of influence is pretty toxic and money-grubbing. I can imagine companies being badgered into paying security weasels big bucks to analyze software with tools that cough up a…

Look up the story of the State of Oregon's failed healthcare exchange. Set up by Oracle.

Last new I'm aware was Oregon sued Oracle for $200 million.

"Oregon sues Oracle over failed Obamacare website" http://fortune.com/2014/08/22/oregon-oracle-spat-200-million...

Oregon’s suit, filed Friday in state court, alleges that Oracle, the largest tech contractor working on the website, made falsely convinced officials to buy “hundreds of millions of dollars of Oracle products and services that failed to perform as promised.” It is seeking $200 million in damages.

Re: “Stop reverse engineering our code”

#305
post #177
post #108

Earlier quoted context omitted.

Just in case a robot.txt kills that http://pastebin.com/rcPSyRnR

Would archive.org typically honor a robots.txt for a resource it already retrieved? I never understood the intent of a robots.txt to be retroactive.

Yes, it simply hides the content, it is still kept in their database so if the robots.txt disappears, it pops back from their archive.

New pages won't be archived though.

Re: “Stop reverse engineering our code”

#306
post #249

Earlier quoted context omitted.

According to the very Wikipedia article you link, Standard Oil was found guilty of anticompetitive actions. Note that monopolistic behavior does not necessarily imply rising prices. See: Wal-Mart. Also see this quote from that Wikipedia article again: "The evidence is, in fact, absolutely conclusive that the Standard Oil Co. charges altogether excessive prices where it meets no competition, and particularly where the…

Without any comment on the business practices of Standard Oil, I do think it's interesting that the price of crude actually increased substantially after the antitrust ruling.

World War I, increased demand, and a period in the 1920s during which there was genuine concern that all the oil that could be found had been.

That fear disappeared with the East Texas oilfield discovery in 1930. Which so increased the supply of oil relative to demand that prices fell to 13 cents per barrel.

This created a number of problems, including the prospect of damaging oilfields to the point that future extraction would be compromised. It ended up with the governors of both Texas and Oklahoma calling out the state militia, and, in Texas's case, the Texas Rangers, and seizing control of wellheads by force of arms in an effort to constrain extraction and drive oil prices up -- to $1/bbl.

This resulted in the Texas Railroad Commission effectively controlling US oil output (with oversight from the US Department of Interior) from 1931 to 1972, at which point, peak US oil meant that there was no longer any surplus extraction capacity to limit. Shortly afterward the Arabs tried another of their periodic embargos against the US and Europe, and, to everyone's shock, it actually worked.

If you look at the price of oil, from 1931 to 1972 it was remarkably stable. Even WWII and the post-war consumption boom barely moved the needle. Post 1974, everything goes all to hell. We're still there now.

Daniel Yergin's masterpiece work, The Prize, covers this history in great depth.

Re: “Stop reverse engineering our code”

#307

Earlier quoted context omitted.

I went to a prominent tech school that adopted an Oracle platform for student course management in my last few years. I won't mince words: it was a piece of shit, and my school's administrators ate shit by agreeing to a contract that forbid them from making any changes to Oracle's broken system. Now I work in college administration and we have to deal with the very same pile of junk. Someone once told me that Larry E…

You might want to fact check yourself on Rockefeller: Founded 1870, antitrust 1911: https://en.wikipedia.org/wiki/Standard_Oil Crude prices in that time frame (and beyond): https://commons.wikimedia.org/wiki/File:Oil_Prices_Since_186... Production in that time frame (having trouble finding a nice long time-series chart): https://en.wikipedia.org/wiki/History_of_the_petroleum_indus... If we want to make a strong claim…

And you might want to consult a contemporary account of Rockefeller, Ida Tarbell's The History of the Standard Oil Company.

https://archive.org/stream/historyofstandar00tarbuoft#page/n...

Particularly chapters 3 "The Oil War of 1872", 4 "An Unholy Alliance", and 5 "Laying the Foundations of a Trust".

The oil industry has almost always been controlled by a small cartel, though that cartel has varied though the years: Standard Oil, the As-Is agreement, the Texas Railroad Commission, the Seven Sisters, the National Producers, and OPEC.

It's not been a competitive market.

Though I'd argue that oil has been tremendously underpriced since 1869.

Re: “Stop reverse engineering our code”

#308

Earlier quoted context omitted.

You're choosing to laser focus in on a specific aspect of the story and cut the bigger picture out of the frame in a very telling way. Surely you've considered why Standard Oil's decision to do this was found to be anticompetitive, have you not?

I responded to multiple points in the post. You questioned a specific excerpt. I responded regarding that specific excerpt. You are now accusing me of laser focus. This thread has all the markings of one that becomes net negative for all involved and those reading. I'll leave it with this: I am focusing on the outcome to the consumer of the behavior in question, not on the outcome to competitors of the behavior.

To get a little more insight into the impact to consumers, and the reason why this behavior is illegal, read the two sections of that Wikipedia quote the other way around.

Re: “Stop reverse engineering our code”

#309
post #249

Earlier quoted context omitted.

Without any comment on the business practices of Standard Oil, I do think it's interesting that the price of crude actually increased substantially after the antitrust ruling.

World War I, increased demand, and a period in the 1920s during which there was genuine concern that all the oil that could be found had been. That fear disappeared with the East Texas oilfield discovery in 1930. Which so increased the supply of oil relative to demand that prices fell to 13 cents per barrel. This created a number of problems, including the prospect of damaging oilfields to the point that future extra…

I should have been more specific - I was more remarking on the period between 1911 and 1914, which saw crude prices rise; that seemed rather interesting, since I'd expect an antitrust ruling to have the opposite effect if Standard had been keeping prices high through elimination of potential competition. The effect of WWI is quite obvious, naturally.

The rest of the history, though, is quite interesting. I've added that book to my reading list. Thank you!

Re: “Stop reverse engineering our code”

#310

Earlier quoted context omitted.

The statement itself is basically 98% false. I've been a Coverity user since very early days, and have used a few other static-analysis tools as well. Every such tool that I've seen runs multiple separate kinds of checks. Yes, the false positive rate for some of those checks can be alarmingly/annoyingly high. OTOH, any software developer with half a brain can see that other checks are much more accurate. Some are dar…

This is diametrically the opposite of my experience with source code scanners. I think the impedance mismatch here might be that you're a software developer, and we're talking about security teams. I don't know that anyone is arguing that static analysis is useless for developers. If you're intimately familiar with the code you're working on, there are probably a lot of ways to make static analysis results both valua…

If somebody's paying a consultant hundreds of dollars an hour to run a static analysis tool and forward the output, without applying a developer's skills in between, they've been defrauded. Static analyzers are coding tools, much like compilers. Their input is code. Their output is pointers to code. True adversarial analysis, or any other endeavor involving static analysis, requires something extremely close to a coder's skill set. I guess if I believed otherwise then I might be tempted to take Davidson's side too, but that's not the case.
Post reply on HN