I'm looking for a bit of advice here. I usually build the wallet on Linux myself, but I've decided that it'd be easier to do upgrades if I could just update using the yaourt package manager on Arch instead of going through the tedious process of building it myself. I find I don't go in to the wallet as much as I should because I'm on a old version and can't be bothered to upgrade. I just want to be able to type yaourt -Syu and know that BitShares will get updated along with everything else in the Arch rolling release.

This is the BitShares package on the AUR:

https://aur.archlinux.org/packages/bitshares/

What slightly concerns me is that the sha256sums has 'SKIP' in it:

https://aur.archlinux.org/packages/bi/bitshares/PKGBUILD

I've built it and it loads up fine, just wondering whether I should push the button and restore my keys from a backup.

What do you guys think..? Safe or not safe?

bts: pseudoscops

Thanks Rune!

Thanks Theoretical. I knew there was more than one reason why I voted for you yesterday 

Sorry it took me so long to vote for you by the way, I had a new machine to build and had to then upgrade and build my wallet.

Actually while we're on the topic my current hot wallet is running sluggishly inside an Xubuntu VM on VirtualBox, but I think that might be because VirtualBox guest editions is not functioning properly or that I need to turn on hardware acceleration. It seem like the sluggishness is mainly due to screen draw speed in the vm, but I've only allocated two cores and 4GB and so perhaps I need to up that too.

I'm going to be setting up some development and server infrastructure for a BitShares project I have in mind that I hope will help grow the BitShares ecosystem. It'll be a web based project and may incorporate some WebVR technology for parts of what I have in mind. I’m planning on changing things up a bit compared to the way I usually develop and deploy things.

This new setup will need to do double duty for a hardware based cloud connected side-project I'm working on too, a project that I also hope to someday connect with the BitShares ecosystem. I am aiming to move away from largely Ruby/Rails focussed developer environments running directly on OSX , with Heroku being used as the main server/production environment.

I want to move to a Docker based workflow that uses Docker containers for local development of apps and for remote developer desktops too. I also want to use Docker on the server sometimes with Docker on its own (see ARM notes belwo) and sometimes by way of CoreOS and http://deis.io/ running on a dedicated baremetal server cluster I am setting up. As mentioned I'm am keen to Dockerise (or possibly Rocketise) the development environment and this needs to go as far as having dockerised dev envrionments with full XFCE4 installed that can be VNC'd in to from anywhere (see how Sony do it https://www.youtube.com/watch?v=M9hBsRUeRdg).

My go to linux distro at the moment is Arch Linux and I have some development only Docker containers on my local dev machine and also separate EC2 AMIs (not-Docker) for remote developer desktops that are based off of it. These remote AMI based desktops allow me to take advantage of fast GPU EC2 instances to run 3d modelling apps over VirtualGL/TurboVNC. This allows me to avoid outlaying lots of cash on GPU hardware and also frees me up to model, in real-time, on my Macbook Air anywhere where I have a reasonably fast internet connection. The Arch based AMIs for remote GPU work took quite a while to setup and get working. I had Nvidia driver issues when I first tried to get things working with Ubunutu on EC2. The thing is - I really really love Arch and one of the main reasons for this is the Arch Wiki. It really helps me to better understand linux and spells out exactly how to get most things I want to get done on linux done. The Arch Wiki is light years ahead of Ubuntu support channels I experienced prior to discovering Arch (i.e. Googling or searching StackOverflow for seemingly random and conflicting opinions and approaches).

ARM support is very important too as my other project is hardware based and I'd like to run docker on the embedded ARM hardware there instead of running my code directly on baremetal Raspian/ArchArm. I'll be upgrading all of my ARM hardware in my prototypes to Rasberry Pi 2 or, more likely the Odroid-C1, and so this opens the doors to debian/ubunutu as they are ARMv7-A compatible. I'd also like to have the ability to deploy Docker containers to online.net upcoming ARM based server platform (http://labs.online.net/) and so this is another reason that ARM is important too outside of my hardware based project. Arch has archlinuxarm.org which is great in my experience so far, but archlinuxarm.org is maintained by a separate group of people, not the same as the the core Arch linux maintainers, as far as I’m aware.  So I'm wondering if baked in ARM support at the main distro level is the way to go and I’m not sure which distros support ARM out of the box?

So I guess my big dilemma is whether to continue to use Arch linux anywhere within the mix. For my Docker developer instances I'm trying to decide whether to stick with Arch, or possibly Manjaro based no Arch. Further is there anyone out there who uses an Arch based distro for server duty? I'm pretty sure the answer to that from you all will be - 'Are you crazy!’ In light of all of the above, and perhaps to stop me jumping around more than one distro, what distro(s) would you recommend I take a look at? If someone can recommend one distro I can run across all of these platforms that has documentation to rival the Arch Wiki then I am all ears!

Package availability is also important. I don't want to have to build absolutely everything from scratch. Also I like that Arch gives me the latest of everything due to rolling release, but obviously this is where the downsides come when you start to consider it as a server platform for server deployments. A distribution that gets the balance right between bleeding edge and being stuck in the dark ages would be great!

Basically this post http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/ got me wondering about all this and whether I should just standardise everything on Debian.

Discuss...... :-)

Been there too. Luckily only about 50$ worth at the time. Heart felt sympathy goes out to you and your brother in law.

I really think it'd be great if the autofill in the wallet didn't make it so easy to make a mistake here. I think that is what happened to me - bter is the first account it suggests.

I think someone suggested a possible solution but I forget what it was now.

No takers...? Keen to try and get this guy to sign up for an account.

Has the layout code changed? Right hand column way too big in FF 34.0.5 OSX Mavericks. Seems fine in Chrome.

What do people think of Dwolla? https://www.dwolla.com/

I like the Dwolla homepage on the whole. But I'd be keen to avoid the 'Learn more' button up there next to the main CTA (i.e. one choice not two). If there's support for a 'Learn more' button then I'd at least suggest we split test and monitor conversion rates. My feeling is that it'd be best to give people the link to download/create account and the information that allows them to easily create an account. Nothing else initially above the fold. The points we've been working on above should be written in such a way that they compel the user to want to download and install without any further information. We want to encourage impulse account creation as soon as possible. Not encourage visitors to read a long whitepaper and then maybe create and account if they get to the end of it. That said I do think there is a need for Whitepapers too.

I think a page similar to Dwolla's learn more - with a comparison table would be useful somewhere on the site. It's the sort of page people will find after creating an account when they've decided that they do actually want to learn more about the details of what BitShares is.

I think it'd also make sense that after the download stage we should encourage a range of social media activities. Ask people to do one of the following: tweet, facebook post, Tumblr post or email form that allows them to reccomend BitShares to friends. This would be entirely optional but should have an incentive. Perhaps 10,000 BTS prize draw or free beer given away every month. I'd suggest we split test this too (i.e. with and without and see which path generates the most users).

Many moons ago I once developed a mechanism to encourage viral loops like this using free beer on a small marketing site for a large international beer brand. The incentive was three crates if beer given away every month awarded from a random prize draw for anyone who'd completed a played a game on the site and performed some form of viral activity after playing the game. Within a month we had hundreds of thousands of users register to play the game. People like free beer 

I think below the fold having the option to find out information relevant to Merchants, Gateways, Investors is a good idea, as with the Dwolla example. But no other information, just links to those more tailored landing pages.

When marketing to those segments gears up then we'd direct traffic to those landing pages for those audiences, rather than the homepage.

The homepage should be all about the end users who have a need for the BitShares products e.g. Banking with privacy and security etc etc. Information for Investors and Merchants needs to be kept off the Homepage IMHO.