Live data from Hacker News

15 years later, Microsoft morged my diagram

nvie.com

371–380 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#371

Earlier quoted context omitted.

Good - we've been building the seed corpus for AI the past 50 years, and all this manual work now becomes exponentially more useful to others who get to build amazing things without all the tedium. I'm personally thrilled if my code made it in to the machine to help others. We laid train tracks by hand so that they could invent a machine to do it and we can focus on the destination. I've been coding for over a decade…

IMO this would be a much more sensible reply to a different post, not one about a chart that unironically contains the words "continvoucly morged"

Yeah, I felt kind of bad that he gave me such an earnest, thought-out reply to what was essentially a stupid morg/borg joke. But his final sentence suggests that he at least got my joke.

(I don't entirely agree with him, but I upvoted for at least trying to get us back on topic!)

Re: 15 years later, Microsoft morged my diagram

#372
post #137

Regarding the original git-flow model: I've never had anyone able to explain to me why it's worth the hassle to do all the integration work on the "develop" branch, while relegating the master/main branch to just being a place to park the tag from the latest release. Why not just use the master/main branch for integration instead of the develop branch - like the git gods intended - and then not have the develop branc…

nvie said as much in 2020 and stuck a big disclaimer at the top of the post https://nvie.com/posts/a-successful-git-branching-model/

Re: 15 years later, Microsoft morged my diagram

#373

Earlier quoted context omitted.

>I don't buy this. It's not really debatable. Git flow came about because of SVN / CVS practices and was the first and for many still is THE branching model they use. >Yet all of us have been using Git for ages You say "all of us" but then you completely ignore the primary branching model the vast, vast majority of people use on Git. Just for the record, this isn't being stated in support of git-flow it's just a hist…

> the primary branching model the vast, vast majority of people use on Git. > it's just a historical fact that's not really debatable. Over my last 15 years of software dev, I have _never_ heard of anyone actually using Gitflow in their codebase. I'm not saying you're wrong. My experience is anecdotal. But I don't know why you say it's a "fact". Was there surveys or anything?

I'm not questioning your experience, but how "enterprise" is that experience? Gitflow was no small part of my convincing my company to move off TFVC. I doubt they still use, but it was shallow waters for scared folk.

I strongly doubt that my story, just as much as yours, is unique.

Re: 15 years later, Microsoft morged my diagram

#374

Earlier quoted context omitted.

There are countless examples. Often I think about the fact that the google search AI is just rewording news articles from the search results, when you look at the source articles they have exactly the same points as the AI answers. So these services depends on journalists to continuously feed them articles, while stealing all of the viewers by automatically copying every article.

I actually often have the opposite problem. The AI overview will assert something and give me dozens of links, and then I'm forced to check them one by one to try to figure out where the assertion came from, and, in some cases, none of the articles even say what the AI overview claimed they said. I honestly don't get it. All I want is for it to quote verbatim and link to the source. This isn't hard, and there is no w…

I have to say, I suffer from both problems, just not simultaneously.

Depending on what I am searching for, and how important it is to me to verify the accuracy and provenance of the result, I might stop at the AI, or might find, as you have, that there is no there there.

But, no matter what, the AI is essentially reducing the ability of primary sources to monetize their work. In the case where the search stops at the AI, obviously no traffic (except for incessant LLM polling) goes to the primary source.

And in the case you describe, identical traffic (your search) is routed to multiple sources, so if one of them actually was the source of something you were interested in, they effectively wind up sharing revenue with other sources, because the value of every one of your clicks is reduced by how often you click.

Re: 15 years later, Microsoft morged my diagram

#375

Earlier quoted context omitted.

A postmortem for that but not Copilot in notepad.exe? Priorities…

I’d also love a post-mortem on their guide to pirating the entire Harry Potter series for AI use. ( https://devblogs.microsoft.com/azure-sql/langchain-with-sqlv... ) I’ve lost trust in anything Microsoft publishes anymore.

[deleted]

Re: 15 years later, Microsoft morged my diagram

#376
post #216

Is this not a good example of how generative AI does copyright laundering? Suppose the image was AI generated and it did a bad copy of the source image that was in the training data, which seems likely with such a widely disseminated image. When using generative AI to produce anything else, how do you know it's not just doing a bad quality copy-paste of someone else's work? Are you going to scour the internet for the…

> What if code generation is copy-pasting GPL-licensed code in to your proprietary codebase? This is obviously a big, unanswered, issue. It's pretty clear to me that we are collectively incentivised to pollute the well, and that it happens for long-enough for everything to become "compromised". That's essentially abandoning opensource and IP licensing at large, taking us to an unchartered era where intellectual works…

> we are collectively incentivised to pollute the well

Honestly, there are two diametrically opposed incentives occurring right now. The one you describe may not even be paramount -- how hard is it to prove infringement, shepherd a case through court, and win a token amount. Is it worthwhile just to enrich a few lawyers, and get more AI-regurgitated slop to open up?

The second incentive is to not publish source code that might be vacuumed up by a completely amoral automaton. We may be seeing the second golden age of proprietary software.

Re: 15 years later, Microsoft morged my diagram

#377
post #214

Earlier quoted context omitted.

LOL, calling Scott Hanselman a 'VP of something' is funny. Been listening to his stuff for years, even when I despised MS. Always seems genuinely nice. Probably one of the main reasons I these days have a more positive image of Microsoft.

Scott is definitely one of the good guys.

I don't this person, but immediately trying to foist blame for a really embarrassing screwup onto a "vendor" does not really sound like "good guy" behavior to me?

Re: 15 years later, Microsoft morged my diagram

#378

Is there a single thing that Microsoft doesn’t half-ass? Even if you wanted to AI generate a graph, how hard is it to go into Paint or something and fix the test? I have been having oodles of headaches dealing with exFAT not being journaled and having to engineer around it. It’s annoying because exFAT is basically the only filesystem used on SD cards since it’s basically the only filesystem that’s compatible with eve…

> Is there a single thing that Microsoft doesn’t half-ass? Nope. TFA writes this: "The AI rip-off was not just ugly. It was careless, blatantly amateuristic, and lacking any ambition, to put it gently. Microsoft unworthy" . But I disagree: it's classic Microsoft. > I have been having oodles of headaches dealing with exFAT not being journaled and having to engineer around it. It’s annoying because exFAT is basically t…

Yeah, I realize other FAT systems work elsewhere too but they're even worse. exFAT is the best portable filesystem.

I really wish the industry had decided on something journaled, as it would make everything better and lead to fewer corrupted files but Microsoft has decided we can't have nice things.

Re: 15 years later, Microsoft morged my diagram

#379

Earlier quoted context omitted.

IMO this would be a much more sensible reply to a different post, not one about a chart that unironically contains the words "continvoucly morged"

Yeah, I felt kind of bad that he gave me such an earnest, thought-out reply to what was essentially a stupid morg/borg joke. But his final sentence suggests that he at least got my joke. (I don't entirely agree with him, but I upvoted for at least trying to get us back on topic!)

Yeah, I knew it was more of a joke comment, I just wanted to put down some thoughts I'd been forming for a while.

Re: 15 years later, Microsoft morged my diagram

#380

Earlier quoted context omitted.

Yes, you have to include QA in the continuous integration process for it to work. That means at any time you can just tag the top of the master branch to cut a release, or do continuous delivery if it makes sense (so no tags at all). It sounds like you are doing a monorepo type thing. Git does work best and was designed for multiple/independent repos.

Even in a monorepo you can tag releases independently in git. git doesn't proscribe any particular version tag naming scheme and stores tags similarly to refs in a folder structure that many (but not all) UIs pay attention to. You can tag `project-a/v1.2.0` and `project-b/v1.2.0` as different commits at different points in the repo as each project is independently versioned. It makes using `git describe` a little bit…

That's true, but git also doesn't have tags that apply to a subset of the repository tree. You can easily check out `project-b/v1.2.0` and build project-a from that tree. Of course, the answer to that is "don't do that", but you still have the weird situation that the source control implementation doesn't match the release workflow; your `git describe` example is but one of the issues you will face fighting the source control system -- the same applies to `git log` and `git diff`, which will also happily give you information from all other projects that you're not interested in.

For me, the scope of a tag should match the scope of the release. That means that a monorepo is only useful if the entire source tree is built and released at the same time. If you're using a monorepo but then do partial releases from a subtree, you're using the wrong solution: different repo's with a common core dependency would better match that workflow. The common core can either be built separately and imported as a library, or imported as a git submodule. But that's still miles ahead of any solution that muddles the developers' daily git operations.

Post reply on HN