Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15 years later, Microsoft morged my diagram

nvie.com

Post reply on HN
Print view View original

321–330 of 427 posts

Re: 15 years later, Microsoft morged my diagram

#321

Post by dh2022 »

oytis wrote: post #265
Animats wrote: post #59

This is so out of hand. There's this. There's that video from Los Alamos discussed yesterday on HN, the one with a fake shot of some AI generated machinery. The image was purchased from Alamy Stock Photo. I recently saw a fake documentary about the famous GG-1 locomotive; the video had AI-generated images that looked wrong, despite GG-1 pictures being widely available. YouTube is creating fake images as thumbnails fo…

Youtube has recently recommended me a video of Feynman allegedly explaining why we couldn't go to Mars and back. I am normally on Youtube for something specific and don't follow recommendations, but hey, it's Feynman and I haven't seen it before, so I had to watch. After a few seconds it has become very clear that the video is totally fake. Then I started digging, and it turned out that both voice and the text it say…

One of these videos was referencing a problem with one of the Mars landers. Feynman died in 1988, long before the landers were even on the drawing board.

Re: 15 years later, Microsoft morged my diagram

#322

Post by jimmaswell »

arduanika wrote: post #181
jezzamon wrote: post #3

"continvoucly morged" is such a perfect phrase to describe what happened, it's poetic

Decades upon decades of hard work by public contributors -- open source code, careful tech blogging, painstaking diagrams -- all of it will be assimilated without credit or accuracy into the morg. Resistance is futile.

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, and I've built some great things, but the slow, careful, painstaking drudge-work parts were always the biggest motivation-killers. AI is worth it at any cost for removing the friction from these parts the way it has for me. Days of work are compressed into 20 minutes sometimes (e.g. convert a huge file of Mercurial hooks into Git hooks, knowing only a little about Mercurial hooks and none about Git hooks re: technical implementation). Donkey-work that would serve no value wasting my human time and energy on when a machine can do it, because it learned from decades of examples from the before-times when people did this by hand. If some people abuse the tools to make a morg here and there, so be it; it's infinitely worth the tradeoff.

Re: 15 years later, Microsoft morged my diagram

#323

Post by duxup »

There's a lot of "bad look" things that aren't a big deal.

But man this one indicates such a horrible look / lack of effort (like none) from Microsoft.

Not that Microsoft is short on bad looks, but this really seems like one of those painfully symbolic ones.

Re: 15 years later, Microsoft morged my diagram

#324

Post by duxup »

yoz-y wrote: post #47
nippoo wrote: post #7

They've taken it down now and replaced with an arguably even less helpful diagram, but the original is archived: https://archive.is/twft6

Wow it’s even worse than I thought. I thought that convictungly morhing would be the only problem. The nonsense and inconsistent arrowheads, the missing annotations, the missing bubbles. The “tirm” axis… That this was ever published shows a supreme lack of care.

It really is wild / telling how fundamentally AI can screw up what seems like just basics like ... an arrow.

Re: 15 years later, Microsoft morged my diagram

#325

Post by jimmaswell »

rzmmm wrote: post #97
nippoo wrote: post #7

They've taken it down now and replaced with an arguably even less helpful diagram, but the original is archived: https://archive.is/twft6

It looks like typical "memorization" in image generation models. The author likely just prompted the image. The model makers attempt to add guardrails to prevent this but it's not perfect. It seems a lot of large AI models basically just copy the training data and add slight modifications

> It seems a lot of large AI models basically just copy the training data and add slight modifications

This happens even to human artists who aren't trying to plagiarize - for example, guitarists often come up with a riff that turns out to be very close to one they heard years ago, even if it feels original to them in the moment.

Re: 15 years later, Microsoft morged my diagram

#326

Post by PaulDavisThe1st »

nancyminusone wrote: post #317
oytis wrote: post #265

Earlier quoted context omitted.

Youtube has recently recommended me a video of Feynman allegedly explaining why we couldn't go to Mars and back. I am normally on Youtube for something specific and don't follow recommendations, but hey, it's Feynman and I haven't seen it before, so I had to watch. After a few seconds it has become very clear that the video is totally fake. Then I started digging, and it turned out that both voice and the text it say…

