Topic: What Bitcoin Could Learn From Gnutella (or, why devs need a spanking) - page 2. (Read 9638 times)

My comment was not about the code but about the code development workflow. Anyone can make a mistake, c.f.
I was just not aware that the problem is so prevalent, that so many people developed such a dependency on build automation that they are incapable of building without it.

It used to be that Microsoft Outlook promised increased productivity by allowing office automation. It ended up with security consultants training the cubicle monkeys to avoid clicking on the e-mail attachments.

Then there was Visual Basic and certain VB programmers for whom any project could be improved by downloading some random ActiveX control from some random web site.

I only just yesterday realized that I've already encountered one such situatuation where the SAP/Netweaver/Java deployment was trojaned. I normally don't do sales calls, but in one unusual situation I've met with a prospective clients after a "security event". They asked if we use "Maven, Netbeans, Eclipse" and were very happy to hear that all our developers are comfortable working with "vi or emacs and our own tools". I didn't pay attention to their secuirity consultants talk about "advanced persistent threats" or some such.

So the summary is that Visual Studio, which I sometimes call Visual Straitjacket has one significant benefit: it makes somewhat more dificult to trojan a whole dev-team using automated dependency collection.

I'm sorry for the off-topic post: it has no relation to Gnutella, but it is related to the security of the build process.

Yep, I noticed and it is definitely great to hear that.

The repositories in my sig (LayerEffects, SimpleDJ, and DSP Filters in particular) should serve as the model. All three are GUI apps, have several dependencies each, are self-contained repositories, and build and run on GNU/Linux with X-Windows, OS X, and Windows.

You can do a git clone on any one of those, and without having to pull any other dependencies build the executables and run them.

They also build really fast, being organized in the "unity build" style, and some of them make use of amalgamated source distributions.

It is. Four years after the project is in production it still looks like a proof of concept code written by an academic genius.
Once you scratch the surface you see that it is actually high quality of its own style (of the early 90s).

I can only guess why refactoring did not happen as follows:

1. There were no unit tests, so people did not dare to change anything non-trivial. This is improving...
2. C++ is too complex and has too many possible side effects for refactoring tools.
3. People maintain it got used to it and only see the beauty that is well below the surface.
4. Is more sexy to add features, tune performance than clean up code, that only have downside of breaking things.

Oh great, its not enough to change the world, now Satoshi has to retroactively learn "proper" C++ coding style before doing so!

Try to clean it up. Rumours hint doing so might have some lurking "gotchas" but maybe that is just idle superstitious scuttlebutt used as an excuse for doing fun stuff instead of code-monkey housecleaning chores.

-MarkM-

That is one thing that is nice about Gentoo. You don't have to do that manually.

If it makes you feel any bigger, sipa would love to ditch the OpenSSL dependency ;p

(and has been coding in that direction)

I've compiled many, many C++ apps in my life. Bitcoin isn't particularly good or bad relative to the others. Manually installing dependencies is boring but is inherent in unmanaged app development.

So that's how they trojan the enterprise resource planing systems! I've seen and heard of some deployments getting trojaned through the internal development departments. I thought that it was some sort of more advanced exploit. But all it takes is some lazy-ass Java code-monkeys that press the "collect dependencies" button in their IDE!

Thanks. Very usefull knowledge, that I was completely unaware of. I always thought that it requires some click-on-the-email-attachment social engineering trick. But it is through the click-some-button-in-the-IDE, no need for social engineering, the engineers are already conditioned for brainless clicking.

Thanks again.

Doesn't Visual Studio collect the dependencies for you automatically like maven and netbeans and eclipse and, I had somehow imagined, pretty much any GUI build-system?

-MarkM-

After reading all the responses to the issue, I think I would be satisfied if I could just build the thing on Windows using Visual Studio 2010 without fetching endless external dependencies and without a set of build instructions that rivals the size of the Bible (old testament).

A textual capture of it could be a good start, but clearly insufficient. Some aspects of the protocol will need to be captured as snippnets of code or formulae to be exact and purposeful, and the definition will have to be supplemented with an extensive set of test vectors and test scenarios. This is a major effort.

Once finished such definition should take over the role of reference even if a scheduled hard fork is needed to enforce to align existing implementations. I can not imagine this economy growing by magnitudes running a single sacred code maintained by a few who preserve its bugs and undefined behavior to eternity.

Should there be crowd funding the effort, I for one, would be contributing to the definition, provided:

Sources of funds declare the funds as irreversible donation to a project separate of their businesses and that they expect no return other than documents, data and programs that immediately become goods of the public domain. Furthermore contributor of work should be set free of claims referring to the result's incompleteness, consequences of its implementation or if the project is abadoned without implementation or influence to the network.

So has anyone actually started a bounty for forming a BTC spec?  Complaining is a much poorer incentive than money.  C'mon complainers, put your money where your mouth is.  I might even chip in. 

No, you are suffering the tragedy of arrogance.

Gavin and myself certainly support alternate client implementations (heterogeneous environment).

I think this is where some of the disagreement is. I prefer to have multiple clients, for a long term(next 20 years and on) safety it's better and safer. And earlier it's done the better. If crypto-currency were to be anything very much larger than software toy of small geek population it needs to be in multiple hands...

Other argument is that is stability of system more important than it not being centralized in some way and one implemention ruling over all is centralised power in my mind.

+1

The majority user of the network, SD pays miner and shareholder and does not care to reduce its footprint even though it would take few lines of code and cost nothing on their side. The miner could fund with 1% of their revenue 4 full time developer and are not even prominent member of the foundation that pays for one.

We seem to already suffer the tragedy of the commons.

We've reduced the minimum fee setting twice already since I've been here.  The transaction fee is a non-issue.

If you only ever want one client, then who cares whether the source code provides good documentation or not? You'll use the software you're given because that's all there is. Your statement makes no sense.

+1

The source code is the best documentation possible, and I dont wish to see few other implementation from third party, this may just brings problems..

Thank devo for devcoins, heck with those things you could buy a stick of gum and still have it come out to a whole coin or more!

-MarkM-