361–370 of 585 posts
Earlier quoted context omitted.
Whenever I have to start windows 10, I still see the same kind of bugs, that were present on XP. One example: They seem to be simply unable to fix the icons "near the clock", which are still shown, when some app has been killed, until you hover over them. Things like that, but of course also lots of stuff that affects people more in form of annoyances, making every action take at least twice as long as on GNU/Linux d…
One similarly ignored bug that springs to mind is the performance of the "Send To" context menu item in File Explorer. I always dreaded dragging my mouse over it by accident.
I'm pretty sure there are a lot of those.
This isn't very compelling to me. SourceForge went bad ... and everyone left. That doesn't seem like a bad thing and there's no reason for me to think any given site / service will or won't go bad too. I expect that for any number of reasons I might need to move from one site to the next. The rest too is kinda hollow to me. The fact that they're for profit doesn't upset me. I figured they wanted to make a profit when…
It's been years, but as I remember it SourceForge's primary downfall was the bundling of malware with binaries. That's why people I know stopped using it completely rather than because it was run on a proprietary platform.
And then it killed itself in its confusion.
Earlier quoted context omitted.
GitLab, with its runners is a more than a decent alternative, which you can also host yourself, with really minimal effort.
The last thing I want to do is host it myself.
So you provide the system, it hosts itself.
Earlier quoted context omitted.
At least a year ago in Azure that wasn't true; everyone had access to nearly every internal service's code (+the windows kernel). Though there were some exceptions (the Teams team didn't want to share their source at all for whatever reason).
> the Teams team didn't want to share their source at all for whatever reason Because it probably mines one bitcoin block every time you click on something. No sane codebase could possibly be so abysmally slow.
> If it is, as you claim, permissible to train the model (and allow users to generate code based on that model) on any code whatsoever and not be bound by any licensing terms, why did you choose to only train Copilot's model on FOSS? For example, why are your Microsoft Windows and Office codebases not in your training set? This is my favorite question about Copilot ever.
I want to know what stuff you guys are putting in public GitHub FOSS repos that you don't want replicated in any way... I also want to know why people think their code is so special that no one else could have ever come up with it independently. Each and every opponent of Copilot is the best developer ever, I guess? That said, I don't understand the choice to use GPL for any reason, so maybe I'm not equipped to under…
I'm worried about exactly the opposite: having Copilot help me write code that seems quite generic to me, but which in fact makes my code subject to a license I don't even know about, and/or simply violates copyright.
For an open-source project this could be embarrassing but probably fixable. It gets more complicated if FAANG is doing due diligence on your company. I can see Copilot being both an accelerant and, later, a liability for startups.
Earlier quoted context omitted.
Until you make the slightest mistake and your work area gets into a state not covered by the cheat sheet. But of course, the standard recommendation seems to be just to remove the work area and check it out again :p
Well you can always for help from a co-worker more experienced with Git, or just search the internet for help. That could be a teaching moment.
Given the context of this thread, comments like these are part of the reasons teams don't use Git.
One probably needs 10x such teaching moments with Git compared to other VCs - including good DVCS.
Earlier quoted context omitted.
To be fair, most people who find it complex do so because Git has a very crappy UI. You don't need to understand the internals to use Mercurial, and I would imagine that's true for most other DVCS's. In that sense, I sympathize with them. I'm pretty sure half of the teams that find Git too complex wouldn't find Mercurial to be complex. But they haven't heard of Mercurial.
I'm the guy people at $work call to do git submodule reorganization, troubleshoot lfs or recover disasters. I'm certainly comfortable with git. It gets the job done. The same can be said of svn. However my own projects always start with hg init. In addition to the UI being less insane it also feels consistent and nice to use. At one point I was on a team using Darcs, which was another level of beautiful but clunky in…
This article doesn't compel me to give up github. It seems like it basically talks a lot about how proprietary software is evil and then complains about Copilot. Then it drops this: > GitHub's business model has always been “proprietary vendor lock-in”. How is this Github's business model? Unless you're using Github specific features like Github actions and workflows, it's fairly easy to switch to another Git based h…
> if you want to convince people to give up Github you should at least be prepared to give an alternative that offers a great deal of feature parity.
These can't both be true. In fact Github is hard to switch away from, because of all the Github features. This is the lock-in. Github then monetizes this by charging for large files (https://docs.github.com/en/repositories/working-with-files/m...), private repos, etc. So the SFC argument is that you should switch away from Github now and get the alternatives to feature parity, to avoid Github getting a monopoly.