monero-extended (OP)
Member

Offline
Activity: 76
Merit: 10
|
 |
July 16, 2014, 03:41:10 AM Last edit: September 27, 2014, 03:38:46 AM by monero-extended |
|
The usage for this thread will encompass questions and discussion on topics that are more technical than can be found in the Monero Support thread. It will focus on development discussion, engineering-related topics such as the API usage, pool developer support as well as information to be found on the upcoming Monero Wikia. This thread is self-moderated. Off-topic questions will either be deleted or possibly re-posted in their appropriate Monero thread depending on the discretion of the OP. Rude, offensive and completely off-topic discussions are not encouraged and will have to be removed to keep a high quality thread. Aside from that posts may be deleted for whatever reason. Deletion does not necessarily mean that the post was offensive. It may also have been too long to quote (in which case either the original, or the reply may be pruned), repetition of yours or somebody else's point, or anything else.Here are useful links (Links will be added as necessary): Links to available software:Github member tree: https://github.com/tewinget/bitmonero/network/membersCryptoNote Pool Source: https://github.com/zone117x/node-cryptonote-poolTsiv's Nvidia Miner Source: https://github.com/tsiv/ccminer-cryptonightJojatekok's Windows wallet source: https://github.com/Jojatekok/monero-client-nettewinget's repo: https://github.com/tewinget/bitmonero/commits/masterWolf0's CPU Miner source: https://github.com/wolf9466/cpuminer-multiMonero Improvement Protocols: https://github.com/monero-developers/mipsI2PD Source: https://github.com/orignal/i2pdLinks to other information sources:Main Website: http://www.monero.cc/Community FAQ Thread: https://bitcointalk.org/index.php?topic=686086.msg7784707#msg7784707Community Recognition Thread: https://bitcointalk.org/index.php?topic=694762.msg7845979White Paper: https://cryptonote.org/whitepaper.pdfWhite Paper Review: http://monero.cc/downloads/whitepaper_review.pdf-updated by kbmSorry in advance for being a tyrant. I know that im deleting a bunch of well meaning posts from well meaning people but they simply aren’t topical. This isn't a thread for discussion about the virtues of or problems with moderation. I still love you guys. Please don't be mad. This is my job. We have other threads with looser standards. This thread is for development related discussion, NOTHING ELSE.
|
|
|
|
kbm
Member

Offline
Activity: 84
Merit: 10
|
 |
July 16, 2014, 04:25:57 AM Last edit: July 16, 2014, 05:10:16 AM by kbm |
|
I edited the post to explain that technical considerations were impacted by the topic you wanted to censor. You know as well as I do that this isn't really about a self-moderated thread, and I'm not going to start off with having the first thing on the thread done by deleting all the posts inside of it. I'm just not. Make of that what you will. If it (edit: aimless conversation - not you personally) gets to the point where it's driving people insane, that's a different story. I posted on your self-moderated thread as 4 different profiles and not even once did I care if I was censored. Your keen insights won't be censored just because you're worried someone won't know you made an awesome technical point. If you can bear it, please stay around. If not and everyone else follows suit, then this will be a lonely thread where I will toss any information I can find into it about anything related to the topics. It's a self-moderated thread, therefore by extension the discussion has simply been about self-moderation itself. I'd consider that a part of the implicit nature of the thread. Can we move on from that or will this be an endless tantrum? You literally just said to aminorex "your IQ is higher than that" ... well ...! Back on topic. Current development discussion topics: I2P C++ Integration Code descriptions/labeling/annotations GUI wallet: https://github.com/Neozaru/bitmonero-qtWebsite progress Pool updates - what kinda of commits are people seeing on github?
|
Thanks 
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
 |
July 16, 2014, 04:30:36 AM |
|
Database
|
|
|
|
kbm
Member

Offline
Activity: 84
Merit: 10
|
 |
July 16, 2014, 06:50:22 AM Last edit: July 16, 2014, 07:19:50 AM by kbm |
|
|
Thanks 
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
 |
July 16, 2014, 08:21:11 AM |
|
Database
That's a pretty good topic. What kind of database is being worked on? How does it differ from bitcoin? It was mentioned in the latest Missives #6: https://bitcointalk.org/index.php?topic=583449.msg7847156#msg7847156What I gather from browsing the commits is that the work is focusing on refactoring to support a clean database interface, and then one or more databases will be supported.
|
|
|
|
fluffypony
Donator
Legendary
Offline
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
|
 |
