My music setup was a pinned browser tab for years. It worked, technically. It also ate RAM doing nothing, my media keys only worked when that tab happened to be focused, and I killed the music at least once a week by closing the wrong window. There’s no official YouTube Music desktop app on Linux, and most of what exists is the same web player in an Electron shell.
So I built my own. It’s called Limusic. Rust and Tauri, no bundled Chromium, audio goes through libmpv.
You sign in with your actual YouTube Music account, so your playlists, likes and subscriptions are just there, and liking a song or adding it to a playlist syncs back like you’d expect.
The part I actually care about is that it’s not bare bones:
- Proper MPRIS, so media keys and your now playing widget just work
- System tray, closing the window doesn’t kill the song, plus play/pause and skip from the tray
- Discord Rich Presence with album art and a live progress bar
- Last.fm scrobbling, connect once and forget about it
- Synced lyrics in a side panel, click a line to jump there
- Listen Together, synced rooms so you and a friend hear the same thing at the same time
- 8 themes, including Catppuccin, because obviously
- Gapless playback, volume normalization, shuffle, repeat, autoplay radio
- Your queue survives a restart
Free and open source, GPL. AppImage (self updating) or an rpm for Fedora, which is what I daily drive. No Flatpak or AUR yet, both are on the list. There’s a Windows build too, and no macOS one yet.
Would really love for people to try it, and I’d genuinely like to hear what everyone thinks. ❤️
Site: https://simohypers.github.io/limusic/ Downloads: https://github.com/SimoHypers/limusic/releases/latest
Not affiliated with Google or YouTube, just a thing I made because I wanted it
Holy shit, it’s great!
I just managed to sit back and finally try the Appimage. I’m loving it. The login flow was easy, the UI is really good, I’m really liking it. There’s ONE thing I don’t like though: the Google login window should open in my default browser. Not the embedded one.
There are security reasons, and then there’s a UX reason: I’m already logged in on my default browser, if it opened in it, I would just have to allow it and that’s it. So, it’s win-win.
What part, if any, does “AI” have in the development or use of this?
from the gitignore:
/.agents/ /.claude/ /CLAUDE.md /PHASE1-PROMPT.md /RELEASING.md /skills-lock.json /plansso probably quite a bit lmao
and from a brand-new account too. this is slop, people
Just because AI was used in the development process doesn’t mean it is bad. Doesn’t mean it’s good either but you can’t just ignore it because AI had something to do with the process. Things being made by humans doesn’t make it good either people can write really bad code.
I think it is the other evidence that it is vibe coded
- Brand new account
- Dev only responds to non-technical or feel-good comments
- other commenters have pointed to AI teltale vibe coding syntax signs in many of the files
- Claude extra files in early commits and changing gitignores to do it.
Advertised Vibe coded projects absolutely are by default bad and here is why:
- Developers do not understand what they have built, so can’t debug it beyond “Claude, fix this”
- Vibe coded projects are easy-come, easy-go very often abandoned (73% of the vibe projects on flathub, and those are the people who thought far enough to decide putting it on flathub was worth it)
- developers can’t answer any questions on security when the app will be handling credentials, be hosted on a server, or attach to some sort of live service -> absolutely gaping security hole that you just have to cross you fingers that Claude didn’t do another “oops, you are completely right to push back,1500 common attack vectors were left open and you are now part of a CSAM botnet, do you want me to fix it?”
If someone wants to make small scripts, one-off test firmware for a home project, writing test cases, design reviews, boilerplates, etc… Are arguably good usecases.
Vibe coding an ongoing software service is almost always a hard no-go and statistically will be abandoned and unupdated, leading to even more security and usability issues.
There’s ponytail comments in the source code, which is a Claude code plugin. Definitely AI-written
If you view the first commit, you can see the
CLAUDE.md, so at least in part vibe-coded.Tbh all the vibe-coded apps look the same, and the UI has that vibe-coded style, so I’m not surprised.
AI use does not mean vibecoded
I didn’t say it did, but also “vibe coding” is a fairly new term that does not have a strict consistent definition anyway.
I’m not sure how else to interpret your comment… You found evidence of AI and concluded its at least partly vibe-coded. As for the definition, no I don’t think its all that inconsistent. Feel free to look it up.
Semantics are defined by how a term is used, and people use the term to refer to AI generation of code in any capacity, as well as stricter definitions. The first commit is not just “evidence of AI”, it’s no code and just a markdown file instructing an LLM, which meets at least some definitions of vibe-coding.
Insisting “a word doesn’t mean X, it means Y” doesn’t make it so. Arguing about definitions can be on one of two premises: the word is in practice used to mean Y and not X, or it’s useful to define the word to mean Y and not X. You’ve argued neither, just made an assertion.
I would say a great part of this code was at least “AI touched”. There are em dashes in the rust scripts, in the markdowns, in the commit messeges. @Simohypers@lemmy.world - disclose your stuff man! people should know what they are putting on their computers
it shouldn’t matter.
these tools are here to stay.
They are here to stay, but stuff built with an LLM is statistically way less likely to be maintained for more than a couple months compared to a hand-written thing. Anecdotally I also feel it’s way more likely to have security issues. So I think it’s important to disclose so people have their expectations set correctly.
Subjective, but I’d also trust it less to not have serious mistakes, such as deleting everything in your home directory. Or unexpectedly running insecure HTTP server on all interfaces.
Or perhaps just having a temporary file stored on SSD which gets written to way too much, causing great wear to the drive. Or slow memory leaks.Just things a human would likely think of.
anecdotally, I’ve built a lot of projects and abandoned them because I ran out of time. With an LLM to reduce the input effort I actually think I would’ve maintained them longer.
do you have a source which backs up what you’re claiming?
Ok, so there’s no statistically rigorous review yet, but 73% of LLM-generated apps submitted to FlatHub were abandoned within 6 months. This is about the abandonment rate you should expect to see on any newly announced LLM-written project, and this figure appears to be much higher than hand-written projects (e.g. this study, while not directly comparable, shows a 16% abandonment rate).
The reason for this is sort of obvious to me: an LLM makes it really easy to write code that makes an app work, therefore the threshold of involvement/interest needed to “make an app” is much lower. This in turn removes the selection force that makes software authors likely to be interested in, and thus put in the effort (or tokens) to maintain their software going forward. (this is putting aside the fact that LLMs are still horrible at software architecture and quite bad at infrastructure, making the long-term maintenance more difficult).
I don’t doubt that some people will have a lot of passion for their vibecoded thing, and will keep it going for a while. This might even be the case here given the author went out of their way to post about it on Lemmy and respond to comments, seemingly without an LLM in the loop at that stage of the process. But it’s also important to disclose your LLM use so others can adjust their statistical expectations.
anecdotally, I’ve built a lot of projects and abandoned them because I ran out of time. With an LLM to reduce the input effort I actually think I would’ve maintained them longer.
Likely you would have also built more projects if you had access to an LLM, thus giving you less time to spend maintaining each individual one. Which is kind of the problem here…
Not the person you’re replying to, but
There are no shortages of evidence showing heavy LLM usage causing cognitive decline.
Likewise, if we accept anecdotal evidence, many users report losing understanding of their codebase after letting an LLM do substantial changes for them. Architecture drift is a common problem, too.
LLMs are trained on public code, much of it subpar, so it stands to reason that they are prone to regurgitating security vulnerabilities.
I am not including the plethora of ethical issues with LLMs, which I assume you do not care about coming from a purely utilitarian although short-sighted perspective.
Nah I’m with this guy. These anti-AI weirdos drive me nuts. Guy writes you a free tool and all they can do is look a gift horse in the mouth.
Guy writes you a free tool and all they can do is look a gift horse in the mouth.
Misunderstanding.
Main point here was that the person should disclose they used LLMs if they did, and to what degree. So, like, one line of text in the README. Similar to how food products list allergens - might be important to some people.Linus Torvalds also has some vibe-coded stuff for private use that he published. But he also made that clear:
Also note that the python visualizer tool has been basically written by vibe-coding. I know more about analog filters – and that’s not saying much – than I do about python. It started out as my typical “google and do the monkey-see-monkey-do” kind of programming, but then I cut out the middle-man – me – and just used Google Antigravity to do the audio sample visualizer.
Given the first few commits referring to scaffolding phases and the frequent use of em dashes, I’m suspicious this was built with AI assistance. Nothing wrong with that, but a disclaimer of some sort somewhere would go a long way.
Pretty tired of people posting slop they don’t understand.
This is going to break in a few weeks when YouTube changes again. This is such a waste everyone’s of time. Just noise distracting from people who actually understand the things they build.
