0.15 dropped features? - Githubissues

Have some features introduced in 0.14 been dropped in 0.15? I compiled master to try it and noticed --exit and --cuda-noeval are gone (and I think some others too)? Those were useful. Was this intentional or ... ?

Read carefully ethminer --help

They are all there. Only difference is --cuda-noeval which has been simplified in --noeval as it works for both cuda and openCL

Quick to close again :). Here's the help from 0.15 master. I see no noeval or exit options. Care to point them out?

# /node/ethminer --help
Usage ethminer [OPTIONS]
Options:

Work farming mode:
    -F,--farm <url>  Put into mining farm mode with the work server at URL (default: http://127.0.0.1:8545)
    -FF,-FO, --farm-failover, --stratum-failover <url> Failover getwork/stratum URL (default: disabled)
        --farm-retries <n> Number of retries until switch to failover (default: 3)
        -S, --stratum <host:port>  Put into stratum mode with the stratum server at host:port
        -SF, --stratum-failover <host:port>  Failover stratum server at host:port
    -O, --userpass <username.workername:password> Stratum login credentials
    -FO, --failover-userpass <username.workername:password> Failover stratum login credentials (optional, will use normal credentials when omitted)
    --work-timeout <n> reconnect/failover after n seconds of working on the same (stratum) job. Defaults to 180. Don't set lower than max. avg. block time
    -SC, --stratum-client <n>  Stratum client version. Defaults to 1 (async client). Use 2 to use the new synchronous client.
    -SP, --stratum-protocol <n> Choose which stratum protocol to use:
        0: official stratum spec: ethpool, ethermine, coinotron, mph, nanopool (default)
        1: eth-proxy compatible: dwarfpool, f2pool, nanopool (required for hashrate reporting to work with nanopool)
        2: EthereumStratum/1.0.0: nicehash
    -RH, --report-hashrate Report current hashrate to pool (please only enable on pools supporting this)
    -HWMON Displays gpu temp and fan percent.
    -SE, --stratum-email <s> Email address used in eth-proxy (optional)
    --farm-recheck <n>  Leave n ms between checks for changed work (default: 500). When using stratum, use a high value (i.e. 2000) to get more stable hashrate output

Benchmarking mode:
    -M [<n>],--benchmark [<n>] Benchmark for mining and exit; Optionally specify block number to benchmark against specific DAG.
    --benchmark-warmup <seconds>  Set the duration of warmup for the benchmark tests (default: 3).
    --benchmark-trial <seconds>  Set the duration for each trial for the benchmark tests (default: 3).
    --benchmark-trials <n>  Set the number of benchmark trials to run (default: 5).
Simulation mode:
    -Z [<n>],--simulation [<n>] Mining test mode. Used to validate kernel optimizations. Optionally specify block number.
Mining configuration:
    -G,--opencl  When mining use the GPU via OpenCL.
    -U,--cuda  When mining use the GPU via CUDA.
    -X,--cuda-opencl Use OpenCL + CUDA in a system with mixed AMD/Nvidia cards. May require setting --opencl-platform 1
    --opencl-platform <n>  When mining using -G/--opencl use OpenCL platform n (default: 0).
    --opencl-device <n>  When mining using -G/--opencl use OpenCL device n (default: 0).
    --opencl-devices <0 1 ..n> Select which OpenCL devices to mine on. Default is to use all
    -t, --mining-threads <n> Limit number of CPU/GPU miners to n (default: use everything available on selected platform)
    --list-devices List the detected OpenCL/CUDA devices and exit. Should be combined with -G or -U flag
    -L, --dag-load-mode <mode> DAG generation mode.
        parallel    - load DAG on all GPUs at the same time (default)
        sequential  - load DAG on GPUs one after another. Use this when the miner crashes during DAG generation
        single <n>  - generate DAG on device n, then copy to other devices
 CUDA configuration:
    --cuda-block-size Set the CUDA block work size. Default is 128
    --cuda-grid-size Set the CUDA grid size. Default is 8192
    --cuda-streams Set the number of CUDA streams. Default is 2
    --cuda-schedule <mode> Set the schedule mode for CUDA threads waiting for CUDA devices to finish work. Default is 'sync'. Possible values are:
        auto  - Uses a heuristic based on the number of active CUDA contexts in the process C and the number of logical processors in the system P. If C > P, then yield else spin.
        spin  - Instruct CUDA to actively spin when waiting for results from the device.
        yield - Instruct CUDA to yield its thread when waiting for results from the device.
        sync  - Instruct CUDA to block the CPU thread on a synchronization primitive when waiting for the results from the device.
    --cuda-devices <0 1 ..n> Select which CUDA GPUs to mine on. Default is to use all
    --cuda-parallel-hash <1 2 ..8> Define how many hashes to calculate in a kernel, can be scaled to achieve better performance. Default=4
 API core configuration:
    --api-port Set the api port, the miner should listen to. Use 0 to disable. Default=0, use negative numbers to run in readonly mode. for example -3333.
General Options:
    -v,--verbosity <0 - 9>  Set the log verbosity from 0 to 9 (default: 8).
    -V,--version  Show the version and exit.
    -h,--help  Show this help message and exit.

That is NOT 0.15

You are reporting help from an outdated release.

Sent from mobile. Apologies for brevity and typos.

In data 4 giugno 2018 22:27:15 aleqx notifications@github.com ha scritto:

Quick to close again :). Here's the help from 0.15 master. I see not noeval or exit options .. care to point them out?

