Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

651–660 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#651

Earlier quoted context omitted.

> I suggested the concept be made available as being by devs, for devs, purposed as a personal coach, with no uplink to the mothership. Ah yes, the classic "foot in the door" approach. Despite all the good intentions behind it, it still would end badly.

As long as there's more demand than supply for SWE workers, something like that would never become the norm. All of the dystopic news stories of WFH employees being subject to monitoring are invariably from fungible employees.

I often read on HN that it's a norm for US employers to install spying software on developers computers. I don't see how is it different. I would try to avoid from working in such a companies, because I don't feel secure knowing that someone is spying on me.

Re: GitHub’s engineering team has moved to Codespaces

#652

Earlier quoted context omitted.

You know how they added Github CLI[0], right? There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects. That would be the "extinguish" phase. Right now they have embraced and are extending (such as with Github CLI). [0] https://cli.github.com/

If you wish to leverage the advanced features of github, the CLI gives you direct access rather than rolling your own api client. git will always be a first class citizen at GIThub.. but how do you open, close, or comment on PRs with a standard git client? Edit: The last part came across a bit snarky, but I’m trying to stimulate the thought process. Such as leveraging GitHub Actions to automate all aspects of PRs via…

It feels like an open source standard on top of git that defines how to do this stuff would be helpful to reduce lockin. I wonder if Fossil or Gitlab have something.

Re: GitHub’s engineering team has moved to Codespaces

#653

Earlier quoted context omitted.

More than that, github was floundering economically, and Microsoft bought them to ensure continuity, because Microsoft was the single largest user. Don't want to rely on Microsoft for GitHub? The underlying 'git' is open source. Just deal with your git repos raw. No one is forcing you to use github.

Github wasn't profitable but had plenty of marketshare to guarantee more funding. Also Microsoft has plenty of infrastructure and did not need Github. How do you think Windows and Office were built for decades?

Wow. I have memories reading Github is a bootstrapped, profitable and dominant 90 person company. What happened to profitability?

Re: GitHub’s engineering team has moved to Codespaces

#654

Earlier quoted context omitted.

It’s very likely them doing pre rollout operations for this feature is actually what caused that outage though.

They're not announcing a new feature with this blog post, are they?

They released codespaces to enterprise customers

Re: GitHub’s engineering team has moved to Codespaces

#655
post #358

Serious question: if I were to use this, would Microsoft collect analytics on me (code written, keystrokes, mouse movements, sleep/work schedule, productivity metrics, etc) and monetize that data by using it to build some AI product like Copilot, or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did), use it to serve me ads, or do some stupid/irresponsible/unet…

If a business is paying for this product, then THEY (not you) are the customer. And in that context - yes, Microsoft may be asked or build a product for managers to manage their workforce, particularly if remote. This could involve presence tracking, engagement tracking (ie, do you open alerts / read your bug reports) etc. One approach would be to monitor what management considers productive / successful employees an…

I think that any workplace that would do this in the future, is already doing similarly toxic things. This isn't an excuse - there's a danger in commodifying and making things like this even easier - but there's already shit workplaces out there with plenty of red flags.

Re: GitHub’s engineering team has moved to Codespaces

#656

> My friends, I’m here to tell you I was a Codespaces skeptic before this started and now I am not. This is the way. ~@iolsen I don't actually doubt that this (and the 4 other glowing employee quotes) are real, but even assuming they are, I can understand people remaining skeptical about the sample size of 5 being broadly representative of the 100s (1000s?) of engineers at the company. Also slightly hilarious that "T…

I've been playing around with a homegrown version of this. It's really not that hard: just set up a docker context to your home lab server and use VSCode remote containers. I've been able to remove WSL from my PC: Docker desktop was gouging itself on resources. I can now also shut down my desktop and continue exactly where I was on my laptop, and visa-versa. I don't have to pull WIP commits back and forth between the…

VS Code remotes are magic. I use a light version of it for 100% of my development on windows with WSL, but I also use it to log into a mac server and edit files on that.

I have no idea what actually went into developing the feature, but I would have to suspect that Electron would have contributed to making the separation of an app client vs server easier than something totally "native".

Re: GitHub’s engineering team has moved to Codespaces

#657

Earlier quoted context omitted.

So how do you edit media files, using some ssh fuse mount magic ? What happen when you need to work from a shitty internet network ? In train ?

> So how do you edit media file This only does code. You'd probably have to do those locally and SCP them over or, yeah, some mount magic. > What happen when you need to work from a shitty internet network ? In train ? You'd have to commit your work, but you'd be able to bring the environment up on your laptop. There are still merits to this, such as the repeatable nature of containers. Depending on where you've work…

> this only does code.

VS Code remotes allows you to drag and drop files from your desktop and they're placed where you want them in your remote environment. I don't understand why this would be any different.

Re: GitHub’s engineering team has moved to Codespaces

#658
post #636

Huh, so there we are again: * you write code in VSCode (developed by Microsoft) * using Codespaces (created by Microsoft) * in TypeScript (developed by Microsoft) * downloading libraries from NPM (owned by Microsoft) * pushing your code to Github (owned by Microsoft) * to run it on Azure (by Microsoft) and on top of that you read email about the launch of a new feature in Outlook and celebrate it with your colleagues…

But Google is the problem.

Both are problems - Microsoft monopolizes development experience, Google monopolizes other areas like private info (they know what you search for, what videos you watch, what restaurants you go to, probably even where you fly)

Re: GitHub’s engineering team has moved to Codespaces

#659

Earlier quoted context omitted.

I don’t know if this is a good indicator or not, but Codespaces costs money. So there is a non-zero probability that you are not the product.

> Codespaces costs money. It's going to be paid by your employer which leads to GP's concern about, > or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did) Which is more likely. If your employer sets something like this up - will they use it to calculate a productivity score and use that for lay offs? Seems rather probable to me.

My company is stupid, but not that stupid. We already have vast amounts of data about checkins that could, in the hands of a stupid person, be used to create stupid developer metrics for performance evaluation, and yet I've never once in my many cross-team performance ranking meetings heard a manager who had the gall to trot out "lines of code" as a serious metric for comparing people. And I'm at a FAAMNG. ;)

Re: GitHub’s engineering team has moved to Codespaces

#660

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.

You know how they added Github CLI[0], right? There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects. That would be the "extinguish" phase. Right now they have embraced and are extending (such as with Github CLI). [0] https://cli.github.com/

I made this comment elsewhere [0], but by this logic anyone who builds an ecosystem for an open source tool should be accused of the EEE strategy.

> There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects

So we're accusing MS of a slippery slope based on a phrase from 25 years ago, which there is absolutely zero proof or indication of them pursuing in the last decade (at least).

When GitHub show the _slightest_ inclination to do anything of the sort, I will be standing there with you, screaming blue murder. As of right now, they're progressing the development of git, "embracing" the open standards that have been developed (lfs being exemplary) and have shown absolutely zero signs of extending git in incompatible ways. See elasticsearch [1] for what "extend" _actually_ looks like.

> Right now they have embraced and are extending (such as with Github CLI).

If they _hadn't_ embraced, people would be complaining that GH are forcing non-open standards to be used. I firmly disagree that the GH issue tracker and pull request management are an "extension" of git. They have nothing to do with git whatsoever.

[0] https://news.ycombinator.com/item?id=28149098 [1] https://news.ycombinator.com/item?id=28110610

Post reply on HN