[ANN][EGC] EverGreenCoin® | 7% PoS | 501c3 Foundation | Android & Web | PoE

[NinjaMan35]

So I've wiped the system as I felt it was the best way to go in starting fresh / clean slate.

What would be the ideal Linux OS to go for that, if any, would have all libraries installed from a fresh OS install ?

Preferably something with a GUI / Desktop Environment... Ty.

What can / would I type to see current boost lib that's installed since the error references 1.57.0 ?

Code:

yum list installed | grep boost

Code:

[amcnamara@Crypto-Online ~]$ yum list installed | grep boost
boost.x86_64                               1.53.0-27.el7               @base    
boost-atomic.x86_64                        1.53.0-27.el7               @base    
boost-chrono.x86_64                        1.53.0-27.el7               @base    
boost-context.x86_64                       1.53.0-27.el7               @base    
boost-date-time.x86_64                     1.53.0-27.el7               @base    
boost-devel.x86_64                         1.57.0-1.el7.centos         installed
boost-filesystem.x86_64                    1.53.0-27.el7               @base    
boost-graph.x86_64                         1.53.0-27.el7               @base    
boost-iostreams.x86_64                     1.53.0-27.el7               @base    
boost-locale.x86_64                        1.53.0-27.el7               @base    
boost-math.x86_64                          1.53.0-27.el7               @base    
boost-program-options.x86_64               1.53.0-27.el7               @base    
boost-python.x86_64                        1.53.0-27.el7               @base    
boost-random.x86_64                        1.53.0-27.el7               @base    
boost-regex.x86_64                         1.53.0-27.el7               @base    
boost-serialization.x86_64                 1.53.0-27.el7               @base    
boost-signals.x86_64                       1.53.0-27.el7               @base    
boost-system.x86_64                        1.53.0-27.el7               @base    
boost-test.x86_64                          1.53.0-27.el7               @base    
boost-thread.x86_64                        1.53.0-27.el7               @base    
boost-timer.x86_64                         1.53.0-27.el7               @base    
boost-wave.x86_64                          1.53.0-27.el7               @base    
libboost-atomic.x86_64                     1.57-1.el7.centos           installed
libboost-date-time.x86_64                  1.57-1.el7.centos           installed
libboost-filesystem.x86_64                 1.57-1.el7.centos           installed
libboost-iostreams.x86_64                  1.57-1.el7.centos           installed
libboost-program-options.x86_64            1.57-1.el7.centos           installed
libboost-regex.x86_64                      1.57-1.el7.centos           installed
libboost-system.x86_64                     1.57-1.el7.centos           installed
libboost-thread.x86_64                     1.57-1.el7.centos           installed
[amcnamara@Crypto-Online ~]$ 

Using yum history. I already tried to undo a trans. Didn't work hence my post. It's also a CentOS7 system. I chose that os for some other things I have running on the headless system.

if it's headless why build the QT version of EGC, the daemon form might be more useful and has fewer dependencies.

So now I'm sort of a rock and a hard place kind of deal. I remember when doing all these libraries initially so I could make my own QT I wanted to rip my hair out... really don't want to go through any more sleepless nights.

why didn't you use the system libraries, if you built the libraries from source then that could easily be your issue.

Also. What can / would I type to see current boost lib that's installed since the error references 1.57.0 ?

rpm -qa and grep can show you the installed packages, ldd might show what libraries you're linking against. Having EGC looking for boost 1.57 suggests something odd in your setup as that's not the version bundled in CentOS. If you're running a website this is probably stuff you should know...

1) It's headless bec I use VNC to log in remotely.

2) I don't recall what I did, I followed most of what I found on Google etc. What I do recall is that CentOS7 didn't seem to have anything installed that EGC needed.

Half tempted to wipe the system and start fresh with an OS that I don't need to install shit for libs. But it has to be linux based because of a backend program I use to manage minecraft servers.

As for what I should and shouldn't know... I don't know much as Linux is still somewhat new for me etc.

Still confused as to why this coin gives me trouble when its based off of BTC just like Doge & LTC both of which run without issue on the same system.

[1714318935]

1714318935

[1714318935]

1714318935

[1714318935]

1714318935

[1714318935]

1714318935

[1714318935]

1714318935

