News for hackers. Stuff that matters.
Re:Devpod: Remote Development at Uber by gandalfgeek on Sunday December 18, 2022 @08:52PM (#34047251)
Back in the early 2000s, Sun ("the network is the computer") had a similar solution that worked seamlessly for most of their software org-- the Sun Ray. https://en.wikipedia.org/wiki/Sun_Ray

It was a network terminal. Your files and entire session were on the server. Your “local” terminal consisted only of a network interface and enough compute power to display your session. The way they had it set up was that you could insert your Sun employee ID – the same card used to get into the building – into a slot in the terminal. That authenticated you to the server and displayed your session instantly. Want to show a colleague something you’re working on? Just put your ID into their Sun Ray and show them exactly what you were doing. That was cool! It was a frictionless way to demo and collaborate.

Re:Devpod: Remote Development at Uber by jimmaswell on Sunday December 18, 2022 @09:32PM (#34047609)
What's old is new again. How soon until we realize the X window system actually had some good ideas again and start running desktop apps on cloud servers for remote work?
Re:Devpod: Remote Development at Uber by paxys on Sunday December 18, 2022 @09:41PM (#34047675)
It had some good ideas, but that was the extent of it. Every iteration of the solution since then has agreed that streaming all application UI is always going to be janky and needless. It's a lot better to host the data on the server and let the client handle visuals.
Re:Devpod: Remote Development at Uber by jimmaswell on Sunday December 18, 2022 @09:58PM (#34047827)
I used to run Firefox on my Debian server with X tunneling in high school sometimes. It wasn't that bad then and surely it's even better with today's internet.
Re:Devpod: Remote Development at Uber by akvadrako on Sunday December 18, 2022 @10:45PM (#34048201)
These days lots of people stream games and CAD sessions over the internet using software like parsec. It works quite well and is often better than the UI running locally on an underpowered GPU.
Re:Devpod: Remote Development at Uber by paxys on Sunday December 18, 2022 @11:05PM (#34048337)
Sure but most regular consumer or business applications don't really need that level of graphical power. Rendering a menu or button or blurb of text locally from some layout language is always going to be more performant than streaming raw pixels from a server.
Re:Devpod: Remote Development at Uber by yjftsjthsd-h on Monday December 19, 2022 @01:59AM (#34049318)
It would be, if everyone agreed on a toolkit. As it as, at least X11, AFAIK Wayland, and Windows/RDP ended up just throwing pixels over the wire because every program renders text/menus/whatever differently.
Re:Devpod: Remote Development at Uber by microsoftdoes on Monday December 19, 2022 @09:56AM (#34052765)
RDP does not mostly do that. It sends higher level commands like text and geometry placement. That’s why it performs 10x better than the competition.
Re:Devpod: Remote Development at Uber by akvadrako on Tuesday December 20, 2022 @07:00AM (#34064720)
Actually it does do that, since about 2010: https://www.anandtech.com/show/3972/nvidia-gtc-2010-wrapup/3

RDP doesn't perform even 0x better than the competition, like parsec.

Re:Devpod: Remote Development at Uber by KronisLV on Monday December 19, 2022 @10:37AM (#34053298)
I wonder what the world would look like if we decoupled what something is supposed to be and what data it's supposed to have, from how it actually looks and acts. Say, some "lowest common denominator" that works reasonably across all platforms.

For example, I'd say that I need:

  A dropdown for a single option, with options: A, B, C
And let the device itself decide what needs to be displayed in the native GUI toolkit. Then just send that specification over the wire, instead of needlessly wasting the bandwidth on lots of pixels.

Actually, I think I'm just describing an analogue to HTML with the equivalent of CSS provided by the platform, but for native desktop toolkits (hopefully without the complexity of a browser engine).

Re:Devpod: Remote Development at Uber by jimmaswell on Sunday December 18, 2022 @11:01PM (#34048311)
I heard Stadia was actually pretty good, especially for a game that wasn't super sensitive to fast reactions like RDR2.
Re:Devpod: Remote Development at Uber by boppo1 on Monday December 19, 2022 @12:21AM (#34048797)
Stadia guy here. There were hiccups, but for the price+convenience, it was awesome.
Re:Devpod: Remote Development at Uber by paxys on Monday December 19, 2022 @12:25AM (#34048818)
The tech was by most accounts groundbreaking. The problem was with everything else – business model, pricing, games, customer trust.
Re:Devpod: Remote Development at Uber by grogenaut on Monday December 19, 2022 @02:23AM (#34049429)
It wasn't really groundbreaking tech. It's been possible for years, see online. It's just the business model sucks. We did some prototypes in a large company I worked for and it was easy to tell if you could put servers in local data centers with fat pipes it would work. We had demos using ec2 back in 2013. Them we ran the numbers and were like why, esp with free to play becoming more and more of a thing so we canned it.

Nvidia had a successful product as well before stadia. Hell I remember reading a use AWS GPU instances as a gaming machine blog posts before stadia.

Re:Devpod: Remote Development at Uber by dmix on Monday December 19, 2022 @08:51AM (#34051982)
I don’t think Stadia itself was groundbreaking. Xbox cloud worked as good as Stadia.

But a few yrs in the big players in the cloud gaming industry figured out some critical latency issues around the controllers and optimizing delivery of the video feed. To the point where lag was almost non-existent on a good fiber connection. The datacenter stuff was obviously the core innovation though.

I still prefer to download my Xbox games to my series s/x but I spent a year playing Xbox cloud games exclusively and I could 100% see that being the default for a big part of the casual audience.

Re:Devpod: Remote Development at Uber by tomjen3 on Monday December 19, 2022 @07:23AM (#34051241)
I have streamed my worksession with nomachine and I have used VS code remote. nomachine is really good, but I would still prefer to have a beefy enough machine.
Re:Devpod: Remote Development at Uber by dividedbyzero on Monday December 19, 2022 @08:28AM (#34051765)
I'm using Steam Remote Play over local LAN for gaming, works pretty well.
Re:Devpod: Remote Development at Uber by erik_seaberg on Sunday December 18, 2022 @09:38PM (#34047652)
X maintainers are promoting a new platform that doesn’t provide for remote hardware rendering. Shipping Javascript to a local web browser seems to be the way ahead for performance.
Re:Devpod: Remote Development at Uber by mhitza on Sunday December 18, 2022 @10:38PM (#34048151)
I bet on LAN X11 forwarding was pretty sweet, but when I tried it over Wi-Fi/tethering is was pretty janky (and before someone suggests xpra, that wasn't buttery smooth either). But I do like the idea of what X11 forwarding is, better than VNC where whole desktop is shared. I read that on Windows RDP can "stream" only the window, whereas on Linux the implementation is full desktop only? (please correct me if I'm wrong cause I would love to tunnel apps from servers).
Re:Devpod: Remote Development at Uber by wbkang on Sunday December 18, 2022 @11:02PM (#34048317)
Honestly, I think xpra is probably the best open solution you will find. It does have (too) many knobs to configure so it takes time to try out different codecs and settings to find a sweet spot using their session info toolset. And the mailing list is very helpful. For example, if bandwidth is plenty, you can use the straight RGB encoding and it performs well. Turning on audio can have effect on your latency as well.
Re:Devpod: Remote Development at Uber by yjftsjthsd-h on Monday December 19, 2022 @02:01AM (#34049327)
> "stream" only the window

I mean, that is a thing xpra can do. Or, x11vnc can do it with some hoop-jumping.

Re:Devpod: Remote Development at Uber by stryan on Monday December 19, 2022 @09:48AM (#34052646)
IIRC, part of the problem is X11 forwarding works best when the software is using raw X primitives (someone can correct my terminology if I'm wrong) because then X11 can just send draw commands. Both GTK and Qt don't use the X11 primitives so instead the server has to send entire pixel buffers, which is naturally a lot slower.
Re:Devpod: Remote Development at Uber by mariusmg on Monday December 19, 2022 @05:02AM (#34050369)
>start running desktop apps on cloud servers for remote work

Hopefully never.

Re:Devpod: Remote Development at Uber by lokar on Sunday December 18, 2022 @09:51PM (#34047766)
I helped deploy the previous version of that, the Java station, to everyone in MPK. They did not take away the existing computers and mostly went unused.
Re:Devpod: Remote Development at Uber by dariusj18 on Sunday December 18, 2022 @10:44PM (#34048196)
The thin terminal possibilities that Java was working on solving was exciting back in the day.
Re:Devpod: Remote Development at Uber by larsla on Monday December 19, 2022 @03:32AM (#34049816)
We had SunRay at a municipality here in Sweden where I worked at the IT department. I tought it was really cool and I had built our own "session routing" script that could connect terminals to different servers based on the smartcard ID. Terminals in the schools connected to a school server where students could login without smartcards, but if a teacher inserted their card it would connect them to the "admin" server or to a windows VM.

I had my own server in the DC that I could then connect to from my desk using a multi-monitor SunRay terminal. At home I had a SunRay connecting in to the office with VPN. I could move between terminals by just inserting my smartcard in whichever terminal I was at. There was even a company creating a SunRay laptop called Gobi that I tried using , but a regular laptop with the software client was a much better experience.

Re:Devpod: Remote Development at Uber by deng on Monday December 19, 2022 @03:58AM (#34049975)
I worked on a Sun Ray. I and many colleagues absolutely hated it.

These tiny machines were just way too slow to handle even the tiny amount of work they had to do. Also, everyone knows that X over network is just not made for modern applications ("modern" in the year 2000!). I worked with Matlab, and had a lot of fun trying to rotate 3D plots with a few thousand points. It was just unbearable.

Then of course the "single point of failure" thing. Network problems? No one can work. Main server has a drive failure? No one can work. Main server needs an upgrade? No one can work.

The Sun Rays had super-poor USB support. My ergonomic keyboard had no auto-repeat when connected to these things, absolutely impossible to fix or even debug. Then of course there was Sun software: although they invented Java, their JVM was leaking like a sieve and everything Java had to be restarted regularly. The Sun coreutils were just very limited compared to the GNU counterparts. We complained endlessly, and in the end, IT budged and we all got our dedicated Linux machines.

Re:Devpod: Remote Development at Uber by dmix on Monday December 19, 2022 @08:41AM (#34051890)
How long did the networked machines experiment last at Sun before you switched to Linux PCs?

I remember that famous Larry Ellison speech in the 90s about how thin client/networked applications will be the future.

Re:Devpod: Remote Development at Uber by deng on Monday December 19, 2022 @08:51AM (#34051988)
No, I did not work at Sun, I did my work on a Sun Ray computer at university. Sorry if that wasn't clear.
Re:Devpod: Remote Development at Uber by jeffbee on Monday December 19, 2022 @10:48AM (#34053434)
> everyone knows that X over network is just not made for modern applications ("modern" in the year 2000!). I worked with Matlab

No. I don't think everyone knows that at all. At my university we used X terminals connected to a central Sun SPARCcenter 2000 over ethernet and it was fine. We used MATLAB, Maple V, SAS, etc etc.