/node/ethminer --help

Usage ethminer [OPTIONS] Options: Work farming mode: -F,--farm Put into mining farm mode with the work server at URL (default: http://127.0.0.1:8545) -FF,-FO, --farm-failover, --stratum-failover Failover getwork/stratum URL (default: disabled) --farm-retries Number of retries until switch to failover (default: 3) -S, --stratum Put into stratum mode with the stratum server at host:port -SF, --stratum-failover Failover stratum server at host:port -O, --userpass
Stratum login credentials -FO, --failover-userpass Failover stratum login credentials (optional, will use normal credentials when omitted) --work-timeout reconnect/failover after n seconds of working on the same (stratum) job. Defaults to 180. Don't set lower than max. avg. block time -SC, --stratum-client Stratum client version. Defaults to 1 (async client). Use 2 to use the new synchronous client. -SP, --stratum-protocol Choose which stratum protocol to use: 0: official stratum spec: ethpool, ethermine, coinotron, mph, nanopool (default) 1: eth-proxy compatible: dwarfpool, f2pool, nanopool (required for hashrate reporting to work with nanopool) 2: EthereumStratum/1.0.0: nicehash -RH, --report-hashrate Report current hashrate to pool (please only enable on pools supporting this) -HWMON Displays gpu temp and fan percent. -SE, --stratum-email Email address used in eth-proxy (optional) --farm-recheck Leave n ms between checks for changed work (default: 500). When using stratum, use a high value (i.e. 2000) to get more stable hashrate output Benchmarking mode: -M [],--benchmark [] Benchmark for mining and exit; Optionally specify block number to benchmark against specific DAG. --benchmark-warmup Set the duration of warmup for the benchmark tests (default: 3). --benchmark-trial Set the duration for each trial for the benchmark tests (default: 3). --benchmark-trials Set the number of benchmark trials to run (default: 5). Simulation mode: -Z [],--simulation [] Mining test mode. Used to validate kernel optimizations. Optionally specify block number. Mining configuration: -G,--opencl When mining use the GPU via OpenCL. -U,--cuda When mining use the GPU via CUDA. -X,--cuda-opencl Use OpenCL + CUDA in a system with mixed AMD/Nvidia cards. May require setting --opencl-platform 1 --opencl-platform When mining using -G/--opencl use OpenCL platform n (default: 0). --opencl-device When mining using -G/--opencl use OpenCL device n (default: 0). --opencl-devices <0 1 ..n> Select which OpenCL devices to mine on. Default is to use all -t, --mining-threads Limit number of CPU/GPU miners to n (default: use everything available on selected platform) --list-devices List the detected OpenCL/CUDA devices and exit. Should be combined with -G or -U flag -L, --dag-load-mode DAG generation mode. parallel - load DAG on all GPUs at the same time (default) sequential - load DAG on GPUs one after another. Use this when the miner crashes during DAG generation single - generate DAG on device n, then copy to other devices CUDA configuration: --cuda-block-size Set the CUDA block work size. Default is 128 --cuda-grid-size Set the CUDA grid size. Default is 8192 --cuda-streams Set the number of CUDA streams. Default is 2 --cuda-schedule Set the schedule mode for CUDA threads waiting for CUDA devices to finish work. Default is 'sync'. Possible values are: auto - Uses a heuristic based on the number of active CUDA contexts in the process C and the number of logical processors in the system P. If C > P, then yield else spin. spin - Instruct CUDA to actively spin when waiting for results from the device. yield - Instruct CUDA to yield its thread when waiting for results from the device. sync - Instruct CUDA to block the CPU thread on a synchronization primitive when waiting for the results from the device. --cuda-devices <0 1 ..n> Select which CUDA GPUs to mine on. Default is to use all --cuda-parallel-hash <1 2 ..8> Define how many hashes to calculate in a kernel, can be scaled to achieve better performance. Default=4 API core configuration: --api-port Set the api port, the miner should listen to. Use 0 to disable. Default=0, use negative numbers to run in readonly mode. for example -3333. General Options: -v,--verbosity <0 - 9> Set the log verbosity from 0 to 9 (default: 8). -V,--version Show the version and exit. -h,--help Show this help message and exit. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

That's master compiled yesterday ... doesn't the master branch contain the latest code?

Also, could you guys please don't remove/rename options immediately for the sake of backwards compatibility? Most of us have scripts designed to use a set of options, which will all break if you change/remove them. Please leave the --cuda-noeval even if you add --noeval (at least for a few releases, with warnings of deprecation).

Do not know what r you compiling and from where, but definitely this is not 0.15 In the snapshot you posted there is not even the -P argument which is around since 0.14

Compatibility matter: latest stable release is 0.14 while 0.15 is development. Development is the key. If you want to stay current with development be prepared to spend some time keeping up. Be thankful for the time we're spending for free on this project: we're addressing problems to make it better. We're not working to make YOUR life easier.

Sent from mobile. Apologies for brevity and typos.

In data 4 giugno 2018 23:46:26 aleqx notifications@github.com ha scritto:

That's master compiled yesterday ... doesn't the master branch contain the latest code? Also, could you guys please don't remove/rename options immediately for the sake of backwards compatibility? Most of us have scripts designed to use a set of options, which will all break if you change/remove them. Please leave the --cuda-noeval even if you add --noeval (at least for a few releases, with warnings of deprecation). — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

We're not working to make YOUR life easier.

No need to get cross. Also, perhaps you don't realize it, but you most definitely are working to make others' life easier when developing open-source code ... Furthermore, if we (the users) signal issues and suggestions it is for the common good, and the issue I raised above is a perfectly valid one which any experienced software developer would agree with. It wasn't meant as criticism, but something to be considered before release.

Regarding the codebase, I think I was on a different branch when I pulled, thinking I'm pulling master.

No need to get cross.

Please understand that sometimes we all may loose calm : when you see issues opened without double check ... well it happens.

Also, perhaps you don't realize it, but you most definitely are working to make others' life easier when developing open-source code

In my opinion simply no (others may think differently). Developing FOSS (note the "F") it's mainly about features: user friendlyness comes way after. Users always want some "Windows style" "Next->Next->Ok" ease of use. But in that case they do pay for it and for a SLA.

Here I get no revenues from the hours I spend thus I do not owe anything to users. If I get suggestions to make something easier I evaluate the burden to implement it : if it's something really adjustable with a simple change in a batch startup ... I won't spend a minute. If users were customers the approach would change ... the more users' laziness the best for my pockets.

Regarding the codebase, I think I was on a different branch when I pulled, thinking I'm pulling master.

Guessed it.

I think you are still missing the point, in fact several points. Your attitude is (sadly) in line with a large part of the open source development, and the reason why a lot of folks aren't fond of open source developers.

By developing open source software, you are working to make others' life easier, whether you like that or not. Being friendly is a separate matter.
You are doing it out of your own volition. Nobody asked or forced you to do it. Requiring or even expecting gratitude is misplaced. Just like you don't owe anyone anything, nobody really owes you anything either (harsh, but true).
Whether you're doing it for the fun of it, to benefit someone or yourself, suggestions and questions (and even criticism) will exist, and it is usually made with the purpose of improving said project.
Choosing to get cross about it is your prerogative, and indeed (too) many open source developers choose the "I don't owe you anything, I don't have to be nice to you, I don't actually give a shit about you" attitude. That almost never impressed anyone, but does in fact hinder both the project (especially if there are alternatives who have a less cross public interface) and the developer who chooses that stance; for example, if any of my colleagues were to ever consider working with you, they'd take into account the fact that you seem quick to shoot from the hip.

I wish you the best of luck. My technical observation of keeping backwards-compatible options instead of removing them, still stands, and is very sensible in both the open source and closed source worlds. Feel free to do whatever you want with that info.

On the same points

By developing open source software, you are working to make others' life easier, whether you like that or not. Being friendly is a separate matter.

While developing FOSS I do not have in mind other's life. As clearly stated by the license (which nobody reads) :

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

You are doing it out of your own volition. Nobody asked or forced you to do it. Requiring or even expecting gratitude is misplaced. Just like you don't owe anyone anything, nobody really owes you anything either (harsh, but true).

This is wrong : if you receive something, no matter what, for free you generally owe a "thank you" to the donor. Or ... at least, your best silence ! This is the minimal users owe to FOSS developers.

Whether you're doing it for the fun of it, to benefit someone or yourself, suggestions and questions (and even criticism) will exist, and it is usually made with the purpose of improving said project

I dropped into ethminer cause I use it extensively. So ... yes ... it's for my personal fun, satisfaction and return. For this reason and due to the fact I don't charge users a single dime for getting advantage of my work I also claim the right to judge what is valuable and what enters in the sphere of user's laziness.

Choosing to get cross about it is your prerogative,

I've never wanted to impress someone. And also I really do not care if ethminer is used by 1, 10 or 10 millions of users. I reiterate : such kind of development gives me the right to follow my path from a technical point of view without the duty to follow highly expensive (in terms of time) requirements from users.

If users were customers ... well I assure you things would change : I've learnt the hard way that customer's satisfaction (no matter how stupid the requirement is) is the one which pays the bills.

This said all suggestions and notifications of bugs are always welcome (in the last 2 months we have solved problems that were stale since long time). But do not pretend we SHOULD offer some sort of SLA or stay tied to a LTS development: this is impossible for a project like this.

Best.

You seem to be confusing responsibility with gratitude, and lawfulness with morality :) ... no matter how upset you are if you don't receive gratitude, users don't owe you any (legally), and you can't lay claim to any (legally). This is a trap many open source developers fall into and adopt the "I don't have to be nice to you" stance because "I don't owe you anything". When that happens, usually the project and the developer have more to lose than the users do (that may seem surprising to some).

