Search content
Sort by
Showing 16 of 16 results by ghotir
I have a "new in the box, still shrinkwrapped" Windows 95 upgrade. found it in the server closet of a company i helped clear out.
https://lh6.googleusercontent.com/-fVq3PXnFUNM/TjR6BmyzWTI/AAAAAAAAANc/KmQBiy1nT8w/s144/IMG_20110730_141200.jpg
https://lh6.googleusercontent.com/-fVq3PXnFUNM/TjR6BmyzWTI/AAAAAAAAANc/KmQBiy1nT8w/s144/IMG_20110730_141200.jpg
Me: https://plus.google.com/#117500003827318237082/posts (also in my sig)
I have tech (linux, bsd, android, etc) and photography circles, too...so if anyone wants to get any thing I share to those types of circles + me directly on there.
I have tech (linux, bsd, android, etc) and photography circles, too...so if anyone wants to get any thing I share to those types of circles + me directly on there.
Some of the patches are more general than just DragonFly support:
1) The bitcoind make target in makefile.unix defines USE_UPNP to 0; however net.cpp among others uses '#ifdef' as the test for miniupnp, which means the upnp headers are always required.
2) main.cpp has:
-char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };
g++ 4.4.5 on DragonFly disapproves; the constants are being narrowed from int -> char inside an array initializer. I think the error is correct, though harsh.
3) g++ on DragonFly wants -std=c++0x or -std=gnu++0x; I agree with it -- typed enumerations are used in the source. I don't know why the same g++ version on Linux doesn't require it, though.
4) in db.cpp, make_tuple is meant to resolve to boost::make_tuple; at least in our configuration, it resolves to std::make_tuple, which is not correct. I don't know enough to say what correct behavior is when a template is defined in more than one namespace (std and boost) and both are 'using namespace '-ed. But qualifying it helps.
DragonFly specific stuff:
1) Currently net.cpp, there is an assumption that all BSD systems support SO_NOSIGPIPE; DragonFly doesn't. The test should probably be for SO_NOSIGPIPE.
I knew about the SO_NOSIGPIPE issue ( supported in FreeBSD >5 only. Being that DragonFly is based on the 4.x series i can understand why it's not; but also read somewhere that Open and Net don't either )1) The bitcoind make target in makefile.unix defines USE_UPNP to 0; however net.cpp among others uses '#ifdef' as the test for miniupnp, which means the upnp headers are always required.
2) main.cpp has:
-char pchMessageStart[4] = { 0xf9, 0xbe, 0xb4, 0xd9 };
g++ 4.4.5 on DragonFly disapproves; the constants are being narrowed from int -> char inside an array initializer. I think the error is correct, though harsh.
3) g++ on DragonFly wants -std=c++0x or -std=gnu++0x; I agree with it -- typed enumerations are used in the source. I don't know why the same g++ version on Linux doesn't require it, though.
4) in db.cpp, make_tuple is meant to resolve to boost::make_tuple; at least in our configuration, it resolves to std::make_tuple, which is not correct. I don't know enough to say what correct behavior is when a template is defined in more than one namespace (std and boost) and both are 'using namespace '-ed. But qualifying it helps.
DragonFly specific stuff:
1) Currently net.cpp, there is an assumption that all BSD systems support SO_NOSIGPIPE; DragonFly doesn't. The test should probably be for SO_NOSIGPIPE.
The db.cpp boost issue has been driving me absolutely nuts (usually I can figure such things out with a little poking around make files, etc.).
Anyway, if it's working for you - compiled, all that, I'd be willing to be a 2nd to apply the patches and build on my dragonflybsd system.
weirdo.
Is this a self-realization and admission, or did you mean to quote another post?Seriously, you're talking like a freakin used car salesman, or a scammer.
Shed more light on this "sensitive information" (red flag) that you're hesitant to reveal more information about (red flag).
Are you friends with his Royal Highness of Nigeria, Prince Megunna Scamou Outtayumoneh?
Shed more light on this "sensitive information" (red flag) that you're hesitant to reveal more information about (red flag).
Are you friends with his Royal Highness of Nigeria, Prince Megunna Scamou Outtayumoneh?
I'd be fine with Debian if it actually worked with the latest bitcoind. 
Maybe they have Debian 6.0 available, not sure. That's one thing I'll be checking out.
Sid is the cutting edge. Try that. Should have the up to date libs, but as with any cutting edge stuff my usual disclaimer applies: "You might break stuff. Don't blame me, I didn't force you to installed it" Maybe they have Debian 6.0 available, not sure. That's one thing I'll be checking out.Re: I don't like Gavin's and Jeff's Bitcoin client - can I write my own?
So I woke up one morning and decided I don't like Gavin's and Jeff's bitcoin clients for any of the platforms.
Can I write my own, and is there anything technically stopping me from doing this if I were to follow the rules of trading/transactions on the Bitcoin network?
Maybe I want to write a Haskell or a Clojure client... or Ruby. Is there anything stopping me from writing one and getting other people to use it if they see value in it?
Where is the protocol specified of how to write a Bitcoin client/daemon?
Thanks!
Go for it.Can I write my own, and is there anything technically stopping me from doing this if I were to follow the rules of trading/transactions on the Bitcoin network?
Maybe I want to write a Haskell or a Clojure client... or Ruby. Is there anything stopping me from writing one and getting other people to use it if they see value in it?
Where is the protocol specified of how to write a Bitcoin client/daemon?
Thanks!
I'm teaching myself Python, and am writing my own python-[n]curses frontend to bitcoind - nothing special, just sending the arguments to bitcoind.
I taught myself PHP-MySQL years back in a similar fashion by writing my own blogging scripts.
Re: Bitcoin-Qt, the future Bitcoin client GUI [user input needed]
I love the crowdsourcing going on here.
I use a very minimal X environment (I only have libs installed that are necessary for Firefox, gimp, and what's needed for scrotwm) & even though this is KDE/Qt, watching it come to life rocks.
I use a very minimal X environment (I only have libs installed that are necessary for Firefox, gimp, and what's needed for scrotwm) & even though this is KDE/Qt, watching it come to life rocks.
Well, I managed to find a working version of 0.3.22 to run. It was meant for centOS, but seems to work on debian without a problem. I have yet to test RPC calls though.
The version I am using was downloaded from this post: http://forum.bitcoin.org/index.php?topic=685.msg371171#msg371171
Why is it such a problem to run bitcoind on Debian and so many other headless linux OS's? From what I have read, it seems like the dependencies are not something you can upgrade - it's part of the core OS. It seems silly to have such dependencies that exclude so many linux OS's from running bitcoin...
I could be wrong, and if I am, I would very much appreciate someone pointing out how it might be possible to run one of the later versions of bitcoind on debian.
What Debian release are you running? Squeeze, Wheezy, Sid?The version I am using was downloaded from this post: http://forum.bitcoin.org/index.php?topic=685.msg371171#msg371171
Why is it such a problem to run bitcoind on Debian and so many other headless linux OS's? From what I have read, it seems like the dependencies are not something you can upgrade - it's part of the core OS. It seems silly to have such dependencies that exclude so many linux OS's from running bitcoin...
I could be wrong, and if I am, I would very much appreciate someone pointing out how it might be possible to run one of the later versions of bitcoind on debian.
From what I know of the Debian Way, Squeeze is stable due to the lack of "latest, greatest and cutting edge" - could be part of the problem?
Rock-solid Stable doesn't always mean "everything is going to work just fine"
As far as I know, the Boost libs are the only so-called "nonstandard" libraries that bitcoin depends on (I could be wrong).
have you tried building just the daemon (no gui, no Wx Widgets)?
I know from IRC there's a handful of us hanging out from the left coast of the United States.
Been a geek since I was 9 - when my dad brought home a VIC-20 (then C64, IBM 8088 - yeah 8088, not 80286 or 386) and I learned Commodore BASIC by typing in programs from the back of magazines, breaking them, seeing what I could do differently.
At this stage in the game, I've not run or used any Microsoft OS willingly since 1996, though I'm forced to keep abreast of developments in order to support my Windows-using clients
My 1st taste of Linux was from a LinuxMall "6 Pack" that included S.u.S.E. gmbh Linux (yep that is what it was called), RedHat 4.1, Caldera Linux, Debian (potato?) and several other distros that have long disappeared.
My current computer set up is FreeBSD 8.2 (GNU Zealots can suck it. MIT license all the way).
Despite the geekness, I'm not a strong programmer (web languages, PHP [and PHP-MySQL interaction], Perl),but I know enough to be a danger to myself but not usually to others.
I'm currently teaching myself python (and curses) to make a console-based interface to bitcoind (for non-GNOME/KDE/[name your GUI here] users and possible headless--but easy access?)
Anyway, I'm one to try the "latest and greatest and most obscure" and also one to try and break it where applicable.
With bitcoin though, I'm relatively new to the scene. But its idea and the ideals speak to my inner anarchistic anti-statist libertarian (go ahead, try and label me - I'm the aforementioned in some regards, conservative in others).
I will more often than not play "devil's advocate" just for the hell of it and in doing so, I may or may not be expressing my true beliefs (something that drives my girlfriend crazy)
Okay, I tried to keep it somewhat coherent, linear and short. I have problems with that, obviously (but so do other geeks, I've come to notice)
Been a geek since I was 9 - when my dad brought home a VIC-20 (then C64, IBM 8088 - yeah 8088, not 80286 or 386) and I learned Commodore BASIC by typing in programs from the back of magazines, breaking them, seeing what I could do differently.
At this stage in the game, I've not run or used any Microsoft OS willingly since 1996, though I'm forced to keep abreast of developments in order to support my Windows-using clients
My 1st taste of Linux was from a LinuxMall "6 Pack" that included S.u.S.E. gmbh Linux (yep that is what it was called), RedHat 4.1, Caldera Linux, Debian (potato?) and several other distros that have long disappeared.
My current computer set up is FreeBSD 8.2 (GNU Zealots can suck it. MIT license all the way).
Despite the geekness, I'm not a strong programmer (web languages, PHP [and PHP-MySQL interaction], Perl),but I know enough to be a danger to myself but not usually to others.
I'm currently teaching myself python (and curses) to make a console-based interface to bitcoind (for non-GNOME/KDE/[name your GUI here] users and possible headless--but easy access?)
Anyway, I'm one to try the "latest and greatest and most obscure" and also one to try and break it where applicable.
With bitcoin though, I'm relatively new to the scene. But its idea and the ideals speak to my inner anarchistic anti-statist libertarian (go ahead, try and label me - I'm the aforementioned in some regards, conservative in others).
I will more often than not play "devil's advocate" just for the hell of it and in doing so, I may or may not be expressing my true beliefs (something that drives my girlfriend crazy)
Okay, I tried to keep it somewhat coherent, linear and short. I have problems with that, obviously (but so do other geeks, I've come to notice)
you could simply make/change freebsd port
DragonFlyBSD uses the NetBSD pkgsrc tree, so if the OP has already done some ground work, why reinvent the wheel?On that note- OP should contact the pkgsrc-wip project about getting it submitted: https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-discuss
Solved this dilema by doing it on FreeBSD (which has an existing, working port of the bitoin software)
I know I could run the linux binary using the emulation layer, but I like to "go native" whenever possible (I have a couple CPU miners running native already).
The issue I'm running in to is apparently with boost.
One of the numerous errors the compile chokes out is "BOOST_FOREACH was not declared in this scope" - yet I have boost/boost libs installed.
I can provide the full error stream if any OpenBSD familiar folks are interested or could help.
If anybody has successfully gotten it to compile on Open/Free/Other BSD I'd greatly appreciate your input (did you have to point to specific directories during configure/build, etc).
Alternately, is there an alternative -like FreeCoin- that you've built on OpenBSD? (I want to be able to check balance, transfer bitcoin, etc. just like the bitcoin native client does)
I know I could run the linux binary using the emulation layer, but I like to "go native" whenever possible (I have a couple CPU miners running native already).
The issue I'm running in to is apparently with boost.
One of the numerous errors the compile chokes out is "BOOST_FOREACH was not declared in this scope" - yet I have boost/boost libs installed.
I can provide the full error stream if any OpenBSD familiar folks are interested or could help.
If anybody has successfully gotten it to compile on Open/Free/Other BSD I'd greatly appreciate your input (did you have to point to specific directories during configure/build, etc).
Alternately, is there an alternative -like FreeCoin- that you've built on OpenBSD? (I want to be able to check balance, transfer bitcoin, etc. just like the bitcoin native client does)
I was quite agitated by the 'newb rule' myself.
In my opinion, even having new member's replies/new posts moderated before posting publicly would be better. After the 5 posts/4 hours, and they seem to be 'legit' or intelligent enough, let em loose.
In my opinion, even having new member's replies/new posts moderated before posting publicly would be better. After the 5 posts/4 hours, and they seem to be 'legit' or intelligent enough, let em loose.