Skip Navigation

Posts
13
Comments
390
Joined
3 yr. ago

  • Why not find a way to automate this,

    Why not find a way to automate every single change that the vscode team makes that may break something?


    Or why not let users do whatever?

    Ultimately, users can do whatever.

    But when they need help, they come to me.

    I have a recommended list of settings for things that should already be defaults, to guide them away from footguns, and to prevent themselves from needing my help in the first place. But I also sometimes need to go around with a critical (usually temporary) list of changes for when a vscode update truly borks something up.

    My concern was potentially needing to go around the office once a month for those critical fixes to once a week.

    This is why I suggested multiple release channels. Have a weekly release for developers who are okay with the trade-off of more frequently broken setups for newer features faster, and have a monthly release for developers who want more stable environments.

    It'd be a lot easier for me to run the weekly channel to be kept abreast of any changes, and I can support other coworkers on a monthly cycle.

  • You’re way quicker manually reviewing code compared to setting up everything just so that an LLM agent could do that.

    Not only that, you're better off reviewing the code manually so you understand how everything works.

    If you understand how things work, you can plan things out.

    If you don't, you'll end up painting yourself into a corner.

    If you are scared of that, commercial products are your choice.

    Commercial products are not a panacea for bad software quality.

    Code openness and code quality are independent, orthogonal axes.

  • Probably a good time to consider helix or ki over vim

  • If the code is reviewed and tested, I don’t care if it was written by a human or machine.

    That's a pretty big assumption there buddy.

    If they didn't care enough to write the code, what makes you think they cared enough to review or test the code?

  • Not exactly,

    They said that they APIs were copyrighted, and that the way that Google had reimplemented the API fell under fair use doctrine (the original work was still copyrighted and they were allowed to use it without authorization).


    As for using an LLM to reimplement a program, you're going to end up with a derivative work which can only be created/authorized by the original copyright holder. If you don't have the authorization, you are infringing on someone else's copyright.


    If however, you used an LLM to read a program's source code, sort each word alphabetically then output the result, you're going to have something that while based on an original copyrighted work no longer functions as a program. It has been transformed to such a degree that it is considered a transformative work, and thus falls under the fair use doctrine.


    TL;DR: Simply getting an LLM to regurgitate source code back out to you does not remove the licence of the original source.

  • Why the fuck do their help videos have motion blur?

    What's next? Shaky cam?

  • No!

    PopOS switched to Cosmic which only just came out.

    Recommend PopOS to users with experience, who know how to fix/avoid problems.

    But, hold off from recommending PopOS for beginners until around the 27.10 release when most of the papercuts are sanded over.

  • although I’m a little bit skeptical about having to integrate additional extensions and workflows

    Just to allay your fears, it's not a mishmash of random extensions and brittle workflows.

    11ty was originally built in a more all-in-one box style, but it was kind of annoying to have 10+ templating languages to choose from (and all the dependencies that came along with them), when you only wanted one.

    Every update, the author does two things:

    1. Splits more functionality into first party plugins
    2. Removes, or forks and takes over third party dependencies.

    You can see that here: (data taken from here: https://www.11ty.dev/blog/dependency-watch/#full-history)

    VersionDeps (3rd-party)Changenode_modules SizeChange
    v0.2.0 (2018 January) First npm release!×401 (400)n/a51 MiB-
    v0.12.1 (2021 March)×362 (360)-9.70%68 MiB+33.30%
    v1.0.2 (2022 August)×360 (357)-0.50%71 MiB+4.40%
    v2.0.1 (2023 March)×213 (208)-40.80%35 MiB-50.70%
    v3.0.0 (2024 October)×187 (174)-12.20%27 MiB-22.80%
    v3.1.2 (2025 June)×134 (123)-28.30%21 MiB-22.20%
    v4.0.0-alpha.1 (2025 July)×130 (116)-2.90%16 MiB-23.80%
    v4.0.0-alpha.6 (2025 December)×105 (89)-19.20%14 MiB-12.50%

    The first-party plugins are all compatible with each other and all use the same 11ty config with the same sensible defaults, and 11ty is built with all of the first-party plugins in mind.

    You can add them all in if you still want the all-in-one-box approach, but this way lets your environments be smaller.

    It's basically pre-computed tree shaking.

    There's also a security argument for it. By splitting everything apart, you isolate security issues. If one of the random 10+ templating languages got a security issue (e.g. supply-chain attack, redos, misglobbing, etc...), it will only affect the projects that decided to use that templating language.

  • I haven't used Hugo.

    I went with 11ty a few years ago because I wanted to stay as close to the actual web standards as possible (so, HTML/CSS/JS).

    The main reason why is that every additional abstraction layer and every invocation of "magic", is just extra hidden complexity which makes things harder to debug, extend, and maintain.

    Having a SSG in go/python/rust would have been an extra layer.

    The "maintain" point above is something most others don't think about until it comes back to bite them. Nothing is more frustrating than reopening a project that worked fine a few years ago, and even though you haven't changed anything, nothing works, and when trying to update it you end up with Frankenstein's monster.

    11ty went out of it's way to remain as simple as possible. Here's your input directory, and here's your output directory. That makes the maintenance and backwards compatibility really easy.

    Then you can add the minimum required complexity/abstraction layers only when you need them.


    In my case, I use:

    • liquid template language, so I only have to write a layout once (header, footer, accessibility landmarks) and every page uses it by default.
    • my own custom extension that adds the build time in a html comment for debugging purposes
    • markdown (so content creator coworkers can create pages)
      • The project is set up in such a way where coworkers can write markdown in vscode, and see a live preview within vscode (using it's own markdown renderer)


    I'll say the one thing I don't like about 11ty is that it's written in js, not ts. The author is all about simplicity and reducing layers of complexity. But now typescript has a typescript-lite version with the erasableSyntaxOnly flag, which basically allows it to run on node (deno and bun already ran typescript), so the next version (or one after), may be migrated to typescript.

  • The --self-extracting flag in deno compile --self-extracting looks awesome.

    I could compile my 11ty stack into a single executable that I could send anywhere, but it would still be able to read external markdowns so semi-technical coworkers can make content changes without the maintenance overhead of a CMS and without the coworkers needing to learn modern web dev.

    It would also be super awesome for all the internal tools I've built that need to run offline.

  • CSS has been considered turing complete for a long time.

    So this isn't a shocking revelation, but it is cool.

  • Fork.dev on Windows and Mac

    • GUI using native APIs, no electron
    • It's free the same way that sublime text and winzip are. It asks about once a month if you want to pay and you can keep clicking "I'm still trying it out".
    • Normal git cli is powerful but with a terrible UI with terrible defaults.
      • To use the best commands you need to add a ton of flags to get what you want, or add a whole bunch of aliases and port them between machines.
        • e.g. git log vs git log --graph --all --remotes --decorate
        • e.g. git fetch vs git fetch --prune --all
        • e.g. git stage -p vs nothing (git cli still doesn't have a good way to specify lines correctly, only hunks that can't be split properly)

    Fork.dev is just what you get when the defaults are set up correctly by default, with more powerful control over staging, and with automatic branch/stash backups whenever your doing risky actions.

    The only thing it doesn't have built in support for is git log -S for when you're searching for a specific file or commit and don't know the file or commit, but know a substring in the commit itself. But it doesn't matter since you can add that as a custom command into fork.dev

  • It's going to be right next to Cavil Ave, the bar and club tourist road!

    Just imagine all the schoolies and just tourists in general taking a shit on the front steps of any building with trump in the name.

    There's so many tourist drones flying every night, you're going to get FPV drones launching bags of dog shit, buckets of paint, and spray painting giant cocks on the side of the building.

  • Gold Coast mayor says he looks forward to considering a ‘formal development application’

    Maybe, maybe not.

    Tom Tate has a history of being an utter whore for real estate developers.

    He'd slather himself in horse diarrhea with a smile on his face if he thought it would get him a new bribe.

    But an association with Trump might shock enough people to give him a hard chance to get re-elected.

    So he's probably considering if he can get a big enough bribe to retire so it doesn't matter if he doesn't get back in.

  • Bruh, just click the reader button on your browser.

  • It's a garbage article.

    It's not checking other's claims, it's not saying anything new, it's not even listening to the majority of the parties.

    For each of the parties (node, deno, bun): they are incentivised to only release benchmarks that make themselves look good, and are disincentivised to release benchmarks that make themselves look bad.

    This article only uses benchmarks from one party then declares it the winner.

    So, it's garbage.

  • I don’t see any products or services being promoted in this article.

    That's kind of the point. You're not supposed to.

    They're farming links so search engines see their domain as more important. That way, their entry will appear higher up on search results against competitors for their paid products.

  • I’m just not going to watch

  • One of the possible reasons was too much sun power and not enough demand. Solar and wind are unreliable.

    No.

    The issue wasn't that there was too much generation, or that it is unreliable.

    It was a grid issue, it wouldn't have mattered what generation was used (solar, wind, gas, nuclear, coal, etc...).

    Don't be mislead by everyone who jumped on the coal bandwagon a day after the incident before we even knew what the cause was.