[1714318935]

1714318935

[drofxafm]

Code:

[amcnamara@Crypto-Online ~]$ yum list installed | grep boost
boost-atomic.x86_64                        1.53.0-27.el7               @base    
boost-thread.x86_64                        1.53.0-27.el7               @base    
libboost-atomic.x86_64                     1.57-1.el7.centos           installed
libboost-thread.x86_64                     1.57-1.el7.centos           installed

(stripped all except a couple of packages for brevity)

The 1.53 versions look to be installed from CentOS, the others have come from somewhere else.

2) I don't recall what I did, I followed most of what I found on Google etc. What I do recall is that CentOS7 didn't seem to have anything installed that EGC needed.

That may just be a case of needing the relevant -devel libraries. I've only build the deamon portion on Debian/Ubuntu/Fedora, I've not tried CentOS but it should probably work.

As for what I should and shouldn't know... I don't know much as Linux is still somewhat new for me etc.

The assumption is that this is what's running the lottery as that seems to be down.

What would be the ideal Linux OS to go for that, if any, would have all libraries installed from a fresh OS install ?

Preferably something with a GUI / Desktop Environment... Ty.

Depending on what this system is doing then I'd potentially suggest not running a gui/Desktop based system. If it's accessible over the internet as webserver / minecraft server etc. then adding a gui adds a lot of extra potential exploit routes you need to ensure is protected.

Personally depending on use I'd look at one of Fedora/CentOS/Ubuntu/Debian.

[EverGreenCoin]

Here is the link to today's EverGreenCoin meeting via Google Hangouts, https://hangouts.google.com/hangouts/_/tuxlm3tfebd4fhzdhi7qkzi3tae

All are welcome! I will not be able to hold the meeting open for very long today, only an hour or 2.

See you there!

[Andrey123]

https://evergreencoin.org/download/snapshot/

Thank you for your answer!
But here only the video and there is no link itself to the archive of the blocks.

[starmman]

https://evergreencoin.org/download/snapshot/

Thank you for your answer!
But here only the video and there is no link itself to the archive of the blocks.

I took a look, the link is in there - just not easy to spot
https://evergreencoin.org/EverGreenCoinSnapshotAt1019462.zip

[NinjaMan35]

Code:

[amcnamara@Crypto-Online ~]$ yum list installed | grep boost
boost-atomic.x86_64                        1.53.0-27.el7               @base    
boost-thread.x86_64                        1.53.0-27.el7               @base    
libboost-atomic.x86_64                     1.57-1.el7.centos           installed
libboost-thread.x86_64                     1.57-1.el7.centos           installed

(stripped all except a couple of packages for brevity)

The 1.53 versions look to be installed from CentOS, the others have come from somewhere else.

2) I don't recall what I did, I followed most of what I found on Google etc. What I do recall is that CentOS7 didn't seem to have anything installed that EGC needed.

That may just be a case of needing the relevant -devel libraries. I've only build the deamon portion on Debian/Ubuntu/Fedora, I've not tried CentOS but it should probably work.

As for what I should and shouldn't know... I don't know much as Linux is still somewhat new for me etc.

The assumption is that this is what's running the lottery as that seems to be down.

What would be the ideal Linux OS to go for that, if any, would have all libraries installed from a fresh OS install ?

Preferably something with a GUI / Desktop Environment... Ty.

Depending on what this system is doing then I'd potentially suggest not running a gui/Desktop based system. If it's accessible over the internet as webserver / minecraft server etc. then adding a gui adds a lot of extra potential exploit routes you need to ensure is protected.

Personally depending on use I'd look at one of Fedora/CentOS/Ubuntu/Debian.

I'm just gonna give Ubuntu a shot and go from there. Cent was used for something else I've all but given upon, but can maybe make it work on Ubuntu. As for the lotto, nail on the head but everything is backed up and protected. It will be reconciled upon reconnect and payout like it should have today. I've got 4 diff coin chains to redownload so gonna be another day or two before everything is up and running. Assuming I don't have any issues trying to get my previously compiled QT for EGC running on a fresh Ubuntu Install.

Edit:Think I'm gonna give Fedora a fair shake this time around.

Downloading it's ISO now.

Edit 2: Going with Ubuntu after all... looks like my Fedora image is bad.

