rid

My concern is that KRdp still doesn’t feel ready to replace the mature X11 remote desktop options. In VM/headless setups, the X11 stack is ugly but predictable, you can run Xvfb, VNC/Selkies/xrdp & control resolution pretty easily.

KRdp on Plasma/Wayland is still much more fragile. It depends on a logged-in Plasma session, has rough edges around unattended access, session startup, reconnection, display sizing, authentication/cert handling, and general automation. Those are exactly the things cloud desktops and disposable VM images need to be boringly reliable.

I’m not against deprecating X11 long term, but deprecating it before KRdp is a solid replacement leaves server/VM/remote-desktop users in a bad spot, hopefully now the team can focus solely on Wayland, KRdp will receive some much needed love.

What does the VM consist of? Is the image available?

Also posted here: https://news.ycombinator.com/item?id=31014222

Website went offline about 30 mins ago, repo and twitter are also gone. Looks like it's been hacked or pulled?

This is great! Nice work. I would add one feature request which is the ability to monitor from multiple locations. Otherwise it's a SPOF and you'll never receive a notification if your whole cluster is down.

Are you using TLS over TCP to route to the DBs?

Is there any chance this will be possible to self-host in future? That's a deal breaker for us.

On the other hand what kind of daft name was "Neo" especially if you're trying to create a solid sense of reality prior to ripping back the curtain?

Neo is an anagram of One.

Thanks! I think for our scenario it's a bit overkill as we're only running one container and pm2 seems a better fit for that.

It would be interesting to know how this works under the hood though, is this just built on top of docker swarm load balancing?

Does Kubernetes support graceful reload of containers, with 0 downtime? I'd be very interested if so.

I'm surprised they haven't included a process manager for the production build. In my experience it allows for much easier 0-sec downtime updates and load balancing.

We're using pm2 [1] for this if anyone's interested.

[1] https://github.com/Unitech/pm2

The whois utility [1] is available on most Linux distros and *nix flavours, it will give you information such as:

- Using an IP, netrange and information regarding the network owner (contact and abuse info). Gathered from the Regional Internet Registry (RIR) databases.

- Using a domain, registrant info --if public, abuse details etc..

[1] http://linux.die.net/man/1/whois

After a bit of digging I found the product is built by http://www.qvivo.com

I think that they're trying to create a viral loop in order to attract advertisers to their platform.

Thanks for the clarification, additionally I could only find a Chrome plugin for Torque, which should be compatible with other torrent clients out of the box. However I can definitely see the advantage of using only web technologies. If anyone's interested I found the paddleover example on github:

https://github.com/bittorrenttorque/paddleover.com

Seems similar to PaddleOver [1] which was developed by Bittorrent inc a few years ago using their Btapp.js [2] library, unfortunately the PaddleOver site has expired and the code base hasn't been updated in a year.

It would be interesting to know if the developer looked at btapp.js and if so, why did he decide not to use it? Getting this technology web embeddable will go a long way to start making peer-to-peer a convenient method of downloading content vs directly downloading from a server, there's always going to be further hurdles to overcome with reliability in a case where the swarm lifetime is very short, but seeding with a few servers can help in that situation. If a web app could upload the torrent and data to a server to seed, then replicate it in a few locations it could be a decent DCDN.

[1] http://pwmckenna.com/2012/06/29/making-of-paddle-over.html

[2] http://btappjs.com/