Missing the point again.

I don't care if I do not receive gratitude. It's my decision to publish my work for free. What I really can't stand is when users (who pay nothing ... repeat after me ... who pay nothing) have the nerve to tell me what I should do just to accomplish their desire of laziness.

Roll up your sleeves and get into the play if you want (and if you know how to) ... otherwise use what I (and others) have given you for free. In the end, I reiterate, wether you use it or not does not change how I sleep at night.

When that happens, the project and the developer have more to lose than the users do (that may seem surprising to some).

What could I loose from a project which gives me no revenues, which costs my free time and lot of understanding of other's people logic ?

Your esteem and admiration ? May be enough in some circumstances ... but I can't pay my rent with it.

Sorry, I'm not missing the point. I made a suggestion, which you refused and asked for my gratitude instead https://github.com/ethereum-mining/ethminer/issues/1205#issuecomment-394519328

Exactly ... you made the suggestion to keep old legacy parameters cause you probably do not want to pass all your rigs and adjust few arguments.

I did not ask for gratitude (unless "be thankful" has been intepreted like a pittance).

As you seem to rush for latest development releases be prepared to keep up: and thank God (not me) that all we write does not come out the blue ... every step is here to read.

Otherwise stay with Claymore or Optiminer (who, if I recall well, suspended the distribution of his miner due to frictions with his userbase).