Oh well... lets see what happens after a fresh install... will need to do port forwards though. Here's hoping I remember that much lol

[AndrewDra]

Hello, all!
Looking forward for more updates! Impeccably plan, engaging business.

[NinjaMan35]

Back up and running so to speak... Got all other coins but EGC running. Seem's it's the only Linux QT that doesn't want to start. Most likely a library problem which is weird, because if it's so closely based to BTC like most all other cryptos. It should run by default.

Either way, not something I'm digging in to tonight. But still think if a QT was made for Linux off the getgo. Alot of this compliation stuff would be a moot point. I can't be the only one who thinks this heh

I just dont want to F'K up another system to the point of redoing it because I have to get into all this library jazz just to get this one coin running like before.

[Andrey123]

del

[tadung8790]

Look at the roadmap 2018, it's great.
It promises great things ahead.
Good luck dev

[chrysophylax]

Back up and running so to speak... Got all other coins but EGC running. Seem's it's the only Linux QT that doesn't want to start. Most likely a library problem which is weird, because if it's so closely based to BTC like most all other cryptos. It should run by default.

Either way, not something I'm digging in to tonight. But still think if a QT was made for Linux off the getgo. Alot of this compliation stuff would be a moot point. I can't be the only one who thinks this heh

I just dont want to F'K up another system to the point of redoing it because I have to get into all this library jazz just to get this one coin running like before.

What OS are you working with now?

There are different things that need to be done with different OS systems. 'Horses for courses' as the saying goes mate.

We run RHEL based systems, and as such, are the LEAST supported, which means we have learned more in our compilation space then almost any one else because of the 'ease' of compilation under Debian/Ubuntu systems. I say 'ease' only because the devs themselves usually DO NOT support RHEL based systems as a base level codebase. The reasons behind that are understandable, but still not fair on us RHEL based people. So CWI have changed a LOT of the setups, and ALL our systems (bar the newest test systems - as we will be supporting both OS based systems) are RHEL based - CentOS 7 x64 and Fedora 27/28 x64.

Windows is Windows, no matter which way you look at it, which is also one of the easiest systems to hack. It is standard and works ONE way. So one backdoor to Windows will be effective on ALL Windows systems.

Linux distros are very very VERY different, and also the reason why we have the most headaches with them. Simply because EACH distro requires different settings, no matter how 'similar' those settings may be.

I actually don't have time to read back mate, so if there is something we can help in anyway, please let me know directly. Skype is the best way to get me - chrysophylax69.

#crysx

[starmman]

Back up and running so to speak... Got all other coins but EGC running. Seem's it's the only Linux QT that doesn't want to start. Most likely a library problem which is weird, because if it's so closely based to BTC like most all other cryptos. It should run by default.

Either way, not something I'm digging in to tonight. But still think if a QT was made for Linux off the getgo. Alot of this compliation stuff would be a moot point. I can't be the only one who thinks this heh

I just dont want to F'K up another system to the point of redoing it because I have to get into all this library jazz just to get this one coin running like before.

What OS are you working with now?

There are different things that need to be done with different OS systems. 'Horses for courses' as the saying goes mate.

We run RHEL based systems, and as such, are the LEAST supported, which means we have learned more in our compilation space then almost any one else because of the 'ease' of compilation under Debian/Ubuntu systems. I say 'ease' only because the devs themselves usually DO NOT support RHEL based systems as a base level codebase. The reasons behind that are understandable, but still not fair on us RHEL based people. So CWI have changed a LOT of the setups, and ALL our systems (bar the newest test systems - as we will be supporting both OS based systems) are RHEL based - CentOS 7 x64 and Fedora 27/28 x64.

Windows is Windows, no matter which way you look at it, which is also one of the easiest systems to hack. It is standard and works ONE way. So one backdoor to Windows will be effective on ALL Windows systems.

Linux distros are very very VERY different, and also the reason why we have the most headaches with them. Simply because EACH distro requires different settings, no matter how 'similar' those settings may be.

I actually don't have time to read back mate, so if there is something we can help in anyway, please let me know directly. Skype is the best way to get me - chrysophylax69.

#crysx

I've been there in the past with something similar to dll hell, currently only running windows systems - but planning on getting some linux boxes together in the next few months - I'll likely be in the same boat

