Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

471–480 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#471

Earlier quoted context omitted.

I've never seen a company collapse because their garbage collector posted an Our Incredible Journey™ blog post and then shut down a week later. I have seen multiple companies collapse because the proprietary Backend-as-a-Service they built their sand castle on top of pulled a vanishing act, however.

I am not concerned with Microsoft posting an Our Incredible Journey (TM) blog post within my lifetime, but duly noted.

Microsoft, too, will pull projects, or just completely rewrite them and make them incompatible.

Applications using .NET Framework with WinForms are not just a dependency update and recompile away from being ported to .NET 6. WinForms got a whole new API and porting complex UI effectively boils down to a rewrite. At least if you can. Microsoft doesn't support third-party controls in the WinForms designer of Visual Studio for .NET 5+, so have fun trying out positions and compiling over and over.

Re: GitHub’s engineering team has moved to Codespaces

#472
post #462

Earlier quoted context omitted.

That's the trick, the git is open, but the metadata is what matters. Issues, PRs, integrations into various code auditing services. That's the whole "extend" bit.

That is somewhat fair - there aren't great alternatives to migrate issues and the like to today. But all of those bits of metadata are easy to pull out of the service via API hooks. If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides. I don't disbelieve that it's possible for microsoft to severely restrict these - but entir…

> If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides.

Like Gitlab? I assumed Gitlab would dominate after the MS purchase of Github, but I was incorrect that people wouldn't want to trust their data and personal projects to the epic abusers of privacy that is Microsoft.

Re: GitHub’s engineering team has moved to Codespaces

#473

Earlier quoted context omitted.

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.

That's the trick, the git is open, but the metadata is what matters. Issues, PRs, integrations into various code auditing services. That's the whole "extend" bit.

Are there any foss initiatives to making these metadata bits portable?

Re: GitHub’s engineering team has moved to Codespaces

#474

Earlier quoted context omitted.

I would be happy to let go of an employee who bank their employment on the preference of toolings. Hear me out: Toolings are, like the name suggests, a means to an end. If a web IDE is fast, works reasonably, and can continue improve itself. And the learning curve is friendly to engineers with different background and experience. Everyone should be comfortable to be nudged to use it. And if the tool additionally is a…

Yeah, whenever I hear this kind of rhetoric - if my company ever required it's time for a new job - I roll my eyes. Sure, keep pushing yourself out of more companies, there are a lot of good engineers* who will be absolutely as productive as you and who won't be a drain on everyone around them. *it's always engineers making these statements or I only know engineers

I wouldn't call it a minor annoyance when it's a way of working you're practicing for 6-8 hours a day.

I am best placed to determine what tools I work with best to get work done. You wouldn't get an electrician in to do some work and then decide you can suddenly prescribe the tools they use.

I just don't have the patience for this sort of nonsense, there are a dozen clients who won't micromanage the operating system, editor and way of working that I'll be using to get the job done. With that said, obviously it's a two-way street and some willingness to be flexible needs to be shown on both sides. If $client wants me to sync my work with their $uniqueVersionControlSystem then fine, I'm willing to put in the extra effort to try and meet their specific needs within reason. But that doesn't extend to working inside a client-provided VM, using a client-prescribed OS image, using a client-specified IDE or making other such major changes to my established ways of doing business.

And in fact any client trying to micromanage this sort of stuff is a massive IR35 working practices red flag over here in the UK. You're better off terminating the agreement and signing something else as a SoftEng contractor.

Re: GitHub’s engineering team has moved to Codespaces

#475
Codespaces seems like magic. I've been using it for personal projects, and it is fantastic to do simple edits in a browser on the go.

That's not the intended use case, though. The actual value is where you get to scale up and automate what used to be only on local workstations.

The nightly builds with up-to-date dependencies and pre-pulled code get to going faster. Having a shared image encourages people to share all those local scripts that make things work where they may have just left them in a local `bin/` before.

Onboarding scripts diverge and fragment workstations because employees that have been there longer ran old versions and never got the new updates. This lets everyone use the same update to date tools together.

I'm excited to see where Github takes this. Tons of possibilities in now using Codespaces to create "local" environments composed of multiple machines.

Re: GitHub’s engineering team has moved to Codespaces

#476

Earlier quoted context omitted.

The fact that they will be able to do it, is problem, we should not put ourselves in position to rely on their future morality. Github at this point needs to be open source, atleast then they would be an easier way out.

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.

> Open source needs to pull its head out of its collective ass and not hand over its entire workflow to private companies.

Well, for starters, there is GitLab which attempts to do a lot of what GitHub does, while allowing you to self host it: https://gitlab.com/gitlab-org/gitlab