YouTube must be absolutely flooded with this stuff. I clicked on one about Henry the 8th, which is a story Ive heard heard 100 times but whatever. It started out normal enough, then claimed he started carrying around a staff with a human skull on the top near the end. Made up artifacts and paintings. The most egregious has to be the "World War II mechanic fixes entire allied plane arsenal with piece of wire" category…

> YouTube must be absolutely flooded with this stuff.

I don't know what the current upload rate to YT is, but this seems unlikely. Despite the reckless and insane energy consumption associated with generative visual and audio art forms, there's no way there's enough power available for generative stuff to overwhelm the "actually recorded digital video" uploads.

Are there some niches on YT where this is true? Seems possible. YT overall? Nah.

Re: 15 years later, Microsoft morged my diagram

#327

Post by WorldMaker »

dsego wrote: post #229
embedding-shape wrote: post #150

Earlier quoted context omitted.

> Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done. That's what tags are for, QA tests the tagged release, then that gets released. Master can continue changing up until the next tag, then QA has another thing to test.

Can I tag a bugfix that goes in after a feature was already merged into main? Basically out of order. Or do I need to tag the bugfix branch, in which case the main branch is no longer the release, so we need to ensure the bugfix ends up in the remote main branch as well as the release. Seems like it could cause further conflicts.

git doesn't care what order or from which branch you tag things in. If you need to hotfix a previous release you branch from that previous release's tag, make your bugfix and tag that bugfix then merge the whole thing back to main.

Presumably you are maintaining the ordering of these releases with your naming scheme for tags. For instance, using semver tags with your main release being v1.2.0 and your hotfix tag being v1.2.1, even while you've got features in flight for v1.3.0 or v1.4.0 or v2.0.0. Keeping track of the order of versions is part of semver's job.

Perhaps the distinction is that v1.2.0 and v1.2.1 are still separate releases. A bug fix is a different binary output (for compiled languages) and should have its own release tag. Even if you aren't using a compiled language but are using a lot of manual QA, different releases have different QA steps and tracking that with different version numbers is helpful there, too.

Re: 15 years later, Microsoft morged my diagram

#328

Post by zamalek »

whoknowsidont wrote: post #300
iainmerrick wrote: post #200

Earlier quoted context omitted.

You’re right. I think what you’re describing is “trunk based development” and it’s much better. Maybe I’m overly cynical but I think git-flow was popular largely because of the catchy name and catchy diagram. When you point out that it has some redundant or counter-productive parts, people push back: “it’s a successful model! It’s standard! What makes you think you can do better?” There’s a nice write-up of the trunk…

> but I think git-flow was popular largely because of the catchy name and catchy diagram. It was because Git showed up in the era of SVN / CVS where those branching models were created because of the uh... let's just call it technical mishaps of those source control systems. Git did not have the hang ups of SVN / CVS / etc but people stuck with what was familiar.

Yup, there would have been much less Git buy-in if it weren't for git flow; people grow incredibly attached to their beloved taxonomies.

Re: 15 years later, Microsoft morged my diagram

#329

Post by pragma_x »

m12k wrote: 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…

I can't say that I've used gitflow in hate. That said, I always saw the full complexity of the approach to address tracking multiple concurrent releases of a product. It's extremely uncommon in our increasingly SaaS world, but I imagine having so many branches with commits moving laterally between them to be invaluable for backporting security fixes and the like.

For the rest of us, trunk-based development with feature/fix branches is more than enough.

Re: 15 years later, Microsoft morged my diagram

#330

Post by WorldMaker »

globular-toast wrote: post #235
choeger wrote: post #144

Earlier quoted context omitted.

I am working with main/master for years now, and there's one problem you don't have with develop: Whenever you merge something into master, it kind of blocks the next release until its (non-continuous) QA is done. If your changes are somewhat independent, you can cherry-pick them from develop into master in an arbitrary order and call that a release whenever you want to.

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 more complicated, but not that much more complicated. You just need to `--match project-a/` or `--match project-b/` when you want `git describe` for a specific project.

Post reply on HN