Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)T
Posts
0
Comments
422
Joined
3 yr. ago

  • There are definitely things to say against AI, but the anti-AI crowd can sometimes be incredibly short sighted and assholishly militant.

    I'd both-sides this except that one side has to constantly fix the other side's mass-produced garbage-on-demand while their management continues to shrink the resources and time available to do both that and their own job.

    Sure, you can responsibly use AI, and creating an environment for that would generally be a good thing. That ignores the reality of the world we live in though, and it's easy to understand why people are exhausted over the artificial hype and want their spaces to remain untainted by it.

  • uutils is rewritten by a corporation? Huh, TIL. I guess their website is wrong:

    uutils is a community-driven, open-source effort maintained by volunteers around the world. There is no company behind it, just contributors who care about the future of foundational command-line tools.

  • Plus, you ALREADY own your code, by nature of it being DRM-free.

    You also own it from a copyright perspective. Any code you write yourself is your own, and GitHub is only given a license to use it when you choose to upload it there (and if you use GH Copilot I guess). You are free to copy and distribute your own code however you want with no regard to anybody else's wishes. You may even choose to charge money for access to your code if you want.

    The two are completely incomparable. Still, it's a well-deserved jab at Sony, though somewhat of a pot-and-kettle situation when accounting for MS as a whole.

  • I wouldn't take it as far as paying allows demands.

    Neither would I.

    Paying implies exchanging money for something the other party is selling, and would require the other party (the maintainer) to sell it. Shoving $20 in someone's face is a donation, not a payment.

    I just refused donations for myself. I would never claim a donation gives someone any special right to demand something.

  • Having been on the maintainer side of a popular project once before, I've pretty much just taken the mindset of "if you owe them nothing, then they owe you nothing". Basically, pay them, or stop making demands (though suggestions and bug reports are usually welcome by maintainers).

    Incidentally, this is why I didn't accept donations for that project (though I have nothing against donations in general, of course). I didn't want to even feel a sense of responsibility to maintain a project I knew I'd eventually burn out from.

  • runtime for real-time voice AI agents (phone + WebRTC)

    Oh boy, my favorite...

    It's a clean-room counterpart to pipecat's architecture, but native Rust

    If by "clean-room" you mean "I had an AI extract the API and another reimplement it" solely with the intent of changing the license (which was already BSD-2 anyway), then you give credibility to the "they rewrote in Rust to change the license" crowd, which might actually bother me more than anything else. Plus, there's no guarantee that the LLM didn't know anything of the original implementation (which is a public GitHub repo... no chance in hell the LLM wasn't trained on it), and I find it unlikely that you didn't reference Pipecat if you did this by hand (something tells me that's not the case).

    not end-to-end voice latency — that's provider-bound

    Genuine question, though somewhat off-topic: I have a method of doing this on my phone keyboard and, via a certain key combination, my desktop, but I'm curious about your method. What method do you use to type an emdash?

  • Seems I'm not the only one who was impressed by the response time opening an issue on the Rust repo. The bug I opened wasn't even critical. It's amazing how fast they fix them, honestly.

  • But, he asked, shouldn't its hidden functionality be treated as a bug or behavior that should be patched out ""to restore the application's neutral and intended functionality for all users equally?""

    The intended functionality is very clearly not "neutrality", and this is very obviously not a bug. Free software does not need to be neutral, and has no obligations to be so. If it were truly an egregious change, I'm sure it'd be possible to rally the community around a fork of the software with the problematic content removed. I don't think there will be a lot of community support around removing this change, though.

  • If you know a faster/better way to sort byte arrays in Java/Clojure let me know!

    I don't know much Clojure, but this should be doable in Java. I would be interested in seeing the results of sorting the data via both quicksort and heap sort. I'm not sure what sort Clojure defaults to, but if the distribution of IDs is uniform, then I'd imagine the downsides of heap sort are pretty much universal to all sorts you're likely to use, which makes it more interesting here to me.

    At the very least, Clojure's docs seem to say that sort is stable, which isn't needed here (we know all IDs are unique). You can probably gain performance just by switching to a performant unstable sort, just in general.

  • With computer languages, we define colors with red, blue, and green.

    It's actually more complicated than this. We specify a color space, then define the color through parameters relevant to that color space. For example, it's not uncommon to define a color in CSS in Oklab, which could look like 40.1% lightness at (0.1143, 0.045). It's also common to define colors relative to other colors. Color space is also not just "well this value maps to this other value in RGB". Different color spaces represent different spectrums of visible light, and you can represent colors in one space that you can't in another space.

    So "when does green become black" is even more complicated to answer.

    Ambiguity is a bitch. Usually when it comes down to "is this color X or Y", the follow-up question is "does the foreground have a contrast ratio of at least 4.5:1 against the background". If not, then whether the color is X or Y doesn't matter. You need a different color.

    Anyway, natural language does not map well to machine code. There's too much ambiguity, and you lose out on the chance to answer the questions you didn't specify answers to that come up when actually writing the code yourself. An interactive approach would take just as much effort as just writing the code itself.

  • Imagine this: instead of reading other people's code and then trying to parse their intentions form [sic] it, you read the documentation to understand their intentions and then you read the code. You no longer have to strain yourself trying to understand what someone wrote for another audience (the machine). They've already explained it for you.

    The best implementation of this I'm aware of is the Entangled bi-directional tangler. A tangler extracts code from your documentation and distributes it across the appropriate source code files. It's [sic] bidirectionality means you can use it to write code embedded in documentation, but then also edit that code normally which it then propagates back into the code blocks in the documentation. This allows programmers to use existing tooling for testing, refactoring, and code formatting without special support for literate programming.

    The best built-in implementation for this that I've seen is Rust's doctests. You write a block of code in your documentation. Then you run cargo test. The code gets compiled and executed as part of your tests, and panics get reported as failures. You can also mark code blocks as should_panic, compile_fail, ignore, etc if needed.

    I'd love to see tools like this in other languages. Write the docs next to the code, but compile the docs as well and make sure they actually work. This is sort of what Entangled seems to do, but ideally more entangled with the build process.

  • it may be underestimating how tightly coupled syntax and language is.

    From a CS perspective, syntax is a major part of a programming language. A syntax (or formal language) is defined essentially as an alphabet and the sequences of words constructed from that alphabet that are allowed in the language. Programming languages combine the syntax, which can be defined formally through BNF (for example), with the semantics they enforce. Semantics include things like "types", "modules", or even "lifetimes" potentially.

    Where you can try to decouple it is between the syntax and the semantics. In fact, this is not without precedent. For example, the JVM and the CLR both allow arbitrary syntaxes to be compiled and executed on them, and both have many languages that can be seamlessly integrated together that all compile to the same intermediate representation. Here's a project compiling Rust to the CLR if you want an extreme example, though more practical examples for the CLR would be C#, F#, and Visual Basic (which can all use each other's defined types, methods, etc).

    So basically, what you might be looking for is a common "intermediate language" for languages. We actually have one already though, and that's the C ABI. I think a better ABI could exist though, ideally one which allows more information to be shared across boundaries. Still, that's where I'd start looking more into this, maybe with inspiration from the JVM or CLR.

  • AI is used to various extents:

    • Some projects do not use AI. The quality of the project is a direct output of the skill and experience of its developers.
    • Some projects use AI lightly. Where AI is used, developers review the output, and it's not trusted to produce large features or even code at all in some cases.
    • Some projects use AI heavily. These projects generally adopt "move fast and break things" mentality which naturally means they both move fast and break things.
    • Some projects are pretty much entirely AI generated. These projects adopt the "break things" mentality. It's like watching someone jogging in place fall over and break both of their legs, and in the process crush someone's pet.

    For a file manager, I would be careful how much I trust AI output.

  • The row-level locking and SKIP LOCKED seem like appropriate features for a SQL-based DBMS. I find it odd that it's not more common, actually. Even MSSQL doesn't make any promises about locking just a row and might decide to lock a whole page instead, from what I read anyway.

    NOTIFY/LISTEN might be scope creep though. I'm not really sure what led to it being implemented.

  • Is it good despite the LLM marketing on the front page? That turns me away whenever I look at it, but I'd be willing to try it if it doesn't shove LLMs down my throat.

  • Of course there's a command for that.

  • I swear Postgres always has new features whenever I look at it again.

    I was building a system for long running durable job queues with multiple workers and of course Postgres has a solution for that. You can do row-level locking in a transaction to "reserve" jobs for the duration of that transaction, and you can use SKIP LOCKED to skip over reserved jobs so workers don't block each other. There's also LISTEN and NOTIFY if you want pub/sub to track when jobs complete, for example.

  • I got linked this somewhere else and made it about halfway. Skip the video, go to the bottom of the description, and open the sources list. You're better off just reading those directly.