401–410 of 427 posts
Earlier quoted context omitted.
I short the stock of companies whose leadership is wasting time posting to LinkedIn instead of… y’know… leading their org. The more they post the more I short. Similarly, the less-attached-to-reality the post is the more I short. I wish I could say I’m making bank off this strategy - but pretty-much all the slopposters (and the most insufferable of the AI boosters) are all working for nonpublic firms, oh well.
Maybe not a winning strategy because a lot of public companies have a comms team that manages the CEO’s LinkedIn. Thereby saving the valuable time of the CEO themselves.
Right; and those PR/comms/social-media-managers know better than to post LLM slop to LinkedIn.
I'm failing to understand the criticism here Is it about the haphazardous deployment of AI generated content without revising/proof reading the output? Or is it about using some graphs without attributing their authors? if it's the latter (even if partially) then I have to disagree with that angle. A very widespread model isn't owned by anyone surely, I don't have to reference newton everytime I write an article on g…
Other than that, I find this whole thing mostly very saddening. Not because some company used my diagram. As I said, it's been everywhere for 15 years and I've always been fine with that. What's dispiriting is the (lack of) process and care: take someone's carefully crafted work, run it through a machine to wash off the fingerprints, and ship it as your own. This isn't a case of being inspired by something and buildi…
Earlier quoted context omitted.
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 sourc…
I know there are monorepo tools out there that do things like automate partial releases include building the git tag names and helping you you get release trees, logs, and diffs when you need them.
I think a lot of monorepo work is using more domain specific release management tools on top of just git.
Also, yeah, my personal preference is to avoid monorepos, but I know a lot of teams like them and so I try my best to at least know the tools to getting what I can out of monorepos.
Earlier quoted context omitted.
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.
This passage from the post by the original creator of the diagramme summarises our Bruh New World: "What's dispiriting is the (lack of) process and care: take someone's carefully crafted work, run it through a machine to wash off the fingerprints, and ship it as your own. This isn't a case of being inspired by something and building on it. It's the opposite of that. It's taking something that worked and making it wor…
This here is just so cheap, I would not even dare to call it a copy.
Earlier quoted context omitted.
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 sourc…
I understand the low level details of why tags don't work that way and why git leaves that "partial release" or "subtree release" as a higher level concept for whoever is making the tags in how they want to name them. I know there are monorepo tools out there that do things like automate partial releases include building the git tag names and helping you you get release trees, logs, and diffs when you need them. I th…
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…
If what they described is "trunk based development", then "git flow" is just "trunk based development where the trunk is called develop and there's a branch which always has the latest release". Is that it?
Earlier quoted context omitted.
I understand the low level details of why tags don't work that way and why git leaves that "partial release" or "subtree release" as a higher level concept for whoever is making the tags in how they want to name them. I know there are monorepo tools out there that do things like automate partial releases include building the git tag names and helping you you get release trees, logs, and diffs when you need them. I th…
Do you have any examples of tooling like that, providing the monorepo tiling on top of git's porcelain so to speak? I had assumed that most of such tooling is bespoke, internal to each company. But if there's generic tooling out there, then I agree, it's useful to know such.
I found someone else's list of well known open source tools (in the middle of a big marketing page advertising monorepos as an ideal): https://monorepo.tools/#monorepo-tools
That list includes several I was aware and several I'd not yet heard of. It's the cross-over between monorepo management tool and build tool is. It's also interesting how many of the open source stacks are purely for or at least heavily specialized for Typescript monorepos.
I don't have any recommendations on which tools work well, just vaguely trying to keep up on the big names in case I need to learn one for a job, or choose one to better organize an existing repo.
I think this just show how plaigarize-y LLMs are. There has been a lot recently about how easy it is to get a model to generate entire books to 98%, and this shows how the same can be done with images. Prompt it the right way, and you can get shitty copies of anything it was trained on. Really shows how little (none?) new content is actually being created, and how much is basically just lossy compression (with really noisy decompression) of the training corpus.