Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

Post reply on HN
Print view View original

671–680 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#671

Post by prirun »

maccard wrote: post #452
blacktriangle wrote: post #414

Earlier quoted context omitted.

Github does not need to be open source. Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies. Github may be the single greatest execution of embrace/extend/extinguish in computing history.

Where are we seeing the extend or extinguish with GitHub? It's been 3.5 years and GitHub is just as compatible with git as it has ever been.

Microsoft plays a very long game. 3-4 years is not enough time to boil a frog; it takes much longer or the frog will realize what's happening. Be patient. Give them 10-15 years after their "We love Linux" shift and you'll see. They love it so much, they will own it.

Just think of Microsoft like the Borg.

Re: GitHub’s engineering team has moved to Codespaces

#672

Post by cameronbrown »

djanogo wrote: post #355
015a wrote: post #190

Earlier quoted context omitted.

That pricing is a ~70% markup over standard Azure rates. Companies typically buy laptops with an assumed 3 year lifespan; so, let's assume a high-end $3000 laptop, that would be ~$83/month. Of course, you need a computer to access Github Codespaces, so this isn't saving all of that money. Maybe companies can cut some costs by buying cheaper laptops? Or if you want a more apples-to-apples; a Lenovo ThinkStation P620 r…

Even with Codespace your company will still have to buy you a laptop, to run corporate VPN, security/virus software, background screen recording, and zoom/video calls. All of this will still need powerful reliable business grade laptop. The cost difference between laptop meant for remote development vs regular dev laptop is less than $1k. ($300 for CPU upgrade, $200 for RAM, $200 for SSD upgrade)?

I think a lot of these things are less important by the day though. Are VPNs or advanced security software even necessary if everything is in Notion/Google Docs and something like Codespaces is being used?

Re: GitHub’s engineering team has moved to Codespaces

#673

Post by didibus »

dvdkon wrote: post #369
didibus wrote: post #165

Earlier quoted context omitted.

Can you install RDP/VNC and just remote into it like that? Then get sudo access and install whatever you want on it?

Well, it's a Linux VM/container, so while you could do that, I don't see why you would, I think all a dev would want to do in a dev container would be command-line in nature.

It's not just a dev container, it's meant to be your workstation, with the code files being stored in it and not on your personal machine. So if I want to install IntelliJ, Beyond Compare, etc. Or even if I don't want to bother with setting up tunnels and port forwarding for testing my web app locally, I could use Firefox in the VM, etc.

Seems it would solve all the issues, which are specifically that it mostly works only with VSCode or terminal apps, but with a remoting solution you could run anything you'd want.

Re: GitHub’s engineering team has moved to Codespaces

#674

Post by closeparen »

secondcoming wrote: post #275
Me1000 wrote: post #181

Earlier quoted context omitted.

Google has a monorepo in which nearly all of the company's code is stored. The monorepo uses a custom implementation of Perforce. No personal computer could download a whole copy of the repo. So for that reason people need to check out a virtual/cloud copy of the repo in order to do work. This has the added benefit (for google) of not allowing individuals to have code on their device which is bad if the employee lose…

It's been a while since I've used Perforce, but wouldn't each team have their own 'path' in the depot and set their clientspec to only download that? Why would anyone, other than a build machine, need the whole repo?

Not a Googler but we do have a monorepo... you can start with a team specific path, but you feed that to the build system and ask it to identify all the other paths where your (transitive) dependencies are.

Re: GitHub’s engineering team has moved to Codespaces

#675

Post by simonw »

pm90 wrote: post #593
simonw wrote: post #552

Earlier quoted context omitted.

What do you mean by fixing the dev stack?

I believe the OP is referring to "local stack" i.e. being able to run a single command e.g. `make up` (if you're using makefiles) to spawn a local environment and run a "local" version of the site i.e. serving on localhost. Having such scripts enables one to quickly setup a local environment to make changes and test them before submitting a Pull Request.

I've tried fixing the local dev stack - all of the scripts and Docker containers in the world still can't predict the ways in which something might break when it's running on 100+ different laptops with different developers with different unique preferences for how they like to get things done.

My expectation is that if you roll out something like Codespaces a small minority of your engineers will resist because it doesn't fit exactly how they want to work.

Meanwhile everyone else will get back several hours of productivity per week.

Re: GitHub’s engineering team has moved to Codespaces

#676

Post by thayne »

goodrubyist wrote: post #642
thayne wrote: post #625

Earlier quoted context omitted.

> but are YOU paying for it. If not - someone else is the revenue source even if you are paying for it, it's quite possible that they also have other revenue sources that conflict with your interests.

Exactly, this heuristic doesn't work all (or even most?) of the times. A more accurate approach is to rely on the terms you agree to when you buy/use software (if you don't want to read them, then you can depend on faulty shortcuts instead).

> if you don't want to read them, then you can depend on faulty shortcuts instead

Or refuse to use software that requires you to agree to long and confusing terms and conditions.

Re: GitHub’s engineering team has moved to Codespaces

#677

Post by didibus »

geofft wrote: post #198
didibus wrote: post #149