I am developer from a long time and I know well all that bunch of users who basically spit on Linux just because they imagine they could have a free Windows.

This is FOSS sir ... a huge discrepancy between what users expect and what they get. They never understand that there are no free meals ... everything has a cost. And with FOSS the cost the user pays is the one to do some tasks manually and, eventually, learn something instead of copying and replacing few executables.

Feels like you have accumulated a lot of frustration over time, and made many assumptions (not all rooted in reality) and are projecting them onto other interactions before they manifest, sometimes jumping to conclusions.

To conclude this particular case, if you look at my past interventions you'd notice I've been the opposite of lazy or ungrateful. My suggestion to keep backwards compatible CLI options was made for the benefit of the project (and it's common practice, for a good reason) -- if it benefits the userbase, it benefits the project. Personally I've been modding ethminer myself for a long time and I have no problem working with changes ...

All devs of open source software I use have my gratitude. It would be better for the project and for said devs if they were also nice to users in the process (bad reputation from open source projects can have knock on effects elsewhere).

I've been a dev for a long time too. Open source devs, especially in *nix communities, could have a better reputation attitude wise. It's cultural.

Oh God ... the analyst.

Let's close it. I wont jump in in your opened threads any more nor I will comment any of your PR when any. I promise !

Best.

ethereum-mining / ethminer

0.15 dropped features? #1205

/node/ethminer --help