[chrysophylax]

Back up and running so to speak... Got all other coins but EGC running. Seem's it's the only Linux QT that doesn't want to start. Most likely a library problem which is weird, because if it's so closely based to BTC like most all other cryptos. It should run by default.

Either way, not something I'm digging in to tonight. But still think if a QT was made for Linux off the getgo. Alot of this compliation stuff would be a moot point. I can't be the only one who thinks this heh

I just dont want to F'K up another system to the point of redoing it because I have to get into all this library jazz just to get this one coin running like before.

What OS are you working with now?

There are different things that need to be done with different OS systems. 'Horses for courses' as the saying goes mate.

We run RHEL based systems, and as such, are the LEAST supported, which means we have learned more in our compilation space then almost any one else because of the 'ease' of compilation under Debian/Ubuntu systems. I say 'ease' only because the devs themselves usually DO NOT support RHEL based systems as a base level codebase. The reasons behind that are understandable, but still not fair on us RHEL based people. So CWI have changed a LOT of the setups, and ALL our systems (bar the newest test systems - as we will be supporting both OS based systems) are RHEL based - CentOS 7 x64 and Fedora 27/28 x64.

Windows is Windows, no matter which way you look at it, which is also one of the easiest systems to hack. It is standard and works ONE way. So one backdoor to Windows will be effective on ALL Windows systems.

Linux distros are very very VERY different, and also the reason why we have the most headaches with them. Simply because EACH distro requires different settings, no matter how 'similar' those settings may be.

I actually don't have time to read back mate, so if there is something we can help in anyway, please let me know directly. Skype is the best way to get me - chrysophylax69.

#crysx

I've been there in the past with something similar to dll hell, currently only running windows systems - but planning on getting some linux boxes together in the next few months - I'll likely be in the same boat

OK ...

Advice then - if there is any chance of you setting up a VM on your Windows system to 'start' the Linux experience by messing with a sandboxed environment, so so. It will save you a HUGE amount of headaches come the time that you do a full Linux install.

Do a few VM if possible. One Fedora 27/28 x64. One CentOS 7 x64. One Debian. One Ubuntu.

We chose RHEL based (RedHat Enterprise Linux) because I personaly am RedHat fluent, and can back the OS itself. Any derivative distro of RHEL (like CentOS, Scientific Linux, Fedora (community based RHEL)) we can usually work with also once you learn the basis of the RHEL system. Same with Debian/Ubuntu except for one thing. The basis of using these systems is that you won't have the frustrating learning experience that RHEL based systems have, due to the support the dev provide in the Crypto community. We chose against the grain, and remain that way until ALL OS systems can become equal. This also means that one cannot learn much without being confronted with issues that require research and learnign to fix.

So it is up to you what your end goal will be. Easy compilation/install with a lot of support but learn little? Or difficult installation with little support, but learn a huge amount in the process?

#crysx

[starmman]

OK ...

Advice then - if there is any chance of you setting up a VM on your Windows system to 'start' the Linux experience by messing with a sandboxed environment, so so. It will save you a HUGE amount of headaches come the time that you do a full Linux install.

Do a few VM if possible. One Fedora 27/28 x64. One CentOS 7 x64. One Debian. One Ubuntu.

We chose RHEL based (RedHat Enterprise Linux) because I personaly am RedHat fluent, and can back the OS itself. Any derivative distro of RHEL (like CentOS, Scientific Linux, Fedora (community based RHEL)) we can usually work with also once you learn the basis of the RHEL system. Same with Debian/Ubuntu except for one thing. The basis of using these systems is that you won't have the frustrating learning experience that RHEL based systems have, due to the support the dev provide in the Crypto community. We chose against the grain, and remain that way until ALL OS systems can become equal. This also means that one cannot learn much without being confronted with issues that require research and learnign to fix.

So it is up to you what your end goal will be. Easy compilation/install with a lot of support but learn little? Or difficult installation with little support, but learn a huge amount in the process?

#crysx

