Remote access rule

Questa pagina ha una gerarchia - Pagina madre:English speaking

Home Forum English speaking Remote access rule

Questo argomento contiene 4 risposte, ha 3 partecipanti, ed è stato aggiornato da stegemma stegemma 3 anni, 1 mese fa.

Stai vedendo 5 articoli - dal 1 a 5 (di 5 totali)
  • Autore
  • #10162

    I’m chatting with a member of Komodo team. One problem we discuss was the rule that avoid using remote machines.

    As said sometime in the past, I think that this rule should be eliminated, if the authors partecipate personally and there are surely no-clones (Komodo surely is not a clone). Maybe we could add an exception for some international engines, like the ones who won the WCCC, for sample.

    Of course we don’t have a 2400 cores, so the competition would not be as fairy as with the rule… but we can’t avoid that someone comes with a truck with a 65536 cores machine, right now! 🙂



    Ok, you can do so now, as an organizer, notwithstanding regulation and for the success of the event.
    But I I hypothesize: Chiron (4 cores) – Komodo (2000 cores) = Chiron has no hope.

    Amunì, si lu voi fari fallu, lu capu si tu a ‘stu giru. Abbasta chi metti ‘pi la bona arrinisciuta di lu turneu’.
    Ma si iu fussi Chiron, io unnavissi spiranzi contru dumila e passa microprucessura.


    Le faq sono nel menu principale, sotto Documentazione! 😉


    No no… I don’t want to change rules without any player agrees on the changes, that’s why I post here. We can discuss this rule, maybe for the future.

    Me and you, we can’t win the first price, with or without hundreds of cores, so Chiron, Rooks/Floyd, Boot, Cyberpagno and so on could give the most important opinion (not because their programs are the strongest but because they will be the most penalized).

    Maybe someone can think: “I haven’t the resources to play with hundreds of cores, so it is not good” but somebody else could think “I know that I can’t compete against those machines but the opportunity to talk with so great programmers would be very nice”.

    What’s important to me is that anybody can enjoy with good “old” friends (and maybe find new ones).

    (PS: ho capito di più il siciliano che l’inglese!)


    Hi guys,
    isn’t it weird that the first posts in English on this forum are about these technicalities? Anyway, I’m glad Stefano put on the poll so that we have some basis for a useful discussion. As one of the creator of the current set of rules, I’d like my brainchild to stay intact, but I can understand why forbidding the use of remote access may discourage some authors from taking part in our tournaments. Yet, it seems important to me to point out why that rule was put in place a couple of years ago.
    To make the story short, let me say that the group was in turmoil, most of the historical programmers had lost interest and we had in general a very low participation rate. As a consequence we switched our focus on rebuilding the core of our group: an enthusiastic bunch of programmers whose aim is not to build the strongest engine in the world, but to explore new and unconventional ideas or simply enjoy the challenge of carving intricate algorithms. Against this background, our idea of a tournament resembled more a convention of friends than a struggle for victory, and therefore we needed a safe haven for our group to gather together and exchange ideas. Having the bright stars of computer chess around was surely a nice bonus, but definitely not the main purpose.
    Now the circumstances have changed, we have a lively group of active programmers and the level of trust in our community is back to normal. Is it time then to revise the rules? Or to put it more bluntly: is it time to slacken the rules? For sure allowing the access to remote machines during our tournaments will please a couple of top-notch programmers, but don’t forget why we forbade that in the first place. The “clone war” seems to have died out, but no one of us wants to perform a provenance check on an executable again, let alone on a remote machine.


    Of course we can’t be sure that the remote machine is playing the declared software but we can’t for local ones too. As said in other posts, me too I could run almost any engine in the background, call it from satana-tourney mode and get a move suggested from… maybe Komodo or StockFish or… Rybka! Renaming an executable so that it looks like a normal Windows process is very easy and I beat anybody to discover this kind of cheating (maybe there are a few programmers that can do this and they could spend time to an original software, instead).

    For your peace of mind (per tranquillizzarti) take care that the proposed new rule requires that the tournament organization gives the authorization to remote access at its own full discretion. We give the hint that it must be a know software, with trusted people involved and that has partecipate to international competitions and bla bla bla but we can reject any subscription if in doubt. Still we have the rule that where in doubt the programmer must provide sources to be analyzed (an there are a complex procedure well defined, for this check). This rule won’t change but, of course, we can’t have any doubt against Komodo or Chiron or RamJet… and so on 😉

    Coming back to your message: ok, it’s true that our goal is to meet ourself one time per year and the competition is not the most important part of this meeting. Personally I would be glad if this year we could meet even someone of the team of the strongest software in the world or see again Morozov and any other new person, from Europe and outside Europe.

Stai vedendo 5 articoli - dal 1 a 5 (di 5 totali)

Devi essere loggato per rispondere a questa discussione.

© 2019 G 6 Tutti i diritti riservati - Buon divertimento!

By continuing to use the site, you agree to the use of cookies. more information

Questo sito utilizza i cookie per fonire la migliore esperienza di navigazione possibile. Continuando a utilizzare questo sito senza modificare le impostazioni dei cookie o clicchi su "Accetta" permetti al loro utilizzo.