GitHub’s engineering team has moved to Codespaces
github.blog
github.blog
Because I feel like the answer to that is yes, and I can already see myself in the future writing something angry in the comments section of an article on HN that exposes some evil/stupid shit Microsoft did with this, or happened as a result of this.
I'm not against the concept of using a thin client for development, but it just doesn't seem smart to me do it in such a way where you have to place trust in a company that, throughout their entire existence, has consistently proven that you should not trust them, because they have no incentive to (and thus never will) act in your best interests. It's like if Facebook released their own web browser and "promised" to respect your privacy; you'd be an idiot to believe them.
Is this satire? A little too on the nose, you know cause Google…
This, I think, is a place where we need some regulation to codify some different forms of privacy and give the government a big stick to bop companies over the head when they violate those definitions. We could potentially manage the definitions as an industry group - but we'd need the government to get the big stick.
I 100% agree with you, but doubt this will ever happen in a heavily pro-surveillance government in an effective corporatocracy. Therefore, I think open source can and needs to do better in providing free competition against potentially-dystopian closed-source alternatives
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.
If they can sell the product AND sell developer productivity metrics to management, they will.
Github at this point needs to be open source, atleast then they would be an easier way out.
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.
I do not think we actually know that. Was there any release of any financial data?
Also, part of the "beauty" of the modern "tech" giants is that they manage to find alternative sources of revenue, in some cases (notably Google and Facebook) completely replacing the old school user subscription revenue. By and large people seem to be OK selling their data for either a price reduction or complete price removal for services. It is what it is.
Was it a common knowledge at the time? I don’t recall seeing info about MS being largest user and unfortunately their newspost on acquisition returns an error…
[1] https://news.microsoft.com/2018/06/04/microsoft-to-acquire-g...
Yeah they paid 7.5B so they can continue using their favorite web app? This is possibly the most naive take I've read on it that ignores any of the strategic reasons for actually acquiring them.
Also Microsoft has plenty of infrastructure and did not need Github. How do you think Windows and Office were built for decades?
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.
I don't disbelieve that it's possible for microsoft to severely restrict these - but entirely removing them is off the table unless they cut out a lot of value. Inter-service communication to third party review tools and CI/CD tools all depend strongly on those API hooks.
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.
Effectively you're saying that all decision making should be based on current observable reality only and any projections about the future should be ignored because they are not 100% provable. I guess that's a way to function, and based on how bad people often get the future wrong it might even be a productive one, but it does explain why we're down to soundbites, because we've reached a fundamental disagreement not on opensource or Github, but a disagreement on how to plan for the future.
I don’t know that this is the result of a deliberate strategy by GitHub, but by any metric the extend step is a resounding success.
If not one developer in a decade can tell the difference between a source control hosting service and a tool they use, that's not really GitHub's problem. This is the same as my parents not konwing that "facebook" isn't the internet.
> Nobody really understands why pull requests are named that way,
Sure they do, the answer is one google search away on the largest Q&A forum for programmers [0]. it was the first google hit for "why are pull requests called pull requests"
> or that it’s possible to have very different workflows to what GitHub offers.
Maybe inside your circle, but plenty of people are aware of different workflows. Some of the largest open source projects in the world exist on github and don't use the pull request workflow (linux kernel, firefox, chromium off the top of my head).
[0] https://stackoverflow.com/questions/14817051/why-does-github...
Nobody said it was GitHub's problem just like nobody said it's Facebook's problem in your example. They're both laughing their heads off all the way to the bank. It's everybody else's problem.
In my view, the entire PaaS ecosystem modus operandi is building on top of open hardware & software, allowing and enticing people to move in easily (familiar tech/open source), and making locked-in products out of them. If that's not EEE I don't know what is.
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 gitops instead of using the GitHub client. Many ways to avoid dependence of the CLI!
In extinguish phase - Git won't prevent GitHub from rejecting a commit if it doesn't contain <TrackingMethodSignature>.
> 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
And their extending has nothing to do with open standards, which is worrying due to the potential to create lock-in.
Implementing "sync" on its own doesn't matter that much, because few people think "sync" is a defining feature of the web standards, or that preview is an inherent part of web feeds. The awareness of alternatives still exists (I hope).
Yes, of course.
Why, did you somehow think otherwise?
Just think of Microsoft like the Borg.
Why would they fuck with their number one audience, developers?
https://www.investopedia.com/how-microsoft-makes-money-47988...
A third is for Office, a third for cloud, and a third is Windows.
IMO Microsoft is a trillion-dollar company because of their long monopoly with Windows. It's so entrenched that their "punishment" for abusing their monopoly position (according to the DOJ) was to give all schools free copies of Microsoft Office, thereby forcing every parent to own a copy of Microsoft office to be able to read reports from their kids' schools. Ingenious!
You know why they would fuck with developers? Because developers have choices now, and Microsoft doesn't like it when anyone has a choice besides Microsoft. They are remedying that.
Oh ffs are you even aware that MS didn't originally build GitHub?
And your comment is super out of touch with what MS was doing in the 90s and early 00s. GitHub has plenty of competition, Gitlab for example is a fantastic platform, overall more powerful than GitHub as well. GH's strength is how much better it is for open source projects and if MS messes with that they'll be killing their golden goose.
There is no all-powerful benevolent deity you can hand your code to and say "here, take care of this for me, for free, for all eternity". At some point private companies will have to get involved (or would you rather have your government get involved instead? Because I don't want your government hosting my code). So you want their incentives to be nicely aligned.
Purchasing a popular product is definitely qualifies for the "embrace" part of the strategy.
But that's not unique to MS - AWS and Google follow similar playbooks, as does almost any large company that provide a platform-like product. The goal is to make the platform as sticky as possible for as many customers as possible.
We know. We understand that it is technically correct. But it's completely useless in the discussion. You know perfectly well what the other person meant.
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...
For example, GH Actions don't support YAML anchors but also have basically no other way of cutting down on repetition in your CI config files (actions can't call other actions, for example), so your CI config is full of brittle boilerplate.
Also noteworthy is how you can't rerun single actions. If your deployment failed, you might have to rerun the whole workflow, including the 10 min test run.
Meanwhile, if you use dependabot, PRs issued by that tool have no access to secrets, so if you need to connect to e.g. AWS to run tests, you need to implement weird workarounds.
I don't understand why GitHub is so popular, GitLab seems like such a better tool and it's also developed totally in the open. Some of the CI stuff is literally amazing (e.g. merge trains).
0. https://blog.stackblitz.com/posts/introducing-webcontainers/
In this worst case scenario (which hasn't happened yet), I'm sure GitHub would expect the good will of open source projects and contributors while simultaneously being the boot on their face in the workplace.
One approach would be to monitor what management considers productive / successful employees and also on employees who have gone on PIP's - then train the AI on that data set. You'd then be able to drive various alerts to manager and HR dashboards (ie, if a manager was failing to address alerts / manager their team it would be surfaced up a level).
Dystopia may be coming indeed. Remember, usually the key issue is not if product is a paid product, but are YOU paying for it. If not - someone else is the revenue source, and Microsoft et al will serve them. Maybe the individual licenses will not have this "management" layer add-on as an option.
But I think a very real chance of something like this occurring! If not right now eventually. In Sci-fi this is an inevitability (monitored through a smart watch or something etc).
Back in the day the boss would be right there with you in the store etc and could watch you all the time.
Or maybe this will be something that really only shows up in china etc? I think they are a bit further along on some of these types of things.
These things are always deployed against the least powerful first.
Just this week was a big story about how a call center provider (used by Apple and others) was forcing employees to install cameras in their own homes to monitor their remote work: https://www.nbcnews.com/tech/tech-news/big-tech-call-center-...
https://www.zdnet.com/article/gdpr-german-laptop-retailer-fi...
€10M fine for keeping employees under video surveillance for no good reason.
This is an example showing that there are limits to employee surveillance on-site.
I look forward to the papers on how to slack off on your job while the AI classifies you as "a straight shooter with upper management written all over him". Possible title: "An adversarial approach to the TwoBobs Productivity Classifier"
(/s if this was not clear)
I’ve been pitched the TwoBobs Productivity Classifier.
My feedback was anyone who needs it has classified themselves as an unproductive dev manager.
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.
All of the dystopic news stories of WFH employees being subject to monitoring are invariably from fungible employees.
I haven't heard of this happening at all.
Whereas it is commonplace for people to use time-tracking software (like Toggl, RescueTime, etc) - and it is also not-uncommon for companies to require employees to use such software (software-eng or otherwise) for the purposes of reporting their time/hours/what-they're-doing, they all have web-based UIs for doing data-entry: which is definitely not the same thing as installing monitoring software on an employees' own personal hardware with or without their informed consent and it being a condition of employment.
I think people are getting terms-conflated and using overloaded terms with negative connotations: "time tracking software" which does active-software-application-window-tracking for the benefit of the direct user can easily be mischaracterized as "monitoring software".
Interestingly, I'd much prefer Microsoft's algorithms classifying me as productive or unproductive, based on how I code - while there's a lot to be said for different patterns of work being equally productive, I trust Microsoft to implement the same heuristics across the board, and not take a look at my gender and race and make assumptions about me based on that.
(Of course, since the ML data of productivity will come from nearly entirely white males, if it's only available to github enterprise cloud subscribers, then the ML data will be pretty biased as it is. Guess discrimination is inevitable!)
even if you are paying for it, it's quite possible that they also have other revenue sources that conflict with your interests.
Or refuse to use software that requires you to agree to long and confusing terms and conditions.
In terms of the biggest companies in the sector, MS has been doing much more for developers and developer productivity than others. At the same time it's not a monolith and so you should not expect boyscout behavior either.
Privacy is a concern, and the onus is on you the user to ensure that you remain in control of your data. When using a service (any service), the answer is to always be ready to bail at a moment's notice. That means using source control and not tying yourself to a specific ecosystem.
The one thing that used to set Microsoft apart from the likes of Google and Facebook was that their main product, Windows, was not anti-user. No matter what you thought about the OS or Microsoft's business practices, it was a paid piece of software that worked for the user. Windows now is filled with user-hostile features and it works for MS instead. And they don't even grant us the courtesy of giving it away for free.
Market share or the fact that the public at large isn't punishing them for it doesn't mean anything. It was already clear that most people are willing to walk headfirst into a dystopia.
This is why I don't like Google collecting data on me now. Not because I don't trust them now, I for the most part still think them trustworthy, but 15 years is a long time and there's no way I can intelligently trust that they will act in a certain way 15 years from now, given the available information at my disposal.
And that's with a company that I think is heavily incentivized monetarily and has a strong employee culture of keeping data private and in-house. Until there are better laws protecting my data or a clear legal relationship with me and an entity with regards to my data, I think the only prudent course of action is to keep as much information about me as possible out of their and others hands.
Not sure if that's supposed to be an argument for using/trusting MS.
The levels of user and privacy hostility they went to (and are continuously going to) with Windows 10/11 makes me see this as a strong argument against.
That's not the most valuable info at all.
What would be valuable is to know which ecosystem, languages and tech people are investing time and resources into. These are the ones you need to prioritize for your dev tools. For instance, Microsoft decided to invest in supporting Rust https://docs.microsoft.com/en-us/windows/dev-environment/rus... as well as making sure .NET works on all OS.
> or build a productivity dashboard so managers can fire people for not being productive enough (like Xsolla did)
When a competitor decides to start using these, it's awesome. You get a nice window of opportunity to poach high performers.
The Facebook web browser. Never say never. If we knew what we know today about privacy, we would have pointed out the idiocy of anyone choosing to use a web browser released by Google.
Google were already making money off targeted ads at that point. There was even an outcry about GMail scanning people’s emails several years before Chrome was released. But you could probably argue that we didn’t fully appreciate just how bad things would get at that stage. Many of us were just happy to see Microsoft get some competition.
I still try to, but it’s a lost battle already. (Don’t use Chrome, BTW.)
Therefore the real question is if Codespaces is helping to get your job done; I guess that depends on the complexity and structure of the code, the complexity of the build environment/how you work with the CI environment and how the project is being deployed. I guess that this complex of issues will increasingly dictate how things will get done - if these are too complex, then you are better off with a remote environment.
now there is a bit of an irony - github helped open source, now this development will be very helpful to corporate software developers, but might turn out to be harmful to open source as such.
It all depends if the industry will act this way or not, I still hope that there is some level of desency left somewhere, because being too paranoid about all of it will not get me anyway either. Also the utility of all this analytics data is limited, for example they could possible get the 'number of lines of code' written by someone, but it is impossible to judge how essential all these lines of code were to the business. Also there would be a significant backlash, if they get too invasive on the privacy of developers. (that's the moment for the video where Steve Balmer is flipping out on stage and shouting 'developers' https://www.youtube.com/watch?v=I14b-C67EXY )
Some manager may toy with an idea of getting IT to install and manage monitoring software, but ultimately reject it as not worth the cost. But if the company starts to work over something like Codespaces - even if only for purely technical reasons - then suddenly they'll find themselves having a dashboard for free, and for sure they'll start using it.
--
[0] - https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-tri...
Seriously. It takes extreme naivety to take a SaaS business at face value today. Patterns of exploitation are well-established and easy to spot. Once you see this a couple of times, including in offerings you got so excited about - or worse, you get burned by them personally - it's hard to be anything but bitchy about tech.
The comments may be negative, but the bigger problem is that they're also not wrong.
Replace Facebook with another major ad company, and you are basically describing the most popular browser right now.
The road is to quantify the work in small packages is a decent one though, dissect a problem until only trivial tasks remain.
Still, I think your intuition is pretty much on point. But with anything, just take the features you like. If your business can dictate this for you, search for other businesses. Contrary to popular belief, there are a lot of those, although pay might indeed be a bit lower.
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 "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways...
On the other hand, there's quite a few "hints" littered throughout the article that their current setup is a bit of a beast, so I can definitely imagine some engineers being relieved to be able to get such a behemoth off their physical laps/desks: I guess if the local development experience is sufficiently brittle & frustrating, any alternative may seem welcome.
> Visual Studio Code is great. It’s the primary tool GitHub.com engineers use to interface with codespaces. But asking our Vim and Emacs users to commit to a graphical editor is less great. If Codespaces was our future, we had to bring everyone along.
snip
> From there, GitHub engineers can run Vim, Emacs, or even ed if they so desire.
I'm curious to know if this statement is true. Most experienced developers these days have a regular desk and a chair where they like to code and focus. How prevalent is the move-and-code scenario?
So I do see the appeal in thin client. My only issue is that the experience his closely tied to latency, so sometimes working over ssh is... irritating. Especially on mobile connection.
My usually setup is chrome dev tools and some node servers fired up, so quite easy to replicate.
But I still prefer to just move my laptop around.
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 two machines.
It's a major leap forward, and there is no need to use GitHub infra.
(Or who hosts it)
I have started to run some dev tasks on a remote Linux server, with Dockers, and then just configured automatic file sync on save over SSH.
Aside/HTH: The new Yarn has "Plug 'n Play"[1]. They claim that committing [their version of] node_modules is a reasonable thing to do, so that's one way to avoid install entirely. I don't trust that claim, yet (it smells like noisy diffs). You can instead re-enable the global cache[2], and then mirror your host cache directory into your container (whatever `yarn cache dir` gives you).
I have tried none of this myself because I'm not working on anything JS right now. pnpm[3] is what I've been using up til now, and is also a direct upgrade in terms of speed (but I suspect it won't work with mounting host directories).
[1]: https://classic.yarnpkg.com/en/docs/pnp/ [2]: https://yarnpkg.com/features/offline-cache#sharing-the-cache [3]: https://pnpm.io/
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 worked, you may have been through the hell of a huge list of setup steps when on-boarding a project: that's one thing that containers are really good at automating.
You may not be the target audience, though.
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.
The wrinkle is that the display server is running on your local machine, and connecting to the thread of execution on the remote server. Vim doesn't really have that concept of separating view from control, but tmux does play a somewhat similar roll.
A closer analogy would be using Plan9, and mounting most of your cloud machine locally. Vim would then just be your local front-end into those mount points.
Containers/docker add the ability to share your exact machine configuration with someone else, and have them create their own copy of it with a single command. It would be almost like sharing a VM image with your team. There's been a lot written about the pros/cons of containers, but they achieve similar goals to VMs, and so-happen to bring a lot to the table in this scenario.
I can't use docker in general because my internet is too crappy. That was annoying in 2012 when I first used it, but it's even worse now. I've always worked with VMs, since 2001 or earlier - virtualbox, wok, AWS, wok, and now proxmox.
It helps to know what your use case is, I don't run a ton of VMs, just one or two at a time that can use almost all of the resources of the server, and I generally do infrastructure and computing work in general.
I presume none of this counts as a homelab, though, since I don't program in rust.
You make an attractive case it for! :) Yeah, this is why I don't have a "home lab".
In my case, my homelab is my laptop (which I connect to from my desktop). I don't actually have a server blade lying around (although those can also be relatively cheap when big cloud upgrades their servers).
[1]: https://www.ebay.com/sch/i.html?_nkw=dell+optiplex+3040+micr... [2]: https://www.ebay.com/sch/i.html?_nkw=intel+nuc&_udhi=200&_ud...
Personally I use Gitea, which should be usable by someone used to Github. I don't switch workspaces too often, but I am sure some tools are available.
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".
With this setup, you can use whatever local tool you want and, as long as environment variables are respected, they’ll just work. The only requirement on your end is to either run nix-shell first, or to use direnv and ask it to load the nix env for you.
The downside is you still are compiling locally, so you still need sufficient CPU/memory resources, but that’s it.
Unfortunately most companies still aren’t paying any attention to Nix.
Yes, the parent comment looks a bit complicated, but that's just the one time setup, not something that needs to be done by every developer. And Codespaces will require some of that setup too; it's not like it'll magically know what packages and dependancies your project requires to build.
If not, then it misses the main benefit outlined in the article.
But yes, once a project commits to using CodeSpaces dev environment (even and especially ones with large code / heavyweight environments) there is a lot that can be done to optimise the spawn up time, that cannot be done as easily for local dev.
That sounds incredibly useful actually. Is that the main sales pitch for codespaces?
The only people who I don't think would instantly like this sort of thing are people like game developers who basically don't do any unit testing of their code and run the binaries they generate. For those users you could find quite a few ways around that.
[0] - https://www.quora.com/What-does-Googles-web-IDE-look-like
My friends, I’m here to tell you I was a Codespaces skeptic before order 66 and now I am not. Good engineers follow orders.
The nightmarish local development experience of either case are symptoms of deeper issues than local development itself being a problem.
So by extension, codespaces is more risky than my current environment.
The question is, how much time do you spend on dev environment issues per year?
When I was at one of the FAANGs, our dev enviroment took about 1hr to install, and you had to redo it everytime you switched platform / version (about every week).
We spent ~50 hours per year managing our local dev enviroment. probably more in reality.
Definitely not little. But at the same time, I usually learn a lot about how stuff works during that. Which I like to think makes me better at helping other people debug weird shit.
Another fun one was when an org was rolling out CarbonBlack on all endpoints and decided to block all Java. Because apparently Java in the web browser is a security threat. They blocked 30 devs Java runtimes as a result. So there was an entire afternoon wasted for those guys.
To a corporation the risks of GitHub being down might be ok. Plus this will drastically increase on boarding devs to an existing project.
It's certainly reasonable to think that a SaaS can approach availability time of a single piece of hardware.
Furthermore, it appears that engineering github/github to work in codespaces helped their local provisioning as well.
> So by extension, codespaces is more risky than my current environment.
That only looks at the hardware. There are many more pieces to the puzzle.
If you’re worried about your SSH connection being stable, mosh is another option.
And with us soon going back to home schooling (thanks delta...) children happily playing outside is much less distracting than pent up children yelling inside. And mama can't do it all.
even my (and many devs') "suffering" work is worth good money - or at least our employers continue to think so :)
Doing it in the cloud probably carries some risks for a business that need to be factored in, but I'm sold on the thin-client dev workflow. I'm wishing I could do it at my day job so my laptop stops screaming at me from all the Docker containers.
And who knows maybe since you have your server running headless it is effectively on par with your laptops. These days most of my cpu cycles on my laptop are spent on Slack or Chrome!
I'd like to set it up for out-of-house stuff, I just haven't gotten around to messing with port forwarding, static IP, etc, not to mention guarding against all the potential security issues
> I did not have the money for a new laptop
> I could afford the ~55/month for a dedicated server with 32GB and 4cores
Umm... you spent 55128 = ~$5000 over 8 years. You could have bought 3 top-specced laptops. A good $1500 laptop will last at least 2-3 years. You would also get some resale value out of your laptop when you upgrade.
According to you they paid roughly the same amount as it would have cost to buy laptops and upgrade them relatively frequently, but amortized over much smaller monthly installments.
And their system would have been elastically upgradeable.
On top of that holding on to money and spending it later is generally better than spending it now, because $X is usually worth > X future $ because of inflation/lost ability to invest.
And I was barely coming out of homelessness at the time. 1500 doesn't just pop out of nowhere.
You did just remind me of the time when I was contracting for that company, they flew me out to California but I didn't have enough money on my card to cover the incidentals fee at the hotel they booked for me. Thankfully an employee came through for me. That was pretty embarrassing.
I can get a $55/mo dedicated server right now and code for 30 days straight and get paid. Or I can save for X months for a laptop.
Also the server price will most likely go down over the years or I could get a beefier one for the same money. The laptop will depreciate every day.
What I'd really like to see is a WebRTC type interface that overlays this to provide some kind of collaborative environment on top of it. I'm thinking of a built in voice chat as well as multi-author editing within the same codespace. Imagine it like pair programming. I'm in FileA.ts and I can see a little avatar icon of another dev in FileB.ts (maybe surfaced through the Explorer and/or the file tab bar). The voice chat could even be location aware so if we are in the same file/package then we are able to chat. I'd go so far as to allow multiple editors to affect the same file within the codespace so I could see the other dev edit the file in realtime (like coderpad or other interview tools).
I imagine a workflow where a feature/ticket is mapped to a codespace. One or more devs are assigned the codespace and they work together until the feature is completed. Incremental changes are stored up until a "build" action is submitted, resulting in the current contents of the codespace being built and deployed to an internally/publicly accessible endpoint. This might also result in a "snapshot" which could represent a commit to a sandboxed repo. The codespace goes away once the feature is completed resulting in a single check in to a master branch which would go through regular code review type processes (probably a squashed version of their local snapshot's changes).
You should try Live Share! VS Code Live Share enables you to collaboratively edit and debug with others in real time, regardless what programming languages you're using or app types you're building. It also supports voice chat:
https://marketplace.visualstudio.com/items?itemName=MS-vsliv...
I see a codespace as a shared destination. It lives independently of any individual. I can hop in and out whenever I want and it continues to live.
To expand on this, it reminds me of how way back in the day we used to use MSN Messenger (and then Skype) to facilitate work chat. The model there was a contact list, a list of individuals I could reach out to and connect. There were group chats as well, but the primary mental model was closer to a phone call. Then Slack came and changed the model so that channels were the default, shared spaces were preferred over personal chats or ad-hoc groups. I don't want the default to be "I have my session and may invite others to join". I want the default to be "there is a shared workspace I connect to that others might be currently active in".
You might even imagine an interface similar to Slack channels (or Teams if that is your world). I could have multiple codespaces as channels that I can switch between. Within each codespace there may be active several devs. I can jump in and out. You could even setup permissions like "read only" spaces or whatever.
I think he had everything in your first couple paragraphs working in 1968!
On GitHub, that instance type is $2.88/hour or $2,073 monthly per developer for a single instance.
(Granted, that's running 24/7 but still - wow, that's expensive for a single instance)
A powerful laptop is a drop in the ocean compared to how much cloud VMs cost per developer.
I guess lucky for them to be owned by Microsoft now and so that's just a cost of doing business. I have a hard time believing they could have even considered an approach like this if they were still paying for hardware out of pocket.
Kudos to the team for figuring it out though.
I do wonder how many VM's they have running though at different points of the day and how many spares they have prepared.
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 runs ~$2800 for 32 threads and 64gb memory. DIY would also land somewhere around that $3K mark; a Threadripper 2950x (32 thread) is $1100; 64gb of memory is around $250.
This, of course, is the most expensive option they have; the more standard option would be 4/8; for which you would pay ~$85/mo (all the time, normal work hours), for the privilege of a machine that's far less powerful than any laptop any of our developers have. For god's sake, my M1 MacBook Air is an 8/16, with four of those cores far more powerful than any three year old Xeon Azure has running. And it was like $1400.
I understand maintaining dev machines isn't the easiest thing in the world. I have never once worked anywhere where it was such a problem that the company would justify tens of thousands of dollars in spend. Because it kind of is one-or-the-other; time invested in making Github Codespaces work for your company is time not invested in maintaining local dev environments. And Github's ideal end-state is companies totally rely on Codespaces, so the local dev environments languish.
Its not worth it.
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)?
If your dev costs you $100/h, you only have to save them +/- 5 hours of faffing around with branches/dependencies every month to make it worth it (assuming a 8 hour workday).
Big could, of course. But considering it takes new devs at my company ~3 business days to get up and running (and we're a React shop), it could be worthwhile.
Look, this is yet another product targeting naive VC funded startups. Milking the cows until they bleed.
Where we run into trouble is when we try to copy the shape of those big companies, and the kind of initiatives they fund, into startups, or mid-range companies. In quite a few ways, those top companies are better at development, but the base costs are only worthwhile if you have a money fountain of real revenue that grows far faster than your dev expenses. Trying to copy them with very different conditions is going to lead to tough problems, possibly company killing, and it's the kind of imitation we see all over the industry.
So yes, someone like Github is going to have eye popping expenses, because the alternatives to avoid those expenses just don't make sense to them. If you are not working in a multi billion dollar company, their practices can be interesting, but it makes as much sense to emulate them as it'd make for you to hire an entire Formula 1 pit crew to keep your commuter car in good shape.
Sure, you might not need to buy machines that are as beefy (although I bet you'll still need a decent machine to run all your chrome/electron windows) but enterprise maintenance on these machines is still a significant cost.
I definitely don't think one can look at this from the 'saving money' angle.
> I do solemnly swear that never again will my CPU have to compile ruby from source.
...yeah, why was that even happening? Why not distribute pre-built artifacts? I feel like the whole docker ecosystem only exists because people forgot how to distribute software and/or python/ruby and friends make deployment so hard.
Back in the day (ahem), I’d have solved the problem by building new .deb or .rpm packages and letting the OS manage the updates for us. This is a lot harder for languages like node/js, ruby, python, etc… Dealing with a system level packages vs local packages is hard, so almost all management happens out-of-band. Older versions of packages was/is still an issue for many distro-managed libraries. And different projects have different requirements.
In the end, I’m largely okay with this… I’d rather have my choice in local OS and be able to work on my client of choice. I see the rise of containers was more of a response to heavyweight VMs as a dev environment.
But it’s good to remember — these are not unique problems and we’ve solved them all before.
The same issue applies to serverless technologies (at least last when I used them). It was extremely difficult to run serverless services locally, debug issues etc.
Having the cloud is great, but nothing will beat being able to run things locally.
It just gives you so much more control. You're not locked into a specific editor or tool chain, you can integrate with whatever other local tools might be specific to you, etc
This is a great feature, something to complement existing development approaches, but I'm always going to prefer my own setup where I have everything configured exactly how I like it.
There are of course risks that the local setup process will differ from the prod environment in a serious way. Even with good automated test coverage I feel less confident about the code I commit here than most other places I've worked.
There must be a better approach than setting up a bunch of mocks and running the core logic in a scratch file.
My experience aligns very strongly with this. A local stack lets you add debug/print statements anywhere. There is no "magic", you can see the thing run on your machine. The freedom is unmatched.
If you’re building a new startup, you don’t need this. Use docker-compose.
The current latest full stack project I built requires a single command: npm run dev. Launches docker-compose (PostgreSQL), Next.js and ngrok (expose/webhooks).
And it takes 10 minutes to setup.
Not everybody has the requirements of GitHub!
Still, I’m sure I’ll use this in a year :)
(I've run a team responsible for the tooling for a company's development environments in the past so this hits really close to home.)
Having such scripts enables one to quickly setup a local environment to make changes and test them before submitting a Pull Request.
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.
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).
> 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.
I'd expect internal support to be highly dependent on how terrible the alternative is. Beyond personal preferences, I'm really apprehensive about coupling all dev work to a single remote cloud provider. What happens if you lose internet access or when they inevitably go offline? In the case of the later, literally all work stops.
Works really really well when you allow your employees to explore and do what they want locally. Then when things break or go wrong (either I tweak something, or an incompatible Apple update lands) - I can just reset to the same dev env as everyone else.
It's fantastic. Spin up and throw away a dev env that is so much more powerful than my local machine could be (100+ GB RAM machines are a click away).
According to the article, Codespaces supports non-IDE users by allowing ssh. CitC supports non-IDE users with a network file system. This seems preferable - the editor runs on your local machine with low latency, but you still run tests on the cloud machine.
I wonder if Github supports this workflow, e.g. by configuring sshd to allow sshfs/sftp access.
[1] https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
Sure, you can install those locally too, but by then you are losing many of the benefits of a cloud environment.
You won’t find many people who started using VSC remote dev and then abandoned it to go back to local. Once you’ve got it working, which is a pretty easy feat, it’s a no brainer, obvious win.
> This seems preferable - the editor runs on your local machine with low latency, but you still run tests on the cloud machine.
Something I miss with remote development is being able to use graphical Git clients like Sublime Merge on my working directory. I don’t want to setup SSHFS just to make that work, and I’m sure performance wouldn’t be great anyway.
I still experience a few glitches (extensions randomly stop working, Intellisense sometimes dies, and auto-detecting architecture for launching mobile apps sometimes fails) but I'm sure those will be ironed out.
The issue is not so much senior devs, but new devs. If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late.
I remember when I first saw the JAM stack, basically they use external services for *EVERYTHING*, claiming it's "The future™". They don't even own the data/database.
I'd rather make things better for users, rather than companies. Stallman's essay [The Right to Read](https://www.gnu.org/philosophy/right-to-read.html) gets more and more scary.
He/She was concerned (and with good reason) about the safety of data. Had to learn the bad way :(
It's just that like auth, logging, etc, CDNs have been neatly abstracted out and service-ified in such a way that it's often more economical to go third-party. But that choice is orthogonal to jamstack.
1. Development environments are running on Kubernetes, and VS Code is remoting into them. You don't have to pay a monthly subscription for that. VS Code remoting is free-as-in-beer and Kubernetes is free-as-in-speech.
https://code.visualstudio.com/docs/azure/kubernetes
2. The actual Kubernetes hosting is the product "GitHub Codespaces" running on Azure. GitHub certainly isn't paying a monthly fee to themselves for this; they are, technically, self-hosting it. I agree that you probably do want to have the option to run it yourself, but I think you do, given 1.
This will be coming to a cloud service near you
In some cities you do, and they're often controlled by organized crime.
(Whether this comment is a metaphor for SaaS is left as an exercise for the reader.)
(not entirely serious, but it has a very expensive monthly fee for what is in essence a better GC algorithm)
I don’t see why that would be a problem though? If I can pay a company to provide improved GC for my infra, where the cost savings made it beneficial, I would do it…
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.
Which is to say, you wouldn't have heard of them, because they never got big enough to be known to anyone beyond a handful of clients and employees. I've personally been hired to try to rescue such a company, and was not successful.
Larger companies have also been known to buy out critical service vendors and in-house them when there was a risk that they might otherwise shutdown or pivot, too; that's less often an option fot smaller firms.
The objection here isn't to hosting per-se – most companies aren't in the business of maintaining PostgreSQL and should consider outsourcing that task early on. If your host of choice shuts down, that's a standard service, you can dump and restore your DB and move on. Annoying but NBD.
The danger with jamstack or BaaS or similar approaches is working yourself into a place where a proprietary service API is baked into your product as a critical, fundamental dependency; if and when the host shuts down, you're in extreme trouble. That's what I'd heavily caution against.
(There's an argument that when the proprietary service is run by an MS or AWS or Google "they won't go bankrupt" so there's no risk, but even then those companies shift priorities and shut down services not infrequently).
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.
> With operations in over 620 cities, it was paramount for us to identify a chat solution that would enable Uber employees to reliably communicate on desktop and mobile regardless of where they were in the world.
Did Uber really need their own chat solution? Are they not better served by a SaaS product, one of 5 that 90%+ of companies are using? Are they still using uChat today? (honest question, I don't know)
This is especially dangerous when talking about security sensitive features. It is highly inadvisable to roll your own crypto
Lot of companies shut down or fail for lots of reasons. I think a business should focus on what they do best and what's critical to their mission.
But at Uber's scale I can see the business need for a custom chat app. Most third party chat apps are bloated, both the cheap and expensive ones. Plus there's the need for custom integrations.
The nice thing about being a client is that they support all this stuff and it gets better over time. Also something like Slack is absurdly cheap compared to the usefulness and productivity it provides.
The implication that Symphony is a better solution for chatting than already exists / existed.
As a (non-trading) user of the platform, I strongly disagree.
I don't know what the traders think, but I'd hope there's a USP in there for them besides "it's cheaper than a Bloomberg seat."
Nowadays, there's a lot more support internally at Uber for buying off-the-shelf solutions instead of trying to reinvent wheels.
Sure, there's obviously a big difference between controlling the things that are critical to your business and wasting time outside your core competencies. And part of that difference is the risk profile: if your entire backend disappears, and takes the API your frontend is built around and all of the data with it, you're basically up shit creek. If your chat app of choice disappears, you can sign the company up for a different one tomorrow – it doesn't take 8 months of crunch to "port" your employees, and likely all of your critical business docs weren't in the form of chat history.
> Lot of companies shut down or fail for lots of reasons. I think a business should focus on what they do best and what's critical to their mission.
Agreed. But very few internet companies can claim that the data in their datastore and the entire mechanism by which their product accesses said data is not critical to their business, which is the distinguishing factor here.
And it isn't all about efficiency. Programming and CS is such a major part of my life, that I want to know the deeper parts, and I want others to understand it too. Programmers who do not seek that knowledge I unjustly judge for it.
I'm sure this has been said dozens of times throughout the years as we've built more and more tools of abstraction. As software gets more complicated, it's OK if not everyone fully understands every part of the stack. People specialize, and then become experts at their small scope.
Or even if they're not experts at their slice, not every company needs a 10x code wizard who understand the system up and down. Some companies just need someone lightly technical to mess with website templates or write simple scripts and services.
At this point Microsoft's strategy around GitHub, VS Code, Copilot, etc. should be pretty obvious, and we should all be running for the hills.
As someone not following this closely, what would that strategy be?
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 NT API.
Most of the examples on that wiki page have been unsuccessful (IE trying to EEE HTML, Outlook trying to EEE SMTP, etc.), because they weren't able to get enough people to rely on the extended version and stop using the standard thing.
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?
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 license. This includes the new remote dev and python tooling. Still free to use and awesome tools, of course, but fully under MS exclusive and controlled. That's the extend.
I don't know what the longer-term plan is. I'm hoping that it won't lead to an extinguish. But if that's what they want, then they could e.g. cripple the open source version, moving all their dev effort into a closed-source, Azure/Github only web environment. Who knows?
Half the dev world is now used to VS code. Many junior developers have never used anything else. Whatever they do can have a big impact.
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.. you try to make your tools as ubiquitous as possible. You convince hobbyists and students that they should use your platform because it is more powerful /useful.. it will help you get a job later. This part of the strategy seems really hard because there are so many development tools that are open source, and lots of companies like IBM, Oracle, Google want to keep one of their own safely under their control.
Extinguish. You add features that only really work on your platform, or work better. Think about trying to develop for Android not on Android Studio. I haven't used VS for a Windows project in a long time but I assume it has similar advantages. Or Intel's compilers used to be the first to work with new instructions.
Ideally people would "have" to use your platform and you can start taxing them for that, either with fees or requirements that they implement your initiatives. Think about Google pushing Kotlin.. Android Studio kind of defaults to that now. Of how it supports Firebase, or defaults new projects in segments. I am not mad about that it or anything, it may just be a good idea. But it shows how if you control the dominant tech platform you can support your initiatives.
This isn't something that keeps me awake at night because a number of tech companies are working to promote their own semi-proprietary or open development platforms. But the fact that so many go to the trouble to do that shows it is a concern.
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 the trap - they ended up getting involved in upstream Git development and turning all their extensions into standard features.
There are definitely cases where if you control the platform you can control what people are doing. I'm arguing that Microsoft has no actual effective control of the platform here.
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.
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.
hmmmm.......
I just don't like the direction of moving the development environment to the cloud. It makes it easier to just consume third-party services and a) Don't understand how anything works, and b) Don't own anything.
If you know, fully aware, what the cloud implies, then sure, use it, but it's dangerous when the decision comes out of ignorance.
I guess there's not really much you can do about it though. People will do whatever is easier, and not everyone wants to know how things actually work.
I do think there's a serious autonomy question here, and I think companies do actually care a lot about maintaining their autonomy from other companies, and in many cases the incentives align a lot. The whole stack here seems like something that you can run internally / self-host:
- Codespaces are specially-configured containers. All the standard infrastructure for running containers (Docker, Kubernetes, etc.) is FOSS and is quite reasonable to run internally. It's not even like OpenStack where it's a knockoff product of what the major cloud vendors run: it's literally what the cloud vendors run.
- Shallow clones, pre-built running containers, etc. are all deployment practices, not products.
- You can ssh into a codespace.
The big problem here in my eyes is that it's reliant on VS Code, whose remoting stuff is not FOSS (and, having tried it at my own workplace pointing it at our self-hosted Kubernetes, it's been a pain to get it to work well with our authentication setup, proxies, etc. without access to the code and we have a number of open bugs filed). I think the challenge is for a free-software IDE to adopt the VS Code model of the IDE running locally but executing code (including running the LSP backend) remotely.
And, in a sense, Emacs already supports this just fine with TRAMP. It's just that the experience of using Emacs and the experience of using any modern IDE (VS Code, any of the JetBrains IDEs, whatever) are very different... and none of them are FOSS.
If you have a FOSS IDE, I think you can get this whole setup working well in a way where you have autonomy over the setup and where you can understand the details just fine. And even if you're using VS Code, you can set all of this up in a way where you're not contacting any external services.
Do you have more details on this? I thought VC Code just uses the language server protocol for remote editing, which supposed to be an open standard. What stops say neovim adding full LSP support?
edit:formatting
If you're not running VS Code, then this isn't relevant to you and I'd imagine you can get a good experience via Neovim using LSP + netrw.
Codespace stuff is a way out of insanity. It's a mediated common ground. You could standardize on Docker or Vagrant or whatever, but they come with a lot of pitfalls and the local dev story with them all kind of suck. Codespace on the other hand is a solution that mostly doesn't suck. It's actually a pretty decent experience.
FUD. Everything is neatly handled by rvm (or rbenv) and bundler. You can even use gemsets if you want to be really anal about it. It all goes in version-controlled user directories. I keep my main Mac machine, my work Windows machine, and the production Linux boxes all running the same versioned stack just fine.
I'm not mounting an attack on Rails. Rails' fine.
(Edit) I can't answer your reply. It seems there's many ways to read the quote you brought up. I'm clarifying that the meaning I intended wasn't an attack on Rails. Take it as you will. I'm a bit confused why my original comment, which I meant as a positive-to-neutral tone, is being perceived so negatively.
I literally quoted you saying that in my first post. But hey, what do I know?
- M: number of devs with their own machine
- N: number of projects with their own way of bringing up dev env
Codespaces has the disadvantage of turning you into a renter.
Can't wait for the equivalent of abusive dmca to be able to put down your entire dev team.
It's really a way out of madness.
Bingo. The inevitable rug pull is going to be very, very expensive/catastrophic for a lot of people (though, profitable if you understand the underlying systems).
I have blown people's minds by showing them how to just call msbuild or git from the command line etc... I think it's changing since dotnet core took over in that space but had a good 10 year run where generally no one at various work places had any understanding of what visual studio was really doing and it did bite us in the ass at times.
I think that's one of the biggest issues I have with codespaces.
MS changed. Google changed. Apple changed. Why do one expect github to never turn evil ? Haven't learned enough from history ?
Don't let them control your entire stack! Don't let anybody control the entire of anything.
There is a difference this time though. This time, most of us will say it only once.
Fight this bullshit. Call your pro-breakup / anti-trust representatives and give them the reasons this is bad for you and your career. Tell them the narrative and give them ammunition to fight this.
Google, Amazon, Apple, and now Microsoft deserve regulations and/or dissolution.
This isn't a black-box system, it's github. Owning your artifacts is as simple as setting up a job to automatically clone the repo a couple times a day (assuming your entire company is working through the cloud interface and not a single person already has a local checkout).
Lots of companies put their entire databases in AWS - owned by a company that's already evil, no speculation required - where the egress charges make offsite backups a challenge. And western civilization hasn't collapsed yet.
If GitHub changes its policies one day or shuts down the service... just push to a new repo and switch over to regular workstations.
Isn't the use-case they're selling in the article approximately "the development environment setup is so fragile that it doesn't work on lots of machines?" I'd be willing to wager that after a few years of the whole team using this, the fragility will be much worse, so moving away will be that much harder.
What are you referring to?
It's 100% economic. "Everything has to be free" means there is no money to be made in selling actual applications. That means the industry pivots to SaaS since the cloud is DRM and by running apps remotely you can charge rent and make piracy impossible. As a bonus you get the user's data, which you can do anything you want with in most cases.
As a bonus SaaS can also claim to be open source if only the client code is open, or if all the code is open but the SaaS still holds all the data and has the network effect. So you get those open source virtue points for free while still locking up the data or the network.
Of course the other response to "everything has to be free" is surveillance capitalism.
I feel like there's an ever growing tension in software development where magic like this makes us more productive but also more vulnerable.
Maybe we need to develop better benchmarks for "knowing enough" so when the magic fails, we're not starting at zero trying to figure out what went wrong.
Why should you trust your computer?
Why should your career be safe?
People are fungible resources to be used when convenient and agreeable. Say or do the wrong thing, or have your utility dip below a threshold, and you can be removed.
It's happening.
There are open-source alternative(s) that support import of most things from github.
Any good CS/Engineering program should have the students build and use a dev environment they configured to their liking.
If the only dev environment used is wrapped into some IDE magic I would be very skeptical of the program.
Imagine your employer watching your every keystroke and getting instant performance metrics. Then some OverseerAI reporting that you didn't type for 10 minutes already, sending a notification to your boss.
If you work for a big company you already have your laptop controlled by MDM software which can do whatever it wants.
E.g. Employee A ran the tests 4 times an hour whereas employee B ran the tests twice an hour.
Call me a luddite if you will, but I feel that the developers should be wary about protecting their craft. This will end up with BigCos turning this into another Social Dilemma type scenario.
Or I don’t know, maybe try using a Linux laptop instead.
This is an underrated, excellent option, especially for solo devs and small shops.
Or run a Linux VM in Parallels Pro with startup-on-login, shared networking, and port forwarding.
In my opinion, Apple should build a virtualized Linux dev environment into macOS (a sort of Linux Subsystem for Mac). That would be so helpful... or Microsoft could build a Linux distro with a next-gen window manager and full support for Windows apps. Either way and I'd be all-in.
That being said, while it has a lot of advantages from an enterprise perspective, I wouldn't want to live that way :)
Wait, what?!?
No, it doesn't. Their engineers' workstation software can read or edit their code just as easily as their engineers can. Going into the cloud just adds another liability, it doesn't take any one away.
If those files are accessible only via the web (or if you bother setting up ssh + pubkey, via ssh) that significantly reduces the surface area of possible attacks.
Don't hate on "not being impossible" for "being less likely."
All it changes is that the attacker will have to launch the browser or rewrite some part of it (what he can do, because the browser auto-updates with your access level), instead of simply taking the files.
Oh, and by the way, not all software running on your machine has complete access to the filesystem. Reading your code and changing your browser requires basically the same level of access.
Also, do keep in mind the target audience for Microsoft's enterprise products - if something lets you check off a bunch of boxes on some government or industry compliance checklist, then that thing has value to those customers, regardless of any actual security benefit.
You have N machines, M developers, with access to the internet and development environment E. What are the chances of someone stealing your code given N, M, and E.
Changes to N, M, and E change your expectation on the frequency and severity of attacks.
> For the best experience with Codespaces, we recommend using a Chromium-based browser, like Google Chrome or Microsoft Edge.
(from https://docs.github.com/en/codespaces/developing-in-codespac...)
Makes sense coming from Microsoft, but it'll be fun to see if/how that affects the ongoing Chromium/Safari battles (and Firefox, to a lesser degree) if Codespaces seriously takes off. "Our company development environment requires every developer to use Chromium" is going to be quite a shock.
In short they never tested it outside it because they never had to. Only now it’s become available as a “web app” with a URL.
- creating a Docker base image with all the dev dependencies
- have a prebuilt environment with a full git clone of the 13GB repo before a developer needs it
But why does this only work for the remote development environment? You could easily make the same optimization for the local development environment, the only downside is dealing with Docker on Mac.
> The GitHub.com repository is almost 13 GB on disk; simply cloning the repository takes 20 minutes.
Their problem seems to be mainly this. Which I'm surprised that they don't fix, but invent a workaround for. Deleting/rewriting a git repo's history is not impossible and often necessary for these kinds of cases.
The concerns were long lived branches that had WIP and I think also just misunderstandings about what was going to happen. We never did it.
Our monorepo is multiples of that and the last time I cloned it was 2 years ago. When we first moved to git we simply had a 'clean' clone sitting on a network drive that all users could just copy to their machines to get started.
Development environments being overly complex to setup, long compile times, those are symptoms of software bloat and bad design, but instead of addressing these fundamental problems, people want compilation to happen externally on a 32-core machine so they can sweep those problems under the rug. Okay, let's see how that turns out.
While the USA is also litigation happy, it actually takes an incredibly high amount of deliberate destruction for an employer to succeed in suing an employee.
I don't think it's very likely you'd get sued, but I wouldn't want to risk it against well funded adversaries with expensive lawyers.
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.
At first I liked them because they have lots of great functionalities out of the box, but vscode has caught up and just yesterday I switched back to vscode from jetbrains. For java spring and react
It's pretty configurable. In my experience, it's pretty quick. It's not text editor or VS Code quick but the only thing that ever trips me up is the occasional re-indexing. Well worth it for how well it does everything else.
Code server (https://github.com/cdr/code-server) works in a similar way using your own PC as a host, but for whatever reason Codespaces is more performant.
Parts of gmail run in the browser, the rest runs on servers written in many different languages at Google.
The article describes using pretty much any IDE, so they are just offloading the setup and running of the development environment to the cloud while letting you run your preferred IDE locally.
People who try working offline are exactly the people who want to do it without Stackoverflow.
My company has a remote VSCode setup not that dissimilar from this setup. Big C++ codebase. Many engineers love it, even some of the "old timers." Our interns can be productive on day one and it brings a lot of productivity to not have to worry about caring for your dev environment.
But there are plenty of people who really just want to SSH into a beefy desktop (or directly edit on that desktop) and use their vim/emacs setups. These are the people who know how the whole build stack works, can debug the vscode/codespace magic, and can do amazing things not available in the VSCode plugin library.
So it's good to be able to do both. Allow power users to use their own tools, but don't require everyone to be a power user to sit down and write some business logic. Give nice rails to ride but don't require them.
I bet smaller/poorer companies may want programmers who are ready to fix tooling when it (inevitably) breaks
Additionally, it's not like developer set up is the only thing that test your ability to manage frustration. I would say developer set-up is just something you need to get through to start your actual job, and if that can be eased up then it's worth it imo.
For smaller/poorer companies, they could always hire an engineer that specializes in fixing broken tooling. Ultimately it's a company's job to hire competent engineers.
Thinking back to all the times I had to set up my workspace, I wonder how much did I really learn vs just Googling and getting quick fixes.
Google allows for normal desktop IDEs, plus having a web based one. The funny thing is, many people move to the web based one because it is so good.
But Google is also unique in how piper/citc[0] (our source control) works. It's effectively designed for web/cloud based style development, so the workflow for web based dev and desktop dev are effectively the same.
So web dev can work, but I don't think the existing tech that most of the software industry has is built well to support it.
[0] https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
There are some exceptions for some teams (like Chrome). And when I was there exceptions for people who did mobile (iOS/Android) development, though Google was moving pretty aggressively towards a world where even iOS code wasn't allowed on the employee's device.
The cloud environment builds and runs faster but the autocomplete, go-to-definition, etc. are pathetic.
It used to be entirely custom, but is currently being re-based on VSCode. Overall very similar feel to Codespaces, just tailed for how Google works.
There are other IDEs besides VS Code and shell based ones.
It can be a pain to set up, but is it more of a pain than setting up a dev environment the old fashioned way?
If you edit a file using some sync over ssh option, and want to run a test - how do you proceed? And how is this not the same thing as just checking out the git repo locally in the first place?
Well you have your files synced over ssh and also have a terminal over ssh which you use to run your tests. Am I missing something?
> And how is this not the same thing as just checking out the git repo locally in the first place?
It's not just avoiding cloning the git repo. It's avoiding building all the dependencies and getting them configured and running. For most of my projects that's not a big deal but I expect GitHub has several databases with specific configuration, memcached or redis, maybe custom patched builds, etc.
If you check out code in RubyMine, it'll try and install the dependencies in the Gemfile regardless, though.
If you’re looking to connect via SSH with your desktop IDE, we do have a workaround here: https://github.com/microsoft/vscode-dev-containers/blob/main... -- and I use this regularly for Jupyter Notebooks. :)
Jetbrains recently added remote capabilities to IntelliJ, I'm hoping it's going to be usable with codespaces soon.
Edit: Here is the CLI program that helped me set this up:
https://docs.github.com/en/codespaces/customizing-your-codes...
I also have a very bespoke dotfiles config that predates Codespaces (https://github.com/wincent/wincent), so I made a thin wrapper around it that makes it work (https://github.com/wincent/dotfiles). For people with less complicated set-ups (ie. basically the entire universe), it is pretty straightforward.
Personally, I just `git init && git remote add ...` in my home directory and have a .gitignore that ignores everything by default, so I have to `git add -f` whenever I want to sync a config. Submodules work well for `.vim/bundle/the-plugin`. It's also nice for syncing important zsh customizations like this one: https://github.com/MatrixManAtYrService/home2/blob/master/.z...
There are also other strategies: https://dotfiles.github.io/
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.
I use Github Codespaces with a Vscode and vscode-neovim. Neovim is running locally.
I don't know how many people would want to use graphic applications over the network however, seems like it would be janky
VSCode editing over SSH works really well in contrast. I think Sublime has a plugin that ain’t bad. Emacs (TRAMP) is probably the worse of the three :/.
Terminal Vim or Emacs over Mosh is a pretty good option too.
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 critical product of the organization, everyone should be comfortable to be mandated to use it, because it's now a very valuable source of dogfooding.
*it's always engineers making these statements or I only know engineers
"Tools are just means to an end" is just one of the many rhetorical devices that cushy managers use to eschew responsibility. Of course they're means to an end, but some means are better than others, and usually those with better means end up doing a better job.
Hiring is brutal, especially now, so good developers can afford to be picky and find another semi identical job in almost no time.
There should honestly be some good faith on both sides. It doesn't make sense for a job, in most cases, to be strict about an editor. But it's also not a good move for eng to be walking around talking about all the fragile things they'll quit abruptly for.
I feel like you're gradually making this hypothetical engineer seem more ridiculous. If someone quit over training or their unwillingness to try scrum, that would be bananas of course. There's an extremely large gap between that and mandating the main tool to use to do your job everyday.
That said, small things can look trivial from the outside and make your life a living hell at the same time.
In my experience (FAANG, startups in the valley and startups out of state/country), strong engineering talent is not particularly difficult to find, but finding a good fit is the tricky part. And I would wager that eagerness-to-rage-quit is a pretty good indicator of someone who will have trouble finding teams that they fit on.
A lot of people "rage-quit" basecamp over their no politics thing. I probably wouldn't have, but to each their own.
FWIW, I have also spent lots of time at FAANG, startups, etc and haven't had any trouble finding a great fit. I have also never looked more than a week or two for a job when I wanted to leave, so that does factor into my willingness to leave if I'm not enjoying my job.
If you look outside of FAANG (companies in the rest of the world with unattractive stock), finding good engineers is a problem and most codebases are filled with horror.
The plus side is that, once you're a good engineer, you get little stress/pressure and a lot of leverage on flexibility (eg. remote in cheap places, in pre covid times), even if you won't make as much as FANG engineers. Also, interviews don't require 2 months of preparation every time you want to jump ship.
I'm sure if you're paying FAANG money you can find plenty of good engineers happy to do backflips.
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.
No hard feelings or anything. I spend 5-8 hours a day working in my IDE. That's a huge chunk of my life and it matters a lot to me to work how I want. I've also found getting this aspect of my worklife right greatly impacts my overall productivity.
> Toolings are, like the name suggests, a means to an end.
It goes both ways. Employees are paid to accomplish an end, and I understand employees who are happy to walk away from an employer that micromanages the means to that end down to preferences in tooling. The reason you quit isn't because you miss Emacs (even if you do), the reason you quit is because your boss doesn't even trust you to choose a text editor.
That said, if the thing is your own product, yeah I get it: dogfooding is important. That said, I know of teams at Microsoft who do their (OS-agnostic) work on macOS... at some point accomplishing the end is more important than dogfooding, and you just let the workers use the tools that they're comfortable with.
I'd love to use Codespaces or a self hosted alternative so that I don't need to carry around a heavy i7 laptop.
Being able to develop in the cloud from a browser opens up the possibility to develop from a thin Chromebook.
(Much better than eg PyCharm's attempt at remote development.)
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
I wish this was even more modular so we could have a dumb compile farm, +local ide +run&debug on-device (I've recently got 90% closer by remote sshing with vs code to a pi vm)
I know not everyone wants to run Linux or FreeBSD, but this is one area where ZFS shines for me. I take regular snapshots on a cron schedule and also whenever making system changes. If I manage to get the system into an unexpected state, I just rollback a snapshot and optionally reboot. Save for the potential reboot, it's an instantaneous operation. I don't need to spend hours restoring from backup.
Using the built-in ZFS support in Ubuntu, you get a nice split between system and user data. You can roll one back without the other. Snapshots are created on every mutating apt operation.
The future is long term probably in the web, I'm just not sure we are there yet.
GitHub's approach seems utterly ridiculous, especially given that I've seen colleagues prevented from working because their Internet connection at some point ran through a part of the world that was sanctioned by Western governments.
Developer, it appears you are somewhere near Crimea! NO EDITOR FOR YOU!
The Visual Studio Code server isn't in Nixpkgs/NixOS yet, but there's an out-of-tree effort being maintained here for now: https://github.com/msteen/nixos-vscode-server
* 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 on Microsoft Teams...
* Codespaces don't spy on me (much)
* Typescript doesn't spy on me
* NPM doesn't spy on me
* Github doesn't spy on me
* Azure doesn't spy on me
Google does. It's literally their main revenue stream.
The tool to fix the broken tool is the broken tool.
> Memory up to 64 Gb
Great, barely enough to develop my new Electron app.
It was an extremely miserable experience.
While I love the marketing materials of Codespaces and I want to believe in the superiority of remote development, I'm not yet convinced.
I can navigate to any internal or dependency definition, out of the box.
But when I need to learn or explore a really large code base in Ruby, I haven't found anything better.
I usually run mine with at least 8GB max heap space (on a 32GB machine) and have a good experience with large Gradle projects.
Developing Online with GitHub Codespace - https://news.ycombinator.com/item?id=24565606 - Sept 2020 (54 comments)
First Impressions of GitHub Codespaces - https://news.ycombinator.com/item?id=24339118 - Sept 2020 (93 comments)
GitHub Codespaces - https://news.ycombinator.com/item?id=23092904 - May 2020 (601 comments)
env portability/consistency/using prebuilds as an example could have been done with in house CD/vagrant/packer ~10y ago. This post doesn't focus specifically on that, and there are additional benefits to the approach taken, but the notion that local dev is incompatible with these types of technologies is a consistent background theme in the writing
also, referring to emacs as non graphical and 'shell based' is a bit off to say the least.
Docker driven development is generally code on your host and run the app in a container. Considering their git pull takes 20 minutes, it makes sense to go the VM route.
Editing happens locally in the client (and is synced to the service in parallel), and so you shouldn’t notice any latency when typing.
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.
Then you can run `make world`. Of course, BSD make is not completely compatible with GNU make...
1. Ubuntu seems to have trouble with psycopg2 while Arch does not, so I often use psycopg2-bin just so Ubuntu developers can easily install the requirements (learned the hard way). 2. Some older (supported) editions of Ubuntu create extra lines in `pip freeze`, including `pkg-resource=0.0.0` which throws an error when installing on nearly any machine (including cloud versions of Ubuntu in Github Actions.
I have an application that uses docker-compose and has Elasticsearch as an image. In order to run it, I have to expand the vm_max_map (or something, I forget). But there are different ways of doing this in Windows vs Linux.
Differences between environments are legion. Unless a company wants to just send standardized laptops to every developer, it seems way better to just spin up a cloud vm that is already set. Plus, there's easier reproducibility in a cloud vm vs a physical machine (unless you want to reach for something like nixos, but hell, what company is equipped for that yet?
The difference between Debian and Ubuntu is enough to be a nuisance.
The Dell XPS laptop my employer provided cannot boot Debian and I'm stuck with Ubuntu. Same packages, maybe a version or two are more recent right? Nope. Aside from the egregious transparent snap installs when using apt (which can't uninstall snaps, thanks Canonical), there's a lot of minute details that amount to quite a time loss (that and having a laptop with no USB/RJ45/HDMI ports). Simple scripts that work on one OS and not the other, font scaling and rendering making my standard 1080p screen unreadable, absurd default configuration that makes WiFi unusable, etc.
Glad I don't have to manage the same oddities for the actual work I do. Everything is simple once it's all Dockerized.
But that's not true either. I had a different problem setting up the repository with every developer and they were all using the same OS. No repo in sources.list (how?), no docker group created when re/installing the docker package (why?), all kind of weird stuff happening.
So you tell me there's a way to have all devs working and testing on the same environment? That's great! But it is _not_ worth handing over everything to Microsoft or any other third party.
I'll never trust GitHub, GitLab, or any other forge with business-critial stuff. Host your own code, commit your dependencies, have your build script work locally. I've deployed through Git{Hub,Lab} outages and the leftpad fiasco, and the cost was insignificant. Host a mirror there for cheap if you want, that's what I do for my public projects (but after the copilot debacle how can I trust GitHub with anything?).
And what if you're a remote team? You can't rely on the internet. My ISP was kind enough to remind me of this when I got my very first outage with them one hour before starting at my current company.
As valuable a product GitHub is and Coderspace may be, it is a step closer to the Minitel 2.0 where everything is centralized and controlled by a single entity. It's not the internet, it's MSN at best.
IMO investing time to keep applications "normal" like this pays off in the long run. It keeps development closer to "greenfield", which causes a general multiplying effect. Tutorials are slightly more likely to work, 3rd party packages will be quicker to integrate, etc etc.
(Note that this is separate from dev/prod parity, which is also good.)
(1) On a team of developers, there usually isn't someone who is designated to be responsible for designing and maintaining a good dev environment.
(2) Many devs don't have the expertise to do it. Build tools, operating systems, dependencies, and configuration management are a related but different skillset than coding.
(3) Many devs don't want to work on it because they enjoy coding more. Just because you enjoy one type of work doesn't mean you enjoy the related work. (This also applies to writing documentation.)
(4) Fixing / improving the dev environment is not rewarded. You need to get X feature done by Y date, and fixing the dev environment may slow you down. It provides a long-term benefit, but not one that is easily measurable, plus that benefit is off the radar when evaluating the contributions of someone whose primary role is coding.
With this cloud environment, they've separated those responsibilities out and given them to a specialized team dedicated to it. IMHO, some of the success is probably due to the organizational structure, not just the technical differences.
GitHub Copilot also only works on VSCode and not on other editors. Soon they will probably move Copilot to only work on Codespaces. All of this is in the 'Extend' side.
Guess what 'Extinguish' looks like?
They will make it all free, starving the competitors out, when everyone runs to the new Microsoft platform.
Google does anything: "Whatever happened to Don't be Evil!"
This might be very resource intensive though.
Now githubs code is going to be developed on an online platform, which works by sharing code others have uploaded.
I have a feeling that this is not a good recipe.
Very curious to know more about this. What exactly are you talking about? Closest thing I could find is this[0], but you said "couple of years ago".
[0] https://www.zdnet.com/article/hacker-gains-access-to-a-small...
Another kid, got access to every single private github repo.
It was on hackernews, he declared it, made a write up about it and got given a pretty small bounty from github. Google it, otherwise I guess the net was scrubbed of it. I follow him on twitter but yeah just google more and you should find out all about it.
I was always surprised it wasn't a much bigger deal. Basically since then I think any company ( most that I work for ) are clinically insane to upload their proprietary code to the site.
On a related note - was it not just a couple of weeks ago people were concerned the codespaces system is using other peoples proprietary code? ( I havent kept up to that on that one so not sure if its still an issue)
Nowadays with LSP there's even less of a reason to lock yourself into a editor as a service or paid editor. If you really love VSCode or Codespaces then more power to you, but I highly recommend giving something with a steeper learning curve a try for at least a few weeks to see what its all about.
I can understand the use case of having to run 200 micro services or something too powerful for my machine.
I don't understand my local environment automagically becoming "brittle".
I assume things may break after pdate on trash operative systems without an official package manager like Windows or Mac, but other than that...
We used to write COBOL using thin client on mainframes. Then we moved to development locally.
[1] https://github.com/svanderburg/disnix
[2] http://hydra.nixos.org/job/disnix/disnix-trunk/tarball/lates...
I've been using Sublime Text for a decade and it has kept the scope creep to a minimum. I've also used JetBrains IDEs and while there is a massive amount of complexity, it is well organized I think. I just get anxiety from launching VSCode, may be it is because of not being familiar with it, I don't know.
The configuration also syncs itself if you login with GitHub, so you're not going to keep having to do this or juggle files around.
In reality it's not that different from juggling around dotfiles and the various configurations that go into other software.
In VSCode (VSCodium to be more specific) I very rarely need to configure things.
From my doffiles git log - two config changes this year so far.
What kills it for many people though is the ability to access the files from the build. Does anyone know how I could mount the “dist” folder locally or somehow sync it? If I can do that I’m set.
You can also use https://code.visualstudio.com/docs/remote/containers to run an identical container locally to reproduce the environment, and then connect to it.
Visual Studio Code is great. It’s the primary tool GitHub.com engineers use to interface with codespaces. But asking our Vim and Emacs users to commit to a graphical editor is less great. If Codespaces was our future, we had to bring everyone along.
Happily, we could support our shell-based colleagues through a simple update to our prebuilt image which initializes sshd with our GitHub public keys, opens port 22, and forwards the port out of the codespace.I read that as you can ssh in and run a terminal-based editor, but that doesn't seem to offer much support for people looking to edit in NEdit or Intellij or Atom or Sublime or whatever else. Maybe some of those could be supported by forwarding an XSession out of the image, but that's going to suck hard for people on macOS whose editor is now the Linux/X version, with all of the attendant mismatch.
What do vim and emacs have to do with the shell?
This is another case of people thinking "shell" is synonymous with "TUI", which is false.
"Visual Studio Code is great. It’s the primary tool GitHub.com engineers use to interface with codespaces. But asking our Vim and Emacs users to commit to a graphical editor is less great. If Codespaces was our future, we had to bring everyone along.
Happily, we could support our shell-based colleagues through a simple update to our prebuilt image which initializes sshd with our GitHub public keys, opens port 22, and forwards the port out of the codespace.
From there, GitHub engineers can run Vim, Emacs, or even ed if they so desire."
Though a lot of people seem to have issues with FUSE filesystems.
Maybe the cheaper, simpler, option is just to buy a performant desktop for less $$$ than has wall current and the space for RAM and heat dissipation.
I don't like the one IDE per repo model, but I like VSCode more than Cloud9.
It would just be cooler if it would still work when I go offline. Working in a train is simply no fun.
Hope there be an automated checker to catch these things.
The article never explains what "macOS model" actually means. Could someone enlighten me?
How does the billing work when I'm not using Codespaces? Does the VM stop automatically after some time idling or do I have to manually pause it to stop billing?
Github has the best part of 10 critical outages every month. It's a surprise when it doesn't go down.
Is it possible to get a 10Gbe link to Github ? That would bring down the clone time to 10 seconds.
I have a blazing fast development computer already. Also, it only takes a few seconds to push changes to a repo.
Maybe if I were highly mobile, but otherwise, this is a nope.
Also, IP much?
Well, if a company pays - then, maybe it's attractive for some. But not for those who love the real power of the real IDE :)
> But in another sense, it makes him more dependent. The burden of paying attention to his oil level he has outsourced to another, and the price he pays for this disburdenment is that he is entangled in a more minute, all-embracing, one might almost say maternal relationship with . . . what? Not with the service technician at the dealership, at least not directly, as there are layers of bureaucracy that intervene. Between driver and service tech lie corporate entities to which we attribute personhood only in the legal sense, as an abstraction: the dealership that employs the technician; Daimler AG, Stuttgart, Germany, who hold the service plan and warranty on their balance sheet; and finally Mercedes shareholders, unknown to one another, who collectively dissipate the financial risk of your engine running low on oil. There are now layers of collectivized, absentee interest in your motor’s oil level, and no single person is responsible for it. If we understand this under the rubric of “globalization,” we see that the tentacles of that wondrous animal reach down into things that were once unambiguously our own: the amount of oil in a man’s crankcase.
> It used to be that, in addition to a dipstick, you had also a very crude interface, simpler but no different conceptually from the sophisticated interface of the new Mercedes. It was called an “idiot light.” One can be sure that the current system is not referred to in the Mercedes owner’s manual as the “idiot system,” as the harsh “judgment carried by that term no longer makes any sense to us. By some inscrutable cultural logic, idiocy gets recast as something desirable.
> It is important to understand that there has been no “high-tech” development such that it is no longer important to stay on top of oil consumption and leakage. With enough miles, oil is still consumed and will still leak; running low on oil will still trash the motor. There is nothing magical about the Mercedes, though such a superstition is encouraged by the absence of a dipstick. The facts of physics have not changed; what has changed is the place of those facts in our consciousness, and therewith the basic character of material culture.
Shop Class as Soulcraft: An Inquiry Into the Value of Work by Matthew B. Crawford
Could be a good alternative to buying new MacBook
This is totally separate from the gist of this post, but I personally think companies should optimize this number into the ground. It would be awesome to join a microservices company that has an install/running time of 15 minutes. If some company had that level of speed, it would mean developing new features is probably pretty fast too. Not necessarily, but one of the biggest obstacles I think most developers face is not running the entire stack locally. Instead in a lot of companies they commit/push things to a branch and tell their CI/CD to build it out. While that might be useful in some companies, I think the ultimate awesome sauce for a development team is entire product running and editable locally.
> Today, GitHub is making Codespaces available to Team and Enterprise Cloud plans on github.com. Codespaces provides software teams a faster, more collaborative development environment in the cloud. Read more on our Codespaces page.
Links to https://github.com/features/codespaces
It's called "reading"