I'm planning on doing something fairly complex, I want to put together a cluster of around pi's in a cube - run it as a docker swarm and containerise all my qt instances and have one container per wallet (and supporting multiple PoS coins), I've heard raspian qt's are not the easiest to build, so will be a fairly steep learning curve (EDIT: although saying that, I'll need to build for docker not raspian)

[drofxafm]

I'm just gonna give Ubuntu a shot and go from there. Cent was used for something else I've all but given upon, but can maybe make it work on Ubuntu. As for the lotto, nail on the head but everything is backed up and protected.
...
Edit:Think I'm gonna give Fedora a fair shake this time around.
...
Edit 2: Going with Ubuntu after all... looks like my Fedora image is bad.

For the lottery setup I'd be somewhat concerned if it's running a desktop based setup with desktop apps - that just increases the attack vectors for the system. Having managed a few internet accessible systems over the years (web servers and others) and also having dealt with various compromised systems (usually not ones I've setup) I know the importance of securing things.

Certainly for the wallet daemon Fedora and Ubuntu should just work (I've even run it on some more esoteric setups) and there are some notes on the Wiki (Some bits need moving around so I'll link directly later).

I've not tried the QT wallet (the command line daemon works well enough for most of my needs) but I'd have thought it should build relatively easily on most systems. If you're having issues then it would make sense to provide the errors and ask for help either here or on Discord. If you've got useful build notes then it might help to add them on the wiki.

One of my longer term goals is to build various packages for installing the EGC daemon and QT wallet. Initially as a way of supporting the solar stake boxes but also for deployment to my own systems. I'm also aware that targetting flatpak might be useful as that could cover distribution of the QT wallet to a variety of desktop based systems.

[starmman]

Advice then - if there is any chance of you setting up a VM on your Windows system to 'start' the Linux experience by messing with a sandboxed environment, so so. It will save you a HUGE amount of headaches come the time that you do a full Linux install.

Do a few VM if possible. One Fedora 27/28 x64. One CentOS 7 x64. One Debian. One Ubuntu.

We chose RHEL based (RedHat Enterprise Linux) because I personaly am RedHat fluent, and can back the OS itself. Any derivative distro of RHEL (like CentOS, Scientific Linux, Fedora (community based RHEL)) we can usually work with also once you learn the basis of the RHEL system. Same with Debian/Ubuntu except for one thing. The basis of using these systems is that you won't have the frustrating learning experience that RHEL based systems have, due to the support the dev provide in the Crypto community. We chose against the grain, and remain that way until ALL OS systems can become equal. This also means that one cannot learn much without being confronted with issues that require research and learnign to fix.

So it is up to you what your end goal will be. Easy compilation/install with a lot of support but learn little? Or difficult installation with little support, but learn a huge amount in the process?

#crysx

thinking about it, I might start on a unbuntu vm I've got floating around to get the containers built then port them across to the raspian cluster later

[drofxafm]

thinking about it, I might start on a unbuntu vm I've got floating around to get the containers built then port them across to the raspian cluster later

You would need to rebuild stuff between the VM and Pi's as they're different CPU architectures (so binaries from one won't run on the other). If you've got the build rules setup though it shouldn't be hard to rebuild on the Pi once you've got something that works.

For a similar operating system it might make slightly more sense to use a Debian VM rather than Ubuntu if you're targeting Raspbian, although the differences are probably minimal

[Brendan-Cohen]

Greetings, team! Looking for something above interesting here! Unblemished results, riveting project!

[starmman]

thinking about it, I might start on a unbuntu vm I've got floating around to get the containers built then port them across to the raspian cluster later

You would need to rebuild stuff between the VM and Pi's as they're different CPU architectures (so binaries from one won't run on the other). If you've got the build rules setup though it shouldn't be hard to rebuild on the Pi once you've got something that works.

For a similar operating system it might make slightly more sense to use a Debian VM rather than Ubuntu if you're targeting Raspbian, although the differences are probably minimal

I believe that once a wallet is containerised it will run on any version of Linux that has docker installed - the complexity will be containerising, got to decorate/renovate 4 rooms in the house before I'll be allowed to complete an IT project, so I'll have plenty of time to think about it =)

[EverGreenCoin]

Greetings, team! Looking for something above interesting here! Unblemished results, riveting project!

I think that this business is quite a juicy investment currently.
 Good luck team.

Thank you both for the kind words and for sharing your enthusiasm!

Welcome to EverGreenCoin!