July 16, 2014, 08:49:12 AM |
|
Database
That's a pretty good topic. What kind of database is being worked on? How does it differ from bitcoin? It was mentioned in the latest Missives #6: https://bitcointalk.org/index.php?topic=583449.msg7847156#msg7847156What I gather from browsing the commits is that the work is focusing on refactoring to support a clean database interface, and then one or more databases will be supported. Spot on - first we refactor in order to support arbitrary key-value stores, and then we test a bunch of them for our specific workloads before deciding on one. Initial candidates that we liked out the box were hamsterdb and rocksdb. There's been some contention as there is a slightly faster version of hamsterdb available for purchase (you get the source, but can't distribute it), and some people feel its very availability would compromise the integrity of Monero. On the other hand, rocksdb (a leveldb fork by Facebook) breaks leveldb's Windows compatibility. So everything is staying as loose and generic as possible, and then we'll plug into as many embedded databases as we can get our hands on, and publish the results. I'm also terribly keen on having a full node pushing the blockchain on to Tahoe-LAFS and having a bunch of independent nodes "verify" that the correct blockchain is being pushed, partly for fun, but also because I can envision some interesting use-cases where applications can be built accessing the blockchain on Tahoe-LAFS instead of locally (lightweight clients, for instance).
|
|
|
|
nexern
|
 |
July 18, 2014, 10:16:43 PM |
|
for databases, i like to mentioned two additional candidates to test. 1. kyoto cabinet | c++ [ http://fallabs.com/kyotocabinet/ ] 2. Sophia | c [ http://sphia.org/benchmarks.html ] kyoto has a very rich feature set and includes also kyoto tycoon (server part), mapreduce and lua scripting, which could be very usefull for bc related services later (if any planed). i have tested and using kyoto under heavy read/write conditions up to 0.5 tb files without any problems so far. it's a lean, fast and very well written kv core with many usefull extensions to mimik relational workload if needed. i didn't test sophia under real world conditions until now and sophia is more generic from it's handling but from the performance view it looks promising. a test could make sense (just in case you are not already settled with hamsterdb).
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
 |
July 18, 2014, 10:30:10 PM |
|
for databases, i like to mentioned two additional candidates to test. 1. kyoto cabinet | c++ [ http://fallabs.com/kyotocabinet/ ] 2. Sophia | c [ http://sphia.org/benchmarks.html ] kyoto has a very rich feature set and includes also kyoto tycoon (server part), mapreduce and lua scripting, which could be very usefull for bc related services later (if any planed). i have tested and using kyoto under heavy read/write conditions up to 0.5 tb files without any problems so far. it's a lean, fast and very well written kv core with many usefull extensions to mimik relational workload if needed. i didn't test sophia under real world conditions until now and sophia is more generic from it's handling but from the performance view it looks promising. a test could make sense (just in case you are not already settled with hamsterdb). What is great about the approach being taken is that databases will be pluggable and it will be easy for others in the community to test their favorite databases and report. There is no reason to think the official build might not eventually use a database identified by the community as the best one, or that there will be different builds for different applications (pool node, high volume non-mining node, end user wallet, etc.)
|
|
|
|
rdnkjdi
Legendary
Offline
Activity: 1256
Merit: 1009
|
 |
September 24, 2014, 10:06:39 PM |
|
What is great about the approach being taken is that databases will be pluggable and it will be easy for others in the community to test their favorite databases and report. There is no reason to think the official build might not eventually use a database identified by the community as the best one, or that there will be different builds for different applications (pool node, high volume non-mining node, end user wallet, etc.)
I'll just throw my opinion in for what it's worth. I used to work for a company that mostly used SQL Server (for end user applications). Later on they picked up web developers who used MySQL for the websites (except for one & on that one they used SQL Server). A little later on, they used postresql for a new project. There was some resistance to using different backends and by the time it was all said and done having one solution seemed like it would've been a better idea. Because the company experience was duplicated across all projects. For something like this it seems like one database solution for all wallets would be a better idea as all troubleshooting & optimization would be focused on one solution rather than several. I know we are talking about completely different types of databases - but I think the substance of the issue is applicable. My (uneducated) .02
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
 |
September 24, 2014, 10:13:17 PM |
|
What is great about the approach being taken is that databases will be pluggable and it will be easy for others in the community to test their favorite databases and report. There is no reason to think the official build might not eventually use a database identified by the community as the best one, or that there will be different builds for different applications (pool node, high volume non-mining node, end user wallet, etc.)
I'll just throw my opinion in for what it's worth. I used to work for a company that mostly used SQL Server (for end user applications). Later on they picked up web developers who used MySQL for the websites (except for one & on that one they used SQL Server). A little later on, they used postresql for a new project. There was some resistance to using different backends and by the time it was all said and done having one solution seemed like it would've been a better idea. Because the company experience was duplicated across all projects. For something like this it seems like one database solution for all wallets would be a better idea as all troubleshooting & optimization would be focused on one solution rather than several. I know we are talking about completely different types of databases - but I think the substance of the issue is applicable. Maybe you misunderstand (I'm not sure). We will likely ship and support just one database, or maybe a database and a flat file version. Other people (for example a payment processing service, exchange, etc.) who want to make their own customized deployment might do something else, but we wouldn't be supporting that, they would.
|
|
|
|
rdnkjdi
Legendary
Offline
Activity: 1256
Merit: 1009
|
 |
September 24, 2014, 10:17:09 PM |
|
Maybe you misunderstand (I'm not sure).
We will likely ship and support just one database, or maybe a database and a flat file version.
Other people (for example a payment processing service, exchange, etc.) who want to make their own customized deployment might do something else, but we wouldn't be supporting that, they would.
ah. got it. my understanding was the devteam having a payment processing download, exchange download, etc. bad reading comprehension.
|
|
|
|
craig-st
Newbie
Offline
Activity: 1
Merit: 0
|
 |
March 11, 2015, 02:33:21 AM |
|
I did a 'git clone' followed by 'make test-release' to run the Monero project's built-in test suite. Two of the twelve tests fail: coretests and unit_tests. I'm on Linux (Ubuntu). Anybody else have this problem? I have the same problem with both the latest release ('git checkout tags/v0.8.8.6') and the most recent updates (v0.8.8.6-46-g6e5797d). Coretests takes a really long time before it fails. Like half an hour.
|
|
|
|
lijingang
Newbie
Offline
Activity: 99
Merit: 0
|
 |
June 17, 2023, 05:22:03 PM |
|
Is The APEPEPOW Project a meme coin in the Monroe community? Whether the APEPEPOW project developer is your Monero developer? https://github.com/APEPEPOW
|
|
|
|
|