In some respects, i'd say that it does things better, for example, GitLab CI seems way easier to use in comparison to GitHub Actions: https://docs.gitlab.com/ee/ci/

As far as alternative source code management platforms go, with some code review and issue management functionality added on top, there is also Gogs, which is a far more lightweight solution and better fits smaller deployments: https://github.com/gogs/gogs

It was also forked by the Gitea project, which is largely compatible with it but is also in active development: https://github.com/go-gitea/gitea

Oh and there's also GitBucket which also attempts something similar to these: https://github.com/gitbucket/gitbucket

Now, you can probably hook those up with Jenkins or most other CI solutions, but personally i rather enjoyed how Gogs/Gitea integrated with Drone, which allowed for container based builds (no more plugin hell like in Jenkins): https://github.com/drone/drone

Then, you can throw in some additional tools, for example, for code analysis you could use SonarQube ( https://github.com/SonarSource ) and for security scanning of infrastructure you could look at OpenVAS ( https://github.com/greenbone ).

Oh, and on the organizational side something like Rocket.Chat ( https://github.com/RocketChat ) or Mattermost ( https://github.com/mattermost ) for communication and perhaps OpenProject ( https://github.com/opf/openproject ) for project management.

And there you have it! An open source based workflow that allows you to do most of the stuff that GitHub would let you! Of course, concessions might need to be made depending on what your definition of "open" is and whether you're okay with certain features being restricted to paid tiers in some software; if you do have a problem with that, there's also the possibility of looking at some libre alternatives, though that might lead to the occasional half-dead piece of software that doesn't really have financial incentives for maintenance anymore on anyone's part.

That said, i believe that few choose this approach, because it's somewhat complicated to run all of that and all of the sudden you become responsible for your own SLAs, which many don't want. It's often the same reason why people just provision VPSes from AWS, instead of running their own servers in a server room. I think the amount of links to GitHub for open source above speaks volumes about the state of the industry.

I don't think that there's an easy answer to the implications of this, maybe people should just familiarize themselves with the concept of "Service as a Software Substitute", so that they're at least aware of the trade-offs that their choices have: https://www.gnu.org/philosophy/who-does-that-server-really-s...

Re: GitHub’s engineering team has moved to Codespaces

#477
post #462

Earlier quoted context omitted.

That's the trick, the git is open, but the metadata is what matters. Issues, PRs, integrations into various code auditing services. That's the whole "extend" bit.

That is somewhat fair - there aren't great alternatives to migrate issues and the like to today. But all of those bits of metadata are easy to pull out of the service via API hooks. If someone wanted to start a serious competitor to github that shares the same basic data model it'd be pretty trivial to write up migration aides. I don't disbelieve that it's possible for microsoft to severely restrict these - but entir…

There are really simple ways to play dirty with APIs like making sure that they are incomplete in subtle and inconvenient ways like leaving out some of the metadata. Hypothetical example: make it impossible to query tags on issues. You'd still be able to do most things through the API, but if you have a workflow that's heavily dependent on tags, the data is effectively siloed.

Re: GitHub’s engineering team has moved to Codespaces

#478

So you're telling me that the next GitHub outage could take out my dev environment and give me an afternoon off? Time to convince management that we need to switch to Codespaces!

There are different risks, but there is not necessarily more risk. Does Codespaces have lower or higher than the availability risks of your current environment?

In the context of my comment of having a free afternoon off - having my local environment messed up means that I'll need to spend my afternoon fixing it instead, whereas having Codespaces go down is essentially an announcement to the entire engineering team to go take the afternoon off as there's nothing we can do

Re: GitHub’s engineering team has moved to Codespaces

#479

Earlier quoted context omitted.

I also don't use VS Code usually. My personal preference is a JetBrains IDE, but my point is more engineers should be able to choose the environment they're most productive in.

Currently, VS Code is the primary method of connection to each Codespace, and we do not support other editors officially. If you’re looking to connect via SSH, we do have a workaround here: https://github.com/microsoft/vscode-dev-containers/blob/main... -- and I use this regularly for Jupyter Notebooks.

That looks cumbersome enough to sound like you guys are trying to discourage the method entirely. A custom password that has to be copied and pasted every time? A lot fewer people will put up with that for long enough, and I'm sure whoever came up with that and whoever approved it, they all know this.

Re: GitHub’s engineering team has moved to Codespaces

#480

Earlier quoted context omitted.

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.

That's the trick, the git is open, but the metadata is what matters. Issues, PRs, integrations into various code auditing services. That's the whole "extend" bit.

What is going to be extinguished?
Post reply on HN