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.
GitHub’s engineering team has moved to Codespaces
651–660 of 704 posts
Re: GitHub’s engineering team has moved to Codespaces
#652Earlier 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…
Re: GitHub’s engineering team has moved to Codespaces
#653Earlier 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?
Re: GitHub’s engineering team has moved to Codespaces
#654Re: GitHub’s engineering team has moved to Codespaces
#655Serious 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…
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…
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
#657Earlier 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…
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
#658Huh, 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.
Re: GitHub’s engineering team has moved to Codespaces
#659Earlier 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.
Re: GitHub’s engineering team has moved to Codespaces
#660Earlier 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/
> 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