101–110 of 113 posts
So most devs are on VSCode and they already have LiveShare which works pretty well. Is the point of this for the non vscode crowd? Trying to understand what is the justification of paying for something like this.
The advantage is that you can have the video chat with pair programming that works with any IDE + the other integrations that we are building.
This looks great. We're trying to build something like this for sales team. Could you shed some light on the video tech you have used?
Daily was pretty easy to set up. If you have a React app, by following this guide [1] you can have a simple video chat quite quickly (in a matter of few hours).
Happy to answer if you have more specific questions.
[1] https://www.daily.co/blog/building-a-custom-video-chat-app-w...
I appreciated the copy of the landing page--my literal first question after 'what is this?' was why would I use this when slack video and live share has been fine...it's still a tough value proposition but I'll certainly give it a spin and really would love to see a dev-built company like yours suceed!
> was why would I use this when slack video and live share has been fine To be able to share your code with people not using VSC. We are also optimizing a lot the video quality and we are going to add more integrations soon to the video chat. As we are focused only on developers we can do a lot of things that Slack video can't.
Here are a few conclusions:
Having multiple, independent mouse cursors in one screen is and extremely useful feature.
Consistent low-latency is much more important than temporary low-quality video.
To conserve bandwidth, we hardly ever use the video-call capabilities; low-latency, crisp and wide-frequency-band audio is more than enough.
The screen sharing codec should be optimized for text, with sharp edges. I don't want to see glow or other jpeg artifacts around my letters...
Any of the mentioned programs can provide audio and video call capabilities; that's not a differentiating factor. I wouldn't mind using a separate program for just that, since it's a negligible initial inconvenience, when we are having pairing sessions for hours on end.
Instead of wasting your money on re-implementing such features in your own software, just blog about what existing solution would recommend for audio/video/chat. It's MUCH CHEAPER, than giving in to the NIH syndrome...
I would rather like to see you focus on more important aspects of developer collaboration, for example terminal and "network" sharing. After all we are writing that code not so we can talk about it, but to run it! For example, since we are programming in Clojure, we must see the same REPL window(s) too, not just the source code. We are constantly running the code we just wrote (and its tests) in those REPLs. Currently, the least painful way to do this is sharing the whole screen :(
I haven't given up on other solutions, like Emacs in tmux or in a headless xvnc server with small resolution, 8bit colors only and tiny fonts. Viewers would just magnify it to full-screen. Characters would look pixelated, but still sharp, if the magnification factor is integer. It's a pity that open-source vnc solutions are a lot slower and macOS' built-in one and they don't support server-side resizing to the viewer's window size and things like that...
I'd love to try it, but your terms of service seem to completely ignore GDPR. https://gitduck.com/terms 2. Communications By creating an Account on our Service, you agree to subscribe to newsletters, marketing or promotional materials and other information we may send. ... 11. Analytics We may use third party services (including Amplitude, Segment, Crisp and Google, and their respective affiliates) that collect, moni…
Gotta love a legislation which makes it much harder for startups while favoring the fully lawyered-up big tech. Never forget what the GDPR fan boys claimed about this legislation being some kind of Big Tech "killer", and now go and look at Big Tech stock prices.
GDPR was never about killing Big Tech, it's about protecting your data.
For a Linux user, you can already build such a system yourself quite trivially by installing an x11vnc server on your host, setting up a SSH tunnel to a remote server which forwards the host's VNC port, and sharing SSH credentials with your colleagues who can use a VNC client to access your screen from Linux, Windows or Mac.
Is this a Dropbox joke?
Earlier quoted context omitted.
Is this a Dropbox joke?
This is the third result when searching for "Dropbox joke". But what is a Dropbox joke?
It's the Dropbox Show HN from 2007 before Show HN was a thing. Someone made a comment with the same feel as this one.
The "joke" is that of course a developer can replicate the early version of most products, but that doesn't mean the product will fail (see Dropbox).
I was a big fan of Floobits a few years back. Tuple and Screen.so are great, but we have devs split between VSCode, vim 8, and Neovim, with different configurations. I would definitely pay for cross-editor collaboration that works. I’ll give this a shot tomorrow with some friends and see how it goes!
Let me know how it goes!
- Collaborative editing was very solid, even with one of us using vim extensions and the other one not. (This has caused me some pain in Screen.so in particular.)
- The leader/follower model was slightly unintuitive at times. I vaguely recall Floobits allowing either participant to e.g. create new files, but in GitDuck the leader has to share them to the workspace for them to become editable. (I might also be misremembering this from the Floobits days, but it was slightly confusing.)
- Similar to ^ - when I was not leading, I couldn't summon the leader into a file I was editing, so I had to tell him when I was switching files. IIRC Floobits let you take yourself in/out of follow mode, even as the leader, so you would be automatically summoned when the other person switched files.
- Looking forward to terminal support - glad that's on your roadmap :)
- Our team is 50/50 between vim and VSCode right now, so we're looking forward to vim8/neovim support to really feel the power compared to Screen.so and Tuple.
Definitely a step forward in sharing by allowing each person to use their own editor. Looking forward to the vim plugin. I find myself also sharing consoles too, I'd like to see this extended to terminal sessions, perhaps the session could be rendered in other people's editors? Kind of like a live asciinema. I'd love to try this at work, unfortunately streaming Corp's code through an unapproved 3rd party service is a…
Earlier quoted context omitted.
I don't know if you're joking, but I'm in the habit of using ZeroTier+VNC.
that works quite well, especially between macOSes, but only down to 1Mbyte/s bandwidth, if u r sharing a FullHD. below that bandwidth, the latency is getting into the annoyingly high territory. and of course I'm taking about using it in approved quality mode. it nicely handles HiDPI resolutions too, but unfortunately the built-in macOS vnc viewer can only scale down the screen, not up. another issue is that zerotier…
In addition to latency and legibility, I also value trust (so non-open-source clients are negatively treated), and CPU efficiency (WebRTC screen-sharing fails on this).
Thus, I cannot use Tuple.app (macOS only) and screen.so (which, on the surface, appears to be using Electron, and thus WebRTC).
This looks great. We're trying to build something like this for sales team. Could you shed some light on the video tech you have used?
GitDuck’s cofounder here. The video tech is pretty simple for now as we are using https://daily.co for that. Daily was pretty easy to set up. If you have a React app, by following this guide [1] you can have a simple video chat quite quickly (in a matter of few hours). Happy to answer if you have more specific questions. [1] https://www.daily.co/blog/building-a-custom-video-chat-app-w...