Earlier quoted context omitted.

https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...

What are they embracing, how are they extending it, and how do they plan to extinguish it? My understanding of EEE is that it involves taking some competitive product/standard, making a cool MS version of it, and then killing off the standard version - e.g. implementing a barely sufficient POSIX layer on Windows, getting customers who have "POSIX" as a purchasing requirement to switch, and then getting them onto the…

They first embraced web standards by building a web based open source IDE called VSCode to get people to convert to it over using Visual Studio.

Now that they attracted people to use it, they embraced Linux containers and offered managed dev containers as a service over it called Codespaces running all on Azure.

At this point, it's all good, this is how a company profits on open source and standards.

But now they are extinguishing by adding proprietary remote extensions, see https://code.visualstudio.com/docs/remote/faq#_why-arent-the...

Those extensions being proprietary will lock you to VSCode and their own containers. As a user you might still use it for free, even though they may add future premium features see: https://code.visualstudio.com/docs/remote/faq#_will-you-char...

But other competitors will not be allowed to use them to compete, and they can't be bundled in anything else, so Sublime wouldn't be able to bundle them in or make use of the remoting features.

The remote extensions are key to the attractiveness of VSCode for use with cloud managed containers, so it's a pretty big differentiator.

On top of that, they purchased GitHub, where most open source software lives, and are now trying to move development on those open source projects to adopt their own proprietary extensions to offer contributors a way to quickly contribute using VSCode and GitHub Codespaces.

Sounds like EEE to me. Maybe it will fail to extinguish, but my guess is we will see a lot of people slowly relying more and more on proprietary extensions owned by Microsoft to the point where if you work for certain companies you might not have a choice but to use VSCode.

Re: GitHub’s engineering team has moved to Codespaces

#678

Post by noptd »

simonw wrote: post #675
pm90 wrote: post #593

Earlier quoted context omitted.

I believe the OP is referring to "local stack" i.e. being able to run a single command e.g. `make up` (if you're using makefiles) to spawn a local environment and run a "local" version of the site i.e. serving on localhost. Having such scripts enables one to quickly setup a local environment to make changes and test them before submitting a Pull Request.

I've tried fixing the local dev stack - all of the scripts and Docker containers in the world still can't predict the ways in which something might break when it's running on 100+ different laptops with different developers with different unique preferences for how they like to get things done. My expectation is that if you roll out something like Codespaces a small minority of your engineers will resist because it d…

>I've tried fixing the local dev stack - all of the scripts and Docker containers in the world still can't predict the ways in which something might break when it's running on 100+ different laptops with different developers with different unique preferences for how they like to get things done.

Running on a remote environment may sidestep the issues of running on local hardware (poor virtualization, resource limitations, etc) but you'll have to standardize and automate the generation and management of your dev environments either way. Otherwise, you'll have the same problems in your remote space as you currently do locally, plus a few more possible points of failure (low latency network reqs, permissions differences, etc).

Re: GitHub’s engineering team has moved to Codespaces

#679

Post by didibus »

metaltyphoon wrote: post #296
z77dj3kl wrote: post #245

Earlier quoted context omitted.

It's a slightly different flavor of the same thing. VS Code is an amazing tool that's getting huge adoption because of how awesome it is, and how open source and community centric it is, etc. They've gotten a lot of mindshare and dev love, that's the embrace bit. The next step is the set of closed source addons. Have you noticed that a lot of the new VS Code features are now in addons that are under a different licen…

Gotta love how the goal post just keeps moving forward.

I don't see what post was moved, this is exactly EEE, adopt an open strategy, extend it with proprietary extensions, don't let competition use those extensions, extinguish competition by not being able to interface with your proprietary extensions while having created an expectation from the user for them to be available.

Re: GitHub’s engineering team has moved to Codespaces

#680

Post by didibus »

geofft wrote: post #284
georgeecollins wrote: post #273

Earlier quoted context omitted.

>> What is the analogy here? Microsoft wants to embrace and extend... compiling software? and will kill off... existing ways of compiling software? How will this work? Microsoft is embracing free development tools that compete with purchased tools they sold. SourceSafe vs Git, Eclipse vs Visual Studio.. those are terrible examples but you get what I mean. So you make a free tier of VS, you buy git hub etc. Extend.. y…

I understand how EEE is supposed to work. My claim is that it doesn't actually work, at least not for this use case. So for my argument, SourceSafe vs. Git is a great example. :-) You simply can't keep up with a proprietary tool that does its own stuff. You have to use Git. Microsoft tried having a custom version of Git for Windows OS development , and decided that they weren't even able to get themselves to fall for…

EEE doesn't have to work to be considered anti-competitive. The intent is nefarious, it's trying to attract people by offering a veneer of good grace and good intentions, only to capitalize on it once you've attracted a strong enough user base that you can get away with closing things down, squeezing things in, and calling the shots.

So it be great if their proprietary remote extensions fail and they are forced to open-source them and make them a standard, but clearly the intent right now is that they don't fail and it gives them a leverage over their competitors.